What your chatbot should not answer: fallback and handoff

Choose a response for the reason the answer is missing

Ask the client to distinguish the situations their staff encounter. A customer leaving out their location needs a different response from someone requesting information about another customer's account.

These are proposed business rules, not a universal platform setting. Google Dialogflow CX, for example, documents separate events for unmatched input, absent input and webhook errors. Your implementation must map the relevant events to the client's response and recovery rules. Google's state-handler documentation explains those event categories and their conditions.

Ask a question that can change the answer

"Could you provide more information?" gives the customer work without telling them what is missing. "Which branch is your appointment with? The cancellation rules differ by branch" is more useful when branch selection will resolve the ambiguity.

Choose the smallest necessary clarification. A chatbot answering a public opening-hours question should not collect a full customer profile. If it needs an account-specific answer, use the client's approved identity and access process before retrieving private information.

Stop asking once clarification cannot solve the problem. In the deposit example, collecting the customer's address again will not give the chatbot authority to waive the charge. Repeating the same question with friendlier wording leaves the customer in a loop.

Agree on a limit for unsuccessful clarification attempts, with an earlier exit when the customer requests a person. The right limit depends on the task and channel; it should not become a fixed number copied into every client project.

Give the part you can support

For the hypothetical repair business, a useful response might be: "The standard booking requires a deposit. I can pass your request for an exception to the service manager, but I can't approve it here."

That answer keeps the policy and the decision separate. It also offers a next step the implementation must actually support.

A partial answer needs a visible boundary. If the chatbot knows the standard service charge but cannot calculate the customer's final total, it should label the amount accurately. "The listed service charge is..." has a different meaning from "Your total will be...". Use a verified pricing source and the client's approved wording; do not fill missing fees with assumptions.

Some requests need no factual answer at all. If a visitor asks for another customer's booking details, the chatbot should not disclose a fragment to appear helpful. The answer limit applies to the whole conversation, including summaries passed to tools.

If staff repeatedly disagree about what the chatbot may say, complete the knowledge-readiness review before adding more prompt instructions.

Keep source uncertainty visible

A plausible search result may concern another location, an expired offer or a policy awaiting approval. A link beside an answer lets someone inspect its source; it does not settle whether that source applies.

Define which approved material can support each answer. When two sources conflict, use an agreed source-authority register. When the answer changes with stock, appointments or customer circumstances, follow the current-facts review.

Avoid asking the model to decide whether it "feels confident enough" as the only control. Make the observable conditions explicit: required details are present, the source applies to this request, the customer may receive the information, and the requested decision is within scope. An unmet condition should lead to a defined response.

A handoff needs an owner and a receipt

"Someone will get back to you" creates an expectation. Before putting that sentence into a chatbot, identify the receiving team, where the request will appear and the response window the business can support.

Prepare a short handoff record containing:

• The customer's question and the part still unresolved.
• Details already collected and needed to continue, including corrections.
• The relevant policy or source reference.
• Any attempted action and whether its result is confirmed, failed or uncertain.
• The receiving queue, request reference and available delivery status.

Keep information proportionate to the task and restrict access to the people who need it. A full transcript may contain details that do not belong in a general staff notification.

Treat a handoff attempt, a saved request and a person accepting the conversation as separate states. Microsoft's documented Bot Framework handoff protocol makes a similar distinction between initiation and status events, including accepted, failed and completed. That protocol is an example of explicit state reporting; connecting a particular staff system still requires its own integration. Microsoft's handoff reference describes the states.

Customer wording should follow the state you can verify. "I've created request 123 for the service team" requires evidence of that saved request. "You're connected to a person" requires an accepted transfer. Neither sentence belongs on a path that merely attempted to send a message.

To see this in a Vora configuration, start from the Knowledge page: confirm the approved business sources, missing-answer behavior and escalation for the configuration you evaluate.

Make the unavailable path useful

After hours, the chatbot may be able to save a request while no staff member is available. Explain that distinction and give the business's approved response window. If no response time has been agreed, do not manufacture one.

If request creation fails, say that the request has not been confirmed and provide an approved alternative, such as the published contact page or telephone number. An alternative channel needs to be real, reachable and suitable for the request.

Where the outcome is uncertain, staff should check for an existing request before creating another. Preserve the uncertainty in the handoff record so the next person does not mistake an attempted action for a completed one.

Review the conversation from the staff side

Use synthetic details to test a missing location, a policy exception, a restricted-data request and a failed lookup. Add a customer who asks for a person immediately, then a case where the receiving queue is unavailable.

For each case, inspect the answer and the result. Did the chatbot ask something useful? Did it state the unresolved part? Did the request arrive in the correct queue with enough context? Keep observations blank until someone checks them.

For an agency's first-client deliverable, a narrow answer set with a working escalation route can be an appropriate starting scope. Add new answers only after the client approves their sources and limits.

During the review, have a staff member open one handoff without listening to the original conversation. Ask them to continue the customer's request. If they have to ask for the same details again, revise the handoff record before expanding what the chatbot handles.

Boundary test worksheet

Run each case with synthetic details and leave the last two columns blank until someone has checked the result.

Generic design versus accepted Vora behavior

Everything above is a generic handoff design that applies to any chatbot. Whether a given product performs it is a separate question. When you evaluate Vora, confirm the approved business sources, missing-answer behavior and escalation for the configuration you are testing, and run this worksheet against it before relying on it.