Самый дорогой Telegram-бот в моей практике стоил не 300 000 ₽. Он стоил 30 000 ₽ на старте и еще одну полноценную переделку через два месяца. Сначала бизнес купил «быстрый запуск», потом - перенос логики, интеграции и ручную работу команды, которая внезапно появилась между ботом и продажами.
Если упростить, выбор тут такой: вы берете либо кнопку в Telegram, либо новый рабочий контур для бизнеса. Считать стоит не цену запуска, а то, что будет через 6-12 месяцев.
Цена ошибки живет не в боте, а вокруг него
Путаница начинается в тот момент, когда «шаблон за 30 000 ₽» и «кастом за 300 000 ₽» сравнивают как один и тот же продукт. Это разные классы решений. Коробка почти всегда закрывает интерфейс, а не процесс.
Очень быстро появляется второй слой работ: запись данных в CRM, уведомления менеджерам, статусы оплат, логирование ошибок, повторная отправка событий, права доступа. В смете конструктора этого обычно не видно в первый день.
Мы в таких задачах смотрим на совокупную стоимость владения (TCO) за 12 месяцев. Туда входят:
- лицензии и платные модули
- интеграции и их поддержка
- ручные действия команды
- миграция, если коробка упрется в потолок
У сервиса записи на услуги мы сначала пошли коротким путем. Собрали бота на шаблоне за 5 дней, потому что задача звучала просто: собирать заявки. Это был как раз тот случай, где решение не сработало. Через два месяца понадобились сегменты клиентов, распределение лидов между менеджерами и статусы в Bitrix24. В этот момент бизнес платит второй раз: сначала за быстрый старт, потом за переделку. Итоговая стоимость доработок вышла примерно в 1,7 раза выше, чем кастомный MVP, который можно было собрать сразу.
Когда коробка правда выгоднее
Я не люблю писать код без причины. Если сценарий линейный - FAQ, прайс, простая запись, сбор контактов, базовые уведомления, - готовый бот часто дает лучший результат по сроку и деньгам.
У локальной сети студий мы запускали именно такой вариант: меню услуг, запись, отправка лида в Telegram и на почту. Без отдельного бэкенда, без сложной модели данных. Запуск занял 4 дня, бюджет был меньше 70 000 ₽, и этого хватило, чтобы проверить спрос на канал.
«Если Telegram еще не дает повторяемый поток заявок, сложная архитектура на старте только мешает». - CTO логистической платформы
Нормальный порог для коробки я бы сформулировал так:
- у вас 1 сценарий, а не набор веток для разных ролей
- интеграций нет или их максимум 1-2
- ошибка бота не ломает продажи и операционку
- менеджеры могут обработать поток вручную без потерь
При таких вводных конструктор - это взрослое решение, а не временная затычка.
Понять, что шаблон уже мешает, можно по трем признакам
Первый признак - бот перестает быть витриной и становится частью операций. Ему нужны статусы заказа, оплаты, роли сотрудников, каталог, остатки, история действий.
Второй - появляются внешние события. Клиент оплатил заказ, курьер сменил статус, CRM закрыла сделку, склад обновил остатки. На этом месте коробочные сценарии обычно начинают ломаться или обрастать обходными ветками.
Третий - команда тратит время руками. Если менеджеры каждый день переносят заявки между Telegram, amoCRM и таблицами по 2-3 часа, дешевый старт уже не окупился.
У delivery-сервиса это проявилось быстро. Пока заказов было мало, коробочный бот принимал заявки без проблем. После роста до 400+ заказов в день понадобились статусы в реальном времени, запись истории в CRM и связка с маршрутизацией курьеров. Переделка заняла 6 недель, потому что логику пришлось выносить из конструктора в отдельный бэкенд.
Для роста нужен уже не «просто бот», а интерфейс к процессу
Системно это выглядит так: Telegram - это только вход. Ценность появляется там, где событие из чата превращается в действие внутри бизнеса.
Telegram -> Webhook -> Backend -> CRM / Payment / Analytics -> ответ пользователю
В production мы обычно идем через Telegram Bot API и webhooks, а не polling. Бэкенд чаще собираем на Node.js 20 + NestJS или Python, данные держим в PostgreSQL 16, очереди и быстрые события — в Redis. Причина простая: когда у вас несколько систем и много статусов, нужен контроль над ошибками и повторной обработкой.
| Подход | Скорость старта | Гибкость | Зависимость от платформы |
|---|---|---|---|
| Конструктор | 1-7 дней | низкая | высокая |
| White-label | 1-3 недели | средняя | средняя |
| Кастом | 3-6 недель | высокая | низкая |
Если на старте уже есть 2-3 интеграции - например, Bitrix24, платежи и склад, - я бы сразу считал кастом. Не потому, что он «солиднее». Просто коробка в такой схеме редко доживает до стабильной второй версии без дорогой миграции.
Что проверить до выбора
Перед стартом полезно сделать короткий технический расчет. Не про кнопки в боте, а про то, как он будет жить в системе.
Пять вопросов, которые быстро отрезают лишние варианты:
- какие данные бот получает и где они хранятся
- куда уходит результат: CRM, почта, ERP, таблица
- что происходит при ошибке интеграции
- сколько ручных действий останется у команды
- как вы поймете пользу через 3 месяца
В ближайшие 6-12 месяцев рынок будет реже покупать «бота как отдельную штуку» и чаще - канал, встроенный в продажи, оплату и аналитику. Кто считает это до запуска, обычно экономит не на разработке, а на второй переделке. По опыту именно она чаще всего и оказывается самой дорогой.
