REFERENCE SCENARIO · SAAS & TECHNOLOGY
Reference scenario - composite, not a named client. A composite build illustrating our method. Figures are modeled and the model is shown.
This AI support triage case study is a reference scenario. No client sits behind it. It shows how three channels feeding one queue get triaged, answered and escalated by agents, and how every figure here is calculated.
What this page is not
We have not published a client story, because we do not have one we are permitted to publish. Naming a company, quoting a person or showing a logo without written consent is a legal problem, not a style choice. So this page does the honest version instead.
Everything below is a composite. The workflow shape is one we build against. The volumes, timings and rates are inputs we picked to make the arithmetic visible, and they are labeled as such wherever they appear. Not one of them is a measurement of a real system.
The situation this build answers
Three inbound channels, one team. Email, in-app chat and a web form all land in the same queue, and the queue is worked in the order it arrives rather than the order that matters. Nothing is broken. It is simply first-come, first-served against a mix that is nothing like uniform.
A large share of that mix already has an answer written down. It sits in a help center, a changelog or a prior ticket that a person has to remember and find.
Where the time actually goes
- The queue is unsorted, so a password reset and a failed payment wait the same length of time.
- The answer often exists, but finding it costs more than writing a fresh one.
- Context is rebuilt by hand on every escalation: account, plan, recent errors, prior tickets.
- The same six questions arrive every week and get answered from scratch every week.
- Out of hours, nothing moves at all.
The hive, agent by agent
Ticket Triage Agent
Reads every inbound conversation on arrival, classifies it, sets priority, and attaches the account context a human would otherwise assemble.
Knowledge-Base Agent
Answers what is already documented, with the source cited in the reply so the customer and the reviewer can both check it.
The orchestrator
Holds the routing rules. It decides which agent owns a conversation, when an answer is confident enough to send, and when the conversation stops being a machine’s job.
Both agents write to the same ticket record a person uses. There is no shadow queue and no second inbox. A human opening a conversation sees the classification, the draft or sent reply, the sources and the reasoning.
The service pages behind this build are AI customer support agents and conversational AI development.
What the agents may not do
Autonomy boundary
Agents classify, route, answer from cited sources and draft. They never issue a refund, change a plan, touch billing or close an account.
Confidence gate
Below the confidence threshold the agent drafts and stops. A person sends it.
Escalation
Anything about money, data deletion, security or a legal complaint routes to a person immediately, whatever the confidence score says.
What stays human
The apology, the exception, the judgment call, and every conversation the customer has asked a human for.
Logging
Every classification, retrieved source, draft and send is recorded with a timestamp. Read our governance approach for how that is held.
How the build would run
| Phase | Typical | What happens |
|---|---|---|
| Audit | 3-10 days | The last 90 days of conversations are scored: what was answerable from existing documentation, what needed a decision. This produces the real rate the model below assumes. |
| Shadow | 2 weeks | Agents classify and draft. Nothing sends. Humans compare their own answer against the draft. |
| Assist | 2-3 weeks | Drafts go to agents for one-click review. The confidence threshold is tuned on real disagreements. |
| Autonomous | from week six | Only the categories that cleared the bar in assist mode send without review. Everything else stays drafted. |
How to read this AI support triage case study
Every figure in the next section is arithmetic. We state the inputs, state the assumption, and show the multiplication. Change an input and the figure changes, which is the point.
| Input | Assumed value |
|---|---|
| Inbound conversations | 1,200 per month across three channels |
| Human handling time, today | 12 minutes per conversation |
| Median first response, today | 4 hours |
| Share answerable from existing documentation | 55% |
| Review sample on agent-sent answers | 20%, at 1 minute each |
The modeled outcome, with the arithmetic
| Figure | The arithmetic | Label |
|---|---|---|
240 h human handling today | 1,200 × 12 min = 14,400 min | Modeled |
660 answered without a person | 1,200 × 55% | Modeled |
540 still reaching a human | 1,200 − 660 | Modeled |
110 h human handling after | (540 × 12 min) + (132 reviews × 1 min) = 6,612 min | Modeled |
~130 h returned per month | 240 − 110.2 | Modeled |
~54% less handling time | 129.8 ÷ 240 | Modeled |
~5.5 min per conversation after | 6,612 min ÷ 1,200 (from 12 min) | Modeled |
~1.8 h mean first response | ((660 × 1 min) + (540 × 4 h)) ÷ 1,200 (from 4.0 h) | Modeled |
100% of escalations to a person | Design rule, not a rate | Target |
What we would measure, and what we will not claim
We publish no outcome range for this build, because we have no consented client result to publish and we will not invent one. What we commit to is the measurement.
What we would change next time
Start with the documentation, not the agent. The Knowledge-Base Agent can only cite what exists, and a scenario like this usually finds that a third of the “documented” answers are documented in someone’s head. That work is unglamorous and it is the actual first sprint.
Set the confidence threshold too high on purpose. It is easier to defend a build that drafted when it could have sent than one that sent when it should have drafted.
The parts this build is made of
AI customer support agents
Triage, deflection and the knowledge layer underneath both.
Conversational AI development
The in-app channel, and agents that carry a task to completion rather than answering once.
Ticket Triage Agent
Classification, priority and context assembly.
Knowledge-Base Agent
Cited answers from your own documentation.
AI agents for SaaS and technology
Where else agents pay off in this sector.
