Efficiency
I’ll be speaking May 6 at the Kustomer Virtual Summit on “The Human Experience of Your Digital Customers.” Come hear my talk and those of other well-known speakers in the CX space.
Efficiency
One of the goals of customer support should be that you’re able to efficiently respond to and solve incoming requests from customers. Customers send emails to an inbox, stand in line outside in the rain, wait on hold for the next available agent, or spar with a chatbot in the hopes of eventually connecting with an actual human. Efficient processing of these queues enables you, as the business, to serve more customers faster, and customers tend to like being served more quickly, so we place a premium on efficiency.
Also, it just feels good? There’s a certain pleasure in knowing your house is in order, that tickets can’t possibly fall through the cracks, that you’re meeting all your service level agreements (SLAs), that you’re not wasting your or the customer’s precious time fighting inefficient systems. At the end of a long day, you want to be able to step back and say, “Yes, we’re in a good place. There aren’t any fires in the inbox. Everyone who needed a response got one. Let’s do this again tomorrow. Time for dinner and a box of wine.”
And so, when it came to building out the support team at FullStory, I did so with an approach of building a system that would efficiently deliver remarkable responsive care to customers. It’s not good enough just to deliver remarkable care to one customer. You have to serve all customers, which means you need efficient systems.
Photo by Brad Stallcup on Unsplash
Go to sleep
One of the earliest hacks I introduced into our help desk to make us more efficient was the ability to put tickets to “sleep” for a specified amount of time so they disappear from the queue and magically show up later.
Why would you want this? Say a customer emails you about a problem that you’re unable to solve on your own. You need to ask an engineer for help, but they’re not available right now, so while you’re waiting to hear back from engineering, you email the customer to let them know the problem is being worked on. Meanwhile, the ticket just sits there in your queue. You can’t solve it—your responsibility to the customer isn’t complete—yet you have nothing to share with the customer, so it just sits there. When this happens with enough tickets, you have the frustrating experience of trying to wade through tickets to find something you can actually work on.
Putting a ticket to “sleep” (we set this up through with a Zendesk Custom Field and Automations) let’s you achieve the following: “I’ve already emailed the customer that we’re working on it and I’m waiting to hear back from engineering. I’m going to put this ticket to sleep for 1 day, and when it reopens I’ll email the customer with what I learned from engineering.” This allows you to set expectations with the customer and keep the queue clean at the same time. Win win!
Oops
One problem with this system is that sometimes engineering gets busy and doesn’t have time to look at the request we send over. No problem. Our system has a way to deal with that. If engineering doesn’t respond and we need a quicker response to the customer, we’ll ping them in a different channel (say, Slack), add a note to the ticket, and put it back to sleep, usually for a shorter period of time so we can make sure we remain responsive to the customer.
Well anyway, I was working on a support ticket this week where I noticed this pattern had happened a few times. Underlying the customer’s request was a complex technical problem, and from reading the ticket, I could see where we had put the ticket to sleep, pinged engineering when it re-opened, put the ticket to sleep, pinged engineering again, etc.
As I was preparing to ping engineering again, I realized we hadn’t checked in with the customer in over a month and half, so maybe we should see if this is still an issue for them? It was at this point that I discovered the embarrassing realization:
Trial Expired 3/20/2020
We had been walking the halls asking for a doctor, yet the patient had been dead on the operating table and we hadn’t bothered to notice. Oops! You would think that with the level of efficiency we have built into our support system, this wouldn’t happen. Nope, we overlooked a pretty critical aspect of supporting the customer, namely, that they exist.
Re-focus
The FullStory support team has many systems in place that keep us highly focused on solving complex customer problems in an efficient manner. It is because of these efficient systems—not despite them—that we lost focus on a rather important aspect of our relationship with the customer, their stage in their journey with us. This was the thesis of what I wrote about last week:
All of us, whether we’re a shareholder or employee at any level within an organization, will necessarily lose focus on the customer. We’ll focus on making sure the company survives, preserving ARR, rightsizing headcount, shipping clean code, getting the support queue down to zero, closing that deal. The importance of that work, whether it actually matters, all depends on whether or not it’s meaningful to the customer.
Systems will always have flaws, which is why it’s so important to consistently take a step back to re-focus on what matters. In my example above, fixing the underlying bug couldn’t have mattered to the customer because they weren’t actually, you know, a customer¹. Reflecting on our failure, we re-tooled some of our support processes to include more information about where the customer is in their journey, which will help us focus more on the customer in the future, and do so efficiently.
Etc.
Things I’ve read:
Zendesk is providing in-app guidance on how to better offer self-service to customers. Here’s a screenshot.
Apparently people working from home has had an impact on account-based marketing (ABM) ad tech.
Mary Meeker’s Coronavirus Trends Report.
Each day I read Matt Levine’s Money Stuff newsletter. It’s excellent.
Hit reply and let me know your thoughts. What stuck with you? What would you disagree with?
¹ There are valid reasons to fix bugs for non-customers: it might impact other customers in the future, it builds goodwill toward your brand to show you fix all bugs, etc. Those are valid outcomes if you have the resources to address those types of bugs in addition to the ones affecting current paying customers.