They weren't slow. Every reply required checking four systems first. We moved the research in front of the reply and the queue stopped growing.
The client came to us convinced they needed to hire three more support agents. Their backlog had grown every month for five months, first response had drifted past eleven hours, and the team was working late without catching up. Every metric pointed at capacity.
We spent day two of the Sprint watching four agents work, with a stopwatch. The pattern was consistent, and none of us expected it to be quite so stark: writing a reply took around ninety seconds. Getting to the point where the reply could be written took between four and nine minutes.
That time went to the same four places on every single ticket. Look up the account in the CRM. Check the subscription and billing state. Search whether this customer had raised something similar before. Find the current policy on whatever they were asking about — which lived in a help centre, an internal wiki, and, for two topics, a pinned message in a chat channel.
Three more agents would have bought them more people doing that lookup work in parallel. It would have worked, in the sense that any brute-force solution works. It would also have cost roughly six times what the build cost, every year, permanently.
Timed across 41 observed tickets during the Sprint. The proportions held when we re-measured against the full month's data.
Three weeks of engineering. Over half of it came off the shelf.
We built MCP connections to the four systems the agents were checking manually, then put IX-03 Ticket Triage behind them. When a ticket arrives, the agent does the same four lookups a human would — in parallel, in about thirty seconds — and writes an internal note summarising what it found, with each fact linked to its source.
It then drafts the reply. A support agent opens the ticket and finds the research already done and a proposed answer waiting, which they read, correct if needed, and send.
The policy problem had to be solved first. Current policy was scattered across three places and two of them disagreed. We didn't automate around that. The client spent a week consolidating into a single source before we connected anything to it — the part of the timeline nobody enjoys and everybody skips.
| Component | Source | Effort |
|---|---|---|
| Helpdesk connection | Registry — existing | 3 days |
| CRM connection | Registry — existing | 2 days |
| Billing connection | Built new — bespoke API | 5 days |
| Knowledge retrieval | Registry — existing | 2 days |
| Triage agent (IX-03) | Registry — tuned | 4 days |
| Category rules & guardrails | Built new — client-specific | 4 days |
Table 1 — Build composition. New work was 45% of effort, concentrated in the client's own systems.
A figure without a method is marketing. Here is exactly what was compared against what.
Median first response went from eleven hours to two. Median handling time fell 38%. The backlog, which had grown every month for five months, cleared inside seven weeks and stayed clear.
The three planned hires didn't happen — but nobody was let go either, and that distinction mattered enormously to how the team received the thing. The capacity went into clearing backlog first, then into absorbing a rising ticket volume without adding people.
The unexpected result was where the team's time went. Their hardest tickets — the ones needing genuine investigation — had previously been triaged into a "look at this later" queue everyone knew was where tickets went to die. With routine work compressed, those tickets started getting the attention they'd always needed. Nobody had asked for that outcome, and it's the one the support lead mentions first.
Three categories reached level 3 autonomy, where review is a single confirmation. Nothing reached level 4. The client considered it, looked at which categories qualified, and decided the remaining risk wasn't worth the marginal saving. We think they were right.
All three are now standard in how we run these.
We found the contradictory policy in week two of the build, and it added a week nobody had planned for. Documentation review now happens during the Sprint, before an estimate exists — which occasionally means telling a prospect their real first project is a writing exercise.
We scoped this with the support lead and the CTO. The agents themselves joined in week three and immediately identified two ticket categories we'd classified wrongly — obvious to anyone who worked the queue daily, invisible from above. That correction should have come in the first ninety minutes.
Our best outcome — complex tickets finally getting proper attention — is the one we can describe but not quantify, because we never measured that segment on its own. We now baseline routine and complex work as separate populations, so the second-order benefit is provable rather than anecdotal.
The reasoning layer. Tuned to this client's ticket categories over four days.
Handled the third of tickets arriving by email rather than through the portal.
Read screenshots and invoices customers attached, so drafts accounted for them.
This client was about to add permanent headcount to a problem that wasn't a headcount problem. The Sprint that established that cost them nothing.