Let’s do some napkin math on wait times and wait distribution among customers using an email or ticket-based support system. Here are the big assumptions I’m carrying into this one:
- There are enough tickets and customer support staff that averages work out as expected over time without major aberrations
- Staff is sufficiently well trained that each staffer can answer any particular ticket in the same amount of time
Wait time, defined here as the period of time between when a customer submits a ticket (or email), and when a staff member responds to it, is something on the forefront of anyone providing customer support in the world today. This is something cafe operators think about, this is something Operations Managers obsess over, it’s a really fun problem to chew on and try to figure out.
In this particular context, we have some flexibility that organizations like Subway lack – we get to choose the order in which we respond to our inputs. At Subway, you help the next person in line. It would be nice to group all of the meatball subs together, but that isn’t the way that their model operates. There are lots of ways we can batch incoming tickets – by difficulty, by product, by language, but the only kind of batching that I’m thinking about today is batching replies by ownership.
What do I mean by ownership? For this particular post, I’m thinking of ticket ownership in this way: once a ticket has been replied to once, it is owned by the operator that replied. That’s all. Once a ticket has a response from The Company and is awaiting a new reply from the Customer, that ticket and its ongoing conversation is owned.
The goal of ticket ownership is to ensure that customers who have created a relationship, whose tickets are owned, get priority. You respond to tickets that you already own first, before going on to new, unanswered, unowned tickets. There is a long history of hospitality leading customer interactions in this way – restaurants don’t usually switch up your waiters mid-meal, right?
I’m going to bastardize some operations management tools to work on this – namely a little bit of process diagramming. Here’s how a process diagram works:
Squares are customer activity, triangles represent wait time. Interactions from the customer side are fairly simple: you submit a ticket, you wait for a reply. When you hear back, you reply again, and wait some more. This goes on until your issue is resolved. From the support side, this would be much more complicated; seeking answers from developers, doing some research, etc etc.
Here’s a fact about support: without bringing in additional staff, making big changes to your training or management systems, or changing your approach in other ways, your average response time is going to stay pretty much static from day to day. When we look at response systems like ticket ownership, we aren’t really talking about decreasing our average wait time, but rather changing the way that it’s distributed. Let’s consider three approaches:
A.) Support staff reply first to tickets which they own, then move on to new tickets.
B.) Support staff ignore ownership, and reply to the tickets experiencing the longest wait time regardless of previous replies.
C.) Support staff ignore ownership, and reply to tickets experiencing the shortest wait time regardless of previous replies.
There are arguments for each of these, and there are many more ways we could break down the approach, but let’s focus on just these three.
Here’s what these would look like (roughly) diagrammed:
Or, a terrible graph:
We can see that what we’re really doing is simply moving our wait times around; approaching online support through ticket ownership is a way of front-loading our wait time – essentially saying “Once we get to you, we’ll reply more quickly.” It’s not obvious to me that this is the very best way to approach this. It seems like each of these approaches could be equally valid, at least in the abstract, and I can see arguments for all of them.
The good news is that we can experiment! Every support department should have a feedback mechanism through which their customers can close a feedback loop. I encourage you to mix up your approach – spend a month using Approach B rather than Approach A – or, if you really want to mix it up, give C a try. Be careful with C, as if you aren’t able to clear all of your tickets every day, your oldest tickets will become asymptotic to the wait time axis, and that’s not good for anyone.
Give it an honest shake; try to reserve judgment as to how the system is working – you’re iterating and collecting data, after all – and, and the end of the month, compare your feedback numbers. Let the data speak for itself – if nothing else, you and your team will have shifted mindsets about how to approach the question of wait time distribution.