Telegram AI bot: what breaks in real operation
A chat demo and production operation diverge quickly. Platform limitations of Telegram — rate limit on outgoing messages, response timeout, update delivery rules — cause the first failures of a Telegram bot: some replies arrive with a delay, some are lost during reconnection.
Next are hallucinations of the language model. It answers in a confident tone even where there is no data: it invents deadlines, terms, service availability. The error looks plausible, the user takes it as the company's position, and someone has to sort it out manually.
At the third or fourth step, loss of dialogue context appears. The history does not fit into the model window, is trimmed by old messages, or is not transferred between sessions — the bot asks again what it has already asked and loses the essence of the request.
A separate line of failures is external dependencies and load on the bot.
While the service responds slowly or is unavailable, requests pile up, repeated clicks duplicate requests, and the operator does not connect: handing over to a live specialist is not provided for in the scenario.
Each of these failures is reproducible and can be fixed engineering-wise: fact checks before sending, storing dialogue state separately from the model, retries with a limit, and clear escalation. Below we break down how this works.
Measurable effect: speed, load, share of auto-replies
Time to first response
The delay before the first meaningful response is the metric by which the user judges the bot, and it is also the most sensitive to implementation.
In Telegram, an incoming message arrives via webhook and is processed asynchronously: while the model composes a response taking into account the dialogue history, checking request status and other heavy operations run in parallel.
That is why the first response fits into a matter of seconds, not minutes of waiting for an operator.
Typical scenarios — order status, booking, clarifying terms, frequently asked questions — are closed without human involvement for 60-80% of requests, and the automation share grows as wording accumulates.
The rest is not lost: the bot passes the entire dialogue to the operator, with the parameters already collected. It is the transfer of context, not the auto-reply itself, that provides the main reduction in support load during peak hours.
Request processing time and peaks
The request arrives in a structured form: what is needed, for whom, by when, contact. The clarification stage disappears, request processing time shrinks from hours to minutes, and the share of cards filled out with errors falls — fields are validated right in the dialogue.
The first line survives peak load without an increase in waiting time: handlers scale with the number of simultaneous dialogues, and platform restrictions on sending messages are smoothed by a queue with retries.
Metrics — share of responses accepted without escalation, queue waiting time, frequency of handover to an operator — are taken regularly, and we further train on escalations: the share of auto-replies grows from iteration to iteration.
Bot formats: assistant, requests, support
The bot mode is chosen by the type of inquiry, not by the functionality of the module. Bot scenarios differ in two things: who makes the decision — the model or a human — and what counts as the result of the dialogue: an answer, a completed request, or a closed issue. The error begins where these modes are mixed in one flow without transition rules.
Below are four working options and their boundaries. They do not exclude each other: one bot on a common core can run several branches, and the mode is determined on input by intent — so switching between them does not require rewriting the logic.
| Option | When it fits | Limitations |
|---|---|---|
| Assistant with a knowledge base | Questions about documentation, regulations, tariffs — the answer already exists in your sources | Answer quality is limited by the completeness of the base; regular export and updating are needed, otherwise the bot confidently answers with outdated information |
| Requests via the bot | You need to collect data (request type, contacts, attachment) and pass it to the accounting system | The model's flexibility gets in the way here: a rigid scenario is more predictable, and the bot must complete the form to the end rather than reason |
| First-line support | High-volume, same-type inquiries: status, access, step-by-step instructions | It covers only pre-described topics; everything outside the scenario accumulates frustration — an honest exit to a human is needed |
| Hybrid with an operator | Mixed flow: routine goes to the bot, complex cases go to a live employee | More expensive to set up: escalation rules, transfer of dialogue context, operator work without losing the message history |
The main source of failures is not the choice of module, but the junctions between modes. If the bot answers from the knowledge base where a form is needed, requests are lost.
If escalation does not pass context, the operator starts the dialogue over — and the client repeats everything a second time. That is why the mode is fixed before development, together with the rules for transitions between branches.
How we conduct implementation: from audit to handover
Before the first line of code, we analyze what is already happening in the correspondence: we export the history of inquiries, label it by topic, and calculate the share of typical questions.
This determines where a language model is truly needed and where buttons and branching are enough — the latter is cheaper to support and does not make mistakes on wording. After that, the work proceeds in fixed stages.
- Dialogue audit. We export the history, calculate the share of repeating requests, note where the operator asks again, and compile a list of topics for which there are no answers either in the regulations or in the knowledge base.
- Scenario design. The conversation scheme: what the model decides, what rigid logic decides, at which step handover to a live operator is mandatory, what data the bot collects and where it writes it.
- Knowledge base connection. We split regulations, instructions, and price lists into semantic fragments, define the model's system instruction and the rule: no source — no answer; instead of guessing, a clarifying question.
- Integration setup. Connection to the accounting system and support channel, roles and access, dialogue logging, limits on response length and frequency.
- Testing on real inquiries. We run the bot against the export from the audit, calculate the share of correct answers and the share of correct refusals to answer, and add missing branches.
- Pilot on a narrow flow. We connect the bot to part of the inquiries, compare metrics with the forecast, and see where people go to an operator and why.
- Handover to operation. We hand over access and schemes, the regulation for editing the knowledge base, instructions for operators, and the procedure for rolling back to the previous scenario.
After handover, a support loop remains: edits to the knowledge base do not require rewriting logic, and dialogue metrics show which topics should be added.
What remains with you: configuration, schemes, regulations
We hand over the bot together with the supporting framework that allows you to maintain it without us.
Artifacts are stored in your repository and documentation storage, not in a closed contractor account: an engineer who did not participate in development can deploy, edit, and roll back the bot using the documentation.
- Bot configuration — environment variables, request rate limits, timeouts, and queue settings for model calls; secrets are stored separately from the code.
- Dialogue scheme — the scenario tree, exit points to external tools, handling of unknown requests, and handover to an operator in an editable form, not as an image.
- Knowledge base and the regulation for replenishing it — source formats, labeling, versioning; loading a new version does not require code edits.
- Model update regulation — the procedure for changing the version, a verification set of questions, acceptance metrics, and return to the previous version in one operation.
- Bot documentation — architecture, deployment and rollback, analysis of typical failures, and what to look at in the logs when there is a complaint about an answer.
- Access and roles — separate accounts for development, testing, and operation, permissions strictly by task, key rotation.
- Set of test dialogues and metrics — reference questions with expected behavior plus a dashboard: share of answers without an operator, response time, refusal frequency.
We close the handover with a walkthrough with your team: we show how to make an edit to the knowledge base and how to roll back a release. After that, you decide — maintain it with your own forces or leave support to us.
Case: support cut manual replies by three times
The area is service support in Telegram: before the bot launch, all inquiries were handled manually by operators.
During peak hours, the first response took 20-40 minutes; outside working hours, the client waited until morning, and about a third of dialogues closed with no answer at all.
Typical questions — order status, return terms, delivery times — made up to 70% of the flow and consumed almost the entire shift.
What changed: the bot answers from the knowledge base and past inquiries, determines intent, and by a confidence threshold decides whether to answer itself or hand the dialogue to an operator.
Handover happens together with the message history and already collected client data, so the person does not start the conversation from scratch.
A separate rule closed the night window: complex cases do not "hang" until morning but go into the morning queue with priority.
Metrics after launch: auto-replies close 65-72% of inquiries without human involvement, and the median first response is less than a minute at any time of day.
Reaction time on handed-over dialogues was cut roughly in half because the operator immediately sees the essence of the request. The peak queue during rush hours decreased by three times — this is exactly the shift saving that is counted as a reduction in manual replies.
The failure class "client did not wait for an answer" has practically disappeared: the share of dialogues closed without support reaction fell from a third to single-digit percentages. An important detail — the bot does not try to answer everything.
Returns, claims, and non-standard terms are handed to a human: the cost of an error in such answers is higher than the gain from speed.
How is a bot on a language model different from buttons?
A scenario bot with buttons is a state tree where every transition is set explicitly. The user clicks "Book", the bot gives the next step, and at any node it is known what will happen next.
Hence predictability: behavior is reproducible, tests are written once, a failure is localized in a specific branch, and the dialogue log reads like a trace.
The price for this is rigidity: any phrase outside the scenario goes to a fallback, and a new branch means modifying the logic and rebuilding.
A bot on a language model parses free-form wording, extracts intent, and maintains the context of several replies. "Move it to after lunch" it understands without a separate menu item, whereas the scenario option requires the person to first find that button.
The gain shows where requests are heterogeneous and cannot be listed in advance: catalog consultation, request analysis, clarifying questions.
The flip side is variability of answers. The model cannot be left without a supporting framework: the answer area is narrowed to the knowledge base, critical actions are moved into separate calls with parameter validation, and the result is checked by rules before sending. Predictability returns — not through a rigid scenario, but through constraints around the model.
Comparison of approaches for support is also not in favor of a single scheme.
In a button bot, editing wording or the order of steps is a logic release; in a bot on a language model, instructions and the knowledge base change, but work with the dialogue log appears: analyzing unsuccessful answers, supplementing sources, controlling recurring errors.
Therefore, the choice of bot architecture is almost always hybrid. The critical path — request, payment, data change — remains deterministic, while free input goes to the model with result validation.
The customer gets predictability where an error is expensive and natural speech where it adds value.
Questions about data, access, and answer quality
When a Telegram AI bot answers from internal documents, doubts concern not the model but the data around it.
Below are direct answers to what usually comes up before launch: behavior when the needed document is missing, failures of external services, access to internal data, and updating without stopping operations.
What if the needed data is not in the knowledge base?
The bot builds an answer only from the found fragments: if there are no relevant documents, it says so directly and offers to pass the question to a human, instead of inventing facts.
The relevance threshold is configurable — for topics where the cost of an error is higher, we make answers stricter.
How does the bot survive failures of external services?
Requests go through a layer with timeouts and retries, and the queue stores requests while the service is unavailable. The user receives a clear message instead of a frozen dialogue, and after recovery, processing continues from the same place.
How do you get access to internal data?
We work in your perimeter or in a dedicated cloud: access via a service account with the minimum necessary permissions, and only what is needed for answers is indexed. Access can be revoked at any time, and permissions are reviewed when the document structure changes.
How do you update the knowledge base without downtime?
Indexing runs in the background into a separate version, and switching occurs after checking against a control set of questions. During this time, users work with the old version, and rollback to the previous one takes minutes.
Let's discuss the task and come back with an implementation plan
For the timeline estimate to be substantive rather than "plus or minus a quarter", several inputs are needed — they determine the scope of work and the implementation plan.
There is nothing to prepare in advance: what is already in support correspondences and exports from accounting systems is enough.
- 20–50 examples of inquiries as they are: with typos, voice messages, attachments, slang. They show where the bot answers confidently and where it must hand the dialogue to an operator.
- What data the bot must see: regulations, price lists, ticket history, tables, exports. The format and update frequency matter — the knowledge preparation scheme depends on this.
- Access boundaries: where there is a programmatic interface, where there is only a file export on a schedule, who issues credentials, and in which perimeter everything operates.
- Entry points: personal chat, groups, buttons, payment, several bots or one with roles. This determines the volume of logic around the dialogue itself.
- Prohibitions and rules: topics in which the bot stays silent, handling of personal data, requirements for storing history and correspondence logs.
- Acceptance criteria: share of dialogues without an operator, time to first response, accuracy on the test set. Without them, acceptance turns into a debate about tastes.
- Roles and timelines: who confirms answers on the customer side, how much time is allocated for the pilot, by what date a working launch is needed.
This is enough to discuss the task substantively and come back with an implementation plan: stages, what we do at each, what you get as output, and by which metrics we check. We provide the timeline estimate and scope of work after that conversation.
