Бот для ресторана в Telegram: бронь столов и доставка

Ресторан в Telegram — это не просто меню в PDF. Это касса, бронь, доставка и программа лояльности в одном окне, без установки приложения и без комиссии агрегаторов 15–35%. Гость уже залогинен в мессенджере, оплачивает в два клика и получает статус заказа от кухни до курьера. Разберём, какие сценарии реально окупаются, как их собрать и где лежат подводные камни.

Какие задачи закрывает бот

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

Дополнительно бот закрывает рутину: рассылка о специальных меню и сетах, подтверждение брони за час до визита, опросы качества и реакция на низкие оценки. Каждая такая мелочь снижает no-show и повышает повторные визиты. По нашим замерам, после внедрения бота с напоминаниями доля несостоявшихся броней падает с 18–25% до 6–10%, а выручка с одного гостя за квартал растёт на 12–18% за счёт активной программы лояльности.

Архитектура: что под капотом

В минимальной конфигурации бот состоит из четырёх блоков. Бот на Bot API принимает сообщения и нажатия кнопок, FSM хранит шаг диалога (выбор зала, даты, гостей), интеграция с системой бронирования (iiko, r_keeper, Quick Resto, Poster) забирает свободные слоты и записывает резерв, а платёжный модуль закрывает оплату через ЮKassa, CloudPayments, Telegram Payments или СБП.

Меню удобнее держать как Mini App: карточки блюд, фото, корзина и оплата работают плавнее, чем кнопки бота. На стороне бота остаётся подтверждение, статус заказа и поддержка. Если SKU меньше 80–100 блюд, можно обойтись inline-каталогом без Mini App, но при наличии модификаторов (соусы, размер, степень прожарки) WebView выигрывает почти всегда.

Под нагрузкой сервиса достаточно стандартной связки: один инстанс бота на Python (aiogram) или Go, Postgres под заказы и брони, Redis под FSM и кэш меню. Для пиков пятницы–субботы добавляем второй инстанс за общим Redis и очередь NATS для исходящих сообщений, чтобы не упереться в лимит Bot API (30 сообщений в секунду глобально, 1 сообщение в секунду на пользователя).

Бронирование столов

Сценарий: гость выбирает дату, время, число гостей, зал. Бот проверяет доступность через API ресторанной системы, показывает альтернативы, если слот занят, и фиксирует резерв. За час до визита приходит напоминание с MainButton «Подтвердить» или «Отменить».

Что важно учесть в логике:

• Ограничение глубины брони — обычно 30–60 дней.
• Шаг времени — 15 или 30 минут, синхронно с iiko/r_keeper.
• Автоотмена, если гость не подтвердил за 30 минут до визита.
• Стоп-лист дат и слотов для банкетов и закрытых мероприятий.
• Депозит для пятниц и праздников через sendInvoice — снижает no-show на 40–60%.
• Учёт особых пожеланий: детский стул, у окна, без громкой музыки, аллергии.
• Фиксация номера телефона для связи администратора при форс-мажоре.

Полезный приём — pre-order при бронировании. Гость выбирает блюда заранее, кухня готовит к моменту посадки, средний чек растёт на 20–30% за счёт допродажи десертов и напитков, а оборачиваемость стола улучшается на 15–20%. Дополнительная скидка 5–10% за ранний заказ окупается ростом загрузки в непиковые часы.

Доставка и навынос

Меню с категориями, фильтрами по аллергенам, корзиной и адресом доставки. Геолокацию берём через KeyboardButton.request_location, зону доставки проверяем по координатам относительно полигонов в базе. Если адрес вне зоны — предлагаем самовывоз с указанием времени готовности.

Оплата — sendInvoice с pre_checkout_query, провайдер ЮKassa, CloudPayments или Tinkoff, плюс СБП по QR. Чек по 54-ФЗ выбивает онлайн-касса со стороны ресторанной системы или платёжного провайдера. Статус заказа («Принят», «Готовится», «Собран», «В пути», «Доставлен») приходит обновлением одного и того же сообщения, чтобы не плодить уведомления.

Минимальная структура позиции меню в API между ботом и кухней выглядит так:

{
  "sku": "PIZZA-MARGHERITA-30",
  "name": "Маргарита 30 см",
  "price": 690,
  "weight_g": 480,
  "category": "pizza",
  "modifiers": [
    { "id": "extra-cheese", "name": "Доп. сыр", "price": 120 },
    { "id": "no-basil", "name": "Без базилика", "price": 0 }
  ],
  "allergens": ["gluten", "lactose"],
  "stop_list": false,
  "cook_time_min": 12
}

Поле stop_list обновляется по вебхуку из iiko или r_keeper при каждом изменении на кухне — это спасает от ситуации «гость заказал, а кончилось 10 минут назад».

Программа лояльности и удержание

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

Хорошо работают такие механики:

1. Welcome-бонус 200–500 ₽ за первый заказ.
2. Накопительные статусы: Silver (от 10 000 ₽ за 6 мес.), Gold (от 30 000 ₽), Platinum (от 80 000 ₽).
3. Бонусы за день рождения с напоминанием за неделю и подарком в виде десерта.
4. Реферальная ссылка через start параметр — за приведённого друга оба получают бонус.
5. Сегментированные рассылки: тем, кто не заказывал 30 дней — скидка 10%; тем, кто часто берёт пиццу — анонс новой пиццы.
6. QR-карта лояльности на кассе: гость показывает QR из бота, официант сканирует и начисляет баллы за заказ в зале.

Расход бонусов лучше ограничивать долей корзины (обычно до 30%), иначе экономика рушится при первом же массовом списании. И обязательно фиксировать сгорание баллов через 6–12 месяцев — это даёт повод для возврата гостя через рассылку «у вас сгорает 850 ₽».

QR-меню в зале и дозаказ без официанта

Отдельный сценарий, который окупается даже в небольших кафе — QR на столе ведёт в Mini App с меню текущего зала. Гость заказывает дозаказ (десерт, второй кофе, ещё пиво) сам, без поиска официанта. Заказ падает в iiko с привязкой к столу, кухня готовит, официант приносит.

Эффект: средний чек растёт на 8–15%, скорость обслуживания в часы пик — на 20–25%, нагрузка на официантов падает. Чаевые при этом не страдают: кнопка «Оставить чай» с выбором процента или суммы выводится в боте после оплаты счёта.

Отзывы, NPS и реакция на негатив

Через 2–4 часа после визита или доставки бот спрашивает оценку по 5-балльной шкале. Если оценка 4–5 — предлагает оставить отзыв в Яндекс.Картах или 2ГИС с готовой ссылкой. Если 1–3 — открывается форма с уточнением, что пошло не так, и сообщение сразу падает управляющему в отдельный чат.

Это даёт два эффекта. Во-первых, поток позитивных отзывов в публичных картах растёт в 3–5 раз — гости с хорошим впечатлением редко идут писать сами, но охотно нажимают одну кнопку. Во-вторых, негатив локализуется внутри: управляющий успевает позвонить, извиниться, сделать комплимент — и гость не уходит ставить единицу публично. По нашей практике, такая схема за 3–6 месяцев поднимает средний рейтинг ресторана на картах с 4.2 до 4.6–4.8.

Интеграции с кассой и складом

Без интеграции с кассовой системой бот превращается в красивый Excel. Минимум, что нужно подключить: получение актуального меню и стоп-листа, передача заказа в производство, синхронизация бонусов и истории визитов. У iiko, r_keeper, Poster и Quick Resto есть REST API — заказ из бота попадает на кухню в той же очереди, что и заказы из зала.

Складские остатки тянем раз в 1–5 минут, чтобы не показать в меню блюдо, которого нет. Цены и комбо обновляются по вебхуку из товароучётной системы.

Универсальное правило — у бота всегда своя БД заказов и броней, обмен с POS-системой асинхронный (очередь + ретраи). Если iiko упала на час, бот продолжает принимать заказы и копит их в очереди, синхронизация догоняется потом.

Подключение агрегаторов: Яндекс.Еда и Delivery Club

Спорный вопрос — ставить ли бот параллельно агрегаторам или вместо. На практике первые 2–3 месяца работают параллельно: агрегатор приводит трафик, бот удерживает уже пришедших клиентов и постепенно перетягивает заказы на прямой канал.

Интеграция с агрегаторами идёт через тот же iiko или r_keeper — заказ из Яндекс.Еды падает в кассу как обычный, и оттуда уже в нашу базу для аналитики. В рассылках корректно сравнивать «заказывали ли вы у нас напрямую», иначе клиент с агрегатора получит «давно вас не было», хотя вчера заказывал через Яндекс.

Через 3–6 месяцев доля прямых заказов в боте обычно растёт с 0 до 30–45% от общего объёма доставки, что освобождает 8–15% выручки с этих заказов от комиссии агрегатора.

Сегментированные рассылки и работа с базой

Рассылки в Telegram-боте дают open rate 70–90% против 15–25% у email, но и токсичность выше — за 2–3 ненужных сообщения гость отпишется или забанит бот. Поэтому сегментация обязательна:

• Давно не был — кто не заказывал и не бронировал больше 30/60/90 дней.
• Любимая категория — суши тем, кто берёт суши; пиццу тем, кто берёт пиццу.
• Геосегмент — рассылка про новый бранч-меню только тем, кто живёт в радиусе 3 км.
• День рождения и около — поздравление за 7 дней и в день.
• Первый раз заказал — серия из 2–3 онбординг-сообщений за 14 дней.
• VIP — отдельные предложения для Gold/Platinum, доступ к закрытым событиям.

Частота — не чаще 1 раза в 7 дней на сегмент, исключения — день рождения и подтверждение брони. Кнопка «Отписаться от акций» обязательна, иначе попадаем под 38-ФЗ о рекламе.

Метрики и окупаемость

Ключевые метрики для ресторанного бота:

• доля брони через бот от общего числа резервов (цель — 40–60% через 6 мес.);
• средний чек заказа на доставку через бот vs агрегатор (обычно бот выше на 10–20%);
• доля повторных гостей за 30 дней (рост на 15–25% после внедрения программы лояльности);
• no-show после внедрения депозита (падение с 18–25% до 6–10%);
• recovery rate брошенных корзин в доставке (10–18%);
• NPS и средний рейтинг на публичных картах.

На практике запуск окупается за 2–4 месяца за счёт экономии на комиссиях агрегаторов (15–35% с каждого заказа), снижения нагрузки на колл-центр (минус 1–2 ставки оператора) и роста повторных визитов. Для сети из 3–5 ресторанов окупаемость наступает быстрее за счёт переиспользования инфраструктуры.

Тарифы и стоимость разработки

Ориентиры по бюджету и срокам в 2026 году в РФ:

Поддержка после запуска — 30–80 тыс. ₽/мес. для базового пакета (мониторинг, обновления меню, реакция на инциденты, работа с рассылками).

Чек-лист запуска ресторанного бота

• Выбран и подключён POS (iiko, r_keeper, Poster, Quick Resto).
• Меню синхронизируется с кассой, стоп-лист обновляется в реальном времени.
• Бронирование сохраняется и в боте, и в POS, дубли исключены.
• Депозит на пятницу–субботу подключён, эквайринг работает.
• Программа лояльности с уровнями и QR на кассе работает.
• Рассылки сегментированы, кнопка «Отписаться» обязательна.
• NPS-опрос отправляется через 2–4 часа после визита/доставки.
• Негатив (оценка ≤ 3) падает управляющему в отдельный чат.
• Чек по 54-ФЗ уходит в ОФД без задержек.
• Зоны доставки описаны полигонами, граница проверяется до оплаты.
• Mini App меню грузится быстрее 1.5 секунд на 4G.
• Подключена аналитика: воронка от старта до оплаты, retention, AOV.
• Юридические документы: оферта, согласие на ПДн, политика лояльности.
• Нагрузочное тестирование под пики пятницы и праздников.
• План работы с агрегаторами: параллельно или с переводом на прямой канал.

Итого

Ресторанный бот в Telegram — это полноценный канал продаж и удержания, а не дубликат сайта. Минимальный набор — бронь, доставка и лояльность с интеграцией в кассовую систему. Сроки разработки от 3 до 6 недель в зависимости от глубины интеграций. Mini App для меню и QR-меню в зале сильно повышают конверсию и средний чек. Окупаемость 2–4 месяца за счёт экономии на комиссиях агрегаторов и роста повторных визитов.

Частые вопросы

Какие задачи закрывает Telegram-бот ресторана?+

Три ключевых потока. Бронирование столов — гость видит свободные слоты, выбирает, оплачивает депозит. Заказ еды на вынос и доставка — без комиссии агрегаторов 15–35%. Удержание гостя через программу лояльности — бонусы, статусы Silver/Gold/Platinum, реферальные ссылки, сегментированные рассылки. Бот объединяет всё это и снимает нагрузку с хостес и колл-центра. Дополнительно закрывает рутину: рассылка о специальных меню, подтверждение брони за час до визита, опросы качества и реакция на низкие оценки, QR-меню в зале для дозаказа без официанта. Каждая такая мелочь снижает no-show с 18–25% до 6–10% и повышает повторные визиты на 15–25%.

Из каких блоков состоит ресторанный бот в Telegram?+

В минимальной конфигурации четыре блока. Бот на Bot API (aiogram, grammY, telegraf) принимает сообщения и нажатия кнопок. FSM в Redis хранит шаг диалога: выбор зала, даты, числа гостей, корзины. Интеграция с системой бронирования и кассой (iiko, r_keeper, Poster, Quick Resto) забирает свободные слоты, отдаёт меню и стоп-лист, записывает резерв и заказ. Платёжный модуль закрывает оплату через ЮKassa, CloudPayments, Telegram Payments или СБП. Меню удобнее держать как Mini App: карточки блюд, фото, корзина и оплата работают плавнее, чем кнопки бота. На стороне бота остаётся подтверждение, статус заказа и поддержка.

Как реализовать бронирование столов в боте ресторана?+

Сценарий: гость выбирает дату, время, число гостей, зал. Бот проверяет доступность через API ресторанной системы, показывает альтернативы, если слот занят, и фиксирует резерв. За час до визита приходит напоминание с MainButton «Подтвердить» или «Отменить». Ограничения: глубина брони обычно 30–60 дней; шаг времени 15 или 30 минут; автоотмена, если гость не подтвердил за 30 минут до визита; стоп-лист дат и слотов для банкетов; депозит для пятниц и праздников через sendInvoice — снижает no-show на 40–60%. Полезный приём — pre-order: гость выбирает блюда заранее, кухня готовит к посадке, средний чек растёт на 20–30%, оборачиваемость стола улучшается на 15–20%.

Как организовать доставку еды через Telegram-бота?+

Меню с категориями, фильтрами по аллергенам, корзиной и адресом доставки. Геолокацию берём через KeyboardButton.request_location, зону доставки проверяем по координатам относительно полигонов в базе. Если адрес вне зоны — предлагаем самовывоз. Оплата — sendInvoice с pre_checkout_query, провайдер ЮKassa, CloudPayments или Tinkoff, плюс СБП по QR. Чек по 54-ФЗ выбивает онлайн-касса со стороны ресторанной системы или платёжного провайдера. Статус заказа («Принят», «Готовится», «Собран», «В пути», «Доставлен») приходит обновлением одного и того же сообщения, чтобы не плодить уведомления. Поле stop_list в карточке блюда обновляется по вебхуку из iiko/r_keeper при каждом изменении на кухне.

Как работает программа лояльности в боте ресторана?+

Программа лояльности на стороне бота даёт гостю прозрачность: текущий уровень, бонусы, до следующего уровня — всё в одном экране. Бонусы начисляются автоматически при оплате через бот и могут списываться частично при следующем заказе (обычно до 30% корзины). Хорошо работают механики: welcome-бонус 200–500 ₽ за первый заказ, накопительные статусы Silver/Gold/Platinum, бонусы за день рождения с напоминанием за неделю, реферальная ссылка через start параметр, сегментированные рассылки, QR-карта лояльности на кассе для заказов в зале. Обязательно фиксировать сгорание баллов через 6–12 месяцев — это даёт повод для возврата через рассылку «у вас сгорает 850 ₽».

Как интегрировать бот ресторана с iiko, r_keeper, Poster?+

Без интеграции с кассовой системой бот превращается в красивый Excel. Минимум, что нужно подключить: получение актуального меню и стоп-листа, передача заказа в производство, синхронизация бонусов и истории визитов. У iiko (iikoCloud REST), r_keeper (XML/REST), Poster (REST JSON) и Quick Resto (REST) есть API — заказ из бота попадает на кухню в той же очереди, что и заказы из зала. Складские остатки тянем раз в 1–5 минут, цены и комбо обновляются по вебхуку. Универсальное правило — у бота всегда своя БД заказов и броней, обмен с POS асинхронный (очередь + ретраи). Если iiko упала на час, бот продолжает принимать заказы и копит их в очереди.

Сколько стоит и как быстро окупается ресторанный бот в Telegram?+

MVP с бронью, меню и оплатой без интеграции с POS — 250–400 тыс. ₽ за 2–3 недели. Базовый пакет с интеграцией в iiko или r_keeper, лояльностью и рассылками — 500–900 тыс. ₽ за 4–6 недель. Для сети с мульти-локацией, агрегаторами и Mini App — 1.2–2.5 млн ₽ за 8–12 недель. Поддержка после запуска — 30–80 тыс. ₽/мес. Окупаемость 2–4 месяца за счёт трёх факторов: экономия на комиссиях агрегаторов (15–35% с каждого заказа), снижение нагрузки на колл-центр (минус 1–2 ставки оператора), рост повторных визитов на 15–25%. Для сети из 3–5 ресторанов окупаемость быстрее за счёт переиспользования инфраструктуры между точками.