Ticket backlog, its formula and how to clear it

To count it, take every request that isn’t solved when you stop for the day. If you closed your laptop on Friday with 30 support emails unsolved, your backlog on Friday was 30. Most support measures count what happened over a period, and a backlog counts what’s still open at one moment, so it’s the one that tells you how far behind you are.

Helpdesks treat it as a snapshot. Zendesk calls your backlog “a snapshot of your unsolved tickets at the end of any given date”, and counts a ticket as unsolved until it’s marked solved or closed. In Jira and Scrum, a backlog is something else, in Atlassian’s words “a prioritized list of work for the development team”. This page is about support requests.

For a founder answering support alone, the backlog is the customers waiting on you while you’re trying to build. Deacon is an AI customer support agent that answers your customers’ questions on your site in seconds, from your own docs, so fewer of them end up waiting, and it has a free plan.

How to calculate ticket backlog

The hard part is deciding what counts as unsolved. Say that at 6pm on Friday you have 30 requests you haven’t solved. 8 are waiting for the customer to reply and 22 are waiting on you, and 6 of those 22 have been open longer than the two days you usually take. About 20 new requests arrive each day.

The same Friday reads as 30, 22, 6 or 150%. Pick one and keep it. Geckoboard also suggests noting how long the oldest request has been open, today’s date minus the day it arrived, since one customer waiting three weeks can hide inside a small number.

Why your backlog is the size it is

A backlog follows from two numbers you probably know already. Little’s law, a result from queueing theory that John Little first proved in 1961, says the average number of items in a system equals the rate they arrive multiplied by the average time each one stays.

If 20 requests arrive a day and each stays open for a day and a half on average, about 30 are open at any moment. Halve the time each one stays open, your average resolution time, and the backlog halves with it.

The second line is the one for a reduction plan. Solve 25 a day while 20 arrive, and a backlog of 30 shrinks by 5 a day and is gone in six days. Solve 20 or fewer and it never clears, however hard the week felt, so the only lasting fixes are solving faster or getting fewer requests.

What is a good ticket backlog?

Few teams publish one. Jeff Rumburg, who runs MetricNet, a firm that benchmarks IT support, wrote for HDI that “it is surprising how few IT support organizations track this metric”, so the data is “somewhat sparse”. His column, read on 23 September 2026, gives approximate targets for IT support teams in the top quarter of the industry, as a share of a month’s tickets.

So a team that gets 200 requests a month would aim for no more than about 15 under 10 days old, 7 between 10 and 30 days, and none older. Tickets past 30 days “are simply not tolerated”, Rumburg writes.

At level 1, the service desk that takes each customer’s first contact, the most common measure is the backlog at the end of the day as a share of a day’s tickets. In Rumburg’s example, a desk that handles 200 tickets a day and ends it with 10 open has a backlog of 5%, and many desks end the day with none, because they solve or pass on every ticket by close.

A backlog of zero isn’t the goal either. “Having a ticket queue of zero isn’t exactly healthy,” a manager on Zendesk’s own support team told Zendesk’s blog, because customers who use a product ask about it.

Why tickets get stuck, and a plan to clear them

When Rumburg asks why a ticket has been open for more than 30 days, these are the answers he hears most. He says they are neither humorous nor hypothetical.

A founder’s version of the plan takes five steps.

1. Count it and sort it by age, using the three bands above. Work the oldest first unless something newer is urgent.
2. Close what’s finished, and chase what’s waiting on the customer on a schedule. Zendesk’s team sends two automatic reminders on a ticket that’s waiting on the customer, a method it calls Bump Bump Solve.
3. Answer by question, not by ticket. Group the requests that ask the same thing and write the reply once.
4. Stop the same questions arriving. Put the answer where customers ask, so the next person never opens a request. Our guide to reducing support tickets shows how to find the questions that come up most.
5. Look at it every week. Rumburg says the mere act of publishing a backlog report often cuts the backlog by 50% or more.

A quick first reply buys time but doesn’t shrink the backlog. “When you’re backlogged with support emails, focus on buying yourself more time by responding rather than resolving,” says Groove’s Len Markidan in Geckoboard’s guide, and that’s fair advice, as long as the request stays on your list until it’s solved.

Ticket backlog vs volume, resolution time and first response time

Fewer customers waiting on you, with Deacon

Much of a founder’s backlog is the same few questions from each new customer. Deacon answers them on your site in seconds, at any hour and in the visitor’s own language, from your own docs, so they don’t join the pile. Nothing waits in a queue for Deacon either. When your docs don’t cover a question, it says it doesn’t know straight away and asks for the visitor’s email, so nobody is left wondering whether anyone read it.

The customers who need you are easy to find. Analytics › Widget has a Waiting for a reply tile that counts the people who left their email in the chat and haven’t had a reply from your dashboard since, however long ago they wrote and whatever date range you pick, with a link to reply to them. It’s the nearest thing to a backlog in Deacon’s dashboard, and it counts differently. It counts people, not requests, and only those who left an email, so a visitor who asked for a person without leaving one isn’t in it, and nor is anything in your inbox. It shows no change on the period before, so it won’t tell you whether you’re catching up. And your first reply takes a person off it, whether or not it settled their problem, where a backlog keeps a request until it’s solved.

Reply in the conversation, and if they still have the chat open, your words appear there under your first name and your company’s. If they’ve gone, your reply goes to the email they left. Until you reply, Deacon keeps answering their other questions.

Deacon keeps a second list, the questions your docs didn’t cover. Filter Conversations by Unanswered, press Answer this on one and write the reply, and it becomes part of what Deacon knows. Save & check asks Deacon the question again and shows you the reply it now gives. If Deacon now answers it, Save & check also tells you how many other open questions your answer covers and takes those off the list too, so one answer can clear several. The more you answer, the less Deacon needs you.

It also shows you where the backlog comes from. Topics group similar questions, count the people who asked and label most groups, for example as a how-to, a bug report or a feature ask. A how-to that keeps coming back is a page to write, a bug report is a fix that stops the requests, and a feature ask is customer feedback about what to build next.

Deacon has no ticketing and can’t see your inbox, so it doesn’t count your backlog. Chatbot analytics walks through the Waiting for a reply tile and the rest of Analytics › Widget, and you can try it on the free plan, which needs no card.