AI ticket triage
96% accuracy at under $30/month

On a Monday morning an operations team at a legal-software vendor opens its ticket queue: 34 to 40 tickets from the previous week, spread across 268 client environments. Thirty-eight people support those environments, and before automation each ticket cost 15 to 25 minutes of manual investigation — which system, which client, who owns the attribute, then a dig through knowledge bases and ticket history.

They put a triage agent powered by Amazon Nova Lite in front of that queue. Over 2.5 weeks it reviewed 109 tickets and agreed with the human conclusion roughly 96% of the time. Against the pre-automation baseline, the team estimates it recovers 8 to 14 engineer hours a week. The whole system bills at under $30 a month, of which model inference is under $1.

Those figures are jointly published by Aderant and AWS, single-sourced and not independently verified: the sample is 109 tickets, and the working-hours figure is worded as an estimate. It can be written as a deployer’s report. It cannot be written as an industry baseline, and 96% is not the going rate for triage systems.

One: the valuable part is not 96%

Accuracy is the part that drifts first. It depends on how ticket types are distributed, how similar the client environments are, and what the team itself defines as a correct routing decision. In another organisation the same model might land at 70% or at 99%, and neither number would say much about whether the design is sound.

What transfers is the shape, and three parts of it are stable here. First, automation inside the threshold and a human outside it: the model acts only where it is confident and hands the rest to whoever can absorb the uncertainty. Second, one-person operability: a single Lambda, one scheduled trigger, one metrics surface, no component that needs a dedicated maintainer. Third, a cost in the tens of dollars per month, low enough that no procurement process is involved and therefore no business case has to be argued first.

Put those three together and a quiet shift shows up: when automation costs tens of dollars a month, the variable that decides whether it happens stops being budget and becomes design. Budget will not kill it. A badly set threshold will.

Two: five stages, from identification to observation

The pipeline has five stages. Identify works out what the ticket is. Enrich pulls context from Jira, Confluence, Athena and SharePoint. Classify decides which category it belongs to. Act reassigns it, posts a Teams notification and triggers predefined actions. Observe writes metrics to CloudWatch and routes low-confidence tickets to a human.

The skeleton is worth copying because it narrows what the model is allowed to do. The model judges and classifies; the actions are predefined, the data retrieval is bounded, and the human fallback is part of the flow rather than an exception branch. Agents that survive in production usually do so not because they are smarter but because their remit was drawn small enough.

Two design details are easy to miss. The confidence threshold is an explicit configuration value, not an adjective in a prompt, which is what makes the pipeline observable: you can see how traffic splits across the threshold and what a change in it would cost. And the team reviews corrected reassignments weekly, feeding those back into prompts and routing rules. That loop is the line between shipping something and operating it; without it, accuracy is a historical snapshot.

One boundary is what keeps the cost so low. The system’s data scope is internal operations data; it does not touch client matter data. That boundary is why it cleared internal review, and it is also why the cost structure holds: no separate isolation and audit engineering is needed for sensitive data. The mirror image matters too. Any plan to extend this kind of automation onto client data jumps an order of magnitude in cost, and at that point the conversation stops being about model selection.

Three: automate above the threshold, hand off below it

There is a reading of this pattern that treats it as a stopgap: once models get better, drop the threshold and automate everything. Against what buyers are actually running, that reading does not hold.

The human handoff is not a patch for insufficient capability. It performs a distinct job: it returns uncertainty to the party that can carry it. A wrong reassignment in back-office operations costs a client environment some extra hours of human effort; in healthcare or financial services it can cost a compliance event. The threshold explicitly couples how confident the model is with who pays when it is wrong, and that coupling is the most valuable part of the design.

Handoff quality also varies. If what crosses the boundary is the raw ticket, the human repeats the investigation and the gains are confined to the automated share. If what crosses is enriched context — related Jira links, environment identifiers, similar past tickets — the human receives a judgement task instead of an investigation task. The 8 to 14 hours saved in this case come mostly from the second arrangement: even tickets that end up with a person arrive with the investigation already done.

Where the threshold sits is an operating parameter, not a one-time setting. Lower it and automation rises along with the cost of wrong reassignments; raise it and human workload and waiting time climb. The weekly correction review exists to walk that curve toward the right place as the business changes. It is routine work, not a configuration decision made once at launch.

Four: what buyers report — 66%, 0%, 37%

A single case shows that one shape works; the distribution across buyers is more persuasive. A survey conducted by IDC for Leah, an agent vendor, with 410 enterprise technology decision-makers, reports that 66% of organisations already run agents in production, that 0% have deployed fully autonomous operation with policy guardrails, and that 37% of use cases require human sign-off before the agent acts. Agentic budgets are said to double within twelve months, with planned deployment growth of 6x.

The same survey carries a set of coordination figures, relayed by CIO Dive: only 29% of agents interact with each other, 7% reach what the report calls advanced orchestration, and more than half remain at basic or workflow-style handoffs. Quote those with the relaying source attached, because the full report sits behind a lead-capture form and the definitions behind those two numbers cannot be checked item by item.

Three qualifiers have to travel with all of it. This is vendor-commissioned research hosted on the commissioner’s lead-generation page, not a neutral census. The 0% figure is what this sample of 410 reports, so it can only be written as “none of these organisations”, never generalised into a claim that no enterprise has ever granted an agent autonomy. And the 6x and the budget doubling are planned values, not realised ones; writing that enterprise agent deployment has grown six-fold would be false.

Read together, the numbers do not describe lagging enterprises. They describe buyers who already manage autonomy in grades. Sixty-six percent in production, zero percent fully autonomous and thirty-seven percent requiring sign-off can all be true at once, which tells you that tiered autonomy and approval boundaries are not a consultant’s model but a field practice. The ticket triage agent is one concrete instance: automation inside the threshold, sign-off outside it, both inside the same workflow.

A second implication matters more for anyone selling into this space: multi-agent orchestration has very low coverage on the buyer side. With 29% interaction and 7% advanced orchestration, it cannot be pitched as a capability the customer already bought and uses. What is actually missing is runtime visibility and post-hoc verifiable evidence — knowing what each agent did, in which state, and being able to produce the record when something goes wrong. That gap is what several recent agent-runtime failures point at as well.

Five: cost is no longer the gate; design is

Our judgement, in one line: when a thirty-dollar-a-month tool replaces a dozen engineer hours a week, the constraint on adoption is not budget but design. The veto point moves from “is this worth funding” to “where does the threshold sit, who owns the correction loop, where is the data boundary”.

That shift has a second-order effect: the set of automatable opportunities grows. Previously only scenarios large enough to justify a project cycle got automated. Now a 38-person team with a few dozen tickets a week qualifies, because it no longer has to argue for a return — it needs a weekend of engineering time. Enterprise AI value may come disproportionately from these small fittings rather than from a handful of flagship programmes. That is worth noting because judging them with a flagship ROI framework systematically undervalues them.

The low-cost shape rests on three preconditions, and dropping any one forces a redesign. The task needs a clear pass-fail standard checkable within about a week: triage qualifies, because a reassignment can be judged wrong within days, while a decision whose consequences land a quarter later does not. Input data has to sit inside an internal boundary, so no new compliance engineering is required. And the cost of an error has to be survivable, which in practice means a human fallback — that is what lets the threshold be set conservatively without losing overall efficiency.

What this shape does not deliver should be stated too. It produces no end-to-end business evidence: the 8 to 14 hours are estimated capacity, not booked savings. If those hours simply leave engineers less busy, no line on any statement changes. For the project to stand up financially, the hours still have to be converted into something checkable, such as mean ticket closure time or incident response time per client environment.

Six: a checklist for copying this shape

First, write down the pass-fail standard and its testability. Ask one question: if the model gets it wrong, how soon would we know, and who would know? A task with no answer to that time-scale is not a candidate for threshold automation.

Second, make the threshold an explicit configuration value and record the traffic split on both sides. A threshold buried in a prompt is not threshold automation; it is a hope that the model will be careful.

Third, give the handoff information gain. What crosses the boundary should be enriched context, not the raw ticket. This sets your ceiling: if only the automated share saves time, returns stay linear; when human-handled tickets also skip the investigation, returns become structural.

Fourth, make the weekly correction review a standing task. Track the correction rate, feed it back into prompts and routing rules, and maintain it the way you maintain alerting rules. Without that loop, the accuracy number quietly expires within months.

Fifth, put a cost ceiling in the design and treat it as a constraint. Under $30 a month means no procurement process; if your design costs thousands a month, it has to prove something entirely different, and you cannot borrow the plausibility of the cheap shape to justify it.

If a ticket costs you 20 minutes of manual investigation and your team sees a few dozen a week, the question is not whether to use AI. It is whether a reassignment can be judged right or wrong within a week. If it can, start with one ticket type and one threshold. If it cannot, build the pass-fail standard first.

Sources

AWS customer story: Aderant builds intelligent ticket triage with Amazon Nova (2026-09-24, co-authored with Aderant): aws.amazon.com/blogs/machine-learning/aderant-builds-intelligent-ticket-triage-with-amazon-nova.

IDC survey landing page (commissioned by Leah, n=410): leahai.com/lp/idc-agentic-enterprise-report; source relaying the orchestration figures: ciodive.com/news/agents-remain-disconnected-enterprises-double-down/831317 (2026-09-25).