What is a reasonable ticket backlog?
We hadn’t even posted How to prioritize tickets in software companies, and our colleagues were already telling us, “talk about backlogs; those are the real pain in the neck.” So here it is, as a holiday special!
To put numbers in perspective, we want to share a story that someone in our group likes to tell: A man walks into a bakery and asks for a baguette. The lady behind the counter says: “Sure. But I must tell you, the baguettes were baked yesterday.” To that, the man replies by asking for a few buns, and the lady tells him those were also baked yesterday. The man changes his mind and asks for the nice-looking loaf of bread he sees on the bottom shelf, but to his dismay, he is told that the loaves were also baked a day earlier. Irritated, he asks: “Well, what do I have to do to get some bread that was baked today?”. And the lady gently replies: “Just come back tomorrow.”
It’s relatively common to see the same thing happening in software companies. With tickets, not bread!
Software companies quickly learn that they must match the workforce to ticket demand. Do we get 800 tickets a week? Does each person close 20 tickets a day? Then we need eight people. Bingo! They understand there is no reason to allocate nine people, and they also know that seven people will not be enough to address the demand they measured. However, we often see companies with seemingly balanced workforces coping with huge backlogs, which greatly hurts productivity, communication, and customer services.
“What do tickets have to do with bread?” you may be thinking. Let’s say the numbers above apply to a company that has been dealing with a not-so-rare backlog of 2,400 tickets (bugs, unanswered questions, intermittent issues, etc.). It would take three weeks with no new tickets for the team to address the whole backlog. But that never happens, so in theory each new ticket would wait three weeks to be serviced and closed. But that’s not the case either. Daily, higher priority tickets are addressed first, some low priority tickets are addressed when customers become impatient, and most hot issues are addressed in less than three weeks.
And if that is the case, then a lot of tickets take far more than three weeks to be serviced. Which means that even though the company has allotted eight people to do the daily job—enough to address the daily volume of incoming tickets—the company still takes around three weeks on average to serve its customers. It’s like baking the right amount of bread every day, but always selling stale bread.
An interesting rationalization that we hear about this scenario is that “at least customers have their high priority tickets serviced fast.” In these cases, we see simple, low priority tickets being closed two or three months later—many with a solution as simple as “this is not a bug, you just had that configured wrong,” to which the customer replies, “and it took you two months to tell me that?”
As we can see, there really are no prioritization processes or classification policies capable of providing good customer services when dealing with large backlogs. The remedy? Just as the bakery has to sacrifice a day’s worth of bread to start selling freshly baked bread, a software company must spend to put together a task force if it wants to get rid of its ticket backlog.
Companies often postpone these task forces because of the business disruption of this effort. However, they don’t take into account the amount of rework that a backlog itself generates: support agents apologizing for delays, delicate email replies, follow-up calls, developers interrupted to switch to another “urgent ticket,” and so on. In fact, in the above example, perhaps seven people—not eight—might be enough to address the daily incoming ticket volume if there is no backlog.
To answer the question posed in the title: we like measuring backlogs in days. For example, if you have 1,000 tickets in your backlog and your team closes 100 tickets each business day, then you have a backlog of 10 business days. This means your customers see their tickets closed on average after 10 business days or more, which is the number we like to analyze. Is it reasonable? Is it too long? Could it be less?
You probably don’t want to try to keep your backlog at zero, as there will be items in process or work on a complex issue that may leave a few simple issues standing by. But in most cases not tackling a backlog and letting customers wait for more than a couple of days is not the best business decision to make. If you want to provide your customers with great customer service, stop selling stale bread!
Agree with the above? Have a different opinion? Have a particular issue with it and would like to exchange some ideas? Lived through an interesting experience? Please leave a comment! We’ll be happy to learn or share more information and insights about the topic.