Off-the-shelf chatbot or custom: counting the cost of ownership
An off-the-shelf bot launches in a week and looks ten times cheaper. The difference shows up not in month one but where the bot has to look inside your systems, answer from your documents and hand over to a human honestly. What the two-year bill is made of and how to choose without overpaying either way.
9 min read
What you are actually buying in a box
In an off-the-shelf bot you are not paying for “the ability to answer” but for four things: channels (site, Telegram, WhatsApp), a scenario editor, an operator console and conversation storage. All of it is expensive to build yourself and pointless to: the market has turned that part into a utility.
What is not in the box is knowledge of your business. It gets there three ways: you write scenarios by hand, you upload documents into their knowledge base, or you connect your systems. The first is cheap and goes stale fast, the second depends on how the platform chunks your documents, the third almost always runs into the limits of their integrations.
Three pricing models and what they mean in practice
Before comparing numbers, look at what exactly is being counted. The pricing model predicts where it will hurt.
- Per operator seat per month. Clear and predictable while the support team is small. It grows with headcount rather than with value: a bot that reduced the load does not reduce the bill.
- Per conversation or per message. The bill grows with success: the better the bot works, the more you pay. On seasonal spikes this model delivers a nasty surprise in exactly the month the business is already stretched.
- Per token, if the bot runs on your own model. Here the bill depends on context length rather than headcount. For scale: GigaChat's public pay-as-you-go price for legal entities is ₽0.065 per 1,000 tokens on Lite and ₽0.5 on Pro; Yandex AI Studio lists YandexGPT Lite synchronous mode at ₽0.2 per 1,000 tokens (both VAT-inclusive, checked 6 September 2026). This is the only model where cost can be reduced by engineering.
Four places where the box runs out
None of these is about platform quality. They are structural limits, and it is better to know them before buying.
- Action instead of an answer. While the bot answers, the box copes. The moment it has to do something in your system (check a balance, file a return, move a booking) you need an integration, and its depth is limited to whatever the platform has already implemented.
- Answers from your documents. Quality here is set by how the corpus is chunked and how retrieval works, not by the model. A ready platform chunks documents its own way and you usually cannot influence it — and that is where most bad answers are born.
- Handover to a human. A good bot differs from a bad one not by how much it answers but by how fast it admits it cannot help. In a box the handover rule is usually coarse: keywords or a count of failed attempts rather than answer confidence.
- Accountability for what was said. If the bot promises a customer something untrue, you answer for it, not the platform. In sensitive domains that means you need your own constraints on wording and a log that lets you reconstruct why the bot answered as it did.
The two-year bill: six lines
Comparing “subscription against a quote” is not a fair comparison. An honest table has six lines and you fill it in for both options.
- Launch: setup, scenarios, integrations, migrating the knowledge base. Lower for the box, but not zero.
- Subscription, or infrastructure plus tokens. Compute it from your dialogue volume, not from the headline plan price.
- Content upkeep: who updates the answers and how often, when terms and prices change.
- The cost of a wrong answer times how many there are. In medicine, finance and logistics this line is often larger than all the others combined.
- Cost of growth: what happens to the bill when dialogue volume triples.
- Cost of exit: whether scenarios, dialogue history and the knowledge base port out if the platform stops fitting.
The hybrid: box at the front, your own layer on knowledge
The pattern we land on most often: channels, widget and operator console stay on the ready platform, while the knowledge and action layer is yours. The platform calls your service over an API; that service searches your documents, talks to your systems and returns an answer with its source.
That way you do not pay for what has already become a utility, and you still control what you are accountable for: retrieval quality over your documents, access rights, wording boundaries and the handover rule.
When the box is the right answer
Take the ready solution if customer questions repeat and there are few of them, answers do not depend on an individual's data, the cost of a mistake is a bad mood rather than money or health, and you have no requirement to keep conversations inside your perimeter.
Your own layer starts paying off when the bot has to look inside your systems, answer from documents you maintain yourself, or work in a domain where a wrong answer is expensive. We say this to the people we end up steering to the box as well: selling development where it is not needed costs us more than it earns.