847 Open Tickets and a Team of Four

That was the situation when a SaaS company's head of support messaged me. They'd gone through a product launch, hired two new agents mid-launch (who needed training), and had a billing migration that generated unexpected tickets. Three problems hit at once, and in six weeks their backlog went from manageable to terrifying.

If you're staring at a similar number, the instinct is to just start answering tickets as fast as possible. That's the wrong move. Speed without triage means you'll spend 20 minutes on a ticket that could've been closed in one, while a paying customer with a critical bug waits another day.

Here's the plan that got that team from 847 to 0 in 11 days.

Day 1: Triage Everything

Don't answer a single ticket on day one. Spend the entire day categorizing. You need to know what you're dealing with before you start working through it.

Create four buckets.

P1 is revenue-impacting or blocking. Customers who can't log in, can't process payments, or have a production outage. These get answered today, even during triage. If someone's business is broken, they can't wait.

P2 is frustrated but functional. The customer has a problem and is unhappy, but their core workflow isn't blocked. Feature not working as expected, confusing UI, billing discrepancy.

P3 is questions and requests. How-do-I, feature requests, general inquiries. Important but not time-sensitive.

P4 is already resolved or duplicate. The customer figured it out, another agent already replied in a different channel, or it's a duplicate of another ticket. These are pure closures.

For 847 tickets, one person triaging full-time can categorize about 200-250 per day using subject lines and first messages. If you have a tool that auto-classifies intent, this goes 3-4x faster. Supp's classifier handles this at $0.20 per message and maps tickets to 315 intents, so your P1/P2/P3 sorting is mostly automated.

When the team finished day one, here's what they found: 127 P1, 289 P2, 318 P3, and 113 P4. Almost 13% of their backlog was already resolved or duplicate.

Days 2-3: Close the Dead Weight

Start with P4. Every ticket that's a duplicate gets merged with its parent ticket. Every ticket where the customer already found a solution gets a quick note: "Looks like you got this sorted. Closing this out, but reopen anytime if you need help." Every ticket older than 30 days with no customer reply gets: "Following up on this. If you still need help, just reply and we'll jump back in. Closing for now."

In two days, the team closed 113 P4 tickets and another 89 stale tickets from P3 that had gone cold. That's 202 tickets gone without writing a single troubleshooting response. Backlog: 645.

Days 4-5: P1 Blitz

Now the real work starts. Your entire team focuses on P1 tickets. Nothing else. P2 and P3 wait.

The trick with P1 tickets: many of them share a root cause. That billing migration generated 47 nearly identical tickets about failed charges. Instead of writing 47 individual responses, write one thorough response, then batch-apply it with personalization (customer name, specific charge amount, date).

Batching by root cause cut the P1 queue in half in one day. The remaining P1 tickets were unique issues that needed individual investigation. Those took another full day.

End of day 5: 0 P1 tickets. Backlog: 518, all P2 and P3.

Week 2: Steady Burn Through P2 and P3

With the urgent stuff gone, you can set a sustainable pace. Assign each agent a daily target. For a team of four handling P2 tickets, 15-20 resolutions per agent per day is reasonable without sacrificing quality.

P2 tickets took days 6-9. Some required back-and-forth with customers, so not all closed immediately. But first responses went out on all of them.

P3 tickets (questions and feature requests) are fastest to handle. Many can be answered with links to documentation, canned responses, or quick one-paragraph answers. Days 10-11 cleared the rest.

Day 11: backlog at zero. Total elapsed time from 847 to 0: 11 working days with a team of four.

Why Backlogs Happen (and How to Prevent Them)

Backlogs rarely come from a sudden spike alone. They come from a spike hitting a team that was already at capacity. Here's what creates the conditions.

No triage system means agents work tickets in the order they arrive. A password reset and a production outage get the same priority. The outage customer churns while the password reset customer got help in 10 minutes.

No self-service options force every question through a human. If 30% of your tickets are "how do I reset my password" and you don't have a self-service flow, you're paying an agent $25/hour to do what a help article could do for free.

No proactive communication during incidents means every affected customer files their own ticket. One incident generates 50-100 tickets that all say the same thing. A status page or in-app banner prevents most of them.

Agent attrition without backfill is the silent killer. When a team of five loses one person and doesn't hire for two months, the remaining four absorb 25% more volume. They burn out. A second person leaves. Now three people are doing the work of five, and the backlog compounds daily.

Using AI to Prevent the Next One

The classification step is where AI pays off fastest. Instead of a human reading every ticket to decide its priority and category, an AI classifier can do it in under a second.

With Supp, incoming tickets get classified into specific intents and routed automatically. Refund requests go to your billing team. Bug reports go to engineering support. General questions get matched to help articles. At $0.20 per classification and $0.30 when it resolves the ticket automatically, it's cheaper than the five minutes a human spends triaging each message.

The batch-response technique from day 4 also scales with AI. When 40 tickets share the same intent (like that billing migration scenario), an AI tool can draft a response template and an agent reviews and sends it. The human is still in the loop. They're just not typing the same paragraph 40 times.

The Maintenance Schedule

Once you're at zero, stay there. Check these numbers weekly.

Tickets opened vs. closed: if opened consistently exceeds closed, you're building a backlog whether you notice it or not. Average time to first response: this creeps up before the backlog becomes visible. If it's growing, act before tickets pile up. Tickets per agent per day: if this number is rising without new hires, you're approaching a breaking point.

A backlog is a lagging indicator. By the time you see it, the underlying problem has been running for weeks. Watch the leading indicators instead.