A Telegram bot is connected to a CRM through two points: the bot receives events from Telegram via a webhook or by polling, and it sends data to the CRM through the CRM's API. Your own service sits in between and turns button presses into fields on a customer record and a deal. The platform itself sets the main limit: a bot cannot message a person first, so only people who have already started the bot will receive notifications.
Key takeaways
Telegram delivers events to a bot in two mutually exclusive ways: either the bot asks what is new, or Telegram pushes events to an address you specify. The choice determines what infrastructure you need.
A webhook has a setting for the number of simultaneous connections to your server: values from 1 to 100 are allowed, and Telegram uses 40 by default. That figure caps the load your bot can absorb during a peak hour.
Telegram keeps unretrieved events until the bot collects them, but for no longer than 24 hours. If the bot's server was unavailable for a day, the requests from that period are gone for good — so a bot needs availability monitoring rather than an assumption that it is running.
A bot works as one more sales channel, so the exchange runs both ways: customer data goes into the company's systems, while statuses and reference information come back into the chat.
Telegram itself hands over very little about the person: a chat identifier, a first name and, where set, a username and interface language. There is no phone number among them — it arrives as a separate contact object when the person sends it to the bot with a button in a private chat. That is why the contact request belongs in the script deliberately, once the person understands what the bot is for, not on the first screen.
| System | What the bot sends | What it gets back |
|---|---|---|
| CRM | Contact, the text of the request, answers to questions, source tag | Deal number, pipeline stage, account manager |
| 1C or accounting software | Order and the buyer's details | Price, stock level, payment and shipment status |
| ERP or warehouse | The request released to work | Fulfilment status, deadline, document number |
| Payment service | Amount and order description | Payment link and payment confirmation |
| Telephony | Call-back request with a number | Call outcome and a note in the customer record |
| Knowledge base and AI assistant | The customer's question | An answer from company documents and a hand-off flag |
Technically these are the same APIs, webhooks and connectors as in any other integration: here the bot is simply a client of someone else's interface. How to decide the direction of each exchange and who owns each reference list is covered in our article on integrating a CRM with corporate systems.
The path from a button press to a task for a sales rep takes six steps, and each of them has to be described before development — otherwise free-form text lands in the CRM and nobody can do anything with it.
Registration for the exhibition in our UzFranchise Expo case worked the same way: the bot registered the guest, asked about the purpose of the visit and issued an electronic ticket, while the CRM built segments and mailings from the answers.
One more detail from the same project: exhibiting companies scanned a guest's QR code with their own phone, and the contact went straight into their database. In a setup like this a bot does not only collect requests, it also hands data to the other participants in the process.
The source travels in the bot link itself: a start parameter with a tag is appended to an address of the form t.me/your_bot, and Telegram passes that tag to the bot in the very first event. The tag then goes into a deal field and stays in the CRM with the customer.
The limits on the parameter are simple: up to 64 characters, with Latin letters, digits, underscore and hyphen allowed. For complex values the documentation recommends encoding the parameter with base64url instead of inventing your own format.
That is why tags are kept short and readable: ig_sept, qr_stand12, site_pricing. A deal report then shows which link brought paying customers and which one only brought subscribers. How the same task is solved for mobile apps and ad campaigns is covered in our article on app analytics and deep link tracking.
One tag is not enough once there are many links. Keep a register of tags and a naming rule — channel, campaign, placement — otherwise in six months the report will hold two dozen values, half of which nobody can trace back to their source.
Some familiar tasks are off limits to a bot under the platform's rules. It is fairer to settle this before development than to discover it on the day a campaign launches.
Important A bot cannot start a conversation: the Bot API documentation puts it plainly — the user has to message the bot first or add it to a group. So the notification list is built only from people who pressed the start button, and purchased phone lists are useless in Telegram.
These rules cannot be worked around, but a scenario can be built around them: capture the bot start at the first touchpoint, duplicate critical notifications in a second channel, and do not count on a bot for cold outreach. What a bot does for a business beyond collecting requests is covered in our article on Telegram bots for business.
Connecting a bot takes six steps, and the first two happen on paper: until the fields and events are written down, there is nothing to configure.
It is worth agreeing separately who looks after the bot after launch. An unattended bot breaks quietly: Telegram stops reaching the webhook, requests pile up, and the problem surfaces through a customer's phone call.
The price depends on whether you are building a bot from scratch or wiring an existing one into a CRM. On the service page these are three different formats.
Three things push the budget above the starting figure: the number of systems to connect, closed or in-house programs without an API, and the length of the script — every extra dialogue step has to be thought through, written and tested. What each format includes is described on our bots and AI assistants page.
After launch a bot carries running costs: the server it lives on, from $30 a month, and someone to watch the exchange. Support for a company's business systems, including the CRM and its integrations, costs from $700 a month; the scope is described on our technical support page.
Syntra Systems starts with the script and the fields rather than the code: we work out what customers ask about, what can be handled without a person and which data has to end up in the CRM. We then fix the exchange design and assemble the chain — bot, exchange service, CRM, payments and the accounting system.
Requests are filed into the CRM with a source tag, alerts go to the people responsible, and statuses come back to the customer in chat. We configure retries and an error log so that a request which failed to arrive is visible at once, and we stay in touch after launch: the first conversations always show which wording in the script needs rewriting.
Let’s discuss your project
Tell us what you need, and we will estimate the timeline and cost and suggest a solution.
Any CRM with an API or webhook support will work: through them the bot creates a contact, a deal and a task. Without an open interface, a file export or an intermediate service remains, but then requests arrive on a schedule rather than instantly.
No. A bot does not start conversations: the person has to open the bot and press the start button. That is why a tagged bot link is added to the website form, and once the person has started the bot, order notifications can be sent to them.
Each ad gets its own tagged bot link, for example t.me/bot_name?start=ig_sept. The tag reaches the bot on first launch and is saved to the deal, so the report shows which ads brought paying clients. Set up a reference list of tag names in advance, or in six months nobody will remember what half of them mean.
The request should not vanish: the bot service puts it in a queue and retries until the CRM responds. Without a queue and retries such requests are lost silently, and the only clue is a mismatch between the number of conversations and the number of deals.
Yes. An integration should run under a dedicated account with minimal rights and its own access key. If the bot works under an employee's login, the exchange stops the day that person leaves and their access is revoked.
It can: the bot creates the deal in the CRM, gets a payment link from the payment service, and pulls the order status from the accounting system. Each system adds its own exchange and its own failure modes, so they're connected one at a time, starting with the CRM.
Telegram holds unread events until the bot picks them up, but for no longer than 24 hours. An overnight outage survives; a full day doesn't — requests from that period are lost for good, which is why the bot needs uptime monitoring.
