How to handle customer complaints effectively - Avoid escalation

abdullah-oguk-256739.jpgRaise your hand if a support agent has ever told you, “Let me escalate this to an engineer…”

I think this is a risky tactic for the success of a customer relationship over time. I have an idea how to prevent it and I want to know what you think.

Hopefully you're familiar with our practice of All Hands Support. I'm proposing we take that to the next level with 'All Hands Ownership.'(To be clear: this isn't a new policy that Olark is adopting, just my own idea.)

All Hands Support is a great way to get everyone immediately and continually engaged with the product, but what happens when someone doing support is asked a technical question that's confusing? In an attempt to quickly diagnose trickier issues, or pass them to someone who can give them more attention, or, and I'm being candid here, to avoid embarrassment/frustration because they don't have answers, the discussion goes "up the chain".

All Hands Ownership means each person takes responsibility for owning a support request, responding to the customer at each step and following it through to its conclusion.

And it starts with pushing back against seven words that are entirely reasonable in a difficult customer exchange: "Let me escalate this to an engineer."

How to handle customer complaints effectively - Avoid escalating an issue and forcing the csutomer to deal with multiple customer support departments.

Is this really a problem?

Customer Support teams have long preached managing expectations: under-promise, over-deliver. In "Let me escalate…" (which I and other great colleagues have used), the customer is rightly made to feel special, but it can result in any of these unintended negative externalities:

  • "Escalate" may overstate importance - Why does something need to be escalated just to be looked at by Aaron on the Triage team today? Can I not just ask him? In the vast majority of cases, the word is too strong. (In the dictionary, examples of the word escalate relate to conflicts, tensions, violence, salaries and fuel prices.)
  • "Engineer" has certain connotations - When your cable company books an engineer, they arrive and fix an issue. There's no relationship, just a gun-for-hire to fix the reported problem and move on.
  • You immediately commit someone else to an issue - Worse, because the word escalate was used, you've set the clock ticking for Madalyn. Madalyn's already busy, thanks.
  • Expectations are reset for future requests - If a customer knows they can get an escalation to an engineer this time, they may be more likely to want to bypass Nick in the Support team next time.
  • Lost knowledge - Every time a ticket is passed to someone else, there's a good chance there will be a lost transfer of knowledge with the lack of a feedback loop.
  • Gives the impression of stratified support - The perception can be that frontline customer service acts as gatekeepers to Engineers, Managers or Business Development personnel. We often experience the "Could you ask your boss…", "Do you have a number for…" and "Tell this to your engineer…" instructions that imply a tiered system of helping.
Sometimes people don't understand who they're speaking with on live chat. Maybe it's the person who wrote the software. In their mind, they're dealing with the monkey and not the organ grinder.

For the last point, we've seen this in practice. We have transcripts where customers have asked for an engineer, not knowing they're already chatting with the person who wrote the software. In their mind, they're dealing with the monkey and not the organ grinder.

What are the benefits of All Hands Ownership?

Instead of moving a ticket to someone else, take ownership of it from beginning to end. Even if you know you don't understand, you can help the customer. Consider the empathy in this alternative to "Let me escalate...":

"Oh, you're right, that is strange. How about I find out what's going on here when I'm free this afternoon and get back to you as soon as I can?"

You might still involve the engineer (which is fine, expected) but instead of passing the issue on, you can synthesize what you're told and relay that to the customer. Suddenly there emerges a new set of possible consequences:

  • The customer doesn't need to re-explain themselves to another person on the Triage team.
  • You can improve your own understanding over time. 
  • You can match the customer's terms and tone in reply. Often, an engineer is only working off case notes and reproduction steps that dehumanize the process.
  • It's personal, you buy everyone time and reset customer expectations.
  • By admitting you don't know, you're putting yourself on a level with the customer. It helps create empathy. We’re in this together. Not us and them.
  • It moves the conversation away from simply fixing issues, but rather addressing problems.

This last point is subtle. All Hands Ownership isn't about making everyone more technical. Instead, we should look to engage with the customer. "What is it you're trying to do?" might get you to the heart of a customer problem in a more effective way than "What is happening?" – until you know what the customer's intentions and expectations are, you'll forever be fixing without necessarily improving.

How does it work in practice?

  1. Ben has a tricky chat but promises to look into it for the customer.
  2. Ben doesn't quite understand the issue described, but that's fine - he just asks the customer what they were trying to do, how long it's been happening, what evidence do they have of it happening and so on.
  3. Ben asks Aaron, who's working on the Triage team this week.
  4. Aaron's answer was solid, but pretty technical. Ben tries to make sense of this, and relays it to the customer.
  5. With the info Ben collected, Aaron can create a comprehensive bug report.
  6. Ben follows up with the customer to know that we're working on the issue and will update with any info.
  7. Once the bug is fixed, Aaron lets Ben know what the fix was. It's not something Ben would've figured out on his own, but Aaron's answer makes sense. Ben's learned something and closes out the ticket by letting the customer know it's been resolved.

While perhaps a quaint example, by changing the way we answer tickets, we could start to recognize patterns even when we don't understand the issue. Over time, the person answering the chat has a better understanding not just of technical questions, but also the benefit of engaging with a customer over several interactions.

All Hands Ownership, much like All Hands Support, would take time. It will not always be appropriate and will be frustrating. It is however intensely satisfying to learn and always appreciated by customers.

Check out relevant topics on: Customer Support

Joe Westhead

Read more posts by Joe Westhead

Chief Brit Joe has helped our support team remotely from the UK, Germany, Armenia and the US. Different timezone, same tea-time observance.