What Stripe-scale support teams get wrong about triage

When support volume reaches the scale of a Stripe or a Shopify, teams pour effort into resolution speed — better runbooks, more engineers on rotation, tighter escalation paths. Those investments are real, and they work on the tickets they touch. The quieter problem is triage: the minutes spent deciding what each ticket is, how urgent it is, and who should own it, multiplied across thousands of tickets a week.

Almost nobody optimizes that step, because almost nobody can see it. It has no dashboard, no owner, and no line in any report. It is simply absorbed into everyone's day.

Take a queue of ten thousand tickets a month — unremarkable for a company at this scale. Assume two minutes per ticket to read it, decide its category, judge its priority, and route it to the right team. Two minutes feels like nothing. It is the least memorable part of anyone's day.

That is roughly 333 hours a month. Around two full-time engineers, doing nothing but sorting. And unlike resolution work, this cost is paid on every ticket regardless of difficulty — the password reset and the payment outage both pass through it.

Now compare that against resolution. Resolution time is dominated by a small number of genuinely hard tickets, which is why it feels like the bottleneck and why it attracts all the attention. But the hard tickets are a minority. The tax on the majority is triage, and because it is spread across everyone in two-minute increments, it never appears large enough to fix.

Triage hides because of how it is distributed. If two engineers sat in a room sorting tickets full time, someone would notice within a week and question the staffing. Instead the same work is smeared across thirty people in two-minute slices, and each slice is far too small to complain about.

It also hides inside metrics that already exist. Time-to-first-response includes triage, so triage looks like responsiveness. Time-to-resolution includes it too, so triage looks like engineering speed. When either number degrades, the instinctive fix is more engineers or better runbooks — investments aimed at resolution, applied to a problem that lives upstream of it.

The context-switching cost is worse than the clock time suggests. An engineer pulled out of a debugging session to categorize an unrelated ticket does not lose two minutes; they lose the two minutes plus the re-entry cost into what they were doing. That second cost is real and appears in no measurement anywhere.

Under load, human triage degrades in predictable ways, and each one shows up as a resolution problem rather than a triage problem.

Priority inflation: when everything is judged quickly and in isolation, priority labels drift upward until most of the queue is marked high and the label stops carrying information. Inconsistent categorization: the same issue lands in three different buckets depending on who read it, which quietly corrupts every report built on those categories. Misrouting: a ticket goes to the wrong team, waits, gets reassigned, and the clock keeps running — the time is recorded against resolution, though the mistake happened at triage.

Duplicates are the most expensive of these. During an incident, thirty people report the same outage in their own words. Without semantic deduplication, that is thirty tickets, potentially thirty owners, and a queue that makes the incident look like thirty problems instead of one.

The instinct at scale is to add headcount. It does not work here, because triage cost scales with ticket count, not with team size. Doubling the team does not halve the per-ticket tax; it just spreads the same total across more calendars while adding coordination overhead.

It also makes consistency worse. Every additional person triaging is another interpretation of what "high priority" means and another opinion about which category a borderline ticket belongs to. The larger the team, the noisier the labels — and the less trustworthy every downstream report becomes.

Before automating anything, measure the thing you are trying to fix. Time-to-resolution will not show it. Time-to-first-action will: the gap between a ticket arriving and someone taking a real step beyond reading and sorting it. That gap is mostly triage.

Two supporting numbers make the picture concrete. Reassignment rate tells you how often the first routing decision was wrong. Duplicate rate tells you how much of the queue is the same problem wearing different words. Both are triage failures that get charged to resolution, and both are easy to count.

Track all three for a few weeks before changing anything. Without a baseline you cannot tell whether automation helped or whether the queue simply had a quiet month.

Auto-triage flips the default. Instead of a person reading each ticket to decide what it is, every ticket arrives already categorized, prioritized against business impact, checked against the open queue for duplicates, and routed by ownership and current load. Engineers stop sorting and start fixing.

The gain is not only speed. It is consistency. A model applies the same definition of "high priority" to the ten-thousandth ticket as to the first, at three in the morning as at ten in the morning. That consistency is what makes the resulting categories worth reporting on — a benefit that outlasts the time saved.

This is also the right place to start automating, because triage decisions are high-frequency and low-variance. Autonomous resolution is a larger step with a larger blast radius. Triage is where the volume is and where a wrong call is cheap to correct.

Run it in suggest-only mode first. Let the system propose category, priority, owner, and duplicates without acting, then compare its calls against what your team actually did. You are not looking for a single accuracy percentage — that number averages away everything useful. You are looking for which categories it is reliably right about, because there is almost always a boring cluster where it is near-perfect and a messy cluster where it is a coin flip.

Then hand over the boring cluster first and keep watching. Expand one category at a time, and keep novel or high-impact work human-reviewed. The goal is not to remove people from the queue; it is to make sure the queue they see contains only tickets that need a person.

A two-minute triage saving is noise on ten tickets a day. On ten thousand a month it is two engineers. That is the whole argument: the value of automating triage scales with volume, while the effort to set it up does not.

Which is why high-volume teams are exactly the ones who should stop optimizing resolution first. The hard tickets deserve the attention they get. The tax on the easy ones is where the queue is actually going.