Why triage, not resolution, is the bottleneck at scale

When a queue degrades, the instinct is to look at resolution: fixes are taking too long, so add capacity. Watch where the hours actually go and a different picture emerges. Time-to-fix is often reasonable once someone is working the right ticket. The delay is upstream, in the step where somebody decides what each item is, how bad it is, and who owns it.

Triage is the bottleneck because it has three properties that resist scaling, and because it consumes exactly the people you least want spending their day on classification.

Resolving a ticket needs depth in one area. Triaging one needs breadth across all of them: enough familiarity with every system to recognise which is involved, enough history to know whether this has happened before, and enough judgement to price the impact. That combination lives in a small number of senior people.

So triage concentrates on the individuals whose time is most valuable and whose absence is most disruptive. Every organisation that runs triage informally has discovered this the same way — the queue quietly degrades during one person’s holiday.

Resolution parallelises cleanly: ten engineers work ten tickets. Triage does not, because part of its job is comparing the new item against everything already open. Two people triaging independently create duplicate tickets for one incident, split its evidence across both, and neither notices.

That forces triage into a single-threaded stage in front of a parallel one, which is the textbook shape of a bottleneck. It is also why adding people to triage produces sub-linear returns and, past a point, negative ones.

Every downstream number inherits triage quality. Priority set inconsistently makes SLA reporting fiction. Categories assigned by mood make trend analysis noise. Misrouting adds a full handoff cycle to a ticket that was already waiting. A wrong duplicate call means two teams investigate one problem or one problem gets closed twice.

This is why "we will fix triage later" does not work: later, none of the data you would use to decide what to fix is trustworthy, because triage produced it.

Automating triage is not primarily a cost play. It removes the serial constraint: every ticket is classified at the moment it arrives, in parallel, against the full set of open work, using the same logic every time. Consistency is arguably the larger win — a queue where categories and priorities mean the same thing on Friday as on Monday is one where the metrics can actually be acted on.

It also changes what the senior people do. Their knowledge stops being spent on classification and starts being spent on the ambiguous fifth of the queue that genuinely needs judgement. That is the shift-left ladder working: the routine moves down, the scarce expertise moves up.

For this to work, triage has to be grounded in the things a good human triager uses: resolved-ticket history, documentation, and — for engineering-adjacent queues — the codebase and error signal. Triage that reads only the ticket text is doing keyword matching with better vocabulary, and it breaks on the same tickets keyword rules always broke on.

That is the design FlowTux is built around: every ticket triaged on arrival against history and the linked repository, duplicates collapsed semantically before they become separate work, routine categories resolved autonomously inside an allow-list, and the reasoning logged on the ticket so the humans can audit the judgement rather than repeat it. Start it in suggest mode and measure agreement — the bottleneck is worth removing carefully.