Телеграм-бот для заказов — это интерфейс, который проводит покупателя от выбора до подтверждённой заявки, а бизнесу передаёт полный и однозначный набор данных для выполнения.
Слово «подтверждённой» отделяет рабочий бот от меню с кнопками. Сообщение «спасибо за заказ» ещё не означает, что товар зарезервирован, оплата получена, а менеджер видит адрес и состав корзины. Для этого нужен не только диалог, но и модель состояний: что уже произошло, кто отвечает за следующий шаг и как система ведёт себя, если ответ или платёж не пришли.
Путь заказа как последовательность состояний
В хорошем сценарии человек всегда понимает, где находится, а система — что разрешено делать дальше. Нельзя перейти к выполнению, если не подтверждён состав; нельзя назвать заказ оплаченным только потому, что создан счёт.
- ВыборПокупатель выбирает товар, услугу или доступный вариант без ввода служебных кодов.
- УточнениеБот собирает только данные, необходимые для цены, доставки и выполнения.
- ПроверкаЧеловек видит состав, сумму и условия и может исправить ошибку до подтверждения.
- СозданиеСистема записывает заказ с уникальным идентификатором и начальным статусом.
- ОплатаСчёт и подтверждённый платёж сохраняются как разные события.
- ВыполнениеОтветственный получает состав, контакты, доставку и уже известные исключения.
- ЗавершениеПокупатель получает результат или сообщение об отмене с понятным следующим шагом.
Эту последовательность не обязательно показывать покупателю техническими названиями статусов. Она нужна системе. В чате можно написать «проверяем оплату», но внутри должно быть ясно, только ли сформирован счёт или провайдер уже подтвердил платёж.
Повторное нажатие тоже следует считать нормальным сценарием, а не ошибкой пользователя. Если человек дважды нажал «подтвердить», бизнес не должен получить два одинаковых заказа. Для этого каждая попытка привязывается к уже созданной записи, пока её состояние не требует новой операции.
Чат, Mini App и учёт выполняют разные роли
Telegram даёт два удобных способа построить интерфейс. Кнопки в чате подходят для короткого выбора. Mini Apps позволяют запускать внутри Telegram отдельный интерфейс на JavaScript — это удобно для каталога, корзины и сложных форм. Но ни один из вариантов не должен становиться единственным местом хранения заказа.
Кнопки в чате
- короткий ассортимент или запись
- линейный выбор без сложных фильтров
- видимая история ответов
- быстрый переход к оператору
Telegram Mini App
- каталог с вариантами и поиском
- корзина с несколькими позициями
- сложный адрес или конфигурация
- отдельный экран проверки заказа
Выбирать Mini App только потому, что он выглядит современнее, не стоит. Если заказ состоит из услуги, времени и телефона, отдельное приложение добавляет разработку, но не ценность. Если покупатель сравнивает варианты, меняет количество и возвращается к каталогу, длинная цепочка сообщений становится неудобной.
Где хранить правду о заказе
История чата полезна человеку, но плохо работает как операционный реестр. Сообщение можно пропустить, порядок меняется из-за уточнений, а команде нужны фильтры по оплате, доставке и ответственному. Поэтому бот передаёт данные в CRM, систему учёта, магазин или другую базу, где у каждого заказа есть одно текущее состояние.
Эта иерархия определяет и разрешение конфликтов. Если чат показывает старую цену, а система учёта — новую, бот не должен молча оформить противоречивый заказ. Если провайдер не подтвердил платёж, сообщение покупателя «я оплатил» служит поводом для проверки, а не новым статусом.
Оплата не равна кнопке «оплатить»
Согласно документации Telegram Payments, бот отправляет счёт, а деньги обрабатывает сторонний платёжный провайдер. Telegram не берёт комиссию за сам Payments API, однако собственные условия могут быть у провайдера и банка. Вопросы споров и возвратов также остаются между покупателем, продавцом, провайдером и банками.
Практический вывод прост: создание счёта, успешная оплата и возврат — разные события. Их нельзя свести к одному флажку. Бот должен показывать человеку понятное состояние, а оператор — видеть техническое подтверждение и историю изменений.
Исключения, которые нужно спроектировать до запуска
| Ситуация | Автоматическое действие | Кто завершает |
|---|---|---|
| Товар закончился | остановить подтверждение и предложить выбор | оператор или покупатель |
| Платёж ожидается | сохранить заказ без статуса «оплачено» | провайдер или оператор |
| Повторное нажатие | вернуть уже созданный заказ | система |
| Неполный адрес | запросить конкретное отсутствующее поле | покупатель |
| Нужен возврат | зафиксировать обращение и передать историю | ответственный менеджер |
Автоматизация заканчивается там, где требуется решение, но контекст должен дойти до оператора без повторного опроса покупателя.
Передача человеку — не аварийный выход из плохо продуманного бота. Это отдельная ветка для ситуаций, где нужно решение: замена товара, нестандартная доставка, спорный платёж. Бот собирает уже известное и передаёт его вместе с состоянием заказа, чтобы оператор не начинал разговор заново.
Перед разработкой полезно пройти более широкий чек-лист чат-бота, а границу между автоматизацией и разговором с менеджером определить по схеме чат-бот или живой человек.