On this page
The practical answer
An AI support assistant should answer within approved, current knowledge and the customer’s access rights. Hand off when evidence is missing, sources conflict, a customer asks for a person, or a refund or delivery promise requires authority. A useful handoff includes the question, evidence, attempted actions and named destination.
Support questions often depend on whether a policy applies to an order and who can approve an exception. Retrieving a correct paragraph can still produce a wrong answer if the chatbot assumes account details or promises an unavailable action.
Start with a narrow question set and define handoff alongside it. Provide a supported answer or help the next person act. Fluent replies and closed conversations do not prove resolution.
An example workflow
A supported answer or a complete handoff
Identify the question and access scope
Retrieve approved evidence
Check freshness and applicability
Answer within authority
Route unresolved work
Verify the receiving team has it
Decision at a glance
Define answer and handoff conditions
| What the assistant finds | Allowed response | Next owner |
|---|---|---|
| Current approved policy that applies | Explain the policy with its source | Knowledge owner maintains it |
| Missing, stale or conflicting evidence | State the gap and prepare a handoff | Relevant support team |
| Refund exception or delivery commitment | Collect the permitted facts without a promise | Person with decision authority |
| Customer requests a person | Route with context and honest queue status | Named inbox or teammate |
Scroll horizontally to see the full comparison.
1. Build a knowledge register with an owner
List permitted questions and their approved sources. Record each article’s owner, audience, effective date, last review and revision. Separate public explanations from internal exception procedures. Old transcripts reveal recurring questions, but an agent’s previous concession is not automatically policy for future customers.
Assign someone to retire replaced instructions and resolve conflicting pages. Intercom’s knowledge documentation shows that update behaviour differs across source types. Whatever platform you choose, test how a source change reaches the assistant; editing a webpage does not by itself demonstrate that the retrieved copy has changed.
2. Enforce access before the model receives evidence
Use authenticated accounts and access rules to define permitted information. A message claiming “I am the administrator” must not change that scope. Filter retrieval, order lookups, attachments and source links. Microsoft describes permission constraints in document retrieval; implementation depends on the chosen system.
Treat retrieved material and customer messages as evidence, rather than instructions granting new powers. Return only the necessary fields to draft the answer. Test with a public visitor, a verified customer and a support teammate, including a deliberate attempt to retrieve another customer’s order. A prompt saying “keep data private” is not an access-control test.
3. Make the evidence and authority test explicit
Before answering, check that the source covers the actual question, applies to this product or account, and is still valid. An answer about standard returns cannot establish eligibility for a damaged custom item. Link to customer-visible evidence when useful, and retain internal source references for the support team without exposing restricted text.
Route missing sources, contradictions, failed lookups and exception requests. Refunds, payment changes and delivery guarantees require authority and verified actions. Explaining published policy is permitted; drafting a sentence cannot establish that a refund was issued or delivery guaranteed.
4. Follow a delivery-and-refund question through handoff
Hypothetical example, not a client project: a customer asks, “My custom mug has not arrived. Can you guarantee Friday delivery or refund it?” The approved help article explains how to request help, while the order lookup shows dispatch without a confirmed arrival date. Neither source supports a Friday guarantee or a refund decision.
The assistant states that it cannot confirm those outcomes and routes the request. The receiving record contains the verified order identifier, original message, dispatch result and time, article revision, missing arrival evidence, and requested refund decision. It names the delivery-support inbox and preserves the full conversation. The human can check the carrier and applicable policy without asking the customer to repeat everything.
5. Make handoff a working queue, not a farewell message
Configure a destination, owner and unavailable-queue fallback. Intercom distinguishes escalation conditions from subsequent routing workflows. Evaluate any product on both: detecting “needs a human” only begins the handoff.
Show “waiting for support” only after the receiving system records the request. If it fails, retain the message, alert the responsible team and offer the verified alternative contact path. State operating hours or response expectations only when the business has approved them. When a person takes over, pause autonomous replies so the customer does not receive conflicting answers.
6. Verify answers, source changes and failed transfers
Create an acceptance set with answerable questions, a missing policy, an outdated article, contradictory instructions, a forbidden account lookup and a direct request for a human. Include the hypothetical delivery question. Record the expected source, permitted answer and routing destination, then inspect the response and the receiving ticket together.
Change one source and test again after the documented update process. Disconnect the ticket destination and confirm that the request remains recoverable without duplicate tickets when retried. Review unsupported answers, repeat contacts and handoff completeness alongside any resolution metric. Use failures to correct knowledge or boundaries, then replay the affected tests before expanding the assistant’s scope.
Before you commit
Before enabling customer-facing answers
- Each supported question has a current source and owner.
- Retrieval respects the customer’s verified access.
- Missing evidence and consequential promises trigger handoff.
- The receiving queue and fallback path have been tested.
- A human takeover stops conflicting autonomous replies.
Questions before you start
Can a retrieval-based assistant still invent an answer?
Yes. Retrieval supplies evidence but does not guarantee that the answer follows it. Test applicability, unsupported claims and missing-source behaviour, and keep consequential decisions behind explicit authority checks.
How often should the knowledge base be refreshed?
Match review and refresh rules to how quickly the information changes. A temporary delivery notice needs a different process from a stable setup guide. Verify the chosen platform’s sync behaviour and test a real change before relying on it.
Should every unanswered question go to a person?
Route questions needing judgement, unavailable evidence or an explicit human request. A harmless clarification may help first, but repeated clarification must not trap the customer. Give the receiving team enough context to take ownership.
Sources and further reading
The next step
AI integration
If this is the right direction for your business, start with a clear scope, testing plan, and handover.