A website chatbot should acknowledge when it cannot give a reliable answer, ask for clarification when that could help, and offer an appropriate way forward. It should not invent prices, policies, availability, or commitments just to keep the conversation moving. Knowing when to stop is part of providing useful help.
Separate missing information from an unclear question
A visitor may use a phrase the business does not recognize, ask about a situation missing from the approved information, or request a decision only a person can make. These are different cases. A clarifying question may solve the first; it cannot create a missing policy or authorize an exception.
Define the important boundaries before launch. Identify which answers can come from business information, which require a connected tool, and which belong with a team member. This gives the assistant a useful role without expecting a conversational model to know everything about the company or the customer's circumstances.
Make uncertainty sound helpful, not evasive
A good fallback is brief and relevant. It explains the limit, preserves what is already understood, and offers a next step the visitor can choose. Avoid a long technical disclaimer or a confident guess followed by a warning. The customer needs to know whether the information can be relied on.
Use language that matches the situation. If the assistant lacks current availability, it can say that it cannot confirm that time and offer the booking path. If the question needs judgment, it can offer to send the request to the team. Neither response needs to describe the model or its internal configuration.
Let a person continue from the conversation
If the visitor wants help from the team, carry forward the relevant question and context through an agreed contact path. Ask for the information needed to respond, rather than requiring the visitor to repeat the whole story. Do not imply that a person is already replying unless that service is actually available.
Keep the confirmation truthful. Preparing a request, submitting it, and receiving a response are separate events. If the handoff fails, show a usable alternative. A pleasant conversation that silently loses the request is not a successful support experience.
Test the difficult questions deliberately
Before launch, test questions with incomplete details, outdated information, conflicting wording, and requests outside the business's scope. Include attempts to obtain private information or make the assistant ignore its rules. OpenAI's evaluation guidance supports using realistic tasks and difficult cases instead of relying on a few successful demonstrations.
Write down what an acceptable response looks like for each case. You are testing behavior: whether the assistant clarifies, answers from the right information, stops, or offers a handoff. No test set proves an AI system will never make a mistake, so the ongoing review and customer fallback still matter.
- Unknown or unpublished price.
- Unconfirmed availability or deadline.
- A request for a policy exception.
- Contradictory business information.
- A failed connection during a handoff.
Use unanswered questions to improve the service
Review unanswered questions for recurring information gaps. Some should lead to a better website answer or an updated business explanation. Others should remain a human decision. Do not treat every fallback as a failure to eliminate; sometimes it shows that the assistant respected an important boundary.
Keep changes to approved information and assistant behavior traceable, and retest affected cases. The useful goal is not a chatbot that answers absolutely everything. It is a customer experience that gives dependable help where possible and makes the limits clear when a person or a different tool is needed.