Customer Support

1. Questions an assistant should handle

Export the last few hundred support conversations and group them by what was actually being asked. The grouping usually shows that a handful of topics dominate, and those are the ones worth automating first — they are high volume, low risk, and have one correct answer.

• ✓Factual questions with a single stable answer: hours, locations, parking, service area, what is included.
• ✓Process questions: how to book, how to cancel, what to bring, what happens next.
• ✓Status questions where the assistant can read a record and report it back accurately.
• ✓Simple self-service actions you have explicitly authorised, such as resending a confirmation.
• ✓Routing questions, where the real job is getting the person to the right team quickly.

Keep an equally explicit list of what it must never attempt: clinical, legal, or financial advice; disputes and refunds outside a published policy; complaints; anything involving a vulnerable person; and any question where being wrong causes harm. These go to a human immediately, without an attempt at an answer first.

2. Building and maintaining the knowledge base

The knowledge base is the product. An assistant is only as accurate as the material behind it, and support content decays quietly — a price changes, a policy is revised, a location closes, and nobody updates the article.

1. 1.Start from your real top twenty questions rather than an imagined structure.
2. 2.Write one short answer per question in plain language, in the words customers use.
3. 3.State the conditions and exceptions explicitly, because that is where wrong answers come from.
4. 4.Give every article a named owner and a review date.
5. 5.Record where each fact comes from, so it can be verified rather than guessed.
6. 6.Remove or rewrite anything contradictory; two conflicting articles guarantee an inconsistent assistant.
7. 7.Review the unanswered and escalated conversations weekly and turn recurring gaps into new articles.

Tie knowledge-base updates to the events that change them — a price change, a new location, a policy revision — rather than to a vague quarterly review that never happens.

3. Tone and conversation boundaries

Write your tone down as instructions rather than adjectives. “Friendly and professional” means nothing operationally; “short sentences, no exclamation marks, never blame the customer, always state the next step” is something you can check.

• ✓Be clear that the customer is talking to an automated assistant, and make reaching a person easy at any point.
• ✓Prefer short answers with one clear next step over long explanations.
• ✓Never guess. If the answer is not in the knowledge base, say so and hand over.
• ✓Never argue, diagnose motive, or apportion blame — acknowledge, then route.
• ✓Do not make promises about timing, outcomes, or goodwill gestures unless a published policy covers it.
• ✓Keep one consistent voice across chat, email, and SMS so the experience does not fragment.

4. Authentication and privacy cautions

The moment an assistant reads or changes a customer record, identity matters. These are operational cautions rather than legal conclusions: obligations differ by region and sector, so confirm your approach with a qualified advisor.

• ✓Decide what may be answered with no identity check at all — general information only.
• ✓Require proportionate verification before revealing anything account-specific, and never accept a name alone.
• ✓Never read back sensitive details a caller has not already proven they are entitled to see.
• ✓Do not ask customers to send payment card details, passwords, or identity documents through chat, email, or SMS.
• ✓Minimise what is stored: keep what you need for the conversation and no more.
• ✓Have a defined path for data access, correction, and deletion requests — straight to a human owner.
• ✓In regulated sectors, treat health, financial, and legal details as out of scope for automated handling unless a qualified advisor has approved the design.

5. Escalation and human handoff

Design the escalation path before the answers. An assistant that hands over cleanly with full context is useful even when it cannot answer; one that traps people in a loop damages the relationship faster than a slow reply would.

• ✓Escalate on request, on repeated failure to answer, and on any sign of distress or anger.
• ✓Escalate automatically on complaints, safety issues, refunds outside policy, and legal threats.
• ✓Pass the whole transcript and the customer's actual question so the human never asks them to repeat themselves.
• ✓Name the receiving owner and a response window for every channel and every hour you accept contact.
• ✓Set an explicit expectation with the customer: who will reply, and roughly when.
• ✓Cap the number of automated attempts before handover; two failed tries is usually enough.

6. A practical example

Three things make this work. The assistant discloses what it is, verifies with a detail on file before reporting anything account-specific, and stops trying to resolve the underlying complaint — it names a person and a time instead.

7. Quality review

Quality review is a scheduled habit, not a launch task. Read a sample of conversations every week for the first month and monthly after that, and compare against your own history rather than published benchmarks.

• ✓Sample both resolved and escalated conversations; the escalations show you the gaps.
• ✓Score for accuracy first, then clarity, then tone — in that order.
• ✓Track how often the assistant answered, how often it handed over, and how often it should have handed over sooner.
• ✓Track time to human response after an escalation; it is usually the cheapest thing to improve.
• ✓Log every incorrect answer as a knowledge-base defect with an owner, not as an anecdote.
• ✓Re-run your test questions after any knowledge-base change.

8. Common mistakes

• ✓Launching against a knowledge base that was never accurate to begin with.
• ✓Hiding the route to a human to inflate automated resolution numbers.
• ✓Letting the assistant answer account-specific questions without verification.
• ✓Allowing it to improvise refunds, goodwill, or timing promises.
• ✓Leaving contradictory articles in place and blaming inconsistent answers on the technology.
• ✓Measuring deflection rate while ignoring whether the customer's problem was actually solved.
• ✓Never reading transcripts, which is where every fixable problem is already written down.

Customer support readiness checklist

• Top twenty questions extracted from real conversations and grouped.
• Explicit out-of-scope list written, including advice, complaints, and disputes.
• One short, plain-language answer per question, with conditions and exceptions stated.
• Every article has a named owner and a review date.
• Contradictory content removed or rewritten.
• Tone written as checkable instructions rather than adjectives.
• Automated-assistant disclosure in place, with an easy route to a person.
• Verification rules defined for anything account-specific.
• Sensitive-data handling and access/deletion request paths reviewed with a qualified advisor.
• Escalation triggers, receiving owners, and response windows agreed per channel.
• Attempt cap set before automatic handover.
• Weekly transcript review scheduled with a named owner for the first month.

Key takeaways

• ★Automate the small number of high-volume, low-risk questions and route everything else.
• ★The knowledge base is the product — give every article an owner and a review date.
• ★Write tone and boundaries as instructions you can verify, not as adjectives.
• ★Verify identity proportionately before revealing or changing anything account-specific.
• ★Design the handover first: full context, a named owner, and a stated response time.
• ★Judge quality on accuracy and resolved problems, not on deflection rate.