A chatbot should ask a follow-up question when missing information changes the answer or next action. It should not interrogate every visitor before showing a public service page. Commission clarification around specific decisions, then test whether the conversation remains easy to correct or leave.
Related service: Custom AI chatbot development- 01Identify the requested task
- 02Find the required missing detail
- 03Ask and confirm the correction
- 04Continue or offer another route
SECTION 01
List the decisions that genuinely need context
For a service inquiry, project type may determine the next page; a full postal address probably does not. For an existing support case, an authorized case reference may be needed before any private lookup. Write these dependencies in plain language. Avoid using model curiosity as a reason to collect more information.
Microsoft's RAG guidance notes the difficulty of vague conversational queries. Clarification is one response, but retrieval can sometimes answer the general question safely. Ask the agency to distinguish a useful general explanation from an account-specific answer that cannot proceed without verification. The user should understand which kind they are receiving.
SECTION 02
Illustrative example: an ambiguous repair request
Imagine a visitor says, 'I need help with the app.' The assistant offers two clear paths: a problem with an existing account or a request to develop an application. The visitor chooses development, describes an Android tool, then corrects it to both Android and iOS. The saved inquiry should reflect the corrected platform scope.
If the visitor refuses to give a phone number, the public service explanation should remain available. If a contact handoff requires a reply address, explain that requirement at that point. A useful test includes someone switching task halfway through; the assistant must not send the old support-case assumptions into a development inquiry. This is an illustrative conversation, not a client transcript.
SECTION 03
Test correction, exit and readable status
W3C status-message guidance is relevant when a chat interface tells users that details were saved or a request was submitted. Make those updates available without forcing the keyboard focus away from the user's current task. A visually changing bubble should not be the only indication that a correction was accepted.
Have the agency demonstrate a skipped question, an invalid value, a changed answer, a restart and a direct route to a person. Keep a concise summary before submission so the visitor can review the collected details. At handoff, provide the field rules and conversation examples to the owner. Changing a required field should trigger review of both the wording and the receiving system.
SECTION 04
Frequently asked questions
Should a chatbot ask one question at a time?
Often, but use a short form when several simple fields are easier to review together. Choose the interaction that helps the user complete the task.
Can it infer missing details?
Use inference only where the consequence and uncertainty are acceptable. Confirm details that change a booking, private lookup or business commitment.
What if the visitor changes their answer?
Update the saved context, show the corrected summary and invalidate downstream assumptions that depended on the earlier value before submission.
PRIMARY REFERENCES
Sources and further reading
These references cover the standards, platforms, or published prices discussed in the guide. Worked examples and checklists are our editorial guidance.
- Retrieval-augmented generationMicrosoft Learn
- Accessible status messagesW3C WAI
EDITORIAL METHOD
About this guide
We use AI to assist with drafting and editing. Catapult AI Work is responsible for the published content. Examples illustrate possible approaches; they are not client case studies unless identified as such.
Budget examples are not Catapult package prices. Check linked provider pages for current fees and plan limits before making a purchase.
Read the editorial policy