Автоматизация доставки еды: готовая система или бот для приёма заказов

Автоматизация доставки еды начинается не с выбора чат-бота. Сначала ресторан определяет, где хранятся меню, цены, стоп-лист и сам заказ, кто подтверждает оплату, кто принимает заказ на кухне и кто отвечает за вручение. После этого можно решить, достаточно ли функций готовой ресторанной системы или нужен дополнительный канал для гостя.

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

Что входит в автоматизацию доставки еды

Полный путь нового заказа состоит из связанных, но отдельных операций:

1. Система ресторана отдаёт актуальное меню, цены, модификаторы и доступность.
2. Гость выбирает блюда и дополнения. Бот собирает выбор, но перед оформлением снова читает стоп-лист.
3. Система проверяет полный адрес, зону доставки, доступное время и контакт клиента.
4. Ресторанная система рассчитывает итоговую сумму и создаёт заказ с уникальным идентификатором.
5. Платёжная система отдельным событием подтверждает оплату, если заказ оплачивают онлайн.
6. Кухня принимает заказ, отмечает приготовление и готовность.
7. Оператор или диспетчерская система назначает курьера.
8. Вручение фиксируется отдельным событием.

Каждый шаг опирается на свой источник истины. Текст модели или сообщение в чате не доказывает, что блюдо доступно, деньги получены, кухня начала готовить или курьер вручил заказ.

Эта статья посвящена оформлению нового заказа. Бот статуса заказа решает соседнюю задачу: сообщает гостю состояние уже созданного заказа и не должен повторно оформлять его.

Когда выбрать готовую систему, а когда отдельный бот

Если ресторану нужны единый учёт заказов, передача на кухню, работа с курьерами и статусы исполнения, сначала стоит проверить готовую ресторанную систему. Отдельный бот уместен, когда нужен дополнительный клиентский канал: например, диалог в мессенджере с уточнением адреса, модификаторов и контакта.

Вендор r_keeper описывает в составе своего решения приём заказов, актуальные стоп-листы, передачу на кухню, назначение курьера и фиксацию вручения. Это пример возможностей готовой системы, а не заявление о готовой интеграции Switch On AI. Перед проектом отдельно проверяют используемый продукт и его версию, тариф, доступные права, API и возможность получить нужные события.

Выбор зависит не от количества функций в презентации, а от границы ответственности. Если готовая система уже закрывает путь от заказа до вручения, ещё один самостоятельный контур создаст риск расхождения данных. Бот стоит добавлять как управляемый вход в существующий процесс, когда текущего канала общения недостаточно.

Как связать меню, цены и доступность

У меню должен быть один согласованный источник актуальных данных. Для каждой позиции нужны как минимум идентификатор, название, состав, цена и признак доступности. Для модификатора — собственный идентификатор, допустимые сочетания и влияние на сумму. Стоп-лист должен относиться к конкретному ресторану или кухне, если доступность различается по точкам.

Модель может объяснить состав блюда простыми словами или распознать свободную фразу гостя. Она не должна придумывать цену, заменять идентификатор позиции или подтверждать доступность по ранее сгенерированному описанию.

Безопасная последовательность выглядит так:

1. Бот показывает меню из рабочего источника.
2. Гость выбирает позиции и модификаторы.
3. Перед созданием заказа система повторно запрашивает цены и стоп-лист.
4. При расхождении бот показывает, что изменилось, и просит подтвердить новый состав.
5. Итоговую сумму возвращает система, которая создаёт заказ.

Например, если соус стал недоступен между показом меню и оформлением, бот не должен молча удалить его или оставить прежнюю сумму. Он сообщает об изменении и предлагает доступный выбор либо передаёт вопрос оператору по согласованному правилу.

Как принимать заказ и проверять доставку

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

Последовательность проверки:

1. Полнота и формат адреса.
2. Попадание адреса в обслуживаемую зону.
3. Доступность кухни и интервала для этой зоны.
4. Актуальность состава, модификаторов и суммы.
5. Наличие согласованного контакта.
6. Создание заказа ресторанной системой и получение order_id.

Универсального срока доставки для всех ресторанов, адресов и моментов времени нет. Бот показывает только интервал, который вернула рабочая система. Если она не может дать ответ, вопрос получает оператор; бот не обещает гостю время по собственному предположению.

Для защиты от повторов каждой попытке оформления нужен устойчивый ключ. Один из проектных вариантов: K = C + ':' + U + ':' + R, где C — идентификатор канала, U — идентификатор клиента, R — идентификатор конкретной попытки. Повтор запроса с тем же K должен вернуть результат уже обработанной попытки, например прежний order_id, а не создать второй заказ. Новый осознанный заказ получает новый R. Состав ключа и правила его хранения определяют в проекте с учётом доступных идентификаторов.

Как отделить оплату, приготовление и вручение

Создание заказа, оплата, приготовление и вручение — разные события с разными владельцами.

В Telegram Bot Payments для физических товаров платёж обрабатывает сторонний провайдер, а после успешной операции Bot API передаёт событие successful_payment. Конкретного провайдера, его условия и применимость для ресторана проверяют отдельно. Сам факт отправки счёта или нажатия кнопки оплаты ещё не подтверждает получение денег.

Повтор платёжного уведомления нельзя превращать в новый заказ. Система должна распознавать уже обработанный payment_event_id и возвращать прежний результат. Так же повтор сообщения бота не должен повторно передавать заказ на кухню. Статус меняет только событие от его владельца, а бот отображает результат.

Учебный пример недоступного блюда и смены адреса

Ниже — синтетический пример для обсуждения правил. Это не клиентский кейс и не результат внедрения Switch On AI.

Гость выбрал позиции A и B. После выбора позиция B попала в стоп-лист. Исходный адрес находился в зоне Z1, но затем клиент указал новый адрес за её пределами.

После повторной проверки доступный набор равен {A, B} − {B} = {A}. Это не готовый заказ: клиент ещё должен отказаться от B или выбрать замену, после чего система пересчитает сумму. Для нового адреса проверка delivery_allowed = address ∈ Z1 возвращает false. Итоговое состояние — «требуется решение оператора». Оплата и приготовление остаются неподтверждёнными.

Короткий учебный диалог:

— Бот: Позиция B стала недоступна. Позиция A остаётся в заказе. Выберите замену для B или удалите её. До вашего решения состав и сумма не подтверждены.

— Клиент: Удалите B. И доставьте по новому адресу: улица Дальняя, дом 18.

— Бот: Состав обновлён, но новый адрес находится за пределами зоны Z1. Я передам запрос оператору. Пока доставка, оплата и приготовление не подтверждены.

— Оператор: Проверяет доступные ресторану варианты и сообщает решение через согласованный канал.

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

Как проверить запуск и обсудить интеграцию

До запуска составьте учебные сценарии с входом, ожидаемым состоянием, запрещённым действием и владельцем решения. Это спецификация будущей проверки, а не заявление о проведённом тесте.

На приёмке сверяют два результата: что бот сообщил гостю и что произошло в подключённой системе. Фраза «готово» считается корректной только тогда, когда целевая система подтвердила нужную операцию.

Switch On AI может разработать ИИ-помощника, чат-бота или интеграцию для этой операции после проверки данных, API и прав доступа. ИИ нужен, если ресторан хочет разбирать свободные формулировки гостя; для фиксированного меню и обязательных полей может быть достаточно обычного бота. Обмен событиями между системами выполняет интеграция — он не становится ИИ-агентом только из-за диалогового интерфейса.

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

Подробнее о формате такой разработки — на странице чат-ботов для бизнеса. Чтобы разобрать текущий процесс и определить границу автоматизации, опишите задачу и используемые системы. Прототип помогает согласовать ключевой сценарий, но не равен полноценному внедрению и не подтверждает работу всех подключений.