An AI customer support agent that knows when to hand over
The problem with support automation is not that it fails to answer. It is that it answers confidently when it should not, and then hands over a transcript instead of a case. Ours resolves what it can from your own documentation and escalates everything else with the work already done.
Example agent run, run · tier-one-support-agent. plan: classify, retrieve, draft. tool call: docs.search("refund window"). result: 2 passages, policy v4.1. approval: issue refund?. approved: by support@client.com. tool call: billing.refund(order="A-2291").
How this work happens today
The same six questions arrive every day
Where is my order, how do I change a plan, what is the refund window. They are answered well, individually, by people who could be doing harder work, and the answers are already written down somewhere.
Escalation means starting again
A ticket reaches tier two with a transcript attached. The engineer reads the whole thing, re-establishes what the customer actually has, and asks two questions that were already answered on line four.
The bot everybody has already tried made things worse
It answered from a marketing page, got the policy version wrong, and made the customer angrier before a person picked it up. That experience is why the team is sceptical, and the scepticism is reasonable.
What a support agent actually does
It answers from your documentation, not the open web, and it treats not knowing as a valid outcome.
Answer from your current documentation
Grounded in your help centre, policy documents and internal runbooks, with the version it used recorded. When policy changes, the answers change with it, because the source changed rather than because someone retrained something.
Refuse rather than improvise
If the documentation does not cover the question, the agent says so and escalates. This is the single most important behaviour in support automation and the one most systems get wrong.
Assemble the case before escalating
The account, the order, the plan, the steps already tried, what the customer has confirmed, and what remains unknown. Tier two opens a case file rather than a transcript.
Hold every account change behind approval
Refunds, plan changes, cancellations and credits are irreversible from the customer’s point of view. The agent prepares them and a person confirms, with the policy basis shown alongside.
Tell you what it could not answer
The list of questions that fell through is the most useful documentation backlog your team will get, because it is ranked by how often customers actually ask rather than by what somebody assumed would be confusing. Most teams find two or three gaps in the first week that had been quietly generating tickets for years.
The customer facing write path is the risky one
Anything that changes a customer’s account or money is gated, and the gate shows the agent’s reasoning and the policy passage it relied on. That is deliberately the same review a good support lead would do anyway, which is why teams do not find it slow. Read only answers can run unattended once you have watched enough of them, and that decision is per intent rather than all or nothing.
How approval gates workWhat it connects to
Connectors ship behind feature flags, staged and reversible. Everything runs end to end in demo mode before a single live key is issued.
- Zendesk
- Intercom
- Front
- Help Scout
- Stripe
- Shopify
- Slack
- Your help centre
Where to go next
Questions about this
What deflection rate should we expect?
We will not quote you a number before seeing your ticket mix, because the honest answer depends entirely on how much of your volume is genuinely repetitive. What we can promise is that we measure it against your real tickets during discovery, before you commit to a build.
How does it stay current when our policies change?
Can customers tell they are talking to an agent?
What happens out of hours?
Send us last month’s tickets
We will tell you honestly what proportion an agent could resolve, and which categories it should never touch.