A link, sight unseen.
Everything the assistant says is spoken once and gone. There is no screen, no link to hover, no second read. So help traveled off the call: the assistant named the topic and offered to text an article, because instructions belong somewhere you can look at them. The trouble is what that offer asks of a caller. Trust a link you cannot see, from a voice that has not shown it understood your problem. Most people said no, and waited for a person.
Every refused offer became an expert call.
On this line there is no quiet exit. A caller who refuses self-help does not close a tab, they wait for an expert, and the call costs what expert calls cost. That is why the two dials this work is scored on are acceptance, the share of offered help that callers take, and containment, the share of calls that end with no expert on the line. When the work began, about 30 percent of callers offered self-help accepted it. That was the starting position, not a result.
The repair thread had already shown the dials could move. Four different problems share the sentence "I'm locked out of my account," and reading the wrong fix aloud costs the whole call. The pattern I designed spends one turn on a shaped clarifying question, then acts on the answer. On payroll tax calls in 2022, that redesign moved containment from 12.5 to 18.3 percent and acceptance from 23 to 32. When language models arrived, I tested whether they could carry the same judgment: on the disambiguation prompt, the existing approach was correct 53.3 percent of the time, and the treatment prompt I wrote reached 76.7.
The insight the whole case rests on: the problem was never that the answer didn't exist. It was that the offer carried no proof of understanding. Put a piece of the answer in the caller's ear, and accepting help stops being an act of faith.
What it says, when it asks, and how it gets out.
I wrote the behavior as a spec before any prompt existed. The deliberate choice at the center of it: the spoken answer is about three short sentences, a teaser, and it will not fully answer the question. That is on purpose. Its job is to prove the assistant understood and make the offer worth taking. The full steps belong on a screen. The rest of the spec is the part that matters most on a phone line, which is what happens when things go wrong: every failure has a landing, and the caller can always get out.
About three short sentences: the core of the fix, only the most important information, deliberately not the whole answer. The full steps travel by text or email, with a line on what they include.
Open follow-up questions, as many as the conversation earns. Never repetitive, never artificial. When the caller sounds frustrated, acknowledge it before asking again.
Always available. A caller who asks for a person transfers on the spot, and so does a caller who starts pressing digits.
Every failure lands somewhere. A timeout falls back to default routing so the line stays fast. Hitting the turn limit transfers. A question the model can't answer transfers.
The intent mapped at the top of the call stays with the call, so a transfer lands exactly where it would have landed without the new experience.
Routing parity is the least glamorous line in the spec and the one I would defend hardest. A new experience that loses the caller's context on the way out is worse than no new experience, because it spends the caller's patience twice.
The rules that make an answer sayable.
The prompt is where the content bar becomes enforceable. Steps that work on a screen are noise in the ear, so the rules ban lists, URLs, and numbered instructions outright, and make sequence ride on spoken connectives instead. A bare noun never gets an answer; it gets one clarifying question, with no apology padding the turn. This is the part of the work that translates directly: an instruction set is where a design decision either survives contact with a model or quietly doesn't.
Your role is to provide a short, accurate response using a friendly and
conversational tone.
If the question is a standalone product name or object with no clear action
("billing", "invoices", "help with my account"), tell the customer you are
happy to help but need more details. Do not apologize. Do not answer until
you clearly understand the action to be taken.
Once the action is clear:
1. Be brief and conversational. Provide an answer that is a teaser snippet
of the full answer: very concise, only the most important information.
2. Do not use bulleted or numbered lists in your response.
3. Do not provide any URLs in the response.
4. Do not list step-by-step instructions. Use first, then, next, finally...
instead of numbers.
5. After providing a teaser snippet, offer to send the more detailed
solution through text or email.
Keep words simple and specific. Use active verbs, and avoid jargon,
gerunds, and passive sentence constructions.Rules only earn their place when you can hear what they change. The same standards, as utterance pairs:
"I found an article that can help with invoices. Would you like me to text you a link?"
"Happy to help with invoices. What are you trying to do: create one, send one, or fix something that went wrong?"
"Step one: open the Sales tab. Step two: select the invoice. Step three: click the date field."
"First, open the Sales tab. Then pick the invoice. Once it's open, look for the date near the top."
"Let me read you all the steps. First open Settings, then Accounts, then Billing, then scroll down, then..."
"You can fix that in your invoice settings, and it takes about a minute. I can text you the full steps. Would you like that?"
One low-risk intent, then a throttle.
This was the phone line's first generative experience, so the release plan mattered as much as the design. It did not go straight to the full line. I recommended starting on a single low-risk intent: a small slice of call volume, mostly straightforward questions, no special expert tools required, and containment sitting below the assistant's average. Low risk, with room to move. From there, every step had to be earned by the one before it.
That plan is what carried this from a prototype the platform couldn't support in 2023 to a live experiment on December 10, 2024. It reached significance, and the experience moved to full production shortly after.
What shipped, and what it moved.
Here is the call the spec and the prompt produce: a teaser that proves the assistant understood, then the offer.
Containment lift measured at the December 2024 experiment, at significance, then moved to full production. The hypothesis going in was six points or more, so this is a real effect and smaller than the bet.
Self-help acceptance on the login and password reset flow, after the clarifying-question redesign in 2024.
The share of those calls resolved with no expert on the line, on the same flow.
Savings from the login redesign, tracked after launch.
The lift was smaller than the hypothesis, and I would rather say that than round it up. What the work proved is more durable than the number: on a channel where you get one pass and no screen, the fastest way to earn a customer's next thirty seconds is to show them you understood the last thirty. Everything else in the spec, the escapes, the fallbacks, the routing parity, exists so that when the assistant can't do that, the caller never pays for the attempt.
Sending better help was this case's job, and also its ceiling. A later prototype took the next step, staying on the line and walking the customer through the fix live: the voice troubleshooting POC.