«Нужен простой бот для заявок. Уже нашли за 30 тыс. ₽. Почему у вас 220 тыс. ₽?» Я слышу это регулярно. Через десять минут разговора обычно выясняется, что нужен не бот с кнопками, а рабочая схема: принять лид, отфильтровать мусор, передать в CRM, напомнить менеджеру, принять оплату и не потерять статус по дороге.
Под словом «бот» рынок продает слишком разные вещи. Если хотите понять цену без гадания, смотреть надо не на Telegram, а на процесс, который вы туда переносите.
Цена начинается не с Telegram, а с вашей операционки
Telegram Bot API у всех один. Разница в том, что именно бот должен сделать для бизнеса и что сломается, если он ошибется.
У нас был проект для сети клиник. Заказ звучал просто: «запись на консультацию». Когда начали разбирать, внутри оказалось: выбрать филиал, врача и слот, подтвердить запись, отправить данные в amoCRM, уведомить администратора и напомнить пациенту за день. Первая оценка была 40 часов, рабочая - уже 160 часов.
«Мы сначала думали, что покупаем чат с кнопками. А потом поняли, что это вход в расписание, CRM и работу администраторов», - операционный директор сети клиник.
Самые дорогие часы уходят не на команды /start и /help. Они уходят на сценарии: пользователь нажал кнопку дважды, прервал оплату, вернулся через сутки, CRM ответила дублем, менеджер сменился в середине диалога.
У ботов есть четыре класса, и бюджеты у них тоже разные
Здесь обычно промахиваются в одну из двух сторон: либо берут кастом там, где хватит конструктора, либо вешают важный процесс на no-code, а потом переписывают все с нуля.
| Тип | Бюджет | Срок | Где упрется |
|---|---|---|---|
| Бот-визитка / FAQ | 20-80 тыс. ₽ | 1-2 недели | сложная логика |
| Бот для заявок и записи | 120-300 тыс. ₽ | 2-5 недель | ручная работа без CRM |
| Бот с интеграциями | 300-800 тыс. ₽ | 4-8 недель | нужен нормальный бэкенд |
| Бот как часть сервиса | 800 тыс. ₽ - 2+ млн ₽ | 2-4 месяца | это уже продукт |
По стеку картина обычно такая:
- конструктор - дешево и быстро, пока сценариев мало;
- Make или n8n - хороший способ собрать MVP за 2-3 недели;
- кастом на Python 3.12 + aiogram 3 или Node.js 20 + NestJS - когда есть интеграции, роли, платежи и рост нагрузки.
В прошлом году мы делали бота для образовательного проекта. Стартовали на n8n, чтобы проверить спрос и взять первые оплаты. Через месяц перенесли ядро на Node.js 20 + PostgreSQL 16, потому что появились подписка, статусы и разделение прав. Это нормальный путь, если закладывать его сразу.
У нас, кстати, был и обратный случай: однажды мы сами переоценили запас no-code и слишком поздно вынесли критичную логику в код. Ничего не упало, но неделю пришлось разгребать ручные статусы. С тех пор я такие узкие места отмечаю еще на старте.
Дорого стоит не интерфейс, а надежность
Когда заказчик смотрит на смету, он видит строку «разработка бота». Внутри сидят вещи, которых не видно на демо: модель статусов, повторные попытки отправки, логирование, защита от дублей, обработка таймаутов, мониторинг.
Типовая структура бюджета у нас выглядит так:
- аналитика и проектирование - 10-20%;
- разработка - 50-70%;
- тестирование и запуск - 10-15%;
- управление проектом - 10-15%.
Сильнее всего цену двигают интеграции. amoCRM, Битрикс24, 1С, внутренняя ERP, платежки - это легко еще 40-200 часов. Если у клиента старая ERP без внятного API, сроки начинают расти еще до основной разработки. Для живых проектов мы обычно берем webhook, PostgreSQL 16, Redis, Docker и нормальное логирование. Long polling на нагрузке я бы не ставил, если бот влияет на деньги.
С оплатами та же история. ЮKassa, CloudPayments или Telegram Payments сами по себе не проблема. Проблема начинается там, где платеж прошел, а заказ в CRM не создался.
Где можно срезать бюджет, а где потом будет больно
Экономить можно на красивой админке, редких ветках, второстепенных разделах и сложной аналитике. Если надо быстро проверить гипотезу, этого часто достаточно.
Вот короткий чеклист перед запуском:
- что пользователь должен сделать за 1-3 минуты;
- где будут храниться статусы и история действий;
- нужен ли оператор внутри процесса;
- что произойдет, если заявок станет в 5 раз больше;
- кто заметит ошибку раньше клиента.
Один кейс у нас запомнился хорошо. Компания запустила запись через конструктор за 35 тыс. ₽. Пока поток был маленький, все выглядело нормально. Когда дошли до 300+ заявок в неделю, пошли дубли, отмены терялись, менеджеры вручную сверяли CRM и чат. Переделка на кастом обошлась в 280 тыс. ₽ и еще в месяц нервной ручной работы. Мы это чинили на Python 3.12 + aiogram 3, вынесли статусы в PostgreSQL 16 и добавили очередь повторной отправки.
Нормальная оценка начинается с правильных вопросов
Если подрядчик называет цену за пять минут, не разобрав сценарии и интеграции, это не точность, а гадание.
Перед оценкой я бы зафиксировал четыре вещи: цель бота, обязательные интеграции, примерный поток пользователей в месяц и список мест, где ошибка стоит денег. После этого вилки становятся уже не «от 100 до 700», а разговором по делу с понятным объемом работ.
Когда вам в следующий раз покажут вариант за 30 тыс. ₽, спросите не «почему так дешево», а «что будет в понедельник утром, когда менеджеры откроют CRM». В этот момент обычно и становится видна настоящая цена бота.
