When to get on the phone with a customer

I’ve had issues before where TSEs didn’t want to get on a call unless they knew exactly why, what was going on, etc. Yes it’s good to know what the ticket is about before you get on the call, but it’s also important to frame with your team that a call is equal parts customer relationship management as it is troubleshooting. There’s a reason we’re Customer Support, not developers in the back office.

Last week, we had a customer who had a very simple issue, but seemed frustrated & stuck. Instead of directing them to our public docs for the third time, I hopped on a call and talked them through it. They’re not paying us enough to warrant that treatment normally, but the operational time my agents were spending on the back & forth, the emotional duress, and the brand quality made it worth it.

A customer should never leave the product because their support experience was bad. If they’re leaving, it should be despite the quality of our support, and they’ll miss working with our team.

To set your team up for successful troubleshooting calls:

1. We have appropriate details noted on the Account level, maintained by TSEs & Account Managers. So if they’re on-prem, we have notes about what version they’re on, their overall deployment & environment. Also personal details like “Bob is the Kafka expert over there, make sure he’s on any call troubleshooting Kafka”.
2. Hopefully, we’ve got a basic understanding of what’s going on before we get on the call. We try not to bow to “i need to get on a call” as step 1. The correct flow is for a the customer to submit a case with their issue, and we, the csm, or the customer will suggest moving to a call when appropriate. That’s not 100% because there’s always that needy VIP who pays your annual salary every month. But that’s the goal.
3. This is as much about managing expectations & behaviours with the agent as with the customer: a call is not an escalation, it’s a troubleshooting tool. It’s absolutely OK to get on a call to see the behaviour, screenshare as the customer tries out your suggestion, guide them to getting the logs you need, etc. Then you can end the call with “great, that’s what we need to continue investigating on our side. we’ll get back to you with an update within [discrete timeframe].” Or, if your troubleshooting on the call and you get to a point where you’re stuck, where the TSE needs to do some testing, or escalate to eng, you can get off the call to do that, just provide the next timeline steps.

A P1/outage is different of course, but for normal stuff that’s what we should do.

this is part of the overall cultural framing that it’s not us vs customers, it’s us & the customers working together to solve a problem. We’re TSEs because we love solving problems. The customer has done us a favor by bringing us an interesting problem! it’s an opportunity, not a burden.