B2Shift · Published 27 August 2026 · Updated 27 August 2026
Support automation works when it answers from a defined, current knowledge source and hands off cleanly — it fails when it improvises past the edge of what it actually knows.
Ground every answer in approved knowledge, with a citation
Answers should retrieve from a knowledge base you control and update, not from a model's general training data — the same grounding discipline used in RAG implementation and cost applies directly here. If the assistant can't find a source for an answer, the right behaviour is saying so, not generating a plausible-sounding guess.
Narrow account actions are fine; policy exceptions are not
Order status, simple account updates and FAQ-style answers are reasonable to automate end-to-end. Discretionary decisions — a refund outside policy, a complaint, a request that doesn't fit the documented categories — should escalate to a person with full conversation context, not be forced through a rigid flow.
Confidence gates prevent the most damaging failure mode
An assistant that's right 90% of the time but confidently wrong the other 10% erodes trust faster than one that visibly says "let me get someone who can help with this." Set an explicit confidence threshold below which the system hands off rather than answers.
Knowledge freshness determines answer quality more than model choice
A support assistant is only as good as the documentation behind it. Stale pricing pages, deprecated features still described as current, or policy pages that haven't been updated in a year will produce confidently wrong answers regardless of which model powers the assistant. Assign an explicit owner for keeping the knowledge source current — see AI Chatbots & Voice Assistants for how this is scoped, including the escalation matrix and quality evaluation set.
Discuss your workflow