Support

Questions this playbook answers

• Our customers keep re-explaining their problem to every bot and every agent. What would it take to stop that?
• What should a support AI handle on its own, and exactly when should a person take over?
• How should tone change with the customer's situation without becoming a script?
• Should support reach out before the customer notices a problem, and when is silence better?
• How do we prove it worked without being fooled by deflection numbers?

The moment

Friday, 6:40 a.m. Ines runs dispatch for a 120-vehicle regional delivery company that uses Larkspur Systems' routing software. (Larkspur is a fictional composite used throughout this handbook.) Her drivers leave at seven. For the third time in two weeks, the overnight route sync has failed, and her dispatch board is empty.

She opens the support chat. The assistant asks for her account number. Then which product she uses. Then asks her to describe the problem. She types it out. It suggests clearing her browser cache and links a help article. She asks for a person. The queue says 35 minutes. When the agent arrives, the first message is: "Can you confirm your account number and describe the issue?"

Everything Ines typed was already inside Larkspur. The support desk held two earlier tickets with the same symptom, both closed as "resolved in release 8.2." Engineering had linked the failure to a known defect affecting about 60 accounts. Telemetry showed her sync job failing at 2:14 a.m., four hours before she noticed. Her last ticket ended with "if this happens again I am taking it to our COO." Her renewal is ten weeks out. None of it reached the chat.

She is not unusual. In Zendesk's 2025 survey of 6,182 consumers across 22 countries, 74% said they are frustrated when they have to repeat information, and 81% want agents to continue a conversation without backtracking [1]. Salesforce's 2020 survey of 12,000 consumers and 3,600 business buyers found 65% "often have to repeat or re-explain information to different representatives," and 54% said it "generally feels like I'm communicating with separate departments, not one company" [2].

Here is the sentence this playbook turns on: the customer should never be the integration layer between your systems. Every question you ask that your records could have answered is a small bill you hand the customer for your own architecture.

The decision

Support personalization is not a warmer greeting. For every contact, the system makes four decisions, and each one has a "less" option.

1. What to ask. Ask only what memory cannot answer, or what must be confirmed. Everything else is stated back, briefly, so the customer can correct it.
2. How to respond. The register (length, warmth, how much to explain, whether to apologize) follows the customer's situation, not a persona. A third recurrence of an outage gets fewer words and more ownership than a first-week how-to question.
3. Who handles it. The AI resolves, the AI drafts and a person decides, or a person owns the case. This is the handoff line.
4. Whether to reach out first. Proactive help when the system knows before the customer does. Including the decision not to.

The action space is the one from the decision layer (Chapter 14): answer, ask, route, escalate, reach out, suppress other programs, wait, or do nothing. Support adds one discipline the other functions can skip. A support contact is a hard constraint on everyone else. While a customer has an open, severe case, the expansion email, the survey, and the "how are we doing?" check-in should not go out (Chapter 14 walks through that exact upsell).

For Ines, the right decisions were small and specific. Skip intake: her identity, product, and history were known. Recognize the recurrence and the stated escalation, and route straight to a senior engineer-facing agent with the case assembled, instead of the cache article. Tell her what was already known and what happens next. Suppress Larkspur's marketing and expansion programs for her account until the fix holds. And, at 2:30 a.m., before any of the 60 affected accounts woke up, send each dispatch lead a notice: what failed, the manual workaround, and when to expect the next update.

Not every repeat question is waste. Identity verification before account changes is a legitimate ask, and so is confirming a fact past its freshness window ("Are you still the admin on this account?"). The rule is to confirm, not interrogate: one question that checks a stored answer instead of three that rebuild it.

What you need to know

Continuity is a memory problem before it is a model problem. Two kinds of memory matter here, with different lifetimes (Chapter 13). Entity memory is what Larkspur knows about Ines and her company, and it outlives every ticket. Case memory is the working file for this problem: symptom, steps tried, promises made, who owns it now. Most support stacks have the second, locked inside the ticketing tool, and none of the first.

The minimum shape, using the Boundary Rule from Chapter 10 (if you would filter on it, it is a property; if you would put it in a paragraph, it is a memory):

What	Form	Why it matters in support
Resolved identity and role	Property, from the identity spine (Chapter 9)	Greets the right person with the right account; a wrong merge here shows one customer another's data
Open and recent cases: symptom, resolution, whether the fix was confirmed	Properties plus case memory	Detects recurrence; "same issue before?" is the single most valuable field
Links to known defects and incidents	Graph edges	Connects one ticket to 60 accounts; enables proactive notice
Product state and telemetry (failed jobs, errors, configuration)	Properties, with timestamps	Knows before the customer does
Promises made: callbacks, credits, "we will tell you when it is fixed"	Typed constraints (Chapter 18)	A promise in ticket prose is a promise every other agent will miss
Stated preferences: channel, hours, "call my deputy"	Properties with source and date	Respects what the customer already said
Escalation trajectory and stated frustration	Memory with source; a derived severity property	Changes routing and register
Commercial context: renewal date, tier, open deals	Properties	Used to suppress selling and inform routing; never to change what the customer is entitled to

Two freshness rules do most of the work (Chapter 11). A closed ticket is not a fixed problem: "resolved" should mean the telemetry confirms it, not that an agent clicked a button. And a stated fact about a person decays; the admin who opened last year's ticket may have left.

Some things should stay out of the customer-facing context entirely. Internal notes ("customer is difficult") must never reach generated output, and a prompt instruction will not stop it. In the governed personalization engine I built, the same wall separates what a seller sees from what a buyer reads: internal fields are declared prohibited context, so they never enter the prompt, and an explicit serializer decides what leaves the system, so a newly added internal field cannot leak by default (Chapter 18). Case notes and replies need that wall. Sensitive context a customer shared in a hard moment (an illness, a bereavement) may change whether and when you contact them; it should almost never be quoted back to them (Chapter 19).

Support is also where customers paste what they should not: a password, a card number, an API key inside a log. In a self-hosted memory system I built, secrets, checksum-validated card numbers, and US Social Security numbers are removed before any external model call; emails, phone numbers, and a supplied name list can be swapped for tokens and restored locally afterward; your own patterns (account or case numbers) plug into both; and each call can log a hash of what was sent. Two limits: tokenization governs what the provider sees, not what you store, and an unlisted name in free text is not caught (Chapter 19).

Scope the agents too, as that system allows (opt-in): a key per bot and copilot, so a read-only agent's write tools are simply absent; record visibility enforced inside the database, failing closed; and a per-document audience, so one account's negotiated exception is readable only by those who can see that account.

The action

Support runs on three clocks, and each needs a different architecture (Chapter 17).

Real time: chat and voice. The customer is waiting, so there is no time to research. The case brief (identity, open cases, recurrence, linked incidents, promises, stated preferences) should be computed when the signal arrives: when a ticket opens, a sync job fails, or an incident is declared. At contact, the assistant reads the brief rather than rebuilding it. The first message then states what is known and asks one confirming question: "I can see the overnight sync failed again at 2:14, the third time since release 8.2. Is it the same symptom as last week?"

When the brief is thin or late, the assistant should say less, not guess. In the engine I built, when enrichment misses its deadline the record falls back to a deterministic, lower-specificity brief instead of inventing detail. Specificity can degrade before trust does. The degraded support line is "I can see your account and I am checking the sync status now," never a guessed cause.

Figure SP.1. Compute the case brief when the signal arrives, then confirm instead of interrogating.

Human-assisted: the copilot. The strongest field evidence for AI in support is on this side of the line. In a study of 5,172 support agents, access to a generative AI assistant raised issues resolved per hour by 14% on average and by 34% for the least experienced agents, and improved customer sentiment [3]. The mechanism the authors point to is the spread of top performers' practice. For personalization, that means the novice agent who picks up Ines's case sees what the best agent would have looked up.

Async: email replies and proactive notices. These can take minutes and should. A proactive notice is a personalized decision: who is affected, what they will see, what to do in the meantime. It is not a broadcast. Promises belong here too: "we will tell you when it is fixed" should be a recurring job that checks open promises against telemetry and drafts the follow-up once the fix holds, not a sentence in a ticket. The memory system I built runs scheduled prompts and queued jobs beside the memory, and can hand a long investigation to a provider's hosted agent on a memory-only credential scoped to that job and revoked when it ends (Chapter 13).

The handoff. Most support failures happen at the line between machine and person, so draw it explicitly. Route to a human when:

• the customer asks for one (honored on the first request, never looped back to the bot);
• the issue has recurred, or the customer has stated an escalation;
• the answer would state or change a commitment: a policy, a refund, a credit, an exception (these belong on the irreversible-action list, Chapter 18);
• the assistant's evidence is thin or its sources disagree;
• the conversation involves sensitive context.

A good handoff moves state, not transcripts (Chapter 13). The person receives the case record and the assistant's draft, and the customer is told who is taking over and that they will not need to repeat anything. The test is simple: did the human's first message ask for something the system already had?

Figure SP.2. Make the handoff rules explicit and hand over the case record, not the transcript.

Tone. Tone rules are governed centrally, not written into each bot's prompt: own the recurrence, drop the upbeat filler during an outage, never sell inside a support thread. One rule is fixed in code: tone may change how something is said, never what the customer is entitled to. In the memory system I built, guidelines are retrieved for the agent on every action (recall the customer, retrieve the rules, act, store the outcome), and every policy edit keeps the version it replaced, so you can show which refund rule was in force the day a reply cited it.

Disclosure. Say it is an AI. As of September 2026, the EU AI Act's Article 50 requires that people be told they are interacting with an AI system, unless that is obvious, from August 2, 2026 [4]. Outside the EU it is still the honest default. (Not legal advice; see the companion regulation note.)

Proactive help. The evidence is thinner here than the enthusiasm. The best controlled result I know is from onboarding, not incidents: in a 2011 field experiment at a cloud provider, new customers who received proactive guidance were half as likely to churn in their first week, asked about 20% fewer support questions, and used about 47% more of the service over eight months; effects were strongest for less experienced customers [5]. That is one provider and one kind of outreach. For incident notices, I have not found comparable controlled evidence. The decision rule I use: reach out when the customer is affected in a way they will experience, or that changes a decision they are about to make. Do not turn support signals into engagement nudges; Chapter 14's sleeping dogs apply here too. The Customer Success playbook covers the other side of the line: an open severe case pauses success plays until the fix holds, and support hands back what happened and what was promised.

What can go wrong

Failure story: The Invented Policy. In April 2025, users of the coding tool Cursor were being logged out when they switched machines. They wrote to support and got answers from "Sam," which told them the logouts were expected under a policy limiting use to one device. There was no such policy. Some users, who reported assuming Sam was a person, cancelled their subscriptions. A co-founder apologized for an "incorrect response from a front-line AI support bot" [6][7]. A year earlier, a Canadian tribunal had held Air Canada responsible for a bereavement-fare policy its chatbot described wrongly, rejecting the argument that the bot was "a separate legal entity" [8].

Both failures share a shape. The assistant stated a commitment (a policy) that it had not retrieved from the governed source, nothing checked the claim before it was sent, and in Cursor's case the customer did not know they were talking to a model. The fix is not a better prompt. Policy statements are claims that must cite the governed policy they come from, or the assistant must say it will check and hand off (Chapter 15's "specific and true, or honestly general" applied to terms and conditions).

Other risks to name in your design review:

• The Re-intake Loop. Every channel and every tier starts intake from zero. The customer becomes the integration layer.
• The Handoff Cliff. The bot hands off a transcript, or nothing, and the human starts over. Worse than no bot: the customer has now explained twice.
• The Stale Fix. A closed ticket is read as a solved problem, and the next agent apologizes for the wrong thing or, worse, tells the customer it is fixed.
• The Wrong-Record Greeting. A merged identity (Chapter 9) greets one customer with another's cases. Continuity amplifies identity errors, so resolve identity before you personalize support.
• The Pasted Secret. A password or card number typed into chat travels unredacted to an external model.
• The Over-familiar Agent. The assistant opens with everything it knows. Surface only what bears on this issue. Customers expect you to know their tickets; they did not ask to hear their usage history recited (Chapter 19).

What this does not do

Klarna is the honest benchmark, because it produced both the claim and the correction. In February 2024 it reported that its AI assistant had handled 2.3 million conversations, two thirds of its customer service chats, doing "the equivalent work of 700 full-time agents," with satisfaction "on par with human agents," a 25% drop in repeat inquiries, and resolution in under 2 minutes instead of 11 [9]. Note the wording: equivalent work, not 700 people replaced. In May 2025 its chief executive told Bloomberg that cost "was a too predominant evaluation factor when organizing this, what you end up having is lower quality," and Klarna began recruiting human agents again; the assistant still handled about two thirds of inquiries [10]. A month later he said human customer service is "always going to be a VIP thing" [11].

I read that as a correction of the boundary, not a verdict on the technology. The repetitive majority stayed automated. What broke first was the complex, emotional minority, where quality mattered and a cost metric could not see it. I part company with the "VIP" framing, though. Route people to humans by need and consequence first, and by account value second. A small customer whose business is down deserves a person more than a large customer asking for an invoice copy.

Memory also does not fix the product. Ines's problem was a sync defect. Continuity makes the failure less insulting; it does not make it less of a failure. And the survey numbers above measure frustration, not causation: they tell you customers hate repeating themselves, not how much retention you will buy by stopping it. Measure that yourself.

How you will know

Klarna's 2024 announcement led with volume and speed; its 2025 correction was about quality. Measure so you see the second first (method in Chapter 21).

• Re-asked rate. Log every question the assistant or agent asks, and whether memory held a fresh answer to it. This is the direct measure of this playbook's question, and almost nobody instruments it.
• Repeat contact within 7 days for the same issue. The right family of metric; Klarna reported its own version as "repeat inquiries" [9].
• Handoff quality. Share of human handoffs whose first message re-asks a known fact; time from "I want a person" to a person.
• Outcome by severity. Satisfaction and sentiment for escalated and recurring cases reported separately from the average, because averages hide exactly the cases that broke Klarna's quality.
• Downstream retention. Renewal and churn for accounts that had a severe case, against a holdout, over at least a renewal cycle.

Beware containment and deflection rates. A customer who gives up is "contained." That is Chapter 21's Proxy Trap, and support is where it bites hardest.

Test design. Randomize by account or by case, not by message, since one customer's contacts influence each other. For continuity and handoffs, a holdout that keeps the current process for a random share of new cases is fair and clean. For proactive incident notices, do not hold back the notice; test timing, format, and channel instead. For proactive guidance of the onboarding kind, a holdout is reasonable, and the cloud-provider experiment above is a usable template [5]. Record for each case what was known, what was asked, and who handled it, so a bad outcome can be traced to the layer that caused it (Chapter 20).

Reader Q&A

We have to ask for account details for security. Is that "asking what we know"? No. Verification protects the customer and is worth one step. The waste is re-intake: asking the customer to rebuild the case you already hold. Verify once per session, and carry the verified state across the handoff so the human does not verify again.

Can we start without unified customer memory? Yes. Start with a case brief built from the ticketing system alone: last cases, recurrence, open promises, linked incidents. Precompute it at ticket open and put it in front of both the bot and the agent. Recurrence detection is the first field to get right. Then add telemetry, then the rest of the customer record.

playbook: SP
title: "Support"
question: "How do we stop asking customers what we already know?"
concepts:
  - name: Customer as integration layer
    definition: "The failure mode in which the customer must carry facts between channels, tiers, and systems because the company's records do not."
  - name: Case brief
    definition: "A precomputed summary of identity, open and recent cases, recurrence, linked incidents, promises, and stated preferences, built when a signal arrives and read at contact time."
  - name: Confirm, not interrogate
    definition: "State known facts back and ask one confirming question; ask open questions only for what memory cannot answer or what must be verified."
  - name: Handoff line
    definition: "Explicit rules for when an AI resolves, drafts for a person, or yields the case to a person, and the requirement that state, not a transcript, moves with it."
  - name: Support as a hard constraint
    definition: "An open severe case suppresses marketing, sales, and survey programs for that customer until the fix is confirmed."
decision_rules:
  - if: "memory holds a fresh, sourced answer to an intake question"
    then: "state it back and confirm; do not ask it again"
  - if: "a stored fact about the person is past its freshness window"
    then: "ask one confirming question before relying on it"
  - if: "the customer asks for a human"
    then: "route on the first request, with the case record, and tell the customer they will not need to repeat anything"
  - if: "the issue has recurred or the customer has stated an escalation"
    then: "route to a senior human with the case assembled; skip scripted troubleshooting already tried"
  - if: "a response would state or change a policy, refund, credit, or exception"
    then: "cite the governed policy source or hand off; treat as an irreversible action"
  - if: "a ticket is closed but telemetry does not confirm the fix"
    then: "treat the problem as open for routing, tone, and suppression"
  - if: "a customer has an open severe case"
    then: "suppress expansion, marketing, and survey programs until the fix holds"
  - if: "telemetry detects a failure that customers will experience"
    then: "notify affected customers with status, workaround, and next update time; do not hold back notices for testing"
  - if: "a customer message contains secrets, card numbers, or other listed identifiers"
    then: "redact or tokenize before any external model call; never let internal case notes pass the customer-facing serializer"
  - if: "the case brief is incomplete or late at contact time"
    then: "lower specificity and say what is being checked; never guess a cause or a fix status"
  - if: "the interaction is with an AI system"
    then: "disclose it (required in the EU from 2026-08-02 under AI Act Art. 50, unless obvious)"
assessment_questions:
  - "How many questions does a customer answer at first contact that your systems could have answered?"
  - "When a bot hands off to a person, what does the person receive, and does their first message re-ask anything?"
  - "Can your support tools see product telemetry, known defects, and other open cases for the same account?"
  - "Where are promises made in support (callbacks, credits) stored, and can marketing and sales agents read them?"
  - "Which policy statements can your support AI make, and does each cite a governed source?"
  - "Do you report satisfaction for escalated and recurring cases separately from the average?"
patterns: [Case Brief at Signal Time, Confirm Not Interrogate, State-Carrying Handoff, Consequence-First Routing, Incident-Triggered Proactive Notice, Degraded Not Invented, Promise as Scheduled Check]
anti_patterns: [The Re-intake Loop, The Handoff Cliff, The Invented Policy, The Stale Fix, The Wrong-Record Greeting, The Over-familiar Agent, Containment as Success, The Pasted Secret]
metrics: [re_asked_rate, repeat_contact_7d_same_issue, handoff_reask_rate, time_to_human_after_request, csat_escalated_cases, retention_after_severe_case_vs_holdout]
links: [ch9, ch10, ch11, ch13, ch14, ch17, ch18, ch19, ch20, ch21]
maturity_dimension: identity_and_memory