Automation · AI operations
How to build AI support deflection
An assistant confidently answers a billing question wrongly and the customer opens a ticket about the answer. What follows is the model behind deflection that knows its limits, the prompts that build it, and what changes in production.
Built with Tray Headless
- System Zendesk
- Step Retrieve
- Step Check coverage
- Step Answer or escalate
- System Agent
Confidence and coverage are checked before answering, and an escalation carries the whole attempted conversation so the customer never repeats themselves.
The short answer
What is AI support deflection?
AI support deflection breaks into four parts: answering only from retrieved content rather than from the model's own knowledge, escalating early when coverage is thin instead of guessing, handing the agent the full attempted conversation so the customer never repeats themselves, and measuring resolution instead of deflection. Most of these come apart on the metric. Deflection rate counts tickets that did not reach a human, including the customers who gave up, and optimising it makes the experience worse while the number improves.
What matters here
- Never answer from the model's own knowledge. If it is not in the knowledge base, the honest answer is that a person will help.
- Escalate on thin coverage rather than guessing. A confident wrong answer costs more than the ticket it prevented.
- Carry the whole attempted conversation into the escalation. A customer repeating themselves is worse than never having tried.
- Measure resolution, not deflection. Deflection counts the people who gave up.
- Never let it answer on billing, security or contractual questions. Those escalate regardless of confidence.
Who this is for
You run support operations. Volume is rising, the knowledge base is decent, and the concern is an assistant confidently telling a customer something untrue.
How it works in practice
What happens between a customer asking and either being helped or reaching a person.
- 1
The question is classified and checked against topic rules
Billing, security and contractual questions escalate immediately regardless of confidence.
- 2
Content is retrieved before anything is generated
If retrieval returns nothing relevant, that is the answer: escalate.
- 3
Coverage is assessed, not only confidence
How well the retrieved content actually addresses this question.
- 4
An answer cites its sources
So the customer can check it and the agent can see what was said.
- 5
Escalation carries the whole attempt
What was asked, what was answered, what was retrieved, and why it escalated.
- 6
Outcome is recorded against resolution, not deflection
Did the customer come back, and were they satisfied.
What deflection is made of
Four parts. The second is the difference between helpful and harmful.
Retrieval-only answers
Grounded in retrieved documentation with citations. A model answering from its own knowledge about your product will be confidently wrong.
Early escalation
On thin coverage, on a restricted topic, or on a second failed attempt. Guessing costs more than the ticket it saved.
Full context handover
The attempted conversation, the retrieved content, and why it escalated. A customer repeating themselves is worse than never trying.
Resolution measurement
Whether the customer was actually helped. Deflection rate counts the ones who gave up as successes.
The Tray Headless prompts
Paste these into Claude Code or Codex with the Tray Headless plugin installed. Each stage runs on its own. The systems named in them are the worked example rather than a requirement, and every prompt says so.
Once per project, run
/tray-workflows:set-workspace
to pick the workspace these build in. Point it at a sandbox first.
- 1
First, decide what it must never answer
The restricted list is the first control, before any retrieval.
Headless skills
build-workflowUse build-workflow. The systems in play are Zendesk and our knowledge base, or whatever we run in those seats. Before anything else, define what the assistant must never answer regardless of confidence: Billing amounts, refunds and credits Contractual terms, entitlements and SLA claims Security questions and anything about an incident Anything about an account other than the requester's own Legal, compliance or data protection questions Those escalate immediately. Being wrong about a bug is embarrassing. Being wrong about a refund or an SLA is a commercial commitment somebody has to honour or retract.
- 2
Answer only from what you retrieved
A model answering from its own knowledge will be confidently wrong.
Headless skills
build-workflowUse build-workflow. Retrieve before generating, and generate only from what came back. Instruct explicitly: answer only from the provided content. If the content does not address the question, say so and escalate. Do not infer, do not generalise from similar products, and do not fill a gap. Cite the source documents in the answer with links, so the customer can verify and the agent can see what the assistant was working from. A model answering about your product from its training data will be plausible and wrong, and the customer will not be able to tell the difference until it costs them something.
- 3
Escalate on coverage, not just confidence
Coverage and confidence are different, and coverage is the useful one.
Assess whether the retrieved content actually addresses the question, separately from how confident the generation is. Escalate when: Retrieval returned nothing above a relevance threshold The content is adjacent but does not answer the specific question The question spans several documents that disagree The customer has already asked once and the answer did not help Sentiment suggests frustration, which should escalate regardless Two exchanges is the limit. A customer on a third attempt with an assistant is a customer writing a complaint about the assistant, and no deflection statistic is worth that.
Coverage is the better signal because a model can be confident about content that does not answer the question. Checking the retrieval is checking the right thing.
- 4
Hand over everything on escalation
A customer repeating themselves is worse than never having tried.
Headless skills
tray-gotchasUse tray-gotchas, then make the handover complete. The agent receives: the full conversation, what the assistant answered, the documents it retrieved, why it escalated, and the account context. The customer must never be asked to explain again. Being handed to a person who starts with "how can I help" after five minutes with an assistant is the single worst outcome of the whole design, and it is more annoying than never offering the assistant at all. Set expectations honestly in the handover: tell the customer a person is taking over and roughly when. Do not let an escalated conversation sit silently in a queue looking to the customer exactly like the assistant still thinking.
- 5
Measure resolution, never deflection
Deflection counts the people who gave up.
Record an outcome per conversation: resolved by the assistant with no follow-up, escalated, or abandoned. Then report: Resolution rate, meaning the customer did not come back within 72 hours Escalation rate and the reasons, which shows where the knowledge base is thin Abandonment, which deflection rate silently counts as a success Satisfaction split between assistant-resolved and agent-resolved Questions where retrieval returned nothing, which is the content backlog and the most valuable output of the whole thing Never report deflection rate as the headline. It rises when customers give up, and optimising it makes the experience worse while the number improves.
- 6
Prove it works, then hand the topic rules over
Because what is safe to answer changes as the product does.
Run the per-step schema checks and the whole-workflow audit before this touches production. Run it shadow first: generate answers, show nobody, and have support read a week of them against what agents actually replied. Then open the same workflow in Tray Build so support operations can change the restricted topics, the coverage thresholds and the escalation rules in the visual canvas.
What it connects to
The question arrives in the support tool and the answer has to come from the documentation.
Zendesk
Read the incoming ticket, post the answer, and escalate with the full conversation attached.
Reads and writes
Notion
Retrieve from the documentation that is actually current, which is the only thing an answer may be built from.
Reads
Salesforce
Read account and entitlement context, so an escalation reaches the right queue with the right priority.
Reads
Slack
Alert support when escalation rate rises or retrieval starts returning nothing, which is a content gap.
Writes
Snowflake
Land conversations and outcomes, so resolution and abandonment are measurable instead of assumed.
Writes
Same build, other stacks
The design does not change if you run something else in one of these seats. The same prompts build it against Microsoft Dynamics 365, Google BigQuery, Microsoft Teams, Jira, HubSpot or Databricks.
Named systems are the ones most teams run, not the only ones that work. Each is an authentication in your Tray workspace, referenced by name, so the workflow never holds a credential. Where we have a connector page, the name links to it.
Running it in production
This talks to customers unsupervised. Everything here is about limiting what it can get wrong.
It runs on the platform, not on somebody's machine
Answers are generated as tickets arrive, at any hour, with escalation and handover on the same engine.
Every answer records what it was built from
The retrieved documents and the generated reply, stored together. When an answer is wrong, that pairing is how you find out why.
Credentials are managed, never in code
It reads customer conversations and writes replies as your company. Both scoped, in your workspace, and separately revocable.
Support operations own the limits
Restricted topics, coverage thresholds and escalation rules open in Tray Build, changed as the product and the knowledge base change.
Run it shadow first
Generate answers, show nobody, and read a week of them against what agents actually said. That week sets the thresholds honestly.
Questions people ask
Why answer only from retrieved content?
Because a model answering about your product from its training data will be plausible and wrong, and the customer cannot tell the difference until it costs them something.
What should it never answer?
Billing amounts, refunds, contractual terms, SLA claims and anything about security. Being wrong about a bug is embarrassing; being wrong about a refund is a commitment somebody must honour or retract.
When should it escalate?
On thin retrieval coverage, on a restricted topic, on signs of frustration, or after two exchanges. A customer on a third attempt is writing a complaint about the assistant.
Why measure resolution rather than deflection?
Because deflection counts tickets that did not reach a human, including the customers who gave up. Optimising it makes the experience worse while the number improves.
What is the most valuable output?
The list of questions where retrieval returned nothing. That is the content backlog, ranked by real demand, and it is worth more than the deflection itself.
Vibe-coding app guides
Vibe-code an entire app with Helix
This moves the data between systems. It does not give anybody a screen to work in. Build that app in Claude Code, Codex or Cursor, then deploy and run it governed on Tray Helix. Same kind of guide, same kind of prompts.
How to build an internal helpdesk (opens helix.tray.ai in a new tab)
Related guides
AI operations
How to build a knowledge base to vector sync
Chunk on structure, carry permissions into the index, delete on delete, and re-embed only what changed. The Headless prompts that build it.
Customer success
How to build support ticket routing
Route on the skill needed and the account, not on who is free. Derive priority from contract and impact, and time the clock from the customer. The prompts.
Last reviewed September 2026.