Как заказы с сайта и бота попадают на кухню: разбор без магии

Гость оформил заказ на сайте или написал боту — а дальше? Между кнопкой «Оформить» и сковородкой повара лежит цепочка, в которой заказ может потеряться, задвоиться или уехать не на ту точку. Разбираем, как всё устроено на самом деле: что делает касса, что API, а что — человек с телефоном.

Путь одного заказа: от кнопки до сковородки

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

1. Приём. Заказ рождается в канале: форма на сайте, Telegram-бот, сообщение в WhatsApp, звонок, агрегатор.
2. Маршрутизация. Кто-то (человек или программа) решает: на какую точку, какой тип — доставка или самовывоз, всё ли есть в наличии.
3. Проведение через кассу. Заказ попадает в вашу учётную систему (iiko, FrontPad, СБИС Presto, r_keeper) — там он получает номер, попадает в отчёты, списывает остатки.
4. Выдача на кухню. Касса печатает чек на кухонном принтере или показывает позицию на кухонном экране.

Главная мысль, которую владельцы часто упускают: сайт и бот сами по себе на кухню ничего не отправляют. Они умеют только собрать корзину и передать её дальше. Всё интересное происходит в звеньях 2–4, и именно там теряются деньги.

Три способа доставить заказ на кухню

На практике заведения используют один из трёх сценариев. У каждого своя цена ошибки и своя скорость.

Разница не косметическая. При 30 заказах в день ручной ввод съедает 1,5–2 часа рабочего времени менеджера и стабильно даёт 3–5% брака: не тот адрес, забытый модификатор «без лука», задвоенный заказ. На доставке каждая такая ошибка — это либо переделка блюда, либо возврат, либо злой отзыв на картах.

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

Когда говорят «интеграция сайта с кассой», имеют в виду, что две программы умеют разговаривать друг с другом напрямую, без человека-переносчика. Разговаривают они через API — набор команд, которые касса публикует для внешних систем.

Упрощённо обмен выглядит так:

• Сайт формирует заказ в понятном кассе виде: список позиций с их ID (не «Пепперони», а артикул SKU-1024), количество, модификаторы, тип заказа, адрес, телефон, способ оплаты.
• Отправляет это одним запросом на адрес кассы вместе с ключом доступа (токеном).
• Касса отвечает: «принял, номер заказа 415» либо «ошибка: позиции SKU-1024 нет в стоп-листе / нет на этой точке».
• Заказ появляется в кассе как обычный, будто его набил кассир, — и дальше живёт по вашим правилам: печатается на кухне, списывает остатки, попадает в выручку.

Ключевой нюанс, о который спотыкаются все: позиции на сайте и в кассе должны быть связаны по одному и тому же коду. Если у «Маргариты» на сайте один артикул, а в iiko другой — интеграция или отвергнет заказ, или проведёт его как «неизвестное блюдо», и повар увидит пустую строку.

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

Что делает сервис, а что касса

Честно разделим зоны ответственности, потому что тут много маркетингового тумана:

• Касса (iiko, FrontPad, СБИС, r_keeper) отвечает за проведение заказа, остатки, чек, фискализацию и печать на кухню. Она — источник правды.
• Сайт или бот отвечает за витрину и корзину — собрать, что хочет гость.
• Слой интеграции (плагин, коннектор или сервис-посредник) отвечает за перевод: превратить корзину в правильный запрос к API конкретной кассы. Именно здесь живёт вся сложность, потому что у каждой кассы свой «диалект».

Кухонный экран или бумажный чек: что выбрать

Дошёл заказ до кассы — как его увидит повар? Два варианта.

Бумажный чек. Касса печатает заказ на термопринтере на кухне. Просто, привычно, работает без интернета внутри цеха. Минусы: бумага заканчивается в час пик, чеки теряются, нет статуса «готово», сложно понять, сколько заказов «висит».

Кухонный экран (KDS, kitchen display system). Это монитор или планшет на кухне, куда заказы падают карточками. Повар видит очередь, время каждого заказа, может отметить «готово» — и статус уходит обратно на кассу и в доставку. Кухонный экран особенно оправдан, когда:

• у вас несколько цехов (горячий, холодный, бар) — заказ автоматически бьётся по станциям;
• поток от 40–50 заказов в день, где бумага уже мешает;
• важно мерить время приготовления и держать SLA по доставке.

Кухонный экран есть в iiko (модуль KDS), в r_keeper, частично в СБИС. Для маленькой пекарни с 15 заказами это избыточно — хватит принтера. Для тёмной кухни или доставки на потоке — почти обязательная вещь: он снимает хаос «что готовим первым» и убирает потерянные чеки.

Где всё ломается: чек-лист разрывов

90% проблем с тем, что «заказы на кухню не доходят», сводятся к десятку типовых причин. Пройдитесь по списку — это дешевле, чем ловить недовольных гостей.

• ☐ Артикулы на сайте не совпадают с кассой — заказ отвергается или проводится пустым.
• ☐ Заказ уходит не на ту точку — нет привязки адреса к филиалу по зонам доставки.
• ☐ Позиция в стоп-листе на сайте не обновилась — гость заказал то, чего нет.
• ☐ Ночью канал работает, а принять заказ некому — теряете весь ночной поток.
• ☐ Модификаторы («без лука», «остро») не передаются — повар готовит не то.
• ☐ Задвоение: оператор набил вручную то, что уже прилетело по API.
• ☐ Нет обратного статуса — гость не знает, приняли заказ или нет, и звонит.

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

Где ИИ-администратор снимает боль

Прямая интеграция по API отлично проводит заказ, но она глупая: не поговорит с гостем, не уточнит «а соус какой?», не подскажет замену для позиции из стоп-листа. А ручной приём умный, но медленный и спит по ночам. ИИ-администратор закрывает разрыв ровно посередине.

В нашем сервисе Людочка это выглядит так: гость пишет в бот или на сайт обычным языком — «привет, хочу пепперони и колу на Ленина 5». Людочка распознаёт позиции, сверяется со стоп-листом, уточняет недостающее, считает сумму, определяет по адресу нужный филиал — и отправляет готовый заказ прямо в вашу кассу (FrontPad, iiko, СБИС) через ту самую API-интеграцию. Повар видит заказ так же, как от кассира, — на чеке или на кухонном экране. Ночью, в час пик и в выходные — одинаково, без спящего оператора и без задвоений.

Важно понимать границу честно: ИИ не заменяет кассу и не печатает чеки сам — он заменяет человека-переносчика между каналом и кассой и делает приём умным. Касса как была источником правды, так и осталась.

Как внедрить у себя: короткий план

1. Навести порядок в номенклатуре кассы — единые артикулы, актуальные цены, настроенные модификаторы и стоп-листы.
2. Проверить, что у вашей кассы есть API и вы можете получить ключ доступа (у FrontPad, iiko, СБИС он есть).
3. Выбрать способ доставки заказа на кухню: принтер или кухонный экран — по объёму потока.
4. Подключить каналы через интеграцию, а не через ручной ввод, и настроить маршрутизацию по филиалам.
5. Прогнать 5–10 тестовых заказов с разными адресами, модификаторами и стоп-позициями до запуска на гостей.

Сделаете эти пять шагов — и «заказы теряются на кухне» перестанет быть темой утренних разборов. Заказ будет проходить путь от кнопки до сковородки за секунды и без человеческого фактора.