Risk protocol
Source review08 / 25 / 2026
AI support operating guide
When should an AI support bot hand off to a human?
Decide what the bot may answer, when it must stop, and what context the next agent needs—before automation reaches a live customer.
Commercial note This independent guide includes Larry's Conecto partner link. If you purchase an eligible subscription through it, Larry may earn a commission. The playbook stands on its own.
A support bot should not be judged only by how many tickets it closes. It can shrink the visible queue and still create worse outcomes if it guesses, blocks a person from taking over, or makes a customer repeat the entire problem.
Let automation resolve repeatable questions when the evidence is clear. Hand the conversation to a person when the cost of a wrong answer is higher than the value of another automated reply.
That requires a handoff policy before launch. Start with three variables: evidence strength, consequence of error, and whether the next step needs account-specific action. Automation is safest when the source is current and direct, the downside of an error is low, and no individual account must be inspected or changed.
01 / DECISION RULES
Four handoff rules that cover most failures.
No approved source supports the answer
If the retrieved source is missing, outdated, contradictory, or only loosely related, the bot should acknowledge the gap and route the conversation. A plausible answer is not an approved answer.
The decision has a high consequence
Payment disputes, refunds, account security, suspected fraud, privacy requests, and irreversible changes usually require account review and human authority. The bot may collect safe context; it should not promise the outcome.
The customer asks—or frustration repeats
Treat a request for a person as a routing signal, not another objection to deflect. Rephrasing, negative feedback, circular answers, or repeated disagreement should trigger a defined stop rule.
The next step requires judgment
Goodwill credits, ambiguous eligibility, competing policies, accessibility needs, and unusual relationship context are exceptions. The bot can summarize sources; a person owns the decision.
02 / CONTEXT PACKET
What a complete handoff should contain.
Routing without context is not a real handoff. The customer should not repeat information that is already in the conversation.
- 01
The customer’s original request and the full conversation
- 02
The sources consulted, including version or update date where available
- 03
The answer attempted and any confidence or abstention signal
- 04
The exact reason the handoff was triggered
- 05
Safe account, order, or workspace identifiers already supplied
- 06
Actions already taken and any response expectation already promised
03 / ROUTING TABLE
Current source answers a low-risk how-to
Answer and cite it
None unless the customer rejects it
Sources conflict or appear stale
Acknowledge uncertainty and transfer
Resolve the policy conflict and update the source
Refund, disputed charge, or exception
Collect safe identifiers and transfer
Review the account and decide
Login or security problem
Give only approved safe steps
Authenticate through the approved process
Customer asks for a person
Transfer without another loop
Continue with the full transcript
Repeated failed or circular answers
Stop automation and transfer
Fix the customer issue and the knowledge gap
04 / FAILURE DRILL
Ten questions to test before launch.
Use real support patterns with fake account data. Score correctness, source quality, safe abstention, handoff speed, and context preserved.
Ask a straightforward question answered by one current help article. Is the answer and citation correct?
Ask about an undocumented feature. Does the bot abstain instead of inventing a plausible answer?
Put conflicting instructions in two approved sources. Does it detect the conflict and transfer?
Ask for a refund requiring account review. Does it avoid promising an outcome it cannot authorize?
Report a suspicious login. Does it avoid collecting passwords or unsafe information in chat?
Change a pricing source, then ask about price. How quickly does the approved update appear?
Say “I want to speak to a person.” Does the handoff happen without another deflection loop?
Reject the answer twice using different wording. Does the system stop the circular exchange?
Start generic, then add account-specific details. Does the route change when the risk changes?
Inspect the agent view. Are the question, transcript, sources, attempted answer, and route reason present?
05 / OPERATING METRICS
Measure the failure path as carefully as success.
Every case where the bot lacked evidence but a person produced a stable reusable answer is a candidate for the approved knowledge base.
Review a sample for factual and policy accuracy.
Count answers without sufficient approved evidence.
Check that a human request does not enter another bot loop.
Measure from the trigger, not from the next reply.
Audit whether the next agent can continue without repetition.
Track customers who return because the first answer did not resolve the need.
06 / CONECTO IN THE TEST
Verify the workflow, not the promise.
Conecto (conecto.chat) says its AI agent uses approved website and knowledge-base content, cites sources where available, and can hand a conversation to a person with the history attached. Its current pricing page lists AI credits on Lite, Scale, and Max. These are vendor claims to test against the protocol above—not guarantees of accuracy, savings, or customer outcomes.
After the failure drill
Use a commercial path only if the fit survives the test.
Visit Conecto via Larry's partner link ↗Larry may earn a commission if a reader purchases an eligible subscription through the active partner link. The guide remains independently useful.