Integrating a Telegram bot with a CRM
A bot without a CRM is a chat where enquiries lie mixed in with questions like "are you open?". While there are five such enquiries a week, the situation is bearable. At thirty a day, what CRMs were invented for begins. Enquiries get lost not because somebody works badly but because a person physically cannot hold thirty conversations in their head or remember who they promised to call back.
What the integration gives you
The integration solves three problems at once. The enquiry lands in the pipeline automatically and as fields rather than one block of text: name, contact, what the person chose, where they came from. The manager has the history in front of them, including what this customer asked about six months ago. Finally, you get reporting that nobody fills in by hand, which means it can be trusted.
How it works technically
Technically all of this is simpler than it sounds. Every common CRM has an API, so the bot sends a request and creates a deal. The reverse direction runs through a webhook: the CRM tells the bot that the deal status changed, and the bot writes to the customer that their order is ready. The second direction is set up noticeably less often than the first, even though it is the one that takes the bulk of the routine off the managers.
Where the integration breaks in practice
Things usually break not in the API but in the details. The first detail is duplicates. One person wrote to the bot, then called, then filled in a form on the site, and the CRM now holds three cards with the history torn into three parts. So before creating a new contact we look for an existing one by phone, by email or by Telegram identifier, and then attach the deal to whatever we found. Without that the database turns into porridge within six months, and the bot gets the blame.
The second detail is fields. A CRM has required fields, it has lists with fixed values, it has phone formats it accepts and formats it silently discards. The bot has to bring the data into the shape the CRM expects rather than sending it however it came. Separately, agree in advance which fields are needed at all. They can be added later, but reassembling the history across deals already created will not work.
The third and most important question is what to do when the CRM is unreachable. And it does become unreachable, because of maintenance, an exceeded request limit, a changed token or a failure on the service's side. If the bot simply throws an error at that moment, the enquiry disappears and nobody finds out, because the person saw a message saying "thank you, your enquiry has been received". The correct behaviour looks like this: save the enquiry on your own side, answer the customer as usual, put the delivery in a queue and retry with growing pauses. If it has not gone through in several hours, tell the owner. The customer should not suffer because someone else's service had a lie-down.
The fourth difficulty is request rate limits. Every CRM has its own, and a broadcast or a bulk import hits them instantly. Requests have to be queued and spread out over time, which is exactly the same story as with Telegram's own limits.
What should not be moved into the CRM
What should not be dragged into the CRM is the conversation in full. The temptation is understandable: let everything live in one place. In practice you get a card with two hundred messages, not one of which is useful, plus personal data that is now stored there as well. A short summary is more useful: what the customer chose, what they asked about, where things were left. The full dialogue stays in the bot and can always be pulled up by link.
Rollout order and cost
The rollout order that saves money looks like this. First set up one direction, meaning deal creation, and only after the managers have worked with real enquiries for a month, add the reverse one. During that month it usually turns out that half the fields argued over at the start are needed by nobody, while two others nobody thought of are needed after all.
In terms of scope, integrating with one CRM takes a few days on top of the bot itself, provided the CRM has a decent API and you know exactly which fields you need. This is why a bot with integrations costs noticeably more than a lead capture bot. The difference is not in the buttons but in the fact that behind every button stands somebody else's system living a life of its own.