Гость открыл меню на телефоне, но не смог заказать: как разрывы между онлайн-меню, кассой и кухней убивают конверсию
Гость сканирует QR-код, выбирает позицию, нажимает «Заказать» — и ничего не происходит. Кнопка не реагирует, страница зависает, а через минуту человек уходит. Не из ресторана — к конкурентам в соседней вкладке.
Между красивым онлайн-меню и реальным заказом лежит цепочка интеграций: меню → сайт/приложение → POS (iiko, R-Keeper) → кухня. Если хотя бы одно звено работает криво, ресторан теряет заказы, даже не подозревая об этом. Владелец видит трафик в аналитике, но не видит, сколько гостей отвалилось на полпути.
Где рвётся цепочка
1. Онлайн-меню и касса: расхождение цен и остатков
Самый частый сбой — гость видит одну цену в меню, а при оплате или в чеке обнаруживает другую. Это происходит, когда онлайн-меню выгружается из POS вручную или по расписанию раз в сутки, а в ресторане за это время успели изменить себестоимость или поднять цену.
Вторая проблема — отсутствие синхронизации стоп-листов. Гость заказывает блюдо, оплачивает, а через пять минут официант или курьер сообщает: «К сожалению, этого нет». Результат: раздражённый клиент, возврат денег и потеря доверия.
Что проверить: - Частота синхронизации меню и остатков с POS (в идеале — в реальном времени или каждые 5–10 минут). - Совпадение цен в онлайн-меню и кассе на 10 случайных позициях. - Поведение системы при заказе позиции из стоп-листа: блокируется ли кнопка заказа или гость всё равно может оформить и оплатить.
2. Касса и кухня: заказ пришёл, но его не видят
Даже если меню и POS работают синхронно, заказ может потеряться на этапе передачи на кухню. Это особенно критично для доставки и dark kitchen, где нет официанта, который заметит пропажу.
Типичные ситуации: - Заказ прошёл через POS, но не распечатался на кухонном принтере из-за сбоя связи. - Курьерская интеграция передала заказ в POS, но статус не обновился обратно — гость видит «Готовится», хотя блюдо уже уехало. - Дублирование: заказ ушёл на кухню дважды, потому что агрегатор и сайт одновременно передали его в POS по разным каналам.
Что проверить: - Настройка принтов на кухне: каждый ли тип заказа (доставка, зал, предзаказ) попадает на нужный принтер. - Обратная связь статусов: меняется ли статус в приложении/агрегаторе, когда кухня принимает или отдаёт блюдо. - Лог дубликатов в POS за последнюю неделю: были ли заказы с одинаковыми позициями и временем в пределах 2–3 минут.
3. Оплата и подтверждение: гость заплатил, но не понял
Гость оплатил заказ картой, но не получил подтверждения — ни на экране, ни в SMS, ни в email. Он не знает, принят заказ или нет, и звонит в ресторан. Если линия занята или никто не берёт трубку, следующий шаг — отзыв через банк или агрегатор.
Другой сценарий: предоплата за бронь или заказ прошла, но в POS не создался соответствующий заказ, и стол ждёт пустым, а кухня не получила задачу.
Что проверить: - Цепочка от успешной оплаты до создания заказа в POS: проходит ли тестовый платёж до конца. - Настройка уведомлений гостю: SMS, push, email — хотя бы один канал должен работать. - Связка предоплат с модулем бронирования: видит ли хостес оплаченный резерв в системе.
Как проверить цепочку за один вечер
Не нужно ждать, пока гости начнут жаловаться в отзывах. Один человек с телефоном может протестировать весь путь за 30 минут.
Чек-лист аудита
- Откройте онлайн-меню с двух разных устройств (iOS и Android). Проверьте скорость загрузки и корректность отображения.
- Выберите позицию и дойдите до оплаты. Не платите реально — проверьте, не отвалился ли процесс на этапе ввода данных.
- Сверьте цену в онлайн-меню с ценой в POS для этой же позиции.
- Закажите блюдо из стоп-листа (попросите менеджера временно перевести позицию в стоп). Что произошло: заказ прошёл или заблокирован?
- Оформите реальный тестовый заказ и проследите: появился ли он в POS, распечатался ли на кухне, обновился ли статус.
- Проверьте уведомление — дошло ли подтверждение гостю.
- Отменьте заказ и убедитесь, что статус вернулся корректно и в POS, и на стороне гостя.
Почему это не решается «само собой»
Многие владельцы считают, что если они заплатили за интеграцию, то она работает. На практике интеграции ломаются после обновлений POS, смены версии API агрегатора или даже после перезагрузки сервера. Поддержка подрядчика может отвечать сутки, а гости уходят прямо сейчас.
Ещё одна ловушка — несколько независимых интеграций. Сайт подключён к POS через один сервис, агрегатор — через другой, приложение — через третий. Каждый работает сам по себе, и никто не гарантирует, что при изменении каталога в POS все три источника обновятся одновременно.
Что делать системно
- Единая точка входа. Все заказы (сайт, приложение, агрегаторы, виджеты) должны проходить через один шлюз в POS. Это упрощает контроль и исключает дубли.
- Мониторинг статусов. Настройте алерты: если заказ не дошёл до POS за 30 секунд или статус не обновился за N минут — ответственный получает уведомление.
- Регулярный тест. Раз в неделю кто-то из команды проходит по чек-листу аудита. Это занимает 15 минут и спасает от тихих потерь.
- Отдельный лог ошибок. Если интеграция пишет логи, просматривайте их раз в месяц. Если нет — требуйте от подрядчика.
Разрывы в цепочке — это не техническая мелочь, а прямые потери выручки. Гость, который не смог заказать один раз, не вернётся и не оставит отзыв — он просто исчезнет. Проверить свои интеграции можно за полчаса, а найти причину оттока гостей — за месяцы.
Подобрать онлайн-меню и сервисы оплаты, которые корректно связываются с вашей кассовой системой, можно в каталоге решений. Если нужно проверить именно связку с POS — смотрите решения для iiko и R-Keeper.
