Structuring a Support Team
Structure follows volume and complexity, not ambition. Copying the structure of a company ten times your size is the classic mistake.
By size, roughly
Specialise by knowledge, not by status
Splitting a team into tier one and tier two by seniority produces a queue with extra waiting. Splitting by capability, where tier two has database access or writes code, produces genuine leverage.
The test: if the second tier resolves it by reading the same documentation the first tier has, you have a bottleneck rather than a tier.
The roles worth creating early
Staffing for the curve, not the average
Ticket arrival is never flat. Monday morning and the hours after a release are different from a Friday afternoon, and staffing to the daily average guarantees you are late on the peak.
Look at arrivals by hour and day, then staff the shape. Part-time cover on the peak beats a full-time hire on the average, and it is cheaper.
The headcount question worth asking first
Before adding a person, work out what share of your queue should not exist.
At a tenth duplicates, a team of ten is running nine people worth of real work plus one person permanently occupied by tickets that duplicate other tickets. That is a hire you can avoid making, and it arrives faster than recruitment does. The agents needed calculator shows the difference.
Frequently asked questions
When should we hire a support ops person?+
Around fifteen agents, or earlier if your lead spends more time in helpdesk configuration than in the queue.
Should we use tiers?+
Only when tiers have genuinely different capability. Seniority tiers add waiting without adding resolution.
How many tickets should one agent handle?+
It depends entirely on handle time. Work from productive hours and median handle time rather than a benchmark from another company.
The headcount you can avoid hiring
Removing duplicates returns capacity in the same week, which is faster than any recruitment process.
Start free trial14-day free trial. No credit card required.