Someone writes to a bot: “1 is no longer relevant, and you can close 6 too.” The bot replies: “Got it. I won’t mention them again.” Yet both items reappear in the next summary. That happened in one of our internal Telegram bots. The handler meant to process the reply missed its multi-line format; a fallback handler confirmed an action it had not performed. We recorded the bug and changed the behaviour: when the bot cannot identify the items, it asks a follow-up question.
This is a useful test for any pitch claiming that an “AI bot will replace your manager”. A demonstration looks impressive when everyone asks the right questions. Quality becomes visible when someone writes in a way the script did not anticipate. What happens then? Does the bot fall silent, make up an answer, or pass the conversation to someone who can help?
A chatbot is software that receives messages on a website or in a messenger and handles part of the conversation according to defined rules. It can acknowledge a message, ask a few questions, show verified information and hand an enquiry to a person. AI can help interpret free text, but using AI does not make an answer reliable. For a small business, I would define a narrow job and its limits before choosing the technology.
1. Three levels: from an automatic reply to an AI assistant
A prepared automatic reply does not carry on a conversation. It says the message arrived, when a person will respond and where to find basic terms. If the team works until 6 p.m., “We’ll review your request by noon tomorrow” is more useful than pretending a night-shift manager is online. This often meets the need without a separate bot. We have already covered ways to handle repeated customer questions without a complex system.
A scripted bot asks questions in a set order. It might collect the subject of an enquiry, city, contact details and a suitable time for a call, then create a record for the manager. Every branch needs a clear end: an answer, a submitted enquiry or a handover to a person. An “Other” button that leads nowhere is a particularly polite way to lose a customer.
An AI assistant can interpret messages that are not in the menu, search a knowledge base and compose a natural-language reply. That flexibility also creates new ways to go wrong. If its price source is out of date, it may confidently quote an old price. If it cannot see the schedule, it must not confirm a free appointment slot on its own. A more flexible conversation calls for tighter checks on facts and actions.
The same question applies at every level: what will the customer get when their request does not fit the expected pattern? “We’ll pass it to a person with the context attached” is usually worth more than another polished text-generation demo.
2. What to automate and what to leave to a person
| Task | What the bot can do | Condition or limit |
|---|---|---|
| Acknowledge a message | Name the channel and expected response time | Do not promise an immediate reply when nobody is on duty. |
| Give an address, opening hours or service list | Show information from an approved, current source | Someone must own updates to that source. |
| Collect an initial enquiry | Ask only for necessary details and pass on the request | Verify that the responsible person actually receives it. |
| Route by subject | Create a task, CRM record or support-queue entry | Routing mistakes must be visible. |
| Report a status | Read it from a system that is actually kept up to date | Do not say “done” merely because a message was sent. |
| State a price, availability or terms | Show only verified, current information | If information is missing or contradictory, hand over to a person. |
| Agree an exception, refund or dispute outcome | Collect the context and call the responsible person | The decision and responsibility stay with a person. |
The table is not a shopping list for every business. If enquiries are rare and each is unusual, a manager’s ordinary reply may be faster and cheaper. If questions repeat hundreds of times but the rules change daily, fix the source of those rules first. A bot connected to chaos answers faster, not better.
3. Two failures we saw in our own bots
The first appeared at the start of this article. An internal summary listed numbered items. Someone replied in several lines to close the ones that no longer mattered. The message missed the intended route, while an old handler replied “I won’t mention them again”. The items stayed open. Version history records repetitions on 1, 4 and 6 October 2026. The fix was more than friendlier reply copy: we made the handler accept several numbers, ranges and natural phrasings, and ask for clarification when the numbers are unclear. Confirmation should follow the actual state change.
The second failure concerned the pace of a conversation. In a work chat, someone sent three short messages within a minute. The bot launched three parallel turns and produced three replies. To the person, that was one thought split across messages; to uncoordinated automation, it was three separate requests. We added a short pause to gather the series into one context and a queue for conversations with the same person. The AI did not suddenly become smarter. The messenger behaviour was designed properly.
Both examples come from internal systems. They do not establish the outcome of a client chatbot or justify a claim about time saved. They do point to concrete checks to run before a buyer sees an automatic response: an unrecognised message, several messages in quick succession and an action that failed.
4. What Klar shows, and why it is a different system
We have a published Klar case study. It describes an internal work-email triage system, not a customer-facing chatbot. In the internal pilot, it handled five mailboxes across three companies. It triaged 615 emails from 12 to 26 June 2026 and created 91 tasks over a separate period, 13 June to 8 July 2026. AI helped classify incoming messages and prepare the next action, while people remained in control of replies. These numbers describe the throughput of an internal workflow. They do not measure sales, hours saved or chatbot performance.
The example is useful because of its automation boundary. A system can sort and hand over work without pretending it has made a human decision or answered a customer. Apply the same principle in a messenger: receive the request, preserve its context and get it to the responsible person. If enquiries disappear between chats, start with our guide to choosing a CRM or spreadsheet for enquiries.
GrandMa currently has no published client-chatbot case study. I would not use the mail-triage figures to stand in for one. A new bot needs results measured along its own route: enquiries delivered, answer accuracy, handover speed and conversations a person actually took over.
5. A six-step enquiry script
Take an ordinary task: someone messages a business and wants the team to contact them. There is no need to start with twenty branches. Describe the main path and what happens when the bot does not understand.
- Explain the role. “I’m an automated assistant. I’ll help pass your request to the team.” The person knows who is replying and what to expect.
- Ask one question about the subject. Offer short choices and an open “other” answer. Do not make someone read a service catalogue after they have already described the problem in their own words.
- Collect the minimum context. Ask only what the manager needs to respond: for example, the relevant service and a preferred contact method. Do not collect a passport number, address and birth date “just in case” for a first consultation.
- Repeat the request before handing it over. Show a short summary of what the team will receive. Let the person correct a mistake or choose not to continue.
- Create the record and check the result. Send the enquiry to a CRM or work queue, get technical confirmation, and only then say “I’ve passed it on”. If record creation fails, do not say “done”; offer another contact method or summon a person.
- Set an honest expectation for the reply. State the real working hours, channel and, if possible, an enquiry ID. Keep the history for the manager so they do not restart with “What happened?”
The “I didn’t understand” branch: after one failed clarification, the bot asks a simple question again. If it still cannot be confident, it passes the original message to a person. If the manager is unavailable, it says when they are expected and how else to get in touch. This is an editorial design template, not a universal technical protocol. The number of attempts, time limits and exceptions depend on the business.
The Telegram Bot API provides a way for software to receive messages and send replies. It does not decide what counts as a successful enquiry. You must design the rule “notify only after a confirmed action” and the route to a person yourself.
6. Test the bot before its first customer conversation
I would take 20 real messages from previous enquiries, remove personal data and group them by difficulty. Do not copy live private chats into a third-party service without an appropriate basis and access controls. The aim is to test the wording people really use, rather than the polished lines in a vendor presentation.
The set might contain five short, common questions; five vague or incomplete messages; five messages with more than one subject; and five difficult cases, such as changing or cancelling something, a complaint, a missing price or conflicting terms. Test a run of two or three messages sent within a minute separately. Twenty is a practical starting sample, not a guarantee of quality after launch.
For each message, write down the expected action first: answer from a named source, clarify or hand over to a person. Then check four things: what the bot said; what actually changed in the system; whether the team received the enquiry; and whether the person got a truthful account of the outcome. A mistake in the last check can do more damage than clumsy wording. Someone believes their booking was cancelled or their enquiry accepted, and stops taking action.
After launch, keep an error log with examples, an owner and a deadline for each fix. Testing only a demo in which the bot asks three expected questions is not enough. We describe a useful acceptance approach in our article on evaluating an AI agent by its results.
7. What to ask a vendor before paying
Ask for a map of one enquiry, from the first message to the record the responsible person sees, rather than a slide about the model’s capabilities. The map should show where the bot gets answers, which fields it records, how it confirms an action succeeded and what it tells the person when something fails. If the answer is “the AI will work it out”, ask who finds out when it does not. Otherwise the buyer becomes an unpaid tester.
State separately who maintains the knowledge base after launch. Has the company changed its hours or price while the bot still quotes an old page? That is no longer merely a model bug; nobody owns the data. You also need a person for difficult conversations, access to the error log and a way to stop automated replies when they cause harm. A demo can work flawlessly for five minutes. Daily maintenance determines whether the bot remains useful a month later.
It is reasonable to link the first payment to a testable scenario: for example, twenty test messages, recorded enquiries and handover of exceptions. That will not guarantee every future conversation, but it gives you grounds to accept specific work or report a defect without debating whether the bot is “smart enough”.
8. Data, transparency and access to a person
Call a bot a bot. It helps customers judge a reply appropriately. For systems that interact directly with people in the EU, Article 50 of the AI Act sets transparency requirements for AI interaction; the European Commission says these provisions apply from 2 August 2026. The obligations of a particular provider or business using the system depend on its role and market and need individual assessment. A simple scripted auto-reply may fall under a different legal regime, but misleading a person is still a bad idea.
Ask only for necessary data, explain its purpose and retention period for your process, and limit access to the conversation history. A “talk to a manager” button must actually pass the conversation on, not open another menu. If the AI has no reliable source for a price, availability or a legally significant term, it should say a person will check.
If you want to automate this route, start with five typical enquiries rather than a model name. Show where each goes today and where the answer gets lost. Our automation and AI systems service page describes how GrandMa works with such processes. An honest first result is one verified enquiry handover, not a promise to replace a sales team.