A support chatbot should make it easier to resolve a request. If a customer repeats the same problem to three different interfaces, automation has moved the work rather than reduced it.
Decide when a person takes over
List the situations that require escalation: an unresolved answer, an account-specific request, a complaint or a decision the bot is not authorised to make. Give customers a visible way to request help without having to discover a special phrase.
Define the out-of-hours experience. A promise of immediate human support is misleading when the team is offline. A clear ticket confirmation and realistic response expectation are more useful.
Pass context, not an unrestricted transcript
The handoff should include the issue category, a short summary, steps already attempted and relevant identifiers collected through approved channels. Decide what sensitive information should be removed and who can view the ticket.
Ask the specialist to show how a customer resumes the conversation. Test a failed connection, a duplicate submission and a user who closes the page before the ticket is created.
Measure customer outcomes
Track resolved requests, reopened tickets and the time a human spends reconstructing context. A high number of chatbot conversations does not establish useful support. Review a sample of escalations for accuracy and tone.
For acceptance, require a visible ticket reference after successful creation and an honest error message if creation fails. Include a way to disable automated responses while preserving the support form.
The OWASP guidance for LLM applications is a useful security reference, particularly when a chatbot can call business tools. Use a clear project brief to separate answering questions from taking account actions.