Телеграм-бот для доставки еды

Приём заказа: корзина вместо переписки

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

Адрес, зоны доставки и минимальная сумма

Адрес и зона — место, где доставка теряет деньги. Гость отправляет геолокацию или ставит точку на карте, бот проверяет попадание в полигон зоны. Зон обычно несколько: центр с одной стоимостью доставки и своей минимальной суммой заказа, спальные районы с другой, пригород — вне зоны. Границы вы рисуете сами в админке и меняете, когда меняется парк курьеров или трафик в городе. Если адрес вне зоны, бот сообщает об этом сразу, а не после того, как заказ ушёл на кухню. Отдельно храним подъезд, этаж, домофон и комментарий: эти поля уходят в чек и курьеру, и именно из-за их отсутствия человек стоит у закрытой двери с остывающей коробкой. Для сети точек добавляем выбор ближайшей кухни по адресу гостя.

Оплата, передача на кухню и статус курьера

Оплата. Подключаем Kaspi Pay и банковские карты, наличные и терминал у курьера остаются как опция — в Казахстане от них рано отказываться полностью. Предоплату можно включить выборочно: например, для новых номеров, для заказов выше определённой суммы или для дальних зон. Это ваше операционное решение, бот только исполняет правило, заданное в админке. Важная часть — что происходит, когда что-то пошло не так: позиция попала в стоп-лист после оплаты, курьер не доехал, гость отменил. Мы заранее описываем сценарии частичного возврата и отмены, чтобы администратор не решал это каждый раз заново в переписке. Чек и данные оплаты фиксируются на нашей стороне и связываются с заказом, чтобы разбор спорной ситуации занимал минуту.

Повторные заказы, ограничения, старт работы

Заказ должен попасть на кухню сам. Если бот присылает состав в общий чат, а менеджер перебивает его в кассу руками, вы получаете задержку и опечатки в самый неподходящий момент. Поэтому мы подключаем кассу: заказ уходит в iiko или r_keeper как обычный документ, печатается на кухне, учитывается в отчётах и не требует ручного ввода. Меню и стоп-лист едут в обратную сторону — гость не увидит то, что закончилось. Механика подключения та же, что и в проектах, где мы делаем интеграцию iiko с мобильным приложением: общий бэкенд, единый каталог, одна точка правды по ценам. Если кассы нет вообще, заказы принимаются в нашей админке, но это временное решение, а не целевое.

Статус заказа. Гость видит этапы: принят, готовится, передан курьеру, доставлен. Каждый переход приходит сообщением в тот же чат, без звонков и без «где мой заказ». Курьеру даём отдельный интерфейс — простой список назначенных заказов с кнопками смены статуса и адресом, открывающимся в навигаторе. Здесь есть честное ограничение: точность статусов равна дисциплине курьеров. Если человек нажимает «доставлено» пачкой в конце смены, гость получает бессмысленные уведомления, и доверие к ним падает быстрее, чем растёт. Это управленческая задача, а не техническая — мы можем только сделать нажатие максимально быстрым и показать управляющему, где статусы проставляются задним числом. Живую карту с движением курьера подключаем только там, где смена статусов уже налажена.

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

Ограничения, о которых стоит договориться до старта. Бот не чинит логистику: если курьеров не хватает в час пик, автоматизация просто быстрее покажет, что заказ опаздывает. Бот не заменяет агрегаторы — они дают поток новых людей, свой канал даёт заказы без комиссии от тех, кто вас уже знает. Разумная стратегия обычно смешанная: агрегаторы как источник знакомства, бот как место, куда гостя переводят на второй и третий заказ. И бот не заменяет полноценное мобильное приложение для доставки еды: у приложения свои push-уведомления, иконка на экране и место в сторах. Часто правильный порядок — сначала бот, потом приложение, когда поток заказов стабилизировался.

Как мы это делаем. Бэкенд на Node.js, база PostgreSQL, клиентские интерфейсы на Flutter там, где нужен отдельный экран. Админка отдаётся вам: меню, цены, зоны доставки, минимальные суммы, тексты, промокоды, сегменты — всё правится без разработчика. Дальше по задачам: если у вас есть зал и нужен канал для брони, меню и работы с гостями на месте, это телеграм-бот для ресторана. Если нужна витрина с крупными фото, корзиной и личным кабинетом, ближе Telegram Mini App для ресторана. Начинаем всегда с брифа: сценарии, зоны, касса, способы оплаты, кто и как будет вести админку. По итогам брифа считаем объём и называем стоимость и сроки — раньше это были бы выдуманные цифры.