The bot calls a human when it cannot cope
Answers from your documents, and when the answer is not there it hands over honestly and tells the customer so.
What the scenario looks like
- Execute + Data
- Data
- LLM
An ordinary document bot ends with “I could not find that”, and for the customer the conversation ends there. Here the same situation continues: the customer is told the question has been passed on, and a manager already sees both the question and what the bot did find.
What is inside
- Customer question — the entry.
- Search across documents pulls fragments.
- An answer or an admission — the model returns two fields: whether it managed to answer, and the text for the customer.
- Did we answer? — the branch.
- The upper branch answers; the lower one calls a manager and answers too.
The customer gets a reply either way. That matters: silence after a question reads as a breakage even when everything inside worked correctly.
The answer is never empty
The model sometimes returns an empty text field. An empty answer never reaches the chat at all: the customer sees silence, the run is green, and the only way you find out is a complaint. Both branches therefore carry fallback text — that is the difference between “the bot got it wrong” and “the bot vanished”.
What to set up for yourself
- The honesty threshold lives in the prompt: the model must admit failure rather than half-answer. That is the only knob for how often humans get called. Soften it and there are fewer escalations and more unhappy customers.
- The manager’s chat on the call node.
- What the manager sees. Currently the question and the first six hundred characters of what was found — enough to see what the bot was missing without opening the base.
What to connect
A knowledge base with your documents and a Telegram bot for the chat your managers sit in. A dedicated chat works well: then all the hand-offs are visible together, and their number tells you when the documents need extending.