You've probably seen this chat, or been the customer in it:
Want to see one full play before you read on? Play 3 of 15 from The CS Agent Playbook shows how an AI agent turns a long escalation thread into a one-page brief for leaders, and it is free as a 3-page PDF: get the free sample play.
Customer: my invite button is greyed out
Bot: Here's our article on adding users!
Customer: I read it. Can I talk to a person
Bot: I can help! What would you like to do?
Customer: A PERSON
Bot: Transferring you now. Someone will be with you right away.
(two hours later)
Agent: Hi, how can I help you today?
Three things broke. The customer asked for a person twice. The bot promised "right away" with nobody available. And the agent got no context.
None of these needs a new tool. They need written rules for when the bot hands off, a short brief that travels with the handoff, and a first human reply that proves someone read the chat. Here's how to set each up, with scripts and prompts you can copy. (Companies and people in the examples are made up.)
Step 1: One request for a person is enough
When a customer types "human", "agent" or "let me talk to someone", route on that first request. No "before I transfer you, can I try one more thing". Each extra try lands on a customer who is already frustrated.
People don't only type "human". They write "real person", "someone who knows" or "call me", with typos and in other languages. So build the trigger from your own transcripts.
Paste this into whichever AI assistant your company approves:
Search [conversation export, last 30 days] for every way customers asked to speak
to a person. Quote each distinct phrasing once, with a count and 2 example
conversation IDs.
Then list conversations where the customer asked more than once before a handoff
happened, with each request quoted and the bot's reply in between.
This is a draft for me. Don't change the bot.
Check it: read two ask-twice conversations in full. If the customer accepted the bot's reply in between, it isn't a miss.
What the bot says when it routes:
Of course. I'm passing this to the team now with everything you've told me, so you won't have to repeat it. [The current wait is about X minutes, or: You'll hear from us by X.]
Step 2: Hand off after two failed tries
The second trigger is the loop: the bot answers the same question twice, the customer is still stuck, and the bot tries a third time.
- Count tries per problem, not per message.
- A try has failed when the customer says it didn't work, repeats or rephrases the question, or asks for a person.
- Start at two strikes. Use one strike for high-stakes topics like billing and account access. Allow three only where your own transcripts show third tries actually working.
At the handoff, the bot should sound like it noticed:
That hasn't fixed it, and I don't want to keep you going in circles. I'm passing this to a person now, with what we've tried.
Step 3: Watch for mood turns and never-automate topics
Two more triggers round out the set.
Mood turns. Messages get shorter, sharper or all capitals while the bot stays cheerful. Agree a few plain signals with your team: whole sentences in capitals, swearing, phrases like "this is ridiculous", or the customer saying they've already contacted you about this. On billing, account access or data, one signal hands off. Elsewhere, two. And take stock lines like "Great question!" out of the bot's replies.
Never-automate topics. Some topics route to a person on sight, whatever the bot thinks it could do: money disputes and refunds outside policy, legal threats or any mention of lawyers or regulators, security reports and possible data exposure, account access requested by someone who isn't the account holder, cancellations, and a customer who seems distressed or at risk. For distress, legal and security topics, the wording and destination come from your company's policy owners. Listen for real phrasing like "my lawyer", "chargeback" or "I'm reporting you".
The whole set, as starting points to test against your own transcripts, not standards:
| Trigger | Topics | Starting threshold |
|---|---|---|
| Asks for a person, any wording | All | First request |
| Failed tries on the same problem | All | 2 (1 for billing, access) |
| Mood signal | Billing, access, data | 1 signal |
| Mood signal | Everything else | 2 signals |
| Never-automate topic | Your list | On sight |
Step 4: Never promise a wait you can't see
"Someone will be with you right away" at 2 a.m., into a queue nobody reads until 9, is a broken promise. Give the bot your real staffed hours for each channel and each destination team, holidays included. The rule: the bot never says "shortly", "right away" or "in a few minutes" unless it can see that a person is available.
After hours, it says this instead:
Our team is offline right now and back at [time and time zone]. I've saved everything you've told me in ticket [number], so whoever picks it up starts where we left off. You'll get a reply by email.
Step 5: Send a five-line brief with every handoff
This is the fix for "Hi, how can I help you today?" Have the bot write the same five lines on every handoff, shown at the top of the ticket above the transcript:
Goal: [what the customer wants, in their words]
Verified: [facts checked through a tool, with the method] or none.
Customer says: [anything not checked]
Tried: [what the bot suggested, and what happened] or none
Promised: [anything the bot told the customer, word for word] or none
Next: [one suggested step]
Filled in, it looks like this:
Goal: "I need to add a second admin before our audit next Thursday."
Verified: Ostrander Labs, signed-in admin (session check), Growth plan.
Customer says: the invite button is greyed out.
Tried: sent the "Adding users" article. No change.
Promised: a person will reply by email today.
Next: check whether the account has reached its seat limit.
Two lines need the most care. Customer says keeps anything the bot didn't check through a tool out of Verified, so nobody acts on a claim as if it were a fact. Promised matters because the customer may remember every promise the bot made, so the person needs to know them too. If a line is empty, the bot writes "none".
The test: a brief works if the person picking it up can write their first reply without opening the transcript. Check five briefs a week against that.
Step 6: Make the first human line prove you read it
Read the brief before typing. The first line names what's been tried, skips it, and says what happens next or asks the one open question.
Hi Tomasz, thanks for waiting. You need a second admin before next Thursday's audit, so I'm checking your seat limit now.
Hi Ines, I can see the reset code expired twice. Let's skip that and I'll sort out your access directly.
The rule: if your first line could be sent to any customer, rewrite it. Macros that open with "Thank you for contacting us" can tell the customer nobody read the chat. Keep example first lines in your macros for your top handoff reasons, and expect people to edit them each time.
Step 7: Count the misses every week
Two numbers tell you whether the handoff is holding up:
- Ask-twice count. Conversations where the customer asked for a person more than once. Read every one. The aim is zero, because one request is enough.
- Brief pass rate. Briefs that pass the Step 5 test, out of the five you check each week. If it's below 4 of 5 two weeks running, fix the brief instructions first.
Write the count and the denominator, like 3 of 5, not just a rate.
Where to start this week
If you only do three things: route on the first request for a person, switch on the five-line brief, and agree who can switch the bot to "route everything to people" when it starts giving bad answers. Those are the gaps a customer can see, and none of them needs a new tool.
If you want to see a full play in this format, with its prompt, a fill-in list for every bracket, guardrails and a made-up sample result, the free sample is one complete play from The CS Agent Playbook: the Escalation Brief for Leadership, as a 3-page PDF. Get the free sample play.
