# How to Cut a Ticket Backlog Without Hiring

> How to reduce ticket backlog without hiring: measure the excess, find where it sits and use six levers to make the queue shrink every day.

Source: https://clarivoxx.com/articles/how-to-reduce-ticket-backlog · Author: Abdessamad Ghanem · Clarivoxx · Customer Support · Updated 2026-05-28

Here is how I cut a ticket backlog without hiring. A ticket backlog shrinks only when your team resolves more tickets per day than it receives, so the way to reduce ticket backlog without hiring is to turn that daily balance positive: clean out stale and duplicate tickets, then cut repeat contacts and wasted time until resolved beats new. In the example below, a team with 830 excess tickets gets back to a healthy queue in about 27 business days with the same headcount.

The [free ticket backlog calculator](https://clarivoxx.com/tools/ticket-backlog-calculator) runs these numbers for your own queue. In Part 1 we covered [how to improve first contact resolution](https://clarivoxx.com/articles/how-to-improve-first-contact-resolution), which stops tickets from coming back. This part is about what to do when they have already piled up.

## When is a ticket backlog a problem?

A team that gets 300 tickets a day and solves them within 2 days will always have several hundred open. That is work in progress, not a backlog problem. The number that matters is **excess backlog**: the tickets beyond what you can solve within your target time.

## How do you calculate excess backlog?

```
Daily backlog change = New tickets per day − Resolved tickets per day
Healthy queue        = New tickets per day × Target resolution days
Excess backlog       = Open tickets waiting on the team − Healthy queue
Days to clear        = Excess backlog ÷ Net daily burn

Open tickets waiting on the team = exclude tickets pending a customer reply
Net daily burn                   = Resolved per day − New per day
                                   (only meaningful when it is positive)
```

The healthy queue line is Little's law from queueing theory: the average number of items in a system equals the arrival rate times the average time each item spends there. If you want tickets solved in 2 days, a queue of 2 days of arrivals is normal.

## What does a growing backlog look like in numbers?

Say a team of 11 agents gets 310 new tickets a day and resolves 290. There are 1,450 open tickets waiting on the team, and the target is 2 business days.

| Step | Calculation | Result |
|---|---|---:|
| Daily change | 310 − 290 | **+20 a day** |
| Healthy queue | 310 × 2 | 620 |
| Excess backlog | 1,450 − 620 | **830** |
| Days to clear | 830 ÷ (negative burn) | never |

The queue is growing, so it will never clear on its own. The reflex is to hire. One more agent adds about 26 resolutions a day. The levers below look for that capacity inside the team first. Enter your own four numbers in the [backlog calculator](https://clarivoxx.com/tools/ticket-backlog-calculator) before you decide.

## Where does the backlog actually sit?

Split open tickets by age, then by status and category.

Tickets under three days old are normal flow. Those older than a week are usually duplicates of one incident, tickets waiting on engineering, silent customers and a few hard cases nobody owns. Here 240 of the 1,450 tickets, about 17%, are older than a week.

![How to Cut a Ticket Backlog Without Hiring — A photorealistic scene in a dark navy modern office with teal accent lighti](https://clarivoxx.com/article-images/customer-support-is-a-sales-skill.jpg)

## How do you reduce ticket backlog without hiring?

1. **Purge and merge.** Close tickets pending a customer reply after two reminders over 7 days. Merge duplicates into one problem ticket. In the example this removes 180 tickets.
2. **Cut repeat contacts.** The FCR levers from Part 1 lower incoming volume, here by about 15 tickets a day.
3. **Move bug tickets to a problem record.** This is the ITIL idea of problem management: one record for the root cause, linked to every ticket it creates. Update customers when the fix ships and close them together.
4. **Write macros for the top 10 contact reasons.** Tested replies add about 15 resolutions a day.
5. **Protect queue time.** Meetings and admin eat hours. Measure them with the [shrinkage calculator](https://clarivoxx.com/tools/shrinkage-calculator). Getting back 3.5 team hours a day at 14 minutes per ticket adds 15 resolutions.
6. **Work oldest first.** Sort by age within each priority and hold a short daily block where the whole team clears the oldest tickets.

Now incoming falls to 295 a day and resolutions rise to 320, so net burn is **+25 a day**. The healthy queue is 295 × 2 = 590. Open tickets after the purge are 1,450 − 180 = 1,270, so excess is 680. Days to clear: 680 ÷ 25 ≈ **27 business days**, a little over five weeks.

![How to Cut a Ticket Backlog Without Hiring — A photorealistic scene of a B2B support team gathered around a table in a d](https://clarivoxx.com/article-images/data-improves-customer-support-and-sales.jpg)

## What I've seen in practice

After one release, the backlog on a team I worked with nearly doubled in a week and everyone assumed we were understaffed. When we read the oldest tickets, about a third were the same booking-sync error reported by different hotel partners. One problem ticket and one status update cleared most of them in a day.

The mistake I would not repeat is a bulk close to hit a number. The chart looks great for a week, then the same partners write again, less patient. Close only what is truly stale or duplicated.

The other lesson: count only tickets waiting on your team. When "pending customer" tickets sit in the same count, the backlog looks bigger than it is and nobody can tell which part is yours to fix.

## What does a 30-day backlog recovery plan look like?

- **Week 1:** separate waiting-on-team from pending tickets, publish the age profile, run the purge and start a daily chart of new versus resolved.
- **Week 2:** create problem records for open bugs, write the top 10 macros, fix intake forms.
- **Weeks 3 and 4:** block queue time on calendars, run the daily oldest-first block, review net burn every morning.

Keep the daily chart afterwards, and restart the plan if open tickets stay above 125% of the healthy queue for three days. If net burn stays negative after every lever, the gap is real. The [Erlang calculator](https://clarivoxx.com/tools/erlang-calculator) helps you build the hiring case with evidence.

## The backlog dashboard for the weekly review

Next to the daily chart, I keep a weekly table so the trend is clear at a glance. These are the example team's numbers before any lever starts, with targets from the plan above.

| Metric | Target | This week | Last week | Change |
|---|---|---|---|---|
| New tickets per day | 295 | 310 | 302 | +8 |
| Resolved per day | 320 | 290 | 288 | +2 |
| Daily backlog change | −25 | +20 | +14 | +6 |
| Open, waiting on team | 590 | 1,450 | 1,350 | +100 |
| Excess backlog | 0 | 830 | 746 | +84 |
| Share aged 8+ days | 5% or less | 17% | 15% | +2 pts |

Start with the daily backlog change. While it is positive, every other row gets worse, so the purge and the macros come before anything else.

## What to do this week

Split today's open tickets by age and read the twenty oldest. Then start a daily chart of new versus resolved tickets and share it every morning.

## Frequently asked questions

### What is a normal ticket backlog?

Roughly your daily incoming volume times your target resolution time in days. A team receiving 300 tickets a day with a 2-day target will normally have about 600 open.

### Should tickets waiting on the customer count in the backlog?

No. Keep them in a separate status. They are not waiting on your team, and mixing them in hides the real queue.

### Is it OK to bulk close old tickets?

Only tickets that are truly stale or duplicated, with a reminder first. A blind bulk close brings the same customers back angrier.

### When should I hire instead?

When net daily burn stays negative after you have purged, merged, cut repeat contacts and protected queue time. At that point the gap is capacity, not process.

## Sources

- [Little's law](https://en.wikipedia.org/wiki/Little%27s_law), Wikipedia
- [Problem management in ITIL](https://www.atlassian.com/itsm/problem-management), Atlassian