Мобільний застосунок для ресторану: де губляться замовлення
Гість відкриває мобільний застосунок для ресторану, знаходить позицію в електронному меню в застосунку — а на кухні її немає ще з відкриття: стоп-лист оновили на касі, але не в застосунку.
Розмова з офіціантом ситуацію вже не рятує: частина гостей закриває застосунок і йде до сусідів, частина все одно замовляє, і позицію знімають вручну під час віддачі.
Корінь проблеми в тому, що меню живе у двох незалежних місцях. Касова система тримає актуальні залишки та стоп-лист, застосунок — свою копію, яку оновлюють вручну або за розкладом раз на добу.
Між оновленнями приймання замовлень відбувається за застарілим стоп-листом, і кожне таке замовлення повертається до гостя відмовою вже після оплати.
Покинутий кошик додає до цього свою частку. Гість збирає замовлення, а на оформленні його зустрічає обов’язкова реєстрація, повторне введення адреси або змінена ціна — і кошик порожніє.
Під час обриву зв’язку стан втрачається зовсім: застосунок не пам’ятає, що вже вибрано, і замовлення починається з нуля.
Рахувати тут потрібно не встановлення й не відкриття, а частку кошиків, що дійшли до оплати, і кількість відмов через відсутні позиції.
Далі розбираємо, як це закривається: єдине джерело меню замість двох копій, подієва синхронізація з касою та кошик, який переживає перезапуск і втрату мережі.
Що дає мобільний застосунок власнику закладу
Електронне меню та стоп-лист живуть в одній панелі: адміністратор змінює ціну, склад або знімає позицію — гості бачать це за хвилину, без передруку та рознесення правок по залу.
Оновлення стоп-листа перестає бути усною домовленістю зміни й стає станом системи, тому офіціант не витрачає вечір на пояснення «цього вже немає».
Самообслуговування гостей додає другий канал приймання замовлення: гість відкриває меню з телефона й збирає замовлення сам.
У години пік це розвантажує офіціантів і зал — частина столів закривається без участі персоналу, а посадка й оборот столу зростають без розширення штату та площі.
Історія замовлень і збережені вподобання скорочують шлях до повторного замовлення до двох дотиків. Заклад отримує базу, за якою видно, хто повертається й що бере, — повторні замовлення перестають залежати від того, чи пам’ятає гість конкретного співробітника.
Скасування скорочуються на етапі приймання: склад, ціна та добавки підтверджені до відправлення на кухню, а розбіжність «сказали — почули» зникає разом з усним переказом. Гість бачить статус замовлення сам і не смикає персонал зайвий раз.
Усі ці ефекти вимірювані: час оновлення меню, частка замовлень, оформлених самим гостем, частка повторних візитів, частка скасувань — рахуються за подіями в застосунку, а не на відчуттях. Далі на цих цифрах будується план розвитку закладу, а не суперечка про смаки.
Власний застосунок, веб-меню та агрегатор: що вибрати
Гість сідає за стіл, сканує код і хоче побачити страви за лічені секунди — на цьому сценарії ламається більшість «універсальних» рішень. Найшвидше відповідає веб-меню за посиланням: відкривається в браузері, встановлення не потребує, правиться з боку залу за хвилини.
Далі починаються обмеження: немає push-повідомлень, доступ до функцій пристрою урізаний, а гість повертається, тільки якщо зберіг посилання.
Агрегатор доставки приводить потік замовлень одразу, але ваше брендоване меню живе всередині чужого інтерфейсу. Гість залишається клієнтом платформи: покази, комісію та відгуки регулює площадка, а історія замовлень і контакти залишаються в неї.
Власний застосунок закладу знімає ці обмеження — повідомлення, програма лояльності, повторне замовлення в один тап, — але потребує встановлення та регулярних оновлень.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Веб-меню за посиланням | Потрібен запуск за лічені дні, QR на столі, меню та передзамовлення без встановлення | Немає повідомлень, урізаний доступ до функцій пристрою, гість повертається тільки за збереженим посиланням |
| Агрегатор доставки | Потрібен потік замовлень одразу, логістику віддаєте площадці | Бренд живе в чужому інтерфейсі, умови задає площадка, дані про гостя вам недоступні |
| Власний застосунок закладу | Лояльність, повторні візити, історія замовлень, керування меню із залу | Потрібне встановлення, свій канал залучення та постійна підтримка |
На практиці три канали не конкурують: веб-меню закриває швидкий вхід, застосунок — повторні візити та лояльність, агрегатор — приплив нових гостей.
Від схеми меню до публікації: етапи роботи
Порядок етапів заданий не для звітності: меню змінюється кожного сезону, а застосунок живе роками, тому помилка в схемі даних на старті обходиться найдорожче. Нижче — етапи розробки застосунку від розбору меню до передачі ресторану.
- Розбір меню й сценаріїв гостя. Збираємо категорії, стоп-листи, сезонні позиції та шлях гостя до відправлення замовлення: скільки екранів, де частіше йдуть, чого не вистачає офіціанту.
- Схема меню та модифікаторів. Проєктуємо структуру даних — страва, група, опція, доплата, доступність за часом і залом. Після цього меню наповнює менеджер, без розробника й без ризику зламати екран.
- Зв’язка з касою та обліковою системою. Обмін двосторонній: меню та стоп-листи надходять з облікової системи, замовлення йдуть назад. Окремо задаємо поведінку, коли каса недоступна: замовлення стає в чергу й не губиться.
- Складання застосунку. Меню, кошик, оплата, лояльність — одна кодова база на iOS і Android, щоб ціна та стоп-лист не розходилися між платформами. Зображення кешуються, список відкривається навіть на слабкій мережі.
- Тестовий запуск на залі. Дві-три зміни у звичайному режимі: дивимося, де офіціант дублює замовлення руками, а гість кидає кошик. Правки вносимо до публікації, а не після.
- Публікація в магазинах застосунків і передача. Картки, модерація, поетапний випуск на частину аудиторії, версія для відкату. Далі — доступи, регламент оновлення меню та черговий інженер.
Комплект передачі: доступи, схеми, регламенти
Комплект передачі — це не папка з вихідними кодами, а набір артефактів, з якими ваша команда працює самостійно: без нас, але з повним розумінням, що де лежить і хто за що відповідає.
Нижче — те, що ми фіксуємо за актом, і за кожним пунктом перевіряємо разом, що доступ видано й він справді працює.
- Доступи та ролі співробітників. Кабінети керування меню, аналітики та повідомлень передаються на ваші облікові записи з правами власника. Усередині налаштовуємо ролі: керуючий змінює ціни та склад розділів, менеджер залу править стоп-лист і доступність страв, офіціант лише переглядає та підтверджує замовлення.
- Схема зв’язків систем. Один аркуш: застосунок, панель меню, касова система, платіжний сервіс, сервіс повідомлень — хто з ким обмінюється даними й що відбувається із замовленням у разі відмови однієї з ланок.
- Регламент оновлення меню. Хто вносить зміни, у який момент вони з’являються в гостя, як оновлюється кеш на пристроях, що робити зі стравами, знятими з продажу, щоб вони не залишилися у старих збірках.
- Інструкція для персоналу залу. Відкриття та закриття зміни, показ меню й оплата за столом, дії під час втрати зв’язку, типові запитання гостей — на одну сторінку, на допомогу новому співробітнику.
- Магазини застосунків. Акаунти розробника та картки переведені на вас, ключі підпису й порядок випуску оновлень задокументовано, випускати нові версії може будь-яка вибрана вами команда.
- Регламент підтримки та оновлень. Канали звернень, пріоритети, строки реакції на відмову оплати або падіння вітрини, порядок узгодження термінових правок у сезон.
- Схема даних та історія змін. Структура страв, категорій і модифікаторів із прикладом вивантаження — щоб звітність та інтеграції можна було розширювати без розбору застосунку заново.
Підсумок передачі — ви керуєте меню, цінами та ролями самі, а звертаєтеся до нас за розвитком, а не за кожною правкою позиції. Опишіть задачу — повернемося з планом робіт та оцінкою складу такого комплекту під ваш ресторан.
Кейс: мережа піцерій прибрала ручне оновлення меню
До: правки в чотирьох місцях і запізнілий стоп-лист
У мережі піцерій «Три печи» меню жило в чотирьох незалежних місцях: сайт, застосунок, агрегатори доставки та каса в залі. Правку ціни або складу вносили вручну в кожному — від 40 хвилин роботи адміністратора, а у вечірній пік доходило до двох годин.
Розбіжності спливали не відразу: гість бачив на сайті одну ціну, в агрегаторі іншу, і це осідало поверненнями.
Дорожче обходився стоп-лист. Коли на кухні закінчувалася начинка, позицію знімали в застосунку, але на інших каналах вона залишалася доступною ще близько години.
Замовлення встигало піти на кухню, оператор телефонував гостю зі скасуванням або заміною — звідси й набігала основна частка скасованих замовлень, близько восьми відсотків у пікові зміни.
Що змінили і що вийшло
Меню звели до одного джерела: правка в адмінці розходиться по сайту, застосунку та агрегаторах протягом хвилини, стоп-лист проставляється там же й гасить позицію в усіх каналах одночасно.
Локальний кеш тримає меню на пристрої, тому в залі зі слабким зв’язком гість бачить актуальний склад, а не вчорашній.
Оновлення меню тепер займає 2–3 хвилини замість години, стоп-лист доїжджає до всіх точок продажів без ручних дій. Частка скасованих замовлень скоротилася приблизно втричі — до 2–3%, а адміністратори перестали дублювати одну правку в чотирьох вікнах і повернулися до роботи в залі.
Що робити, якщо меню та ціни змінюються кілька разів на день?
Меню з кількома правками на день ламає застосунок, якщо він зберігає копію списку позицій у себе. Офіціант уже знає, що суп закінчився, а гість у залі все ще бачить його доступним і чекає замовлення — на розборі це найчастіша причина негативу у відгуках.
У такому сценарії кожна правка перетворюється на випуск нової збірки, перевірку в магазині та добу очікування.
Ми не дублюємо меню всередині застосунку: воно працює від єдиного джерела даних — облікової системи ресторану, чи то iiko, чи інша каса. Позиції, ціни, склад і доступність надходять звідти, а в застосунку залишається лише локальна копія для швидкого старту. Зміна, внесена технологом, стає видимою гостям без участі розробника.
Правки не йдуть у зал миттєво — працює відкладена публікація змін. Нову ціну або склад готують чернеткою й призначають час набуття чинності: з відкриття, до бізнес-ланчу, після закриття кухні.
Якщо щось пішло не так, попередній стан повертається однією командою, а не відкатом усього застосунку.
Окремо варто зупинитися на перевірці стоп-листа: асортимент звіряється з фактичними залишками, і позиція автоматично переводиться в «немає в наявності» — гість бачить її недоступною, а не отримує відмову після оформлення замовлення.
Оновлення без перезапуску означає, що актуальний набір підтягується під час старту, повернення з фону та за службовим сигналом: офіціанту не потрібно просити гостя закрити й знову відкрити програму.
У підсумку часті правки меню перестають бути проєктною роботою й стають рутиною технолога в обліковій системі, а зал і застосунок показують одне й те саме. Нижче — як ми розгортаємо таку зв’язку й що перевіряємо перед запуском.
Офлайн-режим, ролі персоналу та оновлення: технічні деталі
Перед запуском застосунку спливають ті самі питання: що буде в годину пік при зниклому Wi-Fi, хто з персоналу що бачить, як проходить оплата. Нижче — п’ять вузлів, які найчастіше розбираємо із замовником до старту розробки.
Що станеться із замовленням, якщо мережа зникла?
Застосунок записує замовлення в локальну чергу й надсилає його, коли зв’язок повернувся. Унікальний ключ операції не дає створити дубль під час повторного надсилання, а меню та стоп-лист залишаються доступними з локального кешу.
Як розмежувати доступ персоналу?
Доступ будується на ролях: офіціант, кухня, бар, менеджер, власник. Права задаються на рівні операцій — надіслати замовлення, скасувати позицію, закрити зміну — і кожна дія потрапляє в журнал.
Як приймається оплата всередині застосунку?
Платіж обробляє платіжний провайдер, застосунок отримує лише результат і не зберігає дані картки. Оплата можлива на касі, через термінал або прямо в застосунку, чек іде у фіскалізацію.
Що можна змінювати після запуску?
Меню, ціни, стоп-листи та акції правляться на сервері без перезбирання застосунку. Логіка оновлюється через магазини застосунків, тому інтерфейс обміну версіонується — застаріла версія продовжує працювати в гостя.
Яка аналітика замовлень доступна?
Збираємо події за замовленнями: склад, час від відкриття меню до відправлення, скасування, повторні візити. Звіти вивантажуються в систему обліку, яка вже є в ресторану, а не залишаються всередині застосунку.
Обговоримо задачу й повернемося з планом робіт
Щоб повернутися з планом робіт, нам потрібен мінімум ввідних: скільки точок і залів, яка каса та облікова система вже стоїть, як зараз оновлюється меню й хто веде стоп-листи, чи є доставка, на яких пристроях працюють офіціанти. Цього достатньо, щоб оцінити обсяг і не ганяти вас по десяти уточнювальних листах.
До оцінки додаємо не перелік технологій, а документи, за якими видно, як застосунок буде жити в ресторані:
- план робіт із застосунку: етапи, тривалість кожного та що вважається завершеним на виході;
- склад робіт і передачі — що саме йде вам: код, конфігурації збірки, доступи, інструкції для адміністраторів залу;
- схема зв’язків з касою та кухнею: які дані й у який бік ідуть, де зберігається меню, як поводиться застосунок під час обриву зв’язку;
- порядок перевірки на залі: сценарії на реальному залі в годину пік — стоп-лист, зміна залу, друк замовлення, гість із двома пристроями;
- порядок запуску: пробний запуск на одній точці, поетапне включення решти, критерії переходу та умови відкату;
- регламент підтримки: куди надходить звернення, за який час реагуємо, хто з боку ресторану ухвалює рішення.
Опишіть задачу в зручному вигляді — листування, дзвінок із технологом ресторану або доступ до поточного меню. Повернемося з оцінкою, планом робіт і складом передачі.
