When a visitor asks a question your approved information cannot settle, the chatbot still needs to help them take the next step. It may need clarification, be able to answer only part of the request, or need to stop and involve a person. This guide focuses on what to say in those situations.
The examples below are fictional response designs, not measured RobiFox outputs or customer conversations. They should be adapted to your actual policies and supported product behaviour.
Choose the response before writing the wording
| Situation | Useful response | Boundary |
|---|---|---|
| The request is ambiguous, but approved information may answer it. | Ask for the detail needed to select the right policy or product. | Do not guess which case the visitor means. |
| Only part of the request is supported. | Answer that part with its source, then identify the unresolved part. | Do not let a general rule imply approval for an exception. |
| A fact is missing, stale or contradicted. | Explain what cannot be confirmed and offer an appropriate contact route. | Do not select the most favourable version or invent a compromise. |
| The request needs account data, an action or a discretionary decision. | Explain the limit and direct the visitor to an authorised channel. | Do not claim access, approval or completion that the system does not have. |
Ask a precise question when context is missing
Fictional visitor: “Is installation included?”
Weak response: “Yes, installation is included.”
Better response design: “Which service package and installation location do you mean? The included work depends on those details.”
Use a clarification only when the answer could change with the requested detail and the approved sources explain that difference. If no source covers installation at all, another question merely delays an honest limit. Test whether the configured assistant can follow the intended clarification flow before relying on it.
Answer the supported part without extending the promise
Fictional visitor: “Your policy says dispatch in two working days. Can you guarantee arrival by Friday?”
Better response design: “The published policy states dispatch within two working days. That is not an arrival guarantee, and I cannot confirm delivery by Friday from this information. The delivery policy explains the available service; contact the team if your deadline is essential.”
The answer should cite the policy that supports dispatch and use a real contact route. It should not replace the published condition with a more attractive promise. For a detailed webshop example, see shipping-policy answers.
Be specific about information you cannot verify
Fictional visitor: “Has my refund been approved?”
Weak response: “Your refund should be approved soon.”
Better response design: “I can explain the published refund process, but I cannot see your individual refund status here. Please use the account or support channel that can check your case.”
The named channel must exist and be appropriate. Do not ask visitors to put passwords or payment details into a general chat. A website policy is a source of general information; it does not grant access to personal records.
Handle conflicting or outdated sources honestly
If a current service page and an older document state different conditions, avoid blending the two. Explain that the available material does not establish one reliable answer and route the question to the policy owner. The business then needs to resolve the conflict in its sources.
A reference helps someone inspect the evidence, but does not remove the conflict. For the correction process behind the response, use the unsupported-claim prevention and incident guide.
Offer a next step your team can fulfil
Choose between a relevant public page, contact details, a contact form or a staffed live conversation. Do not promise “an agent is joining” when no one is available. Set ownership and service hours before offering human help; the live-agent takeover guide covers that operating commitment.
For multilingual visitors, preserve the same factual limit and market conditions in the answer. Do not imply that a human agent will speak the visitor’s language unless the team can provide that coverage.
Test the decision and the next step
For each important topic, test a covered question, a missing detail, an unsupported exception and an account-specific request. Review whether the response explains its limit, preserves the supported information and offers a working route forward. Keep these cases in your answer-quality test set.
After launch, group repeated unsupported questions. A missing policy may need a new approved answer; a retrieval failure needs a different repair; a discretionary request may properly stay with a person. The unanswered-question workflow explains how to separate them.
RobiFox provides source-based answers and human support routes, but the desired behaviour still needs checking on your own content. Review the available controls and try the questions that matter to your business.
