Field notes · 9 min read
Beyond Ticket Closing: Building a Scalable Technical Support Organization from the Ground Up
Most technical support teams do not fail because the engineers are weak. They fail because heroics never scale. This is how I have watched a 2-person shop grow into a 10+ person, 24/7 operation — starting from an ISP startup where every outage was personal.
Why most support teams stall
At two people, everything works because both engineers know everything. At five people, the cracks open — nobody documents anything, two engineers solve the same ticket in incompatible ways, the on-call rotation is really just one person who never sleeps. The team looks productive. The metrics say otherwise.
Scaling a support organization is not about hiring faster. It is about replacing tribal knowledge with repeatable processes before the tribe runs out of oxygen.
Phase 1 — The 2-person heroics stage
Two engineers, shared inbox, everything is a P1 because everything might be a P1. This stage is fine for a while and dangerous if it lasts.
- One ticketing system, one queue. Not email, not Slack DMs — an actual ticket ID for every issue
- A shared runbook, even if it is a single markdown file. Every recurring fix goes in it the day it happens
- Basic monitoring: uptime for the top three customer-facing services, alerts routed to a shared channel — not to one person's phone
- A written on-call rotation, even if it is just 'A on odd weeks, B on even weeks'
The single biggest phase-one mistake: treating documentation as something you write later. There is no later. If it is not in the runbook, it did not happen — and the next engineer relearns it from scratch at 3 a.m.
Phase 2 — First real processes (5 people)
Around five engineers, informal breaks. This is where you introduce the smallest useful slice of ITIL — not the certification, the practices.
- Incident management: severity levels (P1 / P2 / P3), response and resolution SLAs, a defined escalation path
- Change management: any production change goes through a lightweight change record — who, what, when, rollback plan
- Knowledge base: separate from the runbook. Customer-facing solutions live here, categorized and searchable
- Weekly incident review: 30 minutes, every Monday, what broke and what will stop it from breaking again
- A dedicated 'firefighter of the week' role so the rest of the team can do project work without interrupt overhead
The point of process at this stage is not bureaucracy. It is giving the team a way to say no to interruptions without saying no to the customer.
Phase 3 — Tiered support (10+ people)
Ten people is where you finally get to specialize without losing coverage. Tiers stop being a job description and start being a workflow lane.
Tier 1 — triage & fast fixes
First response inside SLA, resolve known-issues from the knowledge base, escalate anything unfamiliar with full context attached.
Tier 2 — deeper diagnostics
Systems engineers who own recurring problems and write the runbook so tier one can close them next time. Also the on-call layer.
Tier 3 — engineering & vendors
Root-cause analysis, product bugs, vendor escalations. Small team, high leverage, protected from ticket noise.
24/7 coverage
Follow-the-sun where possible, structured overtime where not. On-call compensation is a real budget line — not a favor.
Where automation actually pays off
Automation is the multiplier that lets 10 people cover the workload of 20. But it works only where the underlying process is already clean.
- Ticket routing: auto-tag by customer, product and severity so tier one is not manually triaging every P3
- Remote troubleshooting scripts: one-click collect logs, restart the service, verify — instead of typing the same commands every time
- Health-check automation: nightly probes of the top 20 customer-affecting integrations, alert only when something regresses
- Password / access resets: self-service portal for the top three most-requested actions
- Post-incident: auto-open a review ticket for every P1, auto-attach the timeline from the alert system
Never automate a process you have not run manually at least a dozen times. If you do not understand the failure modes, you are just automating the outage.
Metrics that matter (and ones that lie)
Number of tickets closed is a vanity metric — it rewards churn. Track the ones that actually reflect customer experience and team health:
Time to first response
How long before a human touched the ticket. Cheap to game, but honest when combined with resolution time.
Time to resolution by severity
Broken out by P1 / P2 / P3. A creeping P2 trend usually predicts a P1 spike two months later.
Repeat-ticket rate
How many issues came back within 30 days. High repeat = you are closing tickets, not fixing problems.
Backlog age
The oldest ticket in the queue. Nothing exposes a broken process faster than a ticket that has been open for 90 days.
On-call incident count
How many times someone was paged outside business hours. Trending up = burnout coming.
FAQ
When should a startup formalize its support team?
The moment a single person cannot hold the on-call phone for a whole week without something dropping. In practice that is around 3 to 5 engineers or the first time you miss an SLA because everyone was firefighting the same incident.
Do I need full ITIL from day one?
No. Full ITIL kills small teams. Pick three things: incident management, change management and a basic knowledge base. Everything else waits until you have the people to run it.
Tier 1 / Tier 2 / Tier 3 — is that model still relevant?
Yes, but not as a career ladder. Treat tiers as workflow lanes: routine issues resolved fast on tier one, engineering-heavy work escalated to tier two, product or vendor work on tier three. People rotate between them.
What is the fastest way to burn out a support team?
No documentation. Every ticket becomes original research, every engineer is a single point of failure, and the same problem gets solved five different ways. Documentation is not overhead — it is the difference between scaling and drowning.
How much automation is too much?
Automate the boring, repeatable and safely-reversible. Leave the judgement calls to humans. If your automation deletes production data with no approval step, that is too much.
Key takeaways
- Documentation is not overhead — it is the difference between scaling and drowning.
- Introduce ITIL practices in the smallest useful slice: incident management, change management, knowledge base.
- Tiers are workflow lanes, not a career ladder. People rotate between them.
- Automate only processes you already understand end to end.
- Measure repeat-ticket rate and backlog age — they expose broken processes faster than any dashboard.
Related reading: my Gigabit / Wizer tenure, network infrastructure and automation expertise, and more infrastructure deep-dives.
Building or restructuring a support organization? This is exactly the work I do.
Let's talk →