Choose the response route separately for each type of support request. Decide which questions may start with an AI answer, which need a person from the outset, and what customers should expect when a person is unavailable. Use the request-by-request matrix below to set a policy, then review a limited pilot using your own conversations.
Compare the operating models
Staffed live chat starts with a person. It can suit requests that call for judgment, reassurance, investigation, or an individual decision. But offering a staffed channel does not tell customers when a person is available. Set clear coverage expectations either way.
An AI-first path starts with an automated response. Consider it for bounded questions with answers you can check against approved, current information. Do not assume every request is suitable. If a request needs a person to investigate, approve an exception, or make a decision, define how the customer can reach human support.
A hybrid policy assigns a starting route to each request type: AI first for selected questions, a person first for others, and a clear human route when the question needs more help. Treat this as a policy for your team to define, not an assumption that a system will identify every case automatically. For wider support planning, see AI Agents for Customer Support. For handover considerations, see chatbot-to-human handover practices.
Choose a starting route by request
Use this matrix as a first draft, not a rule that every request in a category has the same answer. Adjust it to your service rules, approved information, and actual support coverage.
| Request type | Suggested starting point | Why | Decide in advance |
|---|---|---|---|
| General policy question with an approved, current answer | AI first | The customer needs an explanation of published information. | Which source is approved, and what happens if the question concerns an exception? |
| Product or service information | AI first if the answer is documented | A bounded question may be answerable from material you have reviewed. | Which details are in scope, and what should happen if information is missing or conflicting? |
| Account-specific status or change request | Person first unless you have verified the information and process needed | General guidance does not establish a particular account’s status or complete a requested change. | Who reviews the request, and what information is needed? |
| Complaint, sensitive situation, or request for discretion | Person first, or a clearly explained route to a person | The request may need judgment or a response tailored to the situation. | Who can take over, and what should the customer expect if that person is unavailable? |
| Request outside staffed hours | AI first for bounded questions; otherwise explain the next step | An approved general answer may help, while a request needing review will have to wait for a person. | Can the question be answered now? How does the customer request a person, and when is the team next available? |
If you cannot explain why a request belongs in the AI-first column, begin with a person during the pilot. Reconsider only when you have a checked answer, a clear boundary, and a practical route for requests that need more help.
Set after-hours expectations
After-hours coverage is not the same as after-hours resolution. An automated answer may provide approved information about a general question. It should not imply that a person has reviewed an issue when no one has. Human handover is a route for help, not a response-time guarantee.
Draft and review customer-facing wording for each outcome. Adapt these examples to your actual coverage:
- Answer available: “I can help with general questions about our published policy. If your request needs a review, I can direct you to the support team.”
- Human review needed: “This needs a member of our team. Please check our posted support hours for when a person is available.”
- No suitable answer: “I don’t have a reliable answer to that. Please contact the support team during its posted hours.”
Do not say that someone will reply shortly unless your team has defined and can meet that expectation. Make the transition clear, too: Authorized Workspace members can take over a conversation and reply as a human. Waiting or human-takeover conversations do not receive an AI response from the widget. Decide who is responsible for checking the human route and what customers are told when that person is unavailable. You can review the available human handover options against the experience you intend to offer.
Prepare a narrow pilot
Choose one or two request types from the matrix rather than trying to automate every support conversation at once. Write down the boundary in ordinary language. For example: “The AI-first path may explain our published delivery policy. It must not claim to know the status of a particular parcel.” This is an illustrative planning example, not a measured result.
Before starting, work through these steps:
- Collect approved answers. Check that each policy or instruction is current and addresses the questions you intend to include.
- Confirm source readiness. Attaching a file does not prove its contents have been indexed. A source must finish processing before its content can be used in answers. Test the relevant material with questions whose answers you already know.
- Define the human route. Choose examples that should go to a person, such as an account-specific request, a complaint needing judgment, or a question the approved material does not answer. Decide who will check that route.
- Set customer expectations. Explain what the automated path may help with, how to ask for a person, and what happens outside staffed hours.
- Agree on review labels. Define what your team means by a supported answer, a handover, and a resolved request before reviewing conversations.
Use a worksheet to review conversations
Use one row per reviewed conversation, or consistently review a defined group. Record enough detail to understand why the route worked or did not work. Copy and adapt this worksheet:
| Review item | What to record |
|---|---|
| Request category | The request type from your matrix. |
| Intended route | AI first, person first, or human handover. |
| Answer quality | Supported and useful, partly useful, unsupported, or no answer. |
| Handover | Whether a person was needed or requested, and whether your team followed the planned route. |
| Customer expectation | Whether the wording accurately described availability and next steps. |
| Final status | Resolved, still open, or unclear based on evidence available to your team. |
| Next change | A specific source, boundary, wording, or routing decision to review. |
Set a standard for each label. For example, count an answer as “supported and useful” only if it addresses the request and matches approved information. Do not count a conversation as resolved just because an automated reply was sent or the customer stopped responding. For another method focused on reviewing conversation outcomes, see how to review AI Agent conversations.
Keep counts alongside the examples that explain them. The count of unresolved requests, requests needing a person, and answers judged unsupported can help you identify what to review. A small set of conversations may reveal an unclear boundary or missing answer, but it may not represent every request your business receives. Do not compare your pilot with an invented benchmark or treat early observations as a promise of future performance.
If a category repeatedly needs human review, keep it person-first or narrow the AI-first boundary. If the answers are supported but the handover wording confuses customers, revise the wording and review it again. Record the date range and which request types you reviewed so your team can understand what the counts do and do not describe.
Make a decision for each request type
At the end of the pilot, choose separately for each category: keep AI first, move to person first, or revise the boundary and review again. Keep a category AI-first only when the answer can be checked against approved material, the route for requests needing more help is clear, and your wording does not promise human coverage you have not defined.
The useful outcome is a short routing policy your team can explain: what may start with an AI answer, what goes to a person, and what customers should expect after hours. That is more actionable than choosing one model for every conversation.
Compare two versions of the same exchange
These illustrative transcripts use a fictional 30-day return policy:
| Turn | AI self-service path | Human exception path |
|---|---|---|
| Visitor | “What is the return window?” | “The item arrived damaged.” |
| Useful next reply | “The policy allows unopened returns within 30 days.” | “I will review the damage details and explain the next step.” |
| Completion evidence | Correct policy and relevant link | An authorized person completes or clearly explains the pending action |
A conversation ending after the first answer is not proof of customer satisfaction. Review it with the conversation-labeling method, and include handling time in the support-cost calculation. Compare Crisp's inbox approach and LiveChat's current operator package when staffing is central.