Customer Success AI agent · Ticket deflection
Ticket Deflection AI Agent
Disclose the machine at the first interaction, answer only what the documentation already carries, and hand over to a named support engineer the moment a request turns on an entitlement.
- Typical delivery
- 4–6 weeks
- Deployment
- Your stack
- Named engineer
- Disclosed first
- After launch
- Agent Care
What this agent does
Answers what is documented, hands over the rest
In
- 01
A request arrives from a help centre, an inbox or an in-product widget, and the channel travels with it.
- 02
An intent is read, and the request is split into what the documentation covers and what it does not.
Reason
- 03
An answer is drafted from published articles and resolved tickets, each line bound to its passage.
- 04
A disclosure is placed at the first interaction, clear and distinguishable, not on scroll or at handover.
- 05
A request that would settle a refund, deny a warranty claim or close a complaint stops before any answer.
Decide
- 06
An answer that determines nothing sits outside Article 22; one that forecloses an entitlement does not.
- 07
A handover carries the thread, the articles read and the reason it stopped to a named support engineer.
Out
- 08
A request lands where no federal rule compels the disclosure, and the same line is shown regardless.
- 09
Execute write actions only inside the approval boundaries agreed during implementation.
Product statement
Reading, drafting and disclosure belong to the agent. The handover, the closure and any refusal belong to a named support engineer, who answers for all three.
Example workflow
One request, arrival to handover
- 1Request receivedHelp centre, support inbox, in-product widget or messaging channel
- 2Intent read and disclosedThe intent, the disclosure placed at the first interaction and the channel it was placed on
- 3Answer drafted from sourcesThe reply, the articles behind it, the resolved tickets and confidence
- 4Controls appliedScope checks, dispositive-request checks, source-coverage checks and confidence threshold
No human action required
Stages 1 to 4 run unaided, and nothing is decided at any of them — the agent is answering, and the engineer lane opens at the handover gate.
Goes back as the drafted reply.
Goes to a named engineer first.
Engineer review
The reply is held with the articles behind it, the thread and the reason it stopped.
Send · Add source · Take the ticket
Answered — or taken by the engineer
- 6Help-desk and article records updatedOnly where write access and records policy allow it
- 7Outcome evaluatedHandover rate, reopened tickets, engineer corrections and what the customer asked next
Corrections
Each engineer correction is counted in the evaluation.
What should not run autonomously
Human approval stays in control
Outside the boundary — human approval required
8 items
- Deciding a customer does not need a person.
- Closing a claim, a refund or a warranty request.
- Refusing an escalation a customer has asked for.
- Ending a complaint that carries a limitation period.
Automation boundary
Agent acts unaided
- ✓Draft the reply from published documentation.
- ✓Say a machine is answering at the first interaction.
- ✓Bind each sentence in the reply to its passage in the documentation.
- ✓Hand the thread to a named engineer the moment it turns dispositive.
Nothing is closed and no escalation is refused except by a named support engineer.
- Judging whether an answer was adequate.
- Telling a customer an entitlement does not apply.
- Deciding what the documentation ought to say.
- Changes to the handover rules or the thresholds.
Example output
One inbound request, annotated
This serves a support team who may have to explain why a customer got a machine and not a person; below is one request exactly as the agent leaves it.
Deflected answer · single request
Illustrative example- Request
- Password reset, self-serve plan
- Drafted reply
- Reset steps and the article behind them
- Disclosure
- Disclosed at first reply
- Source of record
- Help centre, 5 May 2026
- Confidence
- Answered, not closed
- Held for
- The named engineer, by name
As received
Drawn from the published help centre and a resolved ticket, and it decides nothing the customer is owed.
What the record holds
- Help-centre article
- Resolved ticket
- Product release note
Why no closure here
Closing a ticket is a judgement a named engineer makes, not a model.
What the score decides
Below the configured threshold a reply gets an engineer read before the customer sees it.
Action
SendAdd sourceTake the ticketValue
Where AI adds value
The same four claims, placed at the point in the workflow where each one applies.
Where the value lands
Value 01 – 04
Every request
From the channel it arrived on
Who owes it, and when
The conversational brand agent runs a branded marketing conversation; this is inbound support, where the product is the handover rather than the answer.
Say it is a machine
The test is what a reasonably well-informed, observant and circumspect person would take it for, and a belief that everybody knows does not meet it.
What was checked, and not found
Checked across the statutes surveyed: no duty to offer a human alternative, and no duty to keep a record that the disclosure was made. The route to a person here is a commitment, not a rule anyone imposed.
Build an evidence trail
The answer, the article behind it and the moment it handed over stay together.
Integrations
Typical integrations
Five system groups connect to the same agent. Which of them are in scope is decided in discovery.
Help centre and knowledge
- Zendesk Guide
- Intercom
- Help-centre articles and release notes
Ticketing and help desks
- Zendesk
- Freshdesk
- Front
- Service Cloud
- HubSpot Desk
Messaging and channels
- In-product widget
- live web chat
- Email, WhatsApp and in-app messages
Agent
Ticket deflection and handover
- Reads the sources
- Drafts the answer
- Hands to a person
Resolved-ticket history
- Past tickets
- macros
- notes
- Prior resolutions and their outcomes
Observability & evaluation
- OpenTelemetry
- Langfuse
- Supported monitoring/evaluation sources
Integration availability depends on the client's existing systems and API access.
Agent controls
Six wickets between the model and the customer
Six wickets on one line, the last the tightest. What passes through is set out in the map below.
L6 · Outermost — last line of defence
Inward → L1 · closest to the model
- L1 – L2
- Test whether a reply may stand
- L3
- Leaves the handover to a named engineer
- L4 – L5
- Keep the answer and the article behind it
- L6
- Hands straight to a person when signals degrade
How Nestack evaluates it
Evaluate the whole exchange — not only the reply that goes out.
Coverage runs the whole depth of the workflow, and every layer is cut by slice.
Surface — the reply the customer reads
- E1Final-output evaluationDid the reply hold to what the cited article actually states?
- E2Step-level evaluationDid the agent read the live article, the right version and the right intent?
- E3Tool evaluationDid it read and write the correct ticket and the correct thread?
- E4Confidence calibrationDo low-confidence replies actually attract more engineer corrections?
- E5Slice evaluationHow does performance change across specific intents?
- E6Business outcomeHow many replies needed a handover after the customer had already read them?
Floor — the request the customer actually made
Failure modes
Where each failure originates in the agent
Seven failure modes, each placed at the stage it first shows itself.
Agent lifecycle
Direction of processing →
01 · Retrieval
1 mode
- NV-03
Stale article read
The article read is not the one now published.
Stage gathers
The articles, the tickets and the intent read
02 · Reasoning
2 modes
- NV-04
Answer beyond the source
The reply states what no article states.
- NV-06
Dispositive request answered
A refund or a claim is settled in the reply.
Stage proposes
The disclosure, the articles and the intent
03 · Tool / write
2 modes
- NV-02
Thin answer sent onward
A reply goes out without the engineer read.
- NV-05
Same article returned again
The customer is looped back to one article.
Stage writes
Only where write access and approval policy allow it
04 · Output
1 mode
- NV-01
Handover asked for, not raised
The customer asks for a person and the thread stays put.
Stage returns
The reply the customer reads and then acts on
05 · Change / Version
1 mode
- NV-07
Silent scope drift
The agent starts answering what it used to hand over.
Stage tracks
Model, prompt, answer rules and article dates
- Sev-1 · a claim settled by the agent
- Sev-2 · a wrong answer reaches a customer
- Sev-3 · source degrades, reply held back
Affected slices
Billing intents absorb the handovers
An intent-level handover figure can read clean while billing and refund questions carry most of the escalations. Nestack reports the handover rate by intent, not only in total.
Slice performance — reported separately, not only in aggregate
Illustrative example| Slice | Failure rate | Lift | Lift vs. threshold | Status |
|---|---|---|---|---|
| Billing and refund intents | 11.2% | 3.7× | Review | |
| Warranty and returns intents | 8.0% | 2.6× | Review | |
| Multi-language requests | 5.0% | 1.7× | Watch | |
| Password and access intents | 2.1% | 0.7× | Normal |
Bar: handover-rate lift vs. password-and-access baseline · scale 0–4.0× · tick marks the 2.0× review threshold
2 of 4 slices over threshold
Evidence-linked improvement
What an answer past its limit costs
A cycle ends when the answer given past its limit is a regression case. That suite is what the next reply released is measured against.
Improvement cycle · five stages
Switchback — the path turns at Improve and returns at Learn
- 01
Detect
Handover rate rises on billing and refund intents.
- 02
Diagnose
The customer who asked three times, got the same article three times and then asked for a human is worked backwards until one cause is left standing.
- 03
Improve
The change ships numbered, with the answers that caused it attached.
- 04
Verify
Each touched answer case is run again, and one red holds it back.
- 05
Learn
It stays as a standing test, and the handover rules travel with it.
Learn → Detect
The return edge. The next reply is measured against a suite one case longer.
Typical build scope
Twelve workstreams across six weeks
The build scope read against the delivery timeline. Week structure follows the six-week plan — discovery, sources, answer drafting, evaluation, integration, then production validation and handover.
Workstream
Week 1Week 2Week 3Week 4Week 5Week 6
- 01Disclosure and automation-boundary definition.Week 1
- 02Help-centre and ticketing sources.Week 1, Week 2
- 03Intent-to-article and documentation-coverage mapping.Week 1, Week 2
- 04Request ingestion and intent reading.Week 2
- 05Answer drafting and source binding.Week 2, Week 3
- 06Confidence scoring and handover routing.Week 3
- 07Engineer handover workflow.Week 3, Week 4
- 08Help-desk and channel integration.Week 5
- 09Disclosure and handover cases.Week 4, Week 5
- 10Guardrails and handover controls.Week 4
- 11Answer-trail instrumentation.Week 5, Week 6
- 12Deployment, documentation and Agent Care handover.Week 6
12 workstreams · 6 weeks · bar shows the weeks a workstream is active — several run in parallel
Final scope and sequence confirmed in discovery
Engagement tiers
What each tier includes
Rows are the capabilities named in each tier's scope. Higher tiers include everything below them.
| Capability✓ in scope · — not at this tier | PilotOne channel, one language | ProductionProduction support desk | AdvancedMultiple channels / languages |
|---|---|---|---|
| Introduced at Pilot | |||
| Answer drafting to your documentation | ✓ | ✓ | ✓ |
| Named engineer handover | ✓ | ✓ | ✓ |
| Knowledge-base baseline | ✓ | ✓ | ✓ |
| Introduced at Production | |||
| Reporting by intent | — | ✓ | ✓ |
| Engineer review workflow in your systems | — | ✓ | ✓ |
| Approved write-back | — | ✓ | ✓ |
| Help-centre integration | — | ✓ | ✓ |
| Introduced at Advanced | |||
| Multi-product documentation | — | — | ✓ |
| Cross-team handover routing | — | — | ✓ |
| Large ticket volumes | — | — | ✓ |
| Multi-language answer controls | — | — | ✓ |
| Build price | From $5,000 | From $8,000 | Custom quote |
- Final build price
- Confirmed after discovery based on integrations, workflow complexity, ticket volume, approval controls and deployment requirements.
- Separate from build
- Build pricing is separate from recurring Agent Care, which covers managed monitoring, evaluations, incidents and verified improvements after launch.
What we need from you
What you bring, and what we build with it
Each input maps to a piece of build scope and a week in the delivery timeline.
You bring
We build with it
01Your live intents and the documentation each rests on
→Intent capture and documentation-coverage mapping
Week 102Representative help-centre articles and resolved tickets
→Source binding, answer drafting and the deflection baseline
Week 203Your support rota and the engineers it names
→Disclosure rules, handover rules and the automation boundary
Week 104Access to relevant APIs, feeds or exports
→Help-centre, ticketing and channel assessment, then integration setup
Week 205Answers you would not want quoted
→Handover cases and failure-mode testing
Week 406What no answer may decide
→Confidence scoring, handover routing, guardrails and release controls
Week 307A named engineer who takes the handover
→Release to the named engineer, then pilot and production validation
Weeks 5–6
Nothing else is required
Deployment, documentation and Agent Care handover are ours.
Delivery timeline
Four phases across six weeks
Two phases occupy week five here. Nothing was padded, and nothing was trimmed to tidy the shape.
Phase
W1
W2
W3
W4
W5
W6
- DiscoveryW1
- BuildW2 – W3
- EvaluateW4 – W5
- Pilot & LaunchW5 – W6
Week focus
W1Disclosure discovery, handover rules and the automation boundary
W2Source integration and the knowledge-base baseline
W3Answer drafting, confidence logic and release controls
W4Evaluation suite, handover cases and failure-mode testing
W5Help-desk integration, pilot replies and targeted corrections
W6One support month run under the support lead, then Agent Care handover
- Reading the band
- Each bar covers only the weeks its own work is named for, and week five is shared by design.
- At the end of W6
- Once the handover record validates, Agent Care picks the agent up.
- Duration
- Six-week plan shown · typical delivery 4–6 weeks depending on scope confirmed in discovery.
Next step · Customer Success AI agent
Build a ticket deflection agent around the handover your last bot never made.
Show us one intent you deflect and the article behind the last reply. The customer is told, in the first line, that a machine is answering — a support bot is not high-risk, and running one under your own brand is still a provider argument you would have to answer.
- Typical delivery
- 4–6 weeks
- Deployment
- Your help centre
- Named engineer
- Disclosed first
- After launch
- Agent Care available
Nestack Agents · Ticket deflection
AGT-CX-06 · Agent Care available after launch