Hand a draft to the person answering, surface only the part of the record the reason for contact justifies, and leave the sending to a named queue lead who edits what goes out.
A draft is offered to the person answering, and this agent never speaks to the customer at all.
02
A reply is sent by that person, and Art. 50(1) binds the provider of a system, not you.
Reason
03
A draft reviewed and sent by a human as the main interlocutor is excepted by the Guidelines.
04
A reply whose review is a mere possibility circumvents the duty, which that paragraph refuses.
05
A draft whose object is the customer problem sits outside the four verbs of Annex III 4(b).
Decide
06
A draft scored per person, or a ticket routed by behaviour at the desk, moves it inside.
07
A draft tool that also scores is not classified by halves, says guidance that is still draft.
Out
08
A draft tuned to mood is prohibited for the person answering, high-risk for the customer.
09
Execute write actions only inside the approval boundaries agreed during implementation.
→Product statement
Drafting, scoping the record to the reason for contact and logging every read belong to the agent. Sending belongs to a named queue lead, who edits the draft and owns what goes out.
Example workflow
One reply, drafted to sent
AgentHuman
1Ticket arrives at the queueEmail, chat, web form, an in-app session or a thread routed in from another queue
2Record scoped to the reasonThe reason for contact, the fields it justifies and every read logged against the ticket
3Reply drafted for a personThe draft, what each claim rests on, the flagged lines and confidence
4Controls appliedRecord-scope checks, source checks on each claim, inference checks and confidence threshold
No human action required
Stages 1 to 4 run unaided, and nothing reaches the customer at any of them — the agent is drafting, and the lead lane opens at the confidence gate.
5DecisionBranches at the confidence threshold
High confidence
Goes to the named queue lead to send.
Low confidence
Adds a second reviewer read first.
Queue lead review
The draft is held with the record it drew on, its flagged lines and the confidence.
Approve · Edit the draft · Send to reviewer
Sent — by the named queue lead▼
6Conversation record updatedOnly where write access and records policy allow it
7Outcome evaluatedDraft survival by intent, edit outcomes, review depth and what review found
Edits
Each lead edit is counted in the evaluation.
What should not run autonomously
Human approval stays in control
Outside the boundary — human approval required8 items
Sending a drafted reply to a customer.
Deciding what the customer is owed.
Scoring or ranking the people at the desk.
Inferring the emotion of anybody at all.
Automation boundaryAgent acts unaided
✓Draft the reply and show the source of each claim.
✓Surface only the part of the record the reason for contact justifies.
✓Log every read, and every edit made before sending.
✓Show how much of the draft survived, counted by intent not by person.
Nothing reaches the customer here; a named queue lead edits the draft and sends it.
Judging whether a review was deep enough.
Telling a customer a claim has been checked.
Choosing which tickets a person is given.
Changes to scope, drafting or approval rules.
Example output
One drafted reply, annotated
This serves a desk where staff who over-read a customer record have been prosecuted as individuals while their employer was not; below is one draft exactly as the agent leaves it.
Draft output · single replyIllustrative example
Conversation
Drafted line
Record surfaced
Claim rests on
Confidence
Sent by
Inbound, billing query
Your last invoice was raised on the older plan rate
Billing fields only
Plan record, 3 August 2026
Held unsent
The named queue lead, by name
As receivedTaken from the ticket and the plan record as they stand — nothing on this side is written by the agent.
What the record holdsTicket threadPlan recordRead log
Why nothing left hereSending a reply to a customer is a call a named queue lead makes.
ActionApproveEdit the draftSend to reviewer
What the score decidesBelow the configured threshold the draft picks up a second read before the lead.
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 reply that leavesFrom the ticket in front of you
03Drafting
Draft it, then hand it over
The customer-success ticket-deflection agent answers the customer directly; this one never speaks to the customer, and the person at the desk is its user rather than its subject.
01Approved path
Review is not a rubber stamp
The exception is not a checkbox but a claim about what the person did, and an approval faster than the subject line can be read is not a review.
02Human review
What was checked, and not found
No US law requires telling a customer that a human reply was AI-drafted: the California bot statute misses on the bot, the forum and the intent, Utah needs an interaction that never happens, Colorado repealed its act.
04Build an evidence trail
The draft, the agent who edited it and the reply that actually went stay together.
Integrations
Typical integrations
Five system groups connect to the same agent. Which of them are in scope is decided in discovery.
Ticketing and support desksZendesk · Intercom · Salesforce Ticket threads and queue rules
Customer recordsCRM · billing · order systems Entitlement and plan fields
Knowledge and help centreZendesk Guide · Notion Published articles and when each changed
Agent
Support copilot
Reads the ticket Drafts the reply Holds for the lead
Workflow and recordsJira Service Management · Slack Approvals and the record of sending
An intent-level review-depth figure can read clean while refund and goodwill requests carry most of the editing. Nestack reports the edit rate by intent, not only across a whole desk in total.
Slice performance — reported separately, not only in aggregateIllustrative example
Slice
Failure rate
Lift
Lift vs. threshold
Status
Refund and goodwill requests
9.3%
3.7×
Review
Entitlement and plan disputes
6.6%
2.6×
Review
Technical fault reports
4.1%
1.6×
Watch
Order status queries
1.7%
0.7×
Normal
Bar: edit-rate lift vs. order-status baseline · scale 0–4.0× · tick marks the 2.0× review threshold2 of 4 slices over threshold
Evidence-linked improvement
What an unread draft costs
A cycle ends when the draft that went out unread is a standing case. That suite is what the next reply sent is measured against.
Improvement cycle · five stagesSwitchback — the path turns at Improve and returns at Learn
01Detect
Approvals speed up on one ticket intent.
02Diagnose
The draft that was approved in the time it takes to read a subject line is worked backwards until one cause is left standing.
03Improve
The change ships numbered, and the drafts that forced it ride with it.
04Verify
One draft case still failing is enough to hold the release back.
05Learn
It is kept for good, and the drafting rules are amended in the same commit.
Learn → DetectThe return edge. The next draft 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, drafting workflow, evaluation, integration, then production validation and handover.
WorkstreamWeek 1Week 2Week 3Week 4Week 5Week 6
01Support-queue discovery and automation-boundary work.
02Ticketing, record and knowledge feeds.
03Reason-for-contact and prohibited-inference mapping.
04Ticket and record reading.
05Drafting logic and claim binding.
06Confidence scoring and reviewer routing.
07Queue lead review workflow.
08Ticketing-and-record integration.
09Draft and review cases.
10Guardrails and sending controls.
11Draft-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 queue, one intent setProductionProduction support systemsAdvancedMultiple queues / brands
Introduced at Pilot
Drafting to your record and rules✓✓✓
Queue lead approval✓✓✓
Reply-corpus baseline✓✓✓
Introduced at Production
Reporting by intent—✓✓
Lead review workflow in your systems—✓✓
Approved write-back—✓✓
Ticketing-and-record integration—✓✓
Introduced at Advanced
Multi-brand drafting rules——✓
Multi-stage lead approvals——✓
High ticket volume——✓
Multi-queue drafting 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 queues and the intents each one carries→Intent mapping and record-scope bindingWeek 1
02Representative tickets from each intent→Ticket ingestion, drafting logic and the reply baselineWeek 2
03The record fields each reason for contact justifies→Record-scope mapping, intent binding and the automation boundaryWeek 1
04Access to relevant APIs, feeds or exports→Ticketing, record and knowledge assessment, then integration setupWeek 2
05Drafts you would not want quoted→Review cases and failure-mode testingWeek 4
06What no draft may commit→Confidence scoring, reviewer routing, guardrails and release controlsWeek 3
07A named queue lead who sends the reply→Queue lead review workflow, 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
The bands below are counted, not spaced for looks; the fifth carries two because those two coincide.
PhaseW1W2W3W4W5W6
DiscoveryW1
BuildW2 – W3
EvaluateW4 – W5
Pilot & LaunchW5 – W6
Week focusW1Queue discovery, record-scope mapping and the automation boundaryW2Ticketing and record integration and the reply baselineW3Drafting logic, confidence scoring and review controlsW4Evaluation suite, draft cases and failure-mode testingW5Knowledge integration, pilot drafts and targeted correctionsW6One support month run under the queue lead, then Agent Care handover
Reading the bandA bar sits on the weeks its own work is named in, and week five carries two because both run.
At the end of W6When the reply record validates, Agent Care takes the agent on.
DurationSix-week plan shown · typical delivery 4–6 weeks depending on scope confirmed in discovery.
Next step · Customer Support AI agent
Build a support copilot around the review your desk cannot now show it actually did.
Show us one queue and the replies it sent last week. The person who reviews the draft and sends it is the interlocutor, and the exception rests on that being true rather than on a button existing. Bring one reply approved faster than it could be read.
