Заказы навынос — это другой бизнес, чем обслуживание в зале. Клиенты не садятся. Нет столика, чтобы их разместить. Они хотят знать две вещи: когда будет готова еда и как заплатить. Всё, что мешает ответить на эти два вопроса, — это трение, а трение теряет заказы в пользу конкурента с более отлаженным процессом.
За последние несколько лет стратегия для заказов навынос сместилась от телефонных звонков и стоек к QR-и-очередь-процессу, который масштабируется. Клиенты занимают место в очереди, составляют заказ на своём телефоне, платят, загружая квитанцию банковского перевода, и забирают, когда подходит их номер. Всё работает в браузере — без приложения, без стойки администратора, без наушника.
В этой статье рассматриваются практические решения, которые делают этот рабочий процесс эффективным в реальном ресторане.
Отдельное ценообразование для навынос
Первое решение — должны ли цены навынос совпадать с ценами в зале. Во многих странах ответ — нет. Обслуживание в зале включает посуду, бокалы, столичный сервис и атмосферу. Навынос включает упаковку и предположение, что клиент поест где-то в другом месте. Структуры затрат разные, и готовность платить — тоже.
Распространённая схема — небольшая надбавка за навынос, возможно, 10–15 процентов, для покрытия упаковки и труда по упаковке и выдаче. Некоторые рестораны делают наоборот и предлагают небольшую скидку на навынос, поскольку экономят на мойке посуды и оборачиваемости столиков. В любом случае система меню должна поддерживать отдельное поле цены для каждой позиции — отличное от цены в зале, — которое появляется только при заказе навынос.
Позиции также нуждаются в отдельном флаге доступности для навынос. Некоторые блюда плохо переносят транспортировку. Суфле, нежное карпаччо, десерт из нескольких компонентов — ни одно из них не подходит для меню навынос. Они должны оставаться в меню зала, но быть скрыты из списка навынос одним переключателем — без необходимости вести два параллельных меню.
Двухэтапное подтверждение заказа
Классическая ошибка — трактовать заказ навынос как оформление заказа на сайте, где клиент подтверждает всё в конце. На практике это не работает, потому что шаг оплаты — самый медленный и ненадёжный. Банковские переводы требуют времени. Клиент может ошибиться в сумме. Квитанция может быть нечёткой. Если заказ зафиксирован до подтверждения оплаты, кухня начинает готовить еду, за которую ресторан может так и не получить деньги.
Лучший рабочий процесс — двухэтапная передача. Этап первый: клиент оформляет заказ. Система фиксирует позиции, рассчитывает итог и показывает чёткую сумму в валюте оплаты. Этап второй: клиент загружает квитанцию об оплате. До тех пор, пока ресторан вручную не подтвердит действительность квитанции, заказ находится в статусе «ожидание подтверждения». Кухня не приступает. Статусный значок клиента отображает «Ждём подтверждения оплаты от ресторана» — чтобы он понимал: мяч на Вашей стороне, не на его.
Это звучит медленно. На практике подтверждение персоналом занимает десять секунд — открыть панель управления, просмотреть изображение квитанции, нажать кнопку. Кухня видит заказ в момент подтверждения оплаты, а не раньше — что является именно правильным моментом.
Загрузка квитанций, которая не ломается
Наиболее частый сбой при загрузке квитанций — права доступа. Телефоны клиентов используют случайные IP-адреса. Размер изображений варьируется от 200 КБ до 10 МБ. Одни клиенты делают скриншот банковского приложения, другие фотографируют бумажную квитанцию, третьи вставляют изображение, пересланное из мессенджера. Система загрузки должна поглощать всё это без ошибок.
Несколько практических правил. Первое: принимайте несколько форматов изображений — JPEG, PNG и WebP охватывают практически все камеры телефонов и инструменты создания скриншотов. Второе: используйте предварительно подписанные URL загрузки с коротким сроком действия, чтобы загрузка происходила напрямую с телефона клиента в хранилище, минуя Ваш сервер. Третье: проверяйте тип файла на стороне сервера до выдачи URL. Четвёртое: храните квитанции по чётко организованному пути, чтобы впоследствии можно было провести аудит при спорных платежах.
Пользовательский интерфейс должен содержать одну большую кнопку «Загрузить квитанцию об оплате», а не многошаговую форму. После загрузки покажите клиенту миниатюру квитанции с опцией «Заменить» на случай, если он загрузил не тот скриншот. Статусный значок должен немедленно переключиться на «Ждём подтверждения от ресторана», чтобы клиент понял: загрузка прошла успешно.
Коды для выдачи
Когда клиент приходит забирать заказ, Вам нужен быстрый способ сопоставить его телефон с заказом на Вашем экране. Называть номера вслух работает в тихом ресторане, но не работает в шумном магазине чайных напитков, где в очереди пятеро с номером 12.
Короткий код подтверждения — шесть символов из набора без схожих знаков — решает эту задачу. Генерируйте его на стороне сервера в момент оформления заказа. Показывайте его на телефоне клиента рядом с номером в очереди. Показывайте тот же код в панели управления персонала. Когда клиент приходит, он показывает телефон, Вы сравниваете коды и выдаёте пакет. Весь обмен занимает три секунды и никогда не зависит от выкрикиваемых имён.
Код подтверждения также работает как защита от мошенничества. Клиент не может заявить «я — номер 42», не показав код, соответствующий номеру 42. Два случайных человека не могут случайно получить одинаковый код в один и тот же день в каком-либо реальном сценарии.
Ежедневная сверка
Выручка навынос должна ежедневно сверяться с банковскими переводами. Простейший способ — просмотр истории в панели очереди, где перечислены все заказы, отмеченные как «Выдан» за данный день, с номером в очереди, кодом, временем, суммой и ссылкой на изображение квитанции. Выбираете дату, видите список, видите дневной итог, сверяете с выпиской банка. Пять минут в день, в идеале в рамках процедуры закрытия.
История должна корректно учитывать часовой пояс. Ресторан в Бангкоке, закрывающийся в полночь по местному времени, должен видеть все заказы текущего календарного дня сгруппированными вместе, а не разделёнными полуночью по UTC в середине ужинного сервиса. Система должна знать страну ресторана и использовать местный часовой пояс для группировки.
Что делать, когда что-то идёт не так
В любом реальном рабочем процессе возникают нестандартные ситуации. Клиент платит неправильную сумму. Квитанция нечитаема. Клиент так и не приходит. Кухня заканчивает позицию между оформлением заказа и его подтверждением.
Для каждой ситуации предусмотрите чёткий путь. Неправильная сумма: сотрудник открывает заказ, видит проблему и либо принимает частичную оплату с пометкой, либо просит клиента доплатить. Нечитаемая квитанция: сотрудник не подтверждает; клиент замечает, что его статус завис, и загружает новую. Неявка: запись в очереди остаётся в статусе «готовится» до ручной пометки «Выдан» или «Отменён».
Позиция заканчивается между оформлением и подтверждением — это наиболее неприятный случай. Самый чистый ответ — быстрый возврат клиенту на тот же банковский счёт с извинением и пояснением. Системы должны упрощать это: кнопка «Отменить» в заказе, которую можно нажать после просмотра квитанции, с немедленным отражением отмены на телефоне клиента.
Не оптимизируйте сценарий успеха чрезмерно агрессивно
Соблазн при проектировании потока навынос — предположить, что каждый заказ проходит идеально, и разработать интерфейс соответственно. Это ловушка. Большинство заказов действительно проходят идеально, но плохие занимают непропорционально много времени и создают наибольший объём работы с клиентами. Стройте рабочий процесс вокруг плохих случаев в первую очередь — и хорошие позаботятся о себе сами.
Чёткий статусный значок, который клиент читает за три секунды. Панель, показывающая всё необходимое персоналу с первого взгляда. Коды для быстрой выдачи. Просмотр истории для ежедневной сверки. Плюс базовое ожидание, что некоторые заказы потребуют ручного вмешательства, — и система делает это вмешательство лёгким, а не невозможным. Сделайте эти вещи правильно — и у Вас будет операция навынос, которая масштабируется.
