What I really wanted the headline to be is “Call Center Queues – You’re Probably Doing Them Wrong (and It’s Not Your Fault).”
There’s no place where a call center can hang itself as with queue configuration. In fairness, I have to lay most of the blame on the vendors, as most of them make it opaque, to say the least. All their queues work similarly, but you’d never know it by reading about them. They’ll talk about vectors, MRDs, Exempt Held Interactions, Dynamic Prioritization, and the like. What they unfailingly do is neglect to provide the basic concepts that you can relate to.
It’s impossible to underestimate the impact that some seemingly minor queue changes can make. At one customer I was working with, their queues were set up as well as the typical call center, that is they followed call center queue design “best practices”.
The queues were consistently getting badly backed up. Before embarking on wholesale queue restructuring, we started by making two safe changes that I thought would provide a little immediate relief.
And the results were PROFOUND. My jaw literally dropped when I saw the results. The restructuring turned out to not be necessary, so nothing had to change in the operation at all. The long wait times and abandons went away almost entirely. I realized then that I, and I daresay most people, aren’t looking at this the right way.
What were those two things? You’ll have to wait for a few posts to find out. First, I need to lay on some learnin’ on ya. Apologies if some of it seems really basic – but it’s the basics where we’re going wrong.
Why Do We Need Queues?
If you had an infinite number of agents, and they were all equally good at handling all types of customer issues, it would be easy. You would just give the call to any agent that wasn’t currently on a call. But this isn’t the case. So, we use queues because:
- We don’t have an infinite number of agents
- Most agents are not equally good on all types of calls
AND THAT’S IT. The queue is where the customer waits for a free agent that is able to handle their concern.
For Now, Accept This, and I’ll Explain Better Later
The more agents on a queue, the better that the queue will behave. Using a fast food analogy, imagine that you have 1 server serving 3 people, or 4 servers serving 12 people. One slow person won’t block everyone else. Our phone queues behave the same.
This is important, so repeat after me, “The more agents on a queue, the better the queue will behave”. For bonus points, “The less agents on a queue, the worse the queue will behave”.
So agents, being imperfect humans, aren’t equally good at each type of call. If we’re going to match the call to the agent, we need a way of classifying our calls. With standard call center systems, there are 3 ways this is commonly done:
- Through IVR selection (“press 1 for sales, press 2 for service”). This is the main mechanism.
- By having the customer dial a number that reflects their request (1-800-GETEDAM vs. 1-800-CHEDDAR)
- By looking up the customer in the IVR, and then classifying it by something in their customer record (Platinum vs. Silver customer status)1
If we’re matching a call to an agent’s ability to handle it, this is what we have to work with.
Scary, Non-Obvious Statement
So here’s a scary, non-obvious statement. Your IVR will affect your wait times and/or your staffing levels.
What? Are you kidding me?
Dead Serious. Your IVR is the main method of classifying calls into buckets. So, your IVR is indirectly deciding what agent will get the call.
If the classification is too granular (fancy way of saying “too many buckets”), then you’ll need too many queues, and each queue will have too few agents. The less agents on a queue, the worse the queue behaves. And, I’ve absolutely seen call centers that define one queue per IVR selection.
If your classification is too broad, then you’ll have agents on that queue that aren’t good at handling some of the calls. This means that those calls will go long, or worse, the agent won’t solve the customer’s problem – causing the customer to call back (more calls!).
I’m sure there are readers out there protesting at this statement. And yes, there are ways of mitigating the negatives of poor IVR classification.
But, I’m willing to bet that few were thinking about staffing levels when they were designing their IVR.
More to come.
1The best way of identifying the customer is by having them enter their customer identification in the IVR (customer number, credit card, etc.). Often, contact centers want to use the phone number that the customer called in (ANI or CLID) on to match to the customer record. In practice, phone number match reliability is too low to make it worthwhile.