Skip to content

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

  1. System Zendesk
  2. Step Retrieve
  3. Step Check coverage
  4. Step Answer or escalate
  5. System Agent
Also Snowflake

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. 1

    The question is classified and checked against topic rules

    Billing, security and contractual questions escalate immediately regardless of confidence.

  2. 2

    Content is retrieved before anything is generated

    If retrieval returns nothing relevant, that is the answer: escalate.

  3. 3

    Coverage is assessed, not only confidence

    How well the retrieved content actually addresses this question.

  4. 4

    An answer cites its sources

    So the customer can check it and the agent can see what was said.

  5. 5

    Escalation carries the whole attempt

    What was asked, what was answered, what was retrieved, and why it escalated.

  6. 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. 1

    First, decide what it must never answer

    The restricted list is the first control, before any retrieval.

    Headless skills build-workflow

    Use 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. 2

    Answer only from what you retrieved

    A model answering from its own knowledge will be confidently wrong.

    Headless skills build-workflow

    Use 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. 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. 4

    Hand over everything on escalation

    A customer repeating themselves is worse than never having tried.

    Headless skills tray-gotchas

    Use 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. 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. 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)

Last reviewed September 2026.