A useful chatbot must know how to refer to a person when the answer is missing, a decision is necessary or the user requests it. Design this passage with the rest of the route: available channel, information transmitted and confirmation of consideration.
Delimit what the chatbot can process
Separate general information, consultation of a file and business action. A documentary assistant can explain a procedure without being authorized to modify an order. Indicate its limits in an understandable language. The presence of a chat interface should not eliminate the usual means of contact. On mobile, check that it does not hide the navigation or essential information.
Set relay triggers
Plan as a minimum the explicit request of the user, the absence of sufficient source and situations outside the scope. Avoid loops where the model rephrases the same answer indefinitely. Triggers should be able to be tested with examples. For a sensitive question, the fluidity of an answer does not prove that it constitutes an authorized decision.
Describe the complete handoff process
A contact button is not enough if no one knows what it is transmitting or who will process the request. Describe the initial state, user action, proposed information and expected confirmation. The route can be simple: a replay summary, a form and a verified reception channel. The important thing is not to suggest that the request was taken into account before the application really confirms it.
| Situation | Interface response | acceptance test verification |
|---|---|---|
| The user asks for a person | An accessible means of contact is proposed | No loop imposing new reformulations |
| The documentation does not respond | The limit is announced and a useful sequel is proposed | No invented condition or value |
| The service is closed | Actual availability is explained | No automatic delay not validated |
| The channel fails | A failure message and an alternative are available | No false shipment confirmation |
| A business decision is necessary | Demand is oriented towards the competent role | The model does not present a modification as made |
This grid is a design proposal. Permissions remain decisive: an informative assistant should not be able to modify a contract or access simply because his answer suggests. The recommendations of theOWASP for LLM applications help to distinguish between produced text from actually authorized actions.
transmit only what helps
The relay can offer a summary that the person rereads before sending. Identify the necessary information, the recipient and the approved channel. Do not automatically copy the whole conversation if it contains unnecessary data. If the service is closed, announce the way to leave a request and what will happen next, without promising a delay that has not been validated by the team.
Fictitious example: a change request
A visitor wants to change a service already ordered. The chatbot can explain where to find useful information and suggest a contact, but it does not confirm the change. The user checks a summary of his request before transmission. The page displays a real receipt confirmation or a failure message to try again; A generated formula does not replace this verification.
Design a summary that the person can control
- Limit the summary to the question, the useful context and the elements that the user agrees to transmit. Show it before sending when the route allows.
- Indicate the channel and the functional recipient of the request. A vague formula like "we'll take care of it" does not describe a verifiable reception.
- Allow to correct the summary. Poor reformulation by the model should not become the only version of the request kept by the team.
- Test the reception with demo data, then the failure scenario. Check the route on the keyboard and on a narrow screen, including when the chat window is open.
In a fictional simulation, a person wants to develop a service already ordered. The chatbot can explain what information to prepare and propose a summary. It does not confirm an acceptance or modification of the file. The team receives an actionable request and remains responsible for the decision. This separation makes it possible to help quickly without making a commercial commitment.
For an agency site, the relay can direct towards an exchange of framing rather than seeking to immediately resolve each situation. Plan the review of unanswered questions to improve documentation. The Preparing a Knowledge Base and the RAG quality tests then become complementary to the work on the form and on the actual reception of the messages.
Test how the user journey ends
Simulate an untraceable response, immediate human demand and contact channel failure. Control Keyboard, Mobile Reading and Confirmation Messages. The OWASP identifies the risks associated with the exits and accesses of LLM applications: therefore limit the powers of the chatbot to what is necessary. Link this work toImprovement of the contact form to maintain a reliable issue.