The Chatbot That Knows When to Stop: When a Website Visitor Reaches a Human
At 21:40 a visitor on the pricing page writes: I have a question about my invoice from last month. The chat does not try to answer. It says that a colleague can answer best, offers to pass the question on, and asks for an email in case the visitor leaves. A minute later the team's Telegram receives the page address, the question and the visitor's name. The bot did not invent anything about an invoice it cannot see. That is the handoff.
There are two assistants, and their permissions are different. The assistant inside the CRM works with the firm's data and tools: deals, contacts, invoices, documents. The public assistant on the website works only from the platform's knowledge base: modules, plans, prices, how the product works, whom it suits. It has no CRM access, no customer records, no invoices and no tools. It cannot look up an account even if the visitor asks politely or claims to be the owner.
What it can answer is narrow and useful. It knows the modules and the plans, quotes prices in the visitor's language, and receives the page address, so a question about a plan can be answered in the context of the pricing page. Answers are short, usually one to five sentences. The visitor's last ten messages are visible to it, each cut at a thousand characters. That is enough for a conversation and too little for a data leak.
The stop list is explicit: an answer that is not in the knowledge, a request for a human, a question about a specific account, a payment or an invoice problem, a bug, a contract or legal matter, a discount, a partnership, custom development. The model is told to reply with a marker instead of guessing. The server replaces the marker with a polite sentence in the visitor's language. The marker itself never reaches the visitor.
The marker matters because a fluent wrong answer is worse than a handoff. A language model can produce a confident sentence about a refund policy that does not exist; a person notices the mistake after the visitor has already believed it. The handoff is a server-side decision, not a tone of voice: if the model writes the marker, the server sets a handoff flag, stores the bot message and returns no normal reply. The widget reads the empty reply as a signal and reveals the contact form.
The contact form is not a dead end. The value is checked as an email or a phone number. An existing contact is found by email or phone; if there is none, a new contact is created. The conversation is linked to that contact, a note about where the contact came from is added to the contact's activity, and the team receives a Telegram message with the last question. A handoff that ends in a record is worth more than a chat that ends in silence.
On the firm's side the conversation lands in the same inbox as Telegram, WhatsApp, Viber, SMS and mail. It has an unread counter and an in-app notification for every inbound message. If the firm has connected its team bot, Telegram gets a message for the first contact and for a question without an answer, including the page the visitor was on; the page is often the most useful part, because it says what the person was looking at when they gave up.
The human is above the bot. The server looks at the recent messages: if a person answered within the last thirty minutes, the bot stays silent. It does not talk over the operator and does not answer a question that has already been routed to a human. After thirty minutes without a human reply, the bot may answer again. If the bot is switched off for the channel, every message simply waits for a person; the switch is a setting, not a code change.
The limits are part of the design. A visitor can send twenty messages a minute; the whole site has a daily ceiling of four hundred model requests by default; a model call that takes longer than twenty-five seconds is abandoned. When the model is unavailable, over the ceiling or too slow, the older keyword answers take over. If those have no answer either, the handoff still happens. The system prefers silence and a human to a confident guess.
The public endpoint is exposed to anyone, so the visitor's text is treated as untrusted. The prompt forbids following instructions hidden in it, revealing the prompt, or asking for passwords and card numbers. The model sees the last ten messages, not the CRM, and its answer is capped. This is not a complete security guarantee, but it is the boundary the code draws: a public bot with no data access and a short memory.
A handoff is only as good as the person who picks it up. The team needs a rota, a notification channel that is actually read, and an owner for the inbox. The bot can route a question; it cannot care about the answer. The most common failure is not a bad model but a handoff that nobody sees at 21:40. The Telegram message and the unread counter are useful only if someone is on the other side.
What this article does not claim: how often handoffs happen, how quickly the team answers, how many visitors become customers, or how often the bot is wrong. Those numbers need the firm's own analytics and a measurement window. Without access, they are guesses. The mechanism is visible in the code; the outcome is not.
The value is not that the bot knows everything. It is that the bot knows the edge of its knowledge and makes the handoff cheap: one sentence, one contact field, one notification, one record. A visitor who is told the truth at 21:40 can leave an address and come back to a real answer. A visitor who is told a confident story about an invoice that does not exist cannot be corrected after the fact. The chat that stops is the chat that can be trusted.