Podcast episode
Why support prompts are policy documents, how they get reviewed, and the one rule that stops agents from promising ship dates.
Audio drops soon
Why a support prompt is a policy document
Audio drops soon — subscribe and it lands when it goes live.
A mid-size support desk can handle thousands of tickets a month. When a third of replies start as a model draft, every one of those drafts should go through the same review process as a change to the refund policy — because that is what the prompt is.
Six weeks into one rollout, three separate agents promised customers a ship date for a feature that had no ship date. None of them invented it maliciously. All three used a prompt that said “be helpful and reassure the customer,” and the model filled the gap the way models do.
The fix was not a training session. It was a field in the prompt — an explicit statement of what the agent is authorised to offer — and a rule that anything outside it is a bug in the prompt, not a mistake by the agent.
Cancellations. Anything involving a death or a medical situation. Anything where the customer used the word “lawyer.” The value of a human reply in those moments is not the words. It is that a person read it, and the customer can tell.
Skip the vanity survey. Count how many threads reach a fourth reply, and how many get escalated to a human lead. If both go down after you add authority fields and refusal rules, you are measuring something real. Still: do not over-claim causation.
Write the authority list before the tone guidelines. “Be warm” without “never promise dates” is how you get warm lies at scale.
Drafts a response to an angry customer that acknowledges the real complaint, commits to something specific, and never apologises for things that aren't your fault.
A diagnostic-then-edit pass that names the specific tells in a draft — the tricolons, the hedges, the empty transitions — and fixes them without flattening your voice.
