What a messenger bot costs for business and why the range is so wide

Short answer: a bot with three to five scenarios that takes requests and files them into your CRM is the entry point of this work and takes three to five weeks. A bot that accepts payments, answers from your knowledge base and has an operator panel costs roughly two to four times that and takes two to three months. The number of buttons and screens barely moves the figure. What moves it: integrations with your systems, user roles, and what has to happen when the bot does not know the answer.

We quote in roubles, so the figures below are given as proportions and timelines rather than converted amounts — convert at the rate of the day if you need an absolute number, or ask us for a quote.

Where the line with a no-code builder runs

No-code builders cover broadcasts, simple funnels and answers to frequent questions. If the bot lives on its own and knows nothing about your CRM, there is no reason to pay for development.

Development starts where the bot becomes part of a process. A request has to land in the CRM with the right owner. A customer asks about order status and the answer comes out of the accounting system. A manager sees one thing in the bot, an administrator another, a customer a third. A payment goes through and marks itself in the books. Every one of those items in a builder is either a workaround or impossible.

What the budget is made of

Line	Share of budget	What is inside
Scenarios and design	10–15%	Which dialogues exist, where each button leads, what the bot does on an error
The bot itself	25–35%	Dialogues, states, input handling, notifications
Integrations	25–35%	CRM, accounting system, payment provider, spreadsheets
Operator panel and roles	10–20%	Operators, permissions, dialogue history, manual replies
Launch and tuning	10–15%	Server, monitoring, fixes after the first weeks with live customers

The shares are approximate. A bot without payments and without a panel has smaller integration and panel lines, and the whole project sits near the bottom of the range.

The heaviest line is integrations. A bot that stores requests by itself is cheaper than a bot that writes them into the CRM, reads stock from the accounting system and reconciles payments. The cheap one, though, turns within a month into one more place managers have to check by hand.

Three typical projects

A request-intake bot: the entry point, three to five weeks. A few dialogue scenarios, a short form, the request handed to the CRM, a notification to the manager. An order-status bot belongs here too, as long as the status lives in one system and that system has an API.

A bot with payments and a customer portal: two to three times the entry point, two to three months. A catalogue or a price list, an order, payment through a provider or an instant-payment scheme, and for B2B an invoice from the accounting system with payment tracking. A Mini App often appears at this level, a customer portal inside the messenger: a catalogue and a basket read better as a page than as buttons.

A bot that answers from your knowledge base: three to four times the entry point, two to three months. Simple questions are closed by scenarios, hard ones go to a search over your documents with a language model, and an uncertain answer is handed to an operator. The expensive parts here are preparing the knowledge base and the rule for handing over to a human. How that search works is covered in the piece on parsing corporate documents.

What quietly makes it bigger

Where the bot is hosted. A server inside Russia may have no direct route to the messenger’s servers, and messages stop arriving with no error anywhere in the code. That needs a proxy or an intermediate server abroad, and contracts rarely mention it. We ran into this ourselves on request notifications from our own site.

Roles that appear along the way. At the start it looks like two roles, customer and manager. Then it turns out a head of department has to see everyone while a manager sees only their own accounts, and partners have their own prices. Each new role touches every scenario at once.

An old CRM without a usable API. If the CRM can only export to a spreadsheet, the integration becomes a project of its own. One question on the first call settles it.

Answers “from the knowledge base” that does not exist. A language model needs something to stand on. If the rules and the answers live in the operators’ heads, somebody has to write them down first, and that is work on the client’s side.

What it costs after launch

A running bot keeps spending: the server, the proxy, payment fees, and the language model’s requests if one is connected. Plus fixes whenever the CRM, the price list or the process changes. Telegram changes its own API from time to time, usually with backward compatibility, so that line is rare.

Settle separately whose account the bot is registered on. The bot account should belong to your company, with the code and the database handed over after payment. A bot registered to a developer’s personal account cannot be taken back without that developer.

Common questions

Can a bot be built below the entry point? Yes, if it is connected to nothing. In that case a no-code builder is the better buy: cheaper than any development and changeable without a programmer.

How is a bot different from a customer portal on the website? A bot covers short frequent actions: a request, a status, a document, a notification. A large catalogue, comparisons and many roles work better in a web portal. Covered in detail in when a bot replaces the portal.

How long until the first working version? A bot with the main scenario and a CRM connection goes live in three to five weeks. The rest is added with live customers already on it.

Can payments be taken inside the messenger? Yes, through payment providers, an instant-payment scheme or the messenger’s own payment layer. For B2B an invoice from the accounting system is usually more convenient: the bot sends it and marks it paid.

The rule

To get to a price for a bot, list the systems it has to exchange data with and the roles of the people who will use it. Scenarios and buttons add little. The rest is on the messenger bot development page.