Bot type
One source of truth, and it is the CRM you already pay for
A CRM-connected Telegram bot reads and writes records in the pipeline your team already runs, so a conversation in Telegram updates the same deal a salesperson sees in HubSpot or Salesforce. It removes double entry. It cannot fix a CRM whose data is already unreliable.
CRM-connected bots: price, timeline and limits
- Fixed price
- $4,600 USD
- Delivery
- 24 calendar days from kickoff
- HubSpot ceiling
- ~100 requests per 10 seconds per account, standard plans
- Salesforce ceiling
- Daily API allocation per organisation, not per integration
- Webhook semantics
- At-least-once, out of order, and duplicated
- Concurrency control
- Most CRMs offer none on record updates
As of 2025-10-01, Telegram Bot API 13.4
The problem this solves
The failure mode this build exists to prevent is the second database. A team installs a bot, the bot keeps its own records, and within a quarter there are two answers to the question of what stage a deal is at. Nobody decides which is authoritative because nobody notices the divergence until a forecast is wrong. By then reconciling them is a project rather than a fix.
Wiring a bot into an existing CRM is less glamorous and much more valuable. The CRM stays the source of truth. The bot becomes a fast surface onto it — a salesperson updating a deal from a taxi, a customer answering a qualifying question that writes into a real contact record, a manager pulling the pipeline into a group chat without opening a laptop.
The hard part is not the API. It is the field mapping and what happens when both sides change the same record. Most CRMs have no useful concurrency control, so the design has to decide explicitly which side wins and make the loser visible rather than silently discarded. That decision is where a competent integration and a plausible-looking one diverge, and it is worth making deliberately at the start.
How the build runs
The field mapping is agreed before anything is built
Which CRM object, which fields, which direction each one flows, and what a missing value means. This is a workshop, not a configuration screen, and skipping it is the single most reliable way to produce an integration that has to be rebuilt.
webhookThe bot authenticates as an integration user, not as a person
A dedicated CRM user with scoped permissions. Using a salesperson's credentials works until they leave, at which point every automated write stops and the audit trail becomes a fiction.
webhookWrites go to a local queue first, then to the CRM
The bot records the intended change locally and confirms to the user, then pushes to the CRM with retries. A rate limit or a maintenance window delays the write; it never loses it and never tells the user something happened that did not.
webhookInbound changes arrive by webhook where the CRM supports it
A stage change in Salesforce reaches the bot within seconds. Where webhooks are unavailable or unreliable, a polling fallback runs on a schedule, and the two are reconciled rather than trusted independently.
webhookConflicts resolve by a rule, and the loser is shown
Usually last-write-wins per field with the CRM authoritative on anything a human edited there. What matters is not which rule you pick but that the discarded value appears in a log a person reads, instead of vanishing.
webhookSalespeople update deals in the chat they are already in
A short command or an inline button moves a stage, logs a call or sets a next step. The value is that it happens at the moment of the conversation rather than in a batch at the end of the week, when the detail has gone.
commands
What Telegram will and will not let you do
HubSpot's API allows on the order of 100 requests per 10 seconds per account on standard plans.
A bulk sync of an existing pipeline has to be paced over minutes. It is a one-off cost at go-live, but it needs planning rather than discovering when the account is throttled mid-migration.
Salesforce enforces a daily API call allocation per organisation, not per integration.
Your bot competes with every other integration you run. Sync frequency is a budgeting decision, and a chatty bot can exhaust the org allocation and break unrelated systems.
Most CRMs offer no optimistic concurrency control on record updates.
Two systems writing the same field within the same second produce a last-writer-wins outcome with no error. The conflict policy is therefore a design decision, not something the CRM will enforce for you.
CRM webhooks are at-least-once and can be delivered out of order or twice.
Every handler is idempotent and keyed on the record version rather than assuming each delivery is new. Without that, a duplicate delivery re-applies a stage change that a person already reverted.
Custom fields are frequently renamed by CRM administrators without notice.
Mappings reference internal field ids rather than labels, and a mapping that stops resolving raises an alert instead of writing to the wrong field. Silent misfiling is far more expensive than a loud failure.
When not to build this
- Your CRM data is already unreliable. An integration propagates whatever is there faster and to more places; it does not clean anything up.
- You want the bot to become the primary record system. Then you do not want a CRM integration, you want a different build, and mixing the two produces the two-databases problem this exists to avoid.
- Your CRM is heavily customised with server-side automation on write. Every bot write will trigger workflows nobody has mapped, and the side effects tend to be discovered in production.
- Only one or two people use the CRM at all. The double-entry problem you are solving is smaller than the integration you are buying.
What it runs on
| Component | Version | Why |
|---|---|---|
| grammY | 1.45 | Bot framework and command surface for salespeople. |
| Cloudflare Workers | current | Runtime, with a cron trigger driving the polling fallback. |
| Cloudflare D1 | current | Write queue, sync cursors and the conflict log. |
| Zod | 4.4 | Schema validation on every CRM response, because the shape is not yours to control. |
| TypeScript | 5.9 | Strict mode, with field mappings expressed as types rather than strings. |
Questions people ask before committing
Which CRMs are realistic to integrate with?
HubSpot, Pipedrive, Zoho and Airtable are straightforward and well documented. Salesforce is entirely doable but costs more because of API allocation planning and the volume of org-specific customisation. An on-premise or bespoke CRM is scoped separately.
What happens when the CRM is down or rate-limited?
The write is already recorded locally and the user has already been told it worked, because it did. The push retries with backoff, and if it exhausts its attempts a human is alerted with the exact record and payload. Nothing is dropped.
Who wins when both the bot and a salesperson change the same field?
By default the CRM, on the basis that a human editing directly has context the bot does not. What matters more is that the discarded value is written to a conflict log somebody reviews, so a bad rule shows up as a pattern rather than as a mystery.
Can it create new records or only update existing ones?
Both, though creation is where duplicates come from. New records are matched against existing ones on the keys you nominate before creating, and an ambiguous match is escalated to a person rather than resolved by guessing.
Will this trigger our existing CRM workflows?
Yes, and that is worth taking seriously. Bot writes are indistinguishable from any other API write, so every automation on those objects will fire. Mapping the existing automation is part of scoping precisely because the surprises are otherwise expensive.
Can managers see the pipeline without opening the CRM?
Yes. A command posts a current view into a group, generated on request rather than on a schedule so it is never stale. It is read-only by design; editing a pipeline from a summary view is how records get changed by accident.
How long does the field mapping workshop take?
Usually two sessions. The first surfaces what the fields are supposed to mean, which is often the first time anyone has written it down, and the second settles direction and conflict rules. It is the highest-leverage part of the project.