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."
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:
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:
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.
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.