Before you hire more support engineers, look at your triage
When the queue keeps growing, headcount is the obvious answer. It’s rarely the first one to try.
The pattern is familiar. The ticket queue grows faster than the team. Response times slip. The best people start spending their days on password resets and duplicate bug reports. Someone opens a headcount request.
Sometimes that’s the right call. But hiring into a broken flow mostly gives you more people stuck in the same flow. Each of them also takes longer to onboard. Before adding capacity, it’s worth checking where the current capacity goes.
Know what’s actually coming in
Start with the inbound. Take a representative sample of recent tickets (a few hundred is usually enough) and categorise them by hand. Not by the tags agents picked under pressure; by what the customer actually needed.
You’re looking for a few things:
- Repeat questions that documentation, in-product copy or a better error message could answer.
- Bugs reported many times by different customers, each handled as a separate ticket.
- Tickets that shouldn’t exist: requests caused by a confusing flow, a missing self-serve option, or a status page nobody updates.
- Work that isn’t support work: tickets that are really feature requests, sales questions, or engineering tasks parked in the support queue.
Each one frees up capacity without a single hire.
Route on first touch
The second place capacity leaks is routing. If every ticket lands in one shared inbox and gets picked by whoever is free, your most experienced people end up handling easy tickets, and hard tickets bounce between people until someone senior grabs them.
A tiered model fixes this when it’s kept simple:
| Tier | Handles | Escalates when |
|---|---|---|
| L1 | Known questions, account issues, anything with a documented answer | The answer isn’t documented, or the issue needs investigation |
| L2 | Investigation, reproduction, workarounds, bug triage | A code or infrastructure change is needed |
| Engineering | Fixes, with a clear owner per product area | None |
The rules that matter more than the tiers themselves: clear escalation criteria, a named owner on the engineering side for each area, and a feedback loop so that every escalation that could have been solved lower down turns into documentation or training.
Make engineering handoffs cheap
Escalations to engineering are where tickets go to wait. Usually because the handoff is expensive on both sides: support doesn’t know what information engineering needs, and engineering doesn’t know which escalations are urgent.
Agree on a short escalation template: impact, reproduction steps, account or request IDs, what was already tried. Agree on a severity scale too, one that both teams use the same way. Then give escalations a visible SLA, so everyone can see how long things wait. Nobody gets punished for it.
Then size the team
Once the inbound is cleaned up and routing works, staffing becomes a real question with real data: volume per category, handle time per tier, coverage hours you actually need. That’s a sizing model you can defend, instead of a feeling that the team is underwater.
Sometimes the answer is still “hire”. But now you’re hiring into a flow that works, and the new person gets to do the job they were hired for.