AI Telegram chatbot: where first-line support breaks
First-line support breaks not when the bot is launched, but a few weeks later, when the flow of requests stops being uniform.
The bot confidently handles typical questions — order status, delivery terms, service operation — but as soon as a person needs data from the back-office system or an action on behalf of an employee, the request goes to an operator.
After that, everything is decided by the operator's response time: during peak hours it grows from minutes to hours, and that is exactly where losses begin.
The most vulnerable point is the night shift. At night, one person is on duty for the entire flow, and a bot with a rigid menu sends everything that does not fit the predefined branches to the general queue.
Requests accumulate until morning, some customers go to a competitor and do not return — these are the lost requests that later cannot be seen in any reporting, because the dialogue is formally not closed, but abandoned.
The second layer of the problem is access control and escalation context.
When one bot serves all channels and roles, the operator receives a request without history, without attachments, and without understanding what the bot has already answered, and starts the conversation with “describe the problem again.” At the same time, some scenarios require actions with customer data that cannot be performed without explicit confirmation and a log: without an access matrix, this is either a bottleneck in one person or a risk of irreversible changes.
All of this is treated not with a “smarter model,” but with engineering tooling: scenarios by request types, escalation rules with context transfer, a role model, and an action log. Below we explain exactly how this is covered.
What changes after implementation: metrics and load
The first noticeable shift is first response time. Previously, it depended on the availability of a free operator: during working hours it meant minutes of waiting, at night — until morning.
After connecting the bot to Telegram, the first reaction arrives within seconds at any time of day, and the response queue stops being a separate entity.
The share of autonomous dialogues is the main metric we put in the report. We count by outcomes, not by the number of messages: the denominator includes a dialogue with a task, the numerator includes those closed without transfer to a human.
Order status, terms of service, booking and rescheduling are closed by the bot; everything that requires an exception decision goes to the operator together with the chat history, so the customer is not asked to repeat their story.
Peak hours show the difference most sharply. An operator handles two or three conversations at the same time, while the bot handles hundreds, so a surge of requests does not turn into a queue but is processed immediately.
Abandoned dialogues drop not because customers are patient, but because waiting disappears from the scenario.
To make the numbers prove something, we first capture baseline indicators: request flow by hour, share of peak ones, how many dialogues are lost now.
Then the same slices run by week, separately for autonomous and escalated ones — it becomes clear where the bot hits the boundary of its knowledge and which scenario to expand next.
Implementation options: a builder or a custom Telegram bot
The choice between a ready-made builder and custom development is a choice between launch speed and depth of logic.
A builder assembles a scenario from blocks in a matter of days, but hits a ceiling as soon as the bot needs to look into the back-office system and calculate something based on customer data.
The key criterion is what the bot must know and how often that knowledge changes. If the answers are in a knowledge base and are rarely edited, a visual editor is enough.
If the decision depends on order status, tariff, or request history, integration with the back-office system is needed, and logic branches are moved into code.
| Option | When it fits | Limitations |
|---|---|---|
| Ready-made builder | Typical scenarios: booking, request, knowledge base answers, broadcast | Logic is limited by editor blocks, external data only through standard connectors |
| Custom development | Dialogue based on customer data, custom rules and roles, request handling | Longer launch, code support and quality control of model responses required |
| Hybrid mode | Need fast start and non-standard branches at the same time | Two circuits: part of the logic lives in the editor, part in the service, end-to-end dialogue analytics required |
In practice, the hybrid mode covers most tasks: the bot accepts the dialogue in the editor, while non-standard branches — calculation, status check, transfer to an operator — go to our service.
The launch remains fast, and the logic does not hit the builder's ceiling and does not require rewriting the bot as load grows.
We compare the options by three parameters: data volume, number of scenarios, and frequency of their changes. Describe the task — we will come back with an estimate and a plan for which mode will deliver a sustainable result.
How implementation proceeds: from dialogue scheme to launch
Implementation is divided into six stages — from analyzing current requests to handover for operation. Each step relies on the artifacts of the previous one, so only those scenarios that actually occur in the flow make it into the bot, and bottlenecks are visible before launch.
-
Request analysis. We take an export of chats and operator logs: which topics repeat, where access to internal systems is needed, what share of questions is resolved without a human.
The output is a frequency list of topics and the boundaries beyond which the dialogue goes to an operator.
-
Scenario map. We turn topics into an intent tree with clarification branches, data slots, and explicit exit points. For each branch, we record the expected result, not just the text of the lines.
-
Integration setup. We connect Telegram via a webhook with delivery confirmation, link the bot to CRM, the knowledge base, and the reference directory — with idempotent handling of retries and rate limiting.
-
Test environment. A separate bot and a copy of the data: we run scenarios on synthetic dialogues, check empty messages, attachments, long pauses, and parallel sessions of the same user.
-
Live flow testing. We open the bot to part of the traffic: we look at the share of dialogues closed without an operator, response time, and escalation trigger frequency — we adjust wording based on real failures.
-
Handover for operation. We hand over the scenario scheme, accesses, instructions for editing answers, and the escalation regulation: roles, threshold for transfer to a human, and procedure for updating the knowledge base.
Handover package: scenarios, integrations, documentation
A project is closed not when the bot responds in the work chat, but when the client's team can run and develop it independently.
Therefore, we hand over not only a working service but also a set of artifacts: schemes, policies, instructions, and regulations describe the system's behavior, and with them a new engineer or operator can figure it out without us.
Below is what exactly is included in the package and why each document is needed in practice.
- Dialogue map — all scenario branches with entry and exit points: greeting, data collection, answers to frequent questions, transfer to an operator, and bot behavior when the model is uncertain.
- Integration scheme — what calls what and where: messenger, CRM, knowledge base, team notification channel; separately noted where access keys are stored and how they are changed.
- Access policy — operator and administrator roles, scope of visible data, rules for storing and exporting chat history, and the procedure for when a user requests data deletion.
- Operator instructions — how to take over a dialogue, what to answer in typical situations, how to log a complaint, and when to return the conversation to the bot.
- Knowledge base update regulation — who adds new answers and in what order, how quality is checked after editing, and how to roll back an unsuccessful change.
- Environment configuration — test and production environments, so checking new scenarios does not affect real users.
- Acceptance checklist — a set of scenarios with expected answers, used to check every edit before publication.
- Metrics dashboard — share of dialogues closed without an operator, frequency of transfer to a human, and analysis of dialogues where the bot failed.
We hand over the package in a workable form: schemes are editable, instructions are versioned, regulations are tied to specific steps. After handover, we hold a review with the client's team — so the artifacts do not just sit in a folder but are used in daily work.
Implementation practice: 12,000 requests per month without queues
The client is a service company with a flow of about 12,000 requests per month: applications, statuses, returns, and typical questions about services.
Before implementation, everything went to operators: during peak hours, first response time reached 40–60 minutes, people left without waiting, and nighttime requests simply waited until morning. The queue grew faster than the support staff.
What the before-and-after measurements showed:
| Metric | Before implementation | After |
|---|---|---|
| First response time | 40–60 minutes at peak | 5–15 seconds |
| Self-service share | near zero | 68% of dialogues closed without a human |
| Requests reaching an operator | 100% | 32% |
| Night and weekend requests | accumulated until morning | processed at the moment of request |
The bot was built on Telegram and linked to the internal knowledge base: answers are taken from current regulations, not from hardcoded phrases.
Requests are tagged by topic — where the scenario is predictable, the bot leads the dialogue; where the topic is not recognized or the client asks for a human, the conversation goes to an operator together with the chat history, without repeated questions.
Operator relief came not from turning customers away, but from precise routing: a third of requests go to humans, and these are exactly the complex cases.
The peak queue disappeared, and support stopped being expanded in proportion to flow growth — the previous team handles the volume that would previously have required a second shift.
What to do if part of the requests is already handled by a ready-made service
A ready-made service does not get in the way — it is moved behind a common router. A single entry point receives incoming Telegram messages and decides who answers a specific request: the ready-made solution, your logic, or a live operator.
Then the transition period runs in parallel with the bot's operation, without stopping for switching.
History migration is done before enabling the new logic, not after.
Dialogues are exported in batches, user identifiers are matched, and they are stored in your own database — the handler sees previous messages, does not ask for the name again, and does not start the conversation from scratch.
If identifiers diverge, a mapping table is maintained: without it, part of the context is silently lost, and that only surfaces in customer complaints.
Duplicate answers are the main risk of this period. When both handlers listen to the same message, the person receives two different answers, and this is immediately noticeable.
It is closed by idempotency: the router marks the request as taken into work and gives it to exactly one handler, while the others see that it has already been processed.
Access rights are transferred together with the dialogues. Operator roles, group bindings, and the rules for who sees which requests are mirrored in the new system, so that during the transition period managers do not lose access to their chats. Correctness is checked by reconciliation: the list of roles before and after must match.
When both circuits work on the same data, shutting down the old service becomes manageable. The logic is migrated by shares of requests, and the former channel is kept as a backup until the metrics of both circuits match.
Load, access, and fault tolerance: answers to doubts
We check peak load with load testing: we simulate a flow several times higher than the forecast — a broadcast to the database, a surge after an advertising launch, a nighttime peak in another time zone.
We look not at average response time, but at queue behavior: requests are processed in order, and when hitting platform limits, the bot responds with a delay but does not lose messages.
An external service failure is a standard scenario, not an accident.
The request is sent with a retry and increasing pause; if the primary model provider is unavailable, traffic switches to the backup one, and if both are unavailable, the dialogue is transferred to an operator with context preserved. The user receives a meaningful answer instead of silence.
We store the chat history in your infrastructure: the retention period is set by policy, sensitive fields are encrypted, and access is written to a log.
We delimit rights by roles — an operator sees only their own dialogues, an analyst sees anonymized statistics, an administrator sees settings but not the content of chats.
What happens if an external service is unavailable for several hours?
Requests accumulate in the queue and are processed when the service returns; during a long outage, the rule for transfer to an operator triggers. No dialogue is lost — in case of failure, the client sees in the log how many requests waited and for how long.
Which employees see customer chats?
Only those roles that need it according to the regulation. Export is anonymized, access is via named accounts, and viewing history is retained. We agree on the role scheme before launch, not after an incident.
How can we make sure the bot will withstand peak load?
We run the scenario on the test environment with a realistic traffic profile and record a report: share of processed requests, response time at peak, failure points. We hand over the report together with the configuration — it shows how much headroom remains before the limit.
Let's discuss the task and come back with an estimate and a plan
To calculate launch timelines and team composition, a detailed technical document is not needed — a snapshot of how requests live now is enough.
Discussing the task takes one meeting with the department head and the person who answers customers daily: they will describe more accurately than any document where the bot will relieve the load and where it will break the usual process.
What we ask you to send before the estimate:
- A list of typical requests — 15–30 formulations with approximate frequency. They show what share of dialogues is closed without an operator and what share always goes to a human.
- A list of systems the bot must work with: customer records, request records, knowledge base, calculation system, booking calendar.
- Access to the test environment of these systems — to read data and, where needed, create records.
- Escalation regulation: at what point the dialogue is transferred to an operator, during what hours, and what is considered an emergency.
- Restrictions on wording: which topics the bot does not touch and which promises it does not make.
- Acceptance criteria: share of dialogues without an operator, first response time, scenario matching accuracy.
On our side, by the start we prepare a work plan with stages and dates, a team composition with areas of responsibility, a draft of scenarios and intent markup, a test bot in a closed environment, and a verification procedure before release into the common chat.
