Summary

A field operations business was running a support queue dominated by the same handful of issue types. Device login problems, serial and identifier mismatches, stock availability checks, order cancellations, route closures, stock transfer requests and stocktake approvals held up by bin locks. Every one of those has a documented procedure. Almost none of them were being resolved by reading it.

Agents were opening a ticket, locating the right procedure, confirming a few facts, and executing steps that the procedure specified exactly. The work was procedural, and it was consuming the hours of people hired to handle the cases that are not.

We built support automation in three separate layers: a factual layer that grounds every answer in approved procedure, a workflow layer that classifies and routes, and an agentic layer that executes resolution only where the procedure is unambiguous. The layers are deliberately distinct because they carry different risk and need different governance. Retrieving the right procedure and taking an action against a stock record are not the same decision, and systems that treat them the same either do nothing useful or do something they should not have.

Business Challenge

Summary: The support queue was mostly procedural work being handled manually, which capped capacity and pushed the difficult tickets to the back of the line.

The queue was more predictable than it looked

The recurring ticket types were well understood. Device enrolment and login failures. Serial and identifier mismatches between what the system held and what was physically present. Stock availability and reservation questions. Order cancellations. Route and runsheet closures. Stock transfer requests between locations. Stocktake approvals blocked by bin locks.

Each has a written procedure. The procedures were current, and agents followed them accurately. That is the point. This was not a quality problem. It was a cost and capacity problem wearing a quality problem's clothes.

Time was going to lookup, not judgment

The bulk of handling time went into locating the applicable procedure, confirming which variant applied, and gathering identifiers from two or three systems. The actual decision often took under a minute. Everything around it took twenty.

That ratio is what made the queue expensive, and it is invisible in most support reporting, because average handling time reports the total without separating the lookup from the judgment.

The difficult tickets paid the price

When procedural volume rises, it does not degrade evenly. Straightforward tickets get closed because closing them is fast and it protects the numbers. Complex tickets, which need investigation and cannot be rushed, slip. The queue therefore aged from the difficult end, which is the end where customer impact and escalation risk live.

Why previous automation attempts had not worked

Two failure modes had already been experienced. Answer-only automation could describe a procedure but could not act, so the agent still did all the work and now had an extra tab open. Action-capable automation, trialled narrowly, was pulled back because there was no way to constrain which actions it could take or to reconstruct afterwards why it had taken one.

Neither failure was about model quality. Both were about the absence of layer separation.

Solution Approach

Summary: Three layers with different governance. Grounded retrieval, deterministic classification, and autonomous execution restricted to procedures where the correct action is unambiguous.

Layer 1. The factual layer

Approved procedure documents are indexed and retrieved whenever a ticket is processed or an agent asks a question. Every answer the system produces is grounded in an approved procedure rather than in the model's own recall.

This layer is intentionally conservative. It retrieves and cites. It does not act. Its output carries the retrieved procedure and a confidence value, so an agent reading it can see what it was drawn from rather than being asked to trust a paraphrase.

Retrieval traceability runs to the passage level. When an answer is questioned later, the specific procedure text behind it is recoverable, along with how confident the retrieval was. That matters more than it sounds. Most disputes about automated support answers are actually disputes about which procedure version applied.

Layer 2. The workflow layer

Deterministic actions on every inbound ticket: classification into support tier, enrichment with related records, severity prediction, service level assignment and routing.

These are structured decisions with defined outputs, so they are handled as structured decisions rather than open generation. Each one is recorded with its reasoning. The system stores why a ticket was classified at a given tier, why a severity was assigned, and which procedure context informed the routing.

Explainability here is operational rather than philosophical. A team lead disputing a routing decision needs to see the basis for it inside their working day, not request an investigation.

Layer 3. The agentic layer

Execution of resolution steps, restricted to issue types where the procedure defines the correct action without ambiguity.

The restriction is the design. An agentic layer permitted to act wherever it feels confident is the version that gets switched off after its first bad week. Scope is granted procedure by procedure, and expansion is a decision someone makes rather than a threshold the system crosses on its own.

Human approval sits in the workflow for actions that change inventory, financial or customer-facing state. Workflow limits halt execution when a rule is breached rather than logging the breach and continuing.

Cross-cutting: what every layer inherits

Sensitive data masked before inference. Employee details, customer identifiers, device identifiers, serial numbers, order references and operational credentials are masked ahead of the model. A support queue is one of the highest-density concentrations of operational identifiers in any business, and it is routinely the least protected.

Immutable audit trail. Every summary, classification, severity call, service level assignment, routing decision and executed resolution step is captured with its reasoning.

Role-based access. What the system will retrieve and what it will do both vary by who is asking.

Cost routing. Classification is a cheap, high-volume decision and does not need an expensive model. Resolution reasoning on an ambiguous ticket does. A rules-based orchestrator selects the tier against the nature of the task, the accuracy required and how much human control the step demands. Without this, the highest-capability model gets called for every ticket because that is the path of least resistance, and spend grows with volume in a way nobody planned.

Repeated context served from cache. The same procedure context is retrieved for the same recurring ticket types thousands of times. Caching that context removes both latency and cost from the most common path, which by volume is most of the queue.

Learning from overrides. When an agent overrides a classification or declines a suggested resolution, that correction is retained. Recurring override patterns are the highest-value signal in the system, because they mark exactly where the procedure and reality have drifted apart.

Business Impact & Results

Summary: Procedural volume moves off agent hours, judgment work gets the capacity back, and every automated decision becomes reconstructable.

The deflection economics

Modeled with visible inputs, using a loaded support cost of $50 an hour and a twenty minute average handling time for tier zero work.

Input

Value

Gross labor value per tier zero ticket

$16.67

Cash conversion rate

55%

Cash value per deflected ticket

$9.17

Cash conversion sits at 55% rather than 100% deliberately. An hour saved only becomes money if headcount comes out, a hire is avoided, or growth is absorbed without adding people. Otherwise it becomes slack, and slack does not appear in a budget.

Tier zero typically represents around 55% of inbound volume, of which roughly 35% is safely automatable against unambiguous procedures. Net deflection lands near 19% of total ticket volume.

The volume thresholds, including where this does not work

Monthly tickets

Annual cash benefit

Verdict

2,000

~$42,000

Below the floor. Run cost is higher. It never pays back

2,400

~$51,000

At the floor. Covers run cost, never recovers implementation

4,800

~$102,000

Payback around month 26

10,800

~$229,000

Payback inside twelve months

19,500

~$413,000

Payback around month 7

We give clients the top row before the bottom one. Below roughly 2,400 tickets a month this does not pay for itself, and saying so early is worth more than any figure further down the table.

What becomes measurable

Classification accuracy against agent overrides. Retrieval quality, including which procedures produce low-confidence answers and therefore need rewriting. Autonomous resolution success and, more usefully, failed actions. Response latency by stage. Agent feedback attached to specific decisions rather than collected in aggregate.

The failed-action metric is the one operations teams come to rely on. It is the early warning that a procedure has changed in practice before anyone updated the document.

Where the capacity goes

Into the tickets that were aging. This is the outcome that does not appear in a deflection percentage and is usually what the operations lead actually cared about. Queue age at the difficult end is the metric worth putting in front of them.

Long-term value

Every override makes classification more accurate. Every low-confidence retrieval identifies a procedure worth improving. The support corpus becomes better documented as a side effect of automating against it, which tends to outlast the deflection saving.

Key Takeaways

1. Separate the layers or govern nothing well. Retrieving a procedure, classifying a ticket and executing an action carry different risk. Systems that collapse them either cannot act or act where they should not.
2. The cost is in the lookup, not the decision. Most procedural tickets take a minute to decide and twenty to prepare. Average handling time hides this, which is why the opportunity is routinely underestimated.
3. Grant autonomy procedure by procedure. Scope should expand because someone decided it should, not because a confidence score crossed a line.
4. Failed actions are more informative than successful ones. They mark where documented procedure and actual practice have diverged, usually before anyone else notices.
5. Below roughly 2,400 tickets a month, do not buy this. The run cost exceeds the benefit. Telling a client that early is why they believe the rest of the model.

Conclusion

Support automation gets sold as deflection and bought as capacity. The percentage of tickets closed without a human is the number in the proposal, but the outcome the operations lead notices is that the complicated tickets stopped aging.

Getting there depends less on model capability than on layer discipline. A grounded factual layer that retrieves and cites but never acts. A workflow layer that makes structured decisions and records its reasoning. An agentic layer with deliberately narrow permission, expanded by decision rather than drift. Each governed according to what it can actually break.

Any operation running a queue dominated by procedure-answerable tickets will recognize the shape. Predictable issue types, current documentation, accurate agents, and a cost base set by the time spent finding the right procedure rather than applying it. The remedy is not a better knowledge base. It is grounding the answer in approved procedure, recording why every decision was made, and being conservative about which actions the system is permitted to take on its own.

And where the volume does not support it, saying so.

Looking to solve a similar business challenge? Connect with our experts to explore the right solution for your organization.

A useful first exercise takes about a week: sample a hundred recent tickets and break down handling time into locating the procedure versus applying it. That ratio tells you the size of the opportunity and your monthly volume tells you whether it's worth pursuing this year.