Онлайн-замовлення ресторану: меню, кухня та слоти приймання

Гість оплатив вечерю на сайті, але адміністратор ще не побачив заявку, а кухня вже закрила гарячий цех. Онлайн-замовлення ресторану в такій ситуації не можна вважати прийнятим лише тому, що спрацювала кнопка оплати. Перед запуском прямого каналу потрібно узгодити три речі: яке меню справді доступне, хто підтверджує приготування та яку кількість замовлень заклад може виконати в обраний час.

Починайте з правил обіцянки гостю, а не з вибору між сайтом і застосунком. Нижче — план для власника ресторану й операційного керівника: як підготувати меню, приймання та часові слоти, перевірити збої й визначити межі першого запуску. Це не інструкція з маршрутизації кур’єрів і не огляд усіх систем управління замовленнями.

Спочатку погодьте момент прийняття замовлення

Розділіть отримання заявки, підтвердження оплати й згоду кухні на виконання. Для кожної події потрібні відповідальний, запис у системі та зрозуміле повідомлення гостю. Фраза «замовлення прийнято» має означати, що заклад перевірив склад, час і можливість приготування, а не лише зберіг кошик.

Погодьте, чи адміністратор підтверджує кожне замовлення, чи система робить це автоматично за визначених умов. У першому випадку потрібні чергування й контроль пропущених заявок. У другому — перевірка доступності страв, потужності кухні та чинного розкладу перед підтвердженням. Автоматизація без цих обмежень лише швидше роздає нездійсненні обіцянки.

Визначте власника кожного рішення

Меню й ціни може вести облікова система, стоп-лист — відповідальний працівник зміни, доступні слоти — модуль замовлень. Це можливий розподіл, а не універсальна архітектура. Запишіть, де саме змінюють дані, як вони потрапляють на сайт і хто має право призупинити приймання. Інакше сайт і кухня матимуть дві різні версії правди.

Перетворіть меню на правила продажу

Фотографія й назва страви не описують її доступність. Для кожної позиції визначте варіант, порцію, ціну, дозволені доповнення, години продажу й точку приготування. Кухонний працівник має отримати однозначний склад: «без цибулі» не повинно загубитися в загальному коментарі до адреси.

Синхронізація меню ресторану потребує окремих правил для змін ціни й тимчасової відсутності. Уточніть, чи облік передає готові порції, інгредієнти або лише ручний стоп-лист. Залишок продукту сам собою не доводить, що страву можна продати: можуть бути недоступні потрібний працівник, обладнання або пакування.

Повторно перевіряйте кошик перед підтвердженням

Поки гість заповнює контакти, страва може зникнути з продажу. Перевірте доступність і підсумкову суму на сервері перед створенням підтвердженого замовлення. Якщо склад змінився, поясніть причину й запропонуйте перегляд кошика. Не підміняйте позицію іншою без погодження гостя.

Для наборів і модифікаторів перевіряйте поєднання, а не лише базову страву. Недоступний соус може блокувати певний набір, але не все меню. Інформацію про склад та алергени має погодити відповідальний закладу; вільний коментар гостя не можна перетворювати на автоматичну гарантію безпечного приготування.

Слоти мають відображати роботу кухні

Часовий слот — це доступне вікно отримання замовлення, а не декоративний список годин. Його межі залежать від підготовки, завантаження цехів, пакування та способу отримання. Самовивіз і доставка можуть використовувати ту саму кухню, тому їх не варто рахувати як дві незалежні необмежені черги.

Слоти самовивозу спочатку можна обмежувати зрозумілим правилом місткості, яке погодив керівник зміни. Для складнішого меню одна заявка не дорівнює іншій: великий набір і напій навантажують кухню по-різному. Не починайте зі складного прогнозування, якщо ще немає перевірених даних про приготування.

Відокремте статус кухні від статусу оплати

У гостьовому інтерфейсі можуть бути прості стани: «очікує підтвердження», «готується», «готове до видачі», «видано» та «скасовано». Усередині системи додатково потрібні причина зупинки й відповідальний. Оплачене замовлення може ще чекати кухню, а підтверджене до приготування — мати оплату при отриманні, якщо цей спосіб дозволений.

Офіційна документація Square окремо описує початковий стан виконання PROPOSED і обмеження відображення замовлень у своїх продуктах. Це корисний приклад того, чому створений запис не дорівнює видимому завданню для персоналу. Проте правила Square не є стандартом для всіх касових систем і не доводять доступність конкретного рішення у вашій країні.

Перед вибором інтеграції попросіть перевірити на тестовому середовищі вашу касову систему, або POS, і кухонний екран, або KDS. Чи видно неоплачену заявку? Чи передаються модифікатори? Чи повертається відмова кухні на сайт? Чи підтримуються зміни після прийняття? Наявність API — програмного інтерфейсу обміну — не є відповіддю на ці запитання.

Скасування має завершувати й фінансову дію

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

Повторне повідомлення від платіжного сервісу не повинно запускати друге приготування. У документації Stripe про обробку webhook-подій прямо розглядаються дублікати й порядок надходження. Проєктуйте захист від повторної дії та звірку станів для свого провайдера, не припускаючи, що всі повідомлення приходять один раз і вчасно.

Умовний приклад: остання порція та зайняте вікно

Уявімо ресторан з одним пунктом самовивозу. Це навчальний сценарій, а не кейс GL.ua. На сайті залишилася одна доступна порція лазаньї, а для найближчого вікна керівник зміни дозволив прийняти ще одне замовлення. Двоє гостей одночасно відкрили кошики з цією стравою.

Під час підтвердження перший кошик займає порцію й місце у вікні як одну узгоджену операцію. Другий отримує повідомлення, що умови змінилися: страву вже не можна замовити, а доступний час потрібно вибрати заново. Самого вимкнення кнопки після оновлення сторінки недостатньо — рішення має перевірятися в системі, яка приймає замовлення.

Далі адміністратор приймає першу заявку, але відповідь на сайт губиться. Повторний запит із тим самим ідентифікатором має повернути наявний результат, а не створити ще один кухонний чек. Якщо гість покинув оплату, тимчасовий резерв звільняється за погодженим правилом. Конкретний строк резерву визначають під час проєктування, а не беруть із довільного шаблону.

Пройдіть перевірку до відкриття каналу гостям

Для пілота оберіть одну точку, обмежене меню й погоджений спосіб отримання. Це зменшує кількість залежностей, але не скасовує перевірки відмов. Адміністратор і представник кухні мають пройти сценарії разом, а не отримати лише відео успішної покупки.

1. Змініть ціну й стоп-лист, поки кошик відкритий. Звірте фінальний склад і пояснення гостю до платежу або підтвердження.
2. Надішліть одночасні заявки на останню порцію й останнє місце у слоті. Переконайтеся, що система не підтвердила обидві.
3. Вимкніть приймальний пристрій або обмін із POS. Перевірте сигнал відповідальному, гостьове повідомлення та можливість призупинити канал.
4. Повторіть платіжне повідомлення й запит створення замовлення. На кухні має залишитися одне завдання без повторного списання через власну логіку сайту.
5. Скасуйте заявку до прийняття та після початку приготування. Звірте дозволені дії, повернення й журнал рішень, не припускаючи однакових правил для обох моментів.
6. Пройдіть передзамовлення, закриття зміни та зміну доступного часу з телефона. Перевірте всі повідомлення й фактичну появу завдання на кухні.

Тексти очікування та помилок варто погодити ще в специфікації станів інтерфейсу. Протокол приймання має містити не «все працює», а очікуваний і фактичний результат кожного тесту, відповідального та рішення щодо знайденої розбіжності.

Що обмежує запуск, строки та бюджет

Основні ризики тут операційні: застарілий стоп-лист, непомічена заявка, переоцінена місткість слота й нечіткий порядок скасування. Додайте технічні залежності: недоступність POS, затримку повідомлень та різні ідентифікатори страв. Для кожного ризику потрібен спосіб виявлення і дозволена дія зміни. Ручний резервний процес має бути описаний, а не триматися на пам’яті адміністратора.

Строки залежать від готовності меню, доступів до тестового обліку, підтримуваних операцій інтеграції та часу персоналу на перевірку. Плануйте окремі результати: погоджений процес, прототип, тестовий обмін, перевірка винятків, навчання й обмежений запуск. Якщо документації POS недостатньо, спочатку потрібна технічна проба, а не календарна обіцянка на весь проєкт.

До вартості входять аналіз і підготовка даних, інтерфейс меню та кошика, правила слотів, обмін із касою й кухнею, платіжний сценарій, сповіщення, тестування та навчання. Окремо врахуйте хостинг, тарифи сервісів, моніторинг, оновлення й підтримку. Фіскальні та правові вимоги перевіряють для конкретної моделі роботи з відповідними фахівцями; підключений платіжний модуль сам собою їх не закриває.

Доставку додавайте лише після визначення відповідальності за готовність і видачу. Планування перевезення має інший контур; його межі пояснює матеріал про інтеграцію сайту з TMS. Для першого самовивозу окрема транспортна система може бути зайвою.

Почніть із виконуваної обіцянки гостю

Прямий канал готовий до пілота, коли меню відповідає реальній доступності, кухня бачить і приймає завдання, а слот не продає більше потужності, ніж погодив заклад. Якщо цього немає, новий дизайн чи застосунок не усуне розрив. Спершу перевірте один повний маршрут і право зміни зупинити приймання, потім розширюйте меню та аудиторію.

Для підготовки такого каналу зверніться до GL.ua (Глянець) щодо розробки онлайн-магазину з інтеграціями. Передайте приклад меню, опис приймання, дані про касову систему й сценарії відмов: це основа для перевірки здійсненності та оцінки, а не привід одразу замовляти всі можливі функції.