Телеграм-бот для приёма заказов: что он должен уметь

Собственники малого бизнеса часто заказывают «телеграм-бота для приёма заказов» по короткому брифу в переписке — и получают ровно то, что описали: бот, который умеет здороваться и присылать заявку в чат менеджеру. Через месяц выясняется, что клиенты путаются в меню, менеджер пропускает заказы среди личных сообщений, а статус заказа приходится узнавать по телефону. Дело не в исполнителе — дело в том, что ТЗ описывало интерфейс, а не рабочий процесс. Ниже — минимальный набор функций, без которого бот для заказов не заменяет менеджера, а просто добавляет ему работы, и список ошибок, которые чаще всего портят такие проекты.

Каталог: витрина, а не список из десяти строк

Каталог в боте — это не текстовое меню «1. Пицца — 2. Роллы — 3. Комбо». Такой формат работал в 2018 году, сейчас клиент, привыкший к маркетплейсам, ждёт карточки товара: фото, название, цена, короткое описание и кнопка «В корзину» под каждой позицией. Если ассортимент больше 15–20 позиций, нужны категории и, желательно, поиск или фильтр — иначе клиент листает пять экранов, чтобы найти нужное, и уходит.

Второй момент, который в брифах почти всегда пропускают, — актуальность каталога. Кто и как быстро убирает позицию, которой нет в наличии сегодня? Если ответ «вручную, когда вспомним» — каталог за неделю разойдётся с реальным складом, и бот начнёт принимать заказы на то, чего нет. Для небольшого ассортимента хватает ручного редактирования через админ-панель бота; для меняющегося каждый день — нужна синхронизация с Google-таблицей, 1С или CRM, где ведётся учёт остатков.

Корзина и оформление заказа

Корзина должна делать три вещи: показывать, что клиент уже выбрал, позволять менять количество или удалять позицию без сброса всего заказа, и считать итоговую сумму с учётом доставки, скидки или минимального чека. Кажется очевидным, но именно этот узел чаще всего собирают наспех: клиент добавил товар — а посмотреть, что уже в корзине, кнопки нет, изменить количество нельзя, только удалить и добавить заново.

Дальше — оформление. Минимальный набор полей: имя, телефон, адрес или способ получения (самовывоз/доставка), комментарий к заказу. Каждое лишнее поле в форме — это процент клиентов, которые не дойдут до конца. Если у вас несколько точек выдачи или зон доставки, лучше сделать выбор кнопками, а не просить писать адрес текстом: так меньше ошибок и проще потом обработать заказ.

Статус заказа: клиент не должен звонить, чтобы узнать

Это функция, которую в ТЗ описывают реже всего, а жалуются на её отсутствие — чаще всего. У заказа должно быть минимум 3–4 состояния: принят, в обработке (или готовится), передан в доставку/готов к выдаче, выполнен. Каждый переход — короткое уведомление клиенту в том же чате, где он оформлял заказ. Это снимает звонки «а мой заказ вообще приняли?» и «когда будет готово?» — то есть напрямую разгружает того же менеджера, ради которого бота и заказывали.

Отдельно стоит продумать статус «отменён» или «уточнение по заказу» — с указанием причины. Бот, который умеет только подтверждать заказы и молчит, если что-то пошло не так, создаёт больше недоверия, чем его отсутствие: клиент видит «принято» и ждёт, а по факту менеджер не смог дозвониться, чтобы уточнить адрес.

Уведомления менеджеру — то, ради чего всё делается

Сам по себе бот, который собирает заказ, бесполезен, если заказ никто вовремя не увидел. Уведомление должно приходить не «куда-нибудь», а в канал, который менеджер реально проверяет каждые несколько минут: отдельный рабочий чат в Telegram, группа для заказов, канал в CRM. Личные сообщения одному сотруднику — плохой вариант: он в отпуске, телефон разрядился, уведомления отключены — и заказ потерян.

В карточке заказа для менеджера должно быть всё необходимое для работы одним взглядом: список позиций, сумма, контакт клиента, способ получения, комментарий — и в идеале кнопки для смены статуса прямо в этом сообщении, без перехода в отдельную панель. Если заказов больше 15–20 в день, имеет смысл сразу закладывать интеграцию с CRM или админ-панель со списком заказов и фильтром по статусу — иначе менеджер будет листать историю чата в поисках «того самого заказа», и это займёт больше времени, чем принять звонок.

Оплата: не обязательна, но если есть — без полумер

Приём оплаты в боте — не всегда нужная функция: для заказа с самовывозом и оплатой на месте её вообще можно не делать, это удешевляет проект. Но если оплата есть, она должна быть цельной: клиент платит внутри бота (ЮKassa или Telegram Payments), получает подтверждение автоматически, а не «переведите на карту и пришлите скриншот». Схема со скриншотами добавляет ручную проверку менеджеру — то есть возвращает именно ту работу, от которой должен избавлять бот.

Если часть заказов идёт с предоплатой, а часть — без, в сценарии должна быть явная развилка и понятная логика: что происходит с заказом, если клиент выбрал оплату картой, но не завершил платёж. Оставленный «в подвешенном состоянии» заказ — источник путаницы и потерянных продаж, если про него забыли в ТЗ.

Частые ошибки в техническом задании

• ТЗ описывает экраны, а не процесс. «Кнопка каталог, кнопка корзина, кнопка оформить» — это интерфейс. Не описано: что происходит с заказом дальше, кто и как его обрабатывает, куда уходит уведомление. Без этого бот собирает заявки, которые потом теряются в переписке.
• Не продуман кейс «товара нет в наличии». Клиент выбрал позицию, которой физически нет, оплатил — и дальше начинается ручное разбирательство, которого можно было избежать синхронизацией остатков или хотя бы быстрым ручным обновлением каталога.
• Нет уведомлений клиенту о статусе. Заказ принят молча, и клиент узнаёт, что происходит, только позвонив. Это же тот звонок, который бот должен был отменить.
• Уведомления менеджеру идут в личку одному человеку. При отпуске, смене сотрудника или просто заполненном экране уведомлений заказ пропускают.
• Заложена оплата «на будущее» без чёткого сценария сейчас. В результате разработчик делает заглушку, а через месяц выясняется, что заглушка не подходит под нужный платёжный сервис, и логику приходится переписывать.
• Не указано, на чьём аккаунте регистрируется бот. Формально не про функционал, но именно это условие определяет, останется ли база подписчиков и токен бота у вас, если вы смените подрядчика.
• Нет требования к карте сценариев до начала разработки. Без схемы диалогов на согласование исполнитель собирает бота «как понял», а расхождения всплывают уже на приёмке, когда переделывать дороже.

Что делать: практический вывод

Перед тем как отдавать задачу в разработку, зафиксируйте четыре вещи. Первое — минимальный набор функций: каталог с актуальными остатками, корзина с редактированием, статусы заказа с уведомлениями клиенту, уведомления менеджеру в отдельный рабочий канал. Без любого из этих четырёх блоков бот закрывает задачу лишь наполовину. Второе — кто и как поддерживает каталог в актуальном состоянии: это организационный вопрос, а не только технический, и его стоит решить до старта разработки, а не после первого испорченного заказа. Третье — попросите исполнителя показать карту сценариев до того, как он начнёт кодить: если её нет, ТЗ, скорее всего, дособирается «по ходу», а это и есть источник большинства проблем выше. Четвёртое — уточните, на чьём аккаунте будет создан бот и куда идут доступы после сдачи проекта. Эти четыре пункта закрывают почти все типовые ошибки, из-за которых бот для заказов через пару месяцев эксплуатации оказывается «ещё одним каналом для ручной работы» вместо инструмента, который реально снимает нагрузку с менеджера.