checklist
AI chatbot human handoff policy template for small teams
A practical human handoff policy template for AI customer support chatbots, covering escalation triggers, owner routing, service levels, transcript handling, pause rules, and review metrics.
Use this template before a customer-facing AI chatbot answers support, billing, onboarding, troubleshooting, account, privacy, security, outage, or renewal questions.
The chatbot is not the support process. It is one entry point into the support process. If the bot cannot recognize when it should stop, route, preserve context, and let a human owner decide, it can turn a routine question into a customer-impact incident. Before approving handoff rules, run the AI Tool Risk Checker and keep the result with the launch packet.
Bottom line
Every customer-facing AI chatbot needs a written handoff policy that defines:
- Which topics the chatbot can answer directly.
- Which topics must route to a human immediately.
- Which queue or owner receives each escalation.
- What context the bot may pass to the human.
- How fast the team responds by risk level.
- What the customer sees during and after handoff.
- When repeated handoff failures require pausing the bot.
The Small Team AI Security Checklist covers baseline approval, admin controls, and incident response. This page focuses on human review and escalation for chatbot workflows.
When to use this template
| Scenario | Use this policy? | Why |
|---|---|---|
| Website chatbot answers public product questions | Yes | Customers still need an easy human path when answers are missing or wrong. |
| Chatbot triages support tickets | Yes | Wrong routing can delay urgent customer issues. |
| Bot handles billing, refund, or cancellation questions | Yes | Exceptions and disputes need human ownership. |
| Bot summarizes customer chat before agent handoff | Yes | The summary can omit or distort customer intent. |
| Bot searches customer account records | Yes | Account-specific issues need authenticated support paths. |
| Bot answers security, privacy, or AI data use questions | Yes | Claims must route to approved owners when evidence is missing. |
| Bot can create, close, tag, refund, or update records | Escalate | Tool agency and customer-impact actions need strict review. |
| Internal agent-assist bot only | Maybe | Use if drafts influence customer replies or ticket routing. |
| Static FAQ page | No | Use normal content and support review. |
If the customer asks for a human, the bot should hand off. Do not make the customer argue with automation.
Handoff trigger matrix
| Trigger | Default action | Owner |
|---|---|---|
| Customer asks for a human | Hand off immediately | Support queue |
| Bot is uncertain, source is missing, or answer would require guessing | Hand off | Support queue |
| Customer disputes the answer | Hand off and attach context | Support lead |
| Billing dispute, refund exception, cancellation problem, failed payment, or renewal dispute | Hand off | Billing or support owner |
| Security, privacy, AI training, data deletion, export, or questionnaire question | Hand off | Security, privacy, or trust owner |
| Account access, permission change, admin transfer, or identity verification | Hand off to authenticated workflow | Account support owner |
| Outage, service degradation, data loss, vulnerability report, or incident claim | Escalate immediately | Incident or security owner |
| Legal, contract, regulated, health, finance, HR, children, or government topic | Refuse or hand off | Business or legal owner |
| Angry customer, churn threat, harassment, or public complaint threat | Hand off with priority | Support lead or customer success |
| Bot loops, repeats, or fails twice | Stop bot flow and hand off | Support queue |
| Prompt injection, request for hidden instructions, or request for another customer’s data | Refuse, preserve minimal evidence, and escalate if suspicious | Security owner |
These triggers should be implemented as rules, not just training guidance.
Owner routing table
| Issue type | Primary owner | Backup owner |
|---|---|---|
| Product how-to question | Support | Product documentation owner |
| Bug report | Support | Product or engineering |
| Account access | Account support | Workspace admin |
| Billing or refund | Billing owner | Support lead |
| Cancellation or renewal | Customer success | Billing owner |
| Enterprise customer escalation | Customer success owner | Founder or account owner |
| Security questionnaire or trust question | Security owner | Business owner |
| Privacy, deletion, export, or opt-out request | Privacy owner | Support lead |
| Outage or incident | Incident owner | Engineering lead |
| Vulnerability report | Security owner | Engineering lead |
| Contract or legal interpretation | Business owner | Legal reviewer |
| Regulated or sensitive workflow | Business owner | Privacy or security owner |
Small teams can map roles to the same person, but the route must still be explicit.
Customer-facing handoff script
Use short, honest wording. The customer should understand what happens next.
| Situation | Script starter |
|---|---|
| Customer asks for human | ”I will connect this to our support team so a person can review it.” |
| Bot is unsure | ”I do not have enough approved information to answer this safely. I will route this to support.” |
| Billing or refund | ”I can share the standard policy, but billing exceptions need a person to review your account.” |
| Security or privacy | ”Security and privacy questions need an approved response from our team. I will route this to the right owner.” |
| Account access | ”For account changes, please use our authenticated support process so we can protect your account.” |
| Possible incident | ”This may need urgent review. I will route it to our team with the information you provided.” |
| Unsupported topic | ”I cannot help with that topic here. I can route your request to the team.” |
| Sensitive data pasted | ”Please do not share sensitive information in chat. I will route this without repeating unnecessary details.” |
Do not pretend a human is already reading if the ticket is only queued. Do not promise response times the team cannot meet.
Human review levels
| Level | Use for | Review expectation |
|---|---|---|
| Level 1: ordinary support | Product usage, documentation gaps, setup questions, basic troubleshooting | Human follows normal queue if bot cannot answer. |
| Level 2: customer-impact support | Billing, refund, cancellation, account ownership, failed workflow, enterprise customer issue | Human reviews before final answer or record change. |
| Level 3: trust and sensitive data | Security, privacy, AI data use, deletion, export, vulnerability, incident, regulated data | Named owner reviews before customer-facing claim or action. |
| Level 4: pause condition | Private data exposure, harmful answer, missed urgent escalation, repeated wrong answer, prompt injection success | Pause or restrict bot topic until review closes. |
The bot should not decide Level 3 or Level 4 outcomes. It should route, preserve minimal context, and stop making customer-impact claims.
Ticket context template
When handing off, pass enough context for a human to help without over-collecting data.
| Field | Include? | Notes |
|---|---|---|
| Conversation ID | Yes | Use an internal ID, not raw transcript in every notification. |
| Customer contact | Yes | Use existing authenticated account data where possible. |
| Customer request summary | Yes | Short factual summary. |
| Bot answer given | Yes | Needed for correction if wrong. |
| Source used | Yes | Help center article, policy snippet, status page, or none. |
| Handoff trigger | Yes | Customer requested human, missing source, billing, security, privacy, incident, etc. |
| Risk level | Yes | Ordinary, customer-impact, sensitive, or pause condition. |
| Sensitive data pasted | Minimal | Do not repeat unnecessary sensitive details. |
| Suggested queue | Yes | Support, billing, security, privacy, incident, customer success, or product. |
| Customer-visible promise | Yes | Record any promise the bot made. |
| Next action due | Yes | Based on service level. |
Avoid sending complete raw transcripts into broad channels. Use links with role-based access.
Service level rules
Set realistic response expectations.
| Handoff type | Default response target | Notes |
|---|---|---|
| Ordinary support | Normal queue | Customer sees normal support expectation. |
| Bot cannot answer | Normal queue or faster during pilot | Review gaps to improve source coverage. |
| Billing dispute or cancellation | Same business day when possible | Do not let bot close the issue. |
| Enterprise customer | Account owner rule | Route according to customer success coverage. |
| Security or privacy question | Owner-defined target | Avoid unsupported instant answers. |
| Data deletion or export request | Approved privacy/support process | Follow the formal request workflow. |
| Outage or possible incident | Immediate triage | Route to incident owner. |
| Private data exposure or harmful bot answer | Immediate pause review | Treat as operational incident signal. |
If the team cannot meet a target, adjust the script instead of making false promises.
No-handoff red flags
These are signs the chatbot is unsafe to keep running broadly.
| Red flag | Response |
|---|---|
| Bot refuses to hand off after customer asks | Fix immediately and retest. |
| Bot keeps answering billing exceptions | Remove topic or force handoff. |
| Bot gives security or privacy claims without approved source | Restrict trust topics. |
| Bot creates, closes, refunds, cancels, or updates accounts without review | Pause automated action. |
| Bot summarizes angry customers as ordinary support | Fix priority rules and review similar tickets. |
| Bot exposes internal notes during handoff | Restrict source and transcript sharing. |
| Bot misses outage or vulnerability reports | Route incident keywords and retest. |
| Bot repeats the same failed answer | Add loop limit and handoff trigger. |
| Bot records sensitive data in broad notifications | Change context template and access rules. |
| No one owns escalations after hours | Reduce bot scope or change customer-facing expectations. |
If a red flag reaches customers, review whether the bot should be paused while controls are fixed.
Bot pause rules
Define pause conditions before launch.
| Condition | Pause scope |
|---|---|
| Private customer data exposed | Pause affected workflow or entire bot. |
| Wrong answer caused material customer harm | Pause affected topic. |
| Bot made unsupported refund, pricing, contract, security, or privacy promise | Pause affected topic and approve corrected wording. |
| Missed urgent incident, outage, vulnerability, or data deletion escalation | Pause affected trigger and review similar conversations. |
| Prompt injection bypassed policy | Pause affected source, tool, or action. |
| Knowledge base conflict creates repeated wrong answers | Remove source set or pause topic. |
| Handoff queue is not staffed | Disable customer-facing bot or restrict to low-risk FAQ. |
| Monitoring owner cannot review pilot output | Do not expand; consider pausing pilot. |
Restart only after the owner documents the fix, retests the trigger, and records a restart decision.
Pilot workflow
Use this workflow for the first two weeks.
| Step | Action |
|---|---|
| 1 | Start with agent-assist or limited customer-facing topics. |
| 2 | Test all handoff triggers before launch. |
| 3 | Review every Level 2, Level 3, and Level 4 handoff during pilot. |
| 4 | Sample ordinary support conversations daily for missed handoffs. |
| 5 | Record wrong answers, unsupported claims, missed escalations, customer complaints, and source gaps. |
| 6 | Update scripts, routing, source priority, and prohibited topics. |
| 7 | Decide expand, hold, restrict, or pause. |
Do not expand the bot if handoff quality is unknown. Ticket deflection is not a success metric when customers are being misrouted.
Approval record
Copy this into the launch packet.
| Field | Entry |
|---|---|
| Chatbot name | Tool, vendor, workspace, and launch mode. |
| Approved scope | Topics and customer segments. |
| Handoff triggers | Link to approved trigger matrix. |
| Owner routing | Support, billing, security, privacy, incident, product, customer success, and account owners. |
| Customer-facing scripts | Approved wording for handoff scenarios. |
| Ticket context | Fields the bot may pass to humans. |
| Service levels | Response targets by escalation type. |
| Pause rules | Conditions and pause owner. |
| Pilot review owner | Person reviewing conversations and missed handoffs. |
| Test result | Trigger test pass rate, failures, and remediation. |
| Decision | Approve, pilot, approve with limits, hold, deny, or escalate. |
| Next review | Date and trigger conditions. |
Keep this record redacted. It should not contain private customer transcripts.
Metrics to track
| Metric | Why it matters |
|---|---|
| Human handoff rate | Shows whether scope and sources match customer needs. |
| Customer-requested handoff success rate | Critical trust metric. |
| Missed handoff rate | Shows bot overconfidence or weak triggers. |
| Wrong queue rate | Shows routing quality. |
| Time to first human response | Shows whether promises match operations. |
| Level 3 escalations | Shows trust, privacy, security, and sensitive workflow volume. |
| Bot answers corrected by humans | Shows answer quality and source issues. |
| Customer complaints after bot interaction | Shows external harm. |
| Pause events | Shows control failures or high-risk topics. |
| Repeat failure category | Shows what to fix before expansion. |
Review these metrics weekly during pilot and monthly after stabilization.
Evidence checked
This policy is aligned with:
- NIST AI Risk Management Framework, which frames AI risk management around harms to individuals, organizations, and society across the AI lifecycle.
- NIST AI RMF Appendix C on Human-AI Interaction, which discusses defining human roles and responsibilities for operational AI systems.
- NIST AI RMF Core, which organizes AI risk management around govern, map, measure, and manage functions.
- NIST Generative AI Profile, which identifies generative AI risks and risk management actions.
- OWASP Top 10 for Large Language Model Applications, which highlights prompt injection, sensitive information disclosure, excessive agency, and overreliance risks.
- OWASP LLM06:2025 Excessive Agency, which explains risks from excessive functionality, permissions, and autonomy in LLM-based systems.
- FTC AI and data guidance, which warns businesses to be careful about collecting, retaining, and using consumer data for AI.
- Cybergiz templates for chatbot launch review, chatbot knowledge base review, customer impact assessment, customer data approval, trust-center wording, evidence retention, and incident response.
This page is practical operating guidance, not legal, procurement, privacy, compliance, audit, certification, or security assurance advice.
FAQ
Should a chatbot always hand off when the customer asks?
Yes. The bot can offer self-service help first, but once the customer asks for a human, the workflow should route to a person or create a clear support ticket.
What if handoff volume is too high?
That usually means the scope, knowledge base, or customer expectations are wrong. Fix the source set and allowed topics before making handoff harder for customers.
Can the bot summarize the conversation for the human?
Yes, but the summary should be factual, short, and reviewable. Include the bot answer given and source used. Do not repeat unnecessary sensitive data.
Can the bot close tickets automatically?
Avoid automatic closure during pilot. Closing tickets is a customer-impact action. Require human review until the workflow has strong evidence and a rollback path.
Who should own security and privacy escalations?
Assign a named security or privacy owner, even if that is the founder in a small team. Support should not improvise security, privacy, AI training, deletion, or questionnaire answers.
When should we pause the bot instead of just fixing the answer?
Pause when the bot exposes private data, misses urgent escalation, makes material promises, gives harmful advice, shows prompt injection success, or repeats failures in the same high-risk category.
How often should the handoff policy be reviewed?
Review it after the first week, after the first 100 conversations, after any incident or customer complaint, after source changes, and before expanding the bot to new topics or customer segments.