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.
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
AgentHuman
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.
5DecisionSplits at the handover gate
Answer inside the documentation
Goes back as the drafted reply.
Anything dispositive
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 required8 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 boundaryAgent 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 requestIllustrative example
Request
Drafted reply
Disclosure
Source of record
Confidence
Held for
Password reset, self-serve plan
Reset steps and the article behind them
Disclosed at first reply
Help centre, 5 May 2026
Answered, not closed
The named engineer, by name
As receivedDrawn from the published help centre and a resolved ticket, and it decides nothing the customer is owed.
What the record holdsHelp-centre articleResolved ticketProduct release note
Why no closure hereClosing a ticket is a judgement a named engineer makes, not a model.
ActionSendAdd sourceTake the ticket
What the score decidesBelow the configured threshold a reply gets an engineer read before the customer sees it.
Value
Where AI adds value
The same four claims, placed at the point in the workflow where each one applies.
Where the value landsValue 01 – 04
Every requestFrom the channel it arrived on
03Disclosure
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.
01Approved path
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.
02Human review
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.
04Build 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 knowledgeZendesk Guide · Intercom Help-centre articles and release notes
Ticketing and help desksZendesk · Freshdesk · Front Service Cloud · HubSpot Desk
Messaging and channelsIn-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 historyPast tickets · macros · notes Prior resolutions and their outcomes
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 aggregateIllustrative 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 threshold2 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 stagesSwitchback — the path turns at Improve and returns at Learn
01Detect
Handover rate rises on billing and refund intents.
02Diagnose
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.
03Improve
The change ships numbered, with the answers that caused it attached.
04Verify
Each touched answer case is run again, and one red holds it back.
05Learn
It stays as a standing test, and the handover rules travel with it.
Learn → DetectThe 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.
WorkstreamWeek 1Week 2Week 3Week 4Week 5Week 6
01Disclosure and automation-boundary definition.
02Help-centre and ticketing sources.
03Intent-to-article and documentation-coverage mapping.
04Request ingestion and intent reading.
05Answer drafting and source binding.
06Confidence scoring and handover routing.
07Engineer handover workflow.
08Help-desk and channel integration.
09Disclosure and handover cases.
10Guardrails and handover controls.
11Answer-trail instrumentation.
12Deployment, documentation and Agent Care handover.
12 workstreams · 6 weeks · bar shows the weeks a workstream is active — several run in parallelFinal 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 tierPilotOne channel, one languageProductionProduction support deskAdvancedMultiple 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 priceFrom $5,000From $8,000Custom quote
Final build priceConfirmed after discovery based on integrations, workflow complexity, ticket volume, approval controls and deployment requirements.
Separate from buildBuild 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 bringWe build with it
01Your live intents and the documentation each rests on→Intent capture and documentation-coverage mappingWeek 1
02Representative help-centre articles and resolved tickets→Source binding, answer drafting and the deflection baselineWeek 2
03Your support rota and the engineers it names→Disclosure rules, handover rules and the automation boundaryWeek 1
04Access to relevant APIs, feeds or exports→Help-centre, ticketing and channel assessment, then integration setupWeek 2
05Answers you would not want quoted→Handover cases and failure-mode testingWeek 4
06What no answer may decide→Confidence scoring, handover routing, guardrails and release controlsWeek 3
07A named engineer who takes the handover→Release to the named engineer, then pilot and production validationWeeks 5–6
Nothing else is requiredDeployment, 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.
PhaseW1W2W3W4W5W6
DiscoveryW1
BuildW2 – W3
EvaluateW4 – W5
Pilot & LaunchW5 – W6
Week focusW1Disclosure discovery, handover rules and the automation boundaryW2Source integration and the knowledge-base baselineW3Answer drafting, confidence logic and release controlsW4Evaluation suite, handover cases and failure-mode testingW5Help-desk integration, pilot replies and targeted correctionsW6One support month run under the support lead, then Agent Care handover
Reading the bandEach bar covers only the weeks its own work is named for, and week five is shared by design.
At the end of W6Once the handover record validates, Agent Care picks the agent up.
DurationSix-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.
