Запрос «нужно приложение для записи и уведомлений» я слышу регулярно. И очень часто через пару встреч выясняется, что приложению там просто нечего делать: клиенту надо выбрать услугу, записаться и получить напоминание. Такие сценарии мы запускали через Telegram за 2-6 недель, а мобильная версия уехала бы в 3-5 месяцев вместе со сторами, релизами и отдельной поддержкой iOS и Android.
Я не делю форматы на «серьезные» и «несерьезные». Смотрю на то, что быстрее доводит человека до действия и раньше показывает экономику. Если путь короткий, бот часто выигрывает первый раунд.
Когда приложение добавляет трение, а не ценность
У мобильного запуска высокий порог входа. Нужны макеты, две платформы, публикация, обновления. Потом еще надо убедить человека скачать приложение ради действия, которое занимает 30 секунд.
С ботом путь короче: реклама ведет в Telegram, человек отвечает на пару вопросов, выбирает слот и подтверждает запись - обычно это 3-5 шагов. Для таких запусков мы чаще берем Python 3.12 + aiogram 3 или Node.js 20 + grammY, а данные сразу уводим в amoCRM или Bitrix24.
У нас был проект для сети студий красоты. Клиент закладывал на приложение около 1,8 млн ₽. Мы собрали бота за 5 недель, связали его с amoCRM и календарем мастеров, а через месяц увидели простую вещь: 82% клиентов приходят раз в 2-3 месяца. Им не нужен еще один экран на телефоне.
Мини-диалог на таких созвонах обычно выглядит так:
- Нам точно нужно приложение?
- Клиент будет открывать его каждую неделю?
- Нет, ему надо просто записаться.
- Тогда я бы сначала делал Telegram.
Бот особенно хорош там, где задача одна и понятная
Telegram хорошо работает, когда человеку не нужно разбираться в интерфейсе. Оставить заявку, пройти квалификацию, получить статус заказа, выбрать время, оплатить - все это естественно ложится в диалог.
У нас был B2B-проект для поставщика складского оборудования. Раньше лид падал на почту, менеджер отвечал через 30-60 минут, часть заявок просто остывала. Мы собрали бота на Node.js 20 + grammY: он задавал 5 вопросов, отправлял данные в amoCRM, менеджеру летело уведомление, а клиент сразу получал PDF с базовым предложением. Время до первого ответа сократилось до 1-3 минут.
Уведомления в Telegram вообще нативная история. Напоминание о визите, подтверждение оплаты, изменение статуса доставки, повторное касание после брошенного заказа - в приложении это требует установки и разрешений, в боте это уже часть сценария.
| Критерий | Telegram-бот | Мобильное приложение | Веб-кабинет |
|---|---|---|---|
| Срок запуска | 2-6 недель | 3-5 месяцев | 6-10 недель |
| Бюджет старта | низкий-средний | высокий | средний |
| Барьер входа | почти нулевой | нужна установка | переход по ссылке |
| Повторные уведомления | сильная сторона | сильная сторона | слабее |
| Сложный UX | слабый | сильный | сильный |
Самая полезная роль бота - быстро проверить спрос
Если спрос еще не подтвержден, приложение часто становится дорогим способом узнать неприятную вещь: пользователю нужна одна кнопка и два уведомления. Я видел это десятки раз. Поэтому на ранней стадии мы обычно выносим ключевой сценарий в чат или web-MVP.
Недавно был стартап с платными консультациями для малого бизнеса. Мы собрали цепочку «реклама - Telegram - слот - ЮKassa - напоминание», связали с Google Calendar и аналитикой. Через 4 недели стало видно, где люди выпадают: до оплаты доходило 17%, после замены одного экрана на диалог и сокращения вопросов - 29%.
Если вы еще не знаете, за что клиент готов платить, приложение почти всегда преждевременно.
Тут ценность не в дешевизне как таковой. Ценность в скорости обучения. В боте проще менять тексты, ветки, офферы, механику оплаты и логику квалификации без нового цикла дизайна и публикации.
ROI бота чаще сидит в операционке
Когда мне говорят «хотим ROI», я чаще смотрю не на продажи, а на ручную работу. Статусы заказов, возвраты, FAQ, напоминания, внутренние сервисные запросы - все, что сотрудники отвечают по кругу, хорошо уходит в Telegram. Это уже прямая экономия на операционных расходах.
В одном e-commerce проекте мы отдали боту статусы доставки, возвраты и напоминания о незавершенном заказе. Стек был Laravel 11, PostgreSQL 16, Redis 7 для очередей, интеграции с 1С и МойСклад. Нагрузка на первую линию поддержки просела на 34% за 7 недель.
Я бы смотрел на бота всерьез, если у вас совпадают хотя бы 4 пункта:
- есть 1-3 частых сценария, а не десятки веток
- клиент приходит нерегулярно
- главная ценность - заявка, запись, статус, уведомление или оплата
- важнее интеграции с CRM, 1С, календарем и оплатой, чем визуальная часть
- нужно быстро проверить гипотезу или разгрузить поддержку
У бота есть потолок, и его лучше увидеть заранее
Telegram начинает мешать, когда продукту нужны роли, длинные сессии, история действий, документы, таблицы, много данных на одном экране. Если сценарий нельзя объяснить как диалог на 5-7 шагов, чат быстро становится тесным.
У нас был неудачный кейс в логистике. Команда хотела провести через бота все: заявки, маршруты, акты, документы, статусы, несколько ролей сотрудников. На старте идея казалась экономной, но через пару месяцев люди начали путаться в ветках, ошибаться в операционке и терять историю. Это была ошибка в границах сценария: мы слишком много попытались уместить в чат. В итоге бот оставили для уведомлений и первичного сбора заявок, а рабочую часть перенесли в веб-кабинет.
Перед стартом я обычно прошу сделать очень простую вещь: нарисуйте путь клиента до денег на одном листе. Если он помещается в короткий диалог, начинайте с бота. Если уже на схеме нужны фильтры, роли и история, я бы не стал запихивать это в чат.
