Чому мобільний додаток для ресторану втрачає бронювання столів
Сценарій гостя в додатку для бронювання столів короткий: вибрати дату, кількість гостей, час — і отримати підтвердження бронювання. Ламається він рівно в одному місці.
Гість доходить до вибору часу, бачить сітку інтервалів, витрачає 30-40 секунд на роздуми — і закриває додаток, бо наступний крок перетворюється на листування з менеджером.
Далі й починається втрата бронювання. Форма надсилає заявку, але підтвердження бронювання надходить не одразу, а після того, як співробітник подивиться зал і напише або зателефонує.
Поки гість чекає відповіді, він відкриває карти (Google Maps) або агрегатор і бронює там же за пару хвилин. Додаток отримав відмову не через інтерфейс, а тому що не довів сценарій гостя до кінця.
Друга причина — зайнятість столів. Якщо додаток обмінюється з касою не миттєво, а за розкладом, сітка інтервалів показує дані давністю в кілька хвилин і бреше в обидва боки: вільний стіл виглядає зайнятим, зайнятий — вільним.
Перше дає втрачені бронювання, друге — скандал біля входу, коли двоє гостей приходять на один стіл в один час.
Ціна помилки накопичується тихо. Гість, який не забронював сьогодні, позначає це як «додаток не працює» і повертається до дзвінка — а дзвінок забирає бронювання з системи, де їх видно і за ними можна планувати завантаження залу.
Розбираємо, як це закривається: підтвердженням бронювання за правилами ресторану за секунди, чесною зайнятістю столів і сценарієм, який гість проходить без очікування.
Що змінюється після запуску: швидкість бронювання та завантаження залу
Швидкість бронювання вимірюється не відкликом додатка, а шляхом до підтвердженого бронювання. При дзвінку цей шлях складається з додзвону, уточнення вільних слотів, очікування передзвону й ручного запису в журнал — частина таких звернень губиться на стику «вільно — зайнято».
У додатку гість вибирає зал, дату й кількість гостей, залишок посадки перераховується автоматично, і підтвердження надходить одразу, без участі хостес.
Завантаження залу зростає не за рахунок реклами, а за рахунок перерозподілу місць. Слоти прив'язані до реальної посадки й стоп-листа, тому скасоване бронювання миттєво повертається в доступ і його бачить наступний гість.
Зал перестає простоювати на стиках між посадками, а пікові години закриваються депозитом або попереднім замовленням — стіл займають ті, хто прийде.
З неявками гостей бореться не штраф, а керування життєвим циклом бронювання.
Нагадування напередодні й підтвердження в день візиту, депозит для великих компаній, авто-звільнення столу, якщо гість не прийшов за відведений час, — частка бронювань «в нікуди» падає, а хостес бачить, хто підтвердив, і не тримає стіл під мовчазного гостя.
Повторні візити тримаються на історії. Додаток пам'ятає улюблений стіл, середній чек і привід минулого візиту, тому повернення до дати йде персоналізованою пропозицією, а не загальною розсилкою.
Інтеграція з iiko підтягує посадку та історію з облікової системи ресторану: одна база замість журналу, таблиці й переписки в месенджері.
Усі ці ефекти — наслідок однієї зв'язки: бронювання, посадка й гість живуть в одних даних, а не в трьох облікових контурах.
Три шляхи: єдине ядро, нативна збірка, коробкове рішення
Вибір підходу визначається не смаком, а часткою платформеної логіки в сценарії. Бронювання — це карта з точками, сповіщення про підтвердження, передоплата за стіл, календар і нагадування за годину до візиту: чим більше таких вузлів, тим сильніше розходяться варіанти. Нижче — три альтернативи, між якими обирають на практиці.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Кроссплатформена розробка: одне ядро, дві збірки | Обидві платформи потрібні в один строк, сценарії бронювання типові, важлива швидкість випуску нових версій | Спільна частина коду закриває не все: карти, оплата й фонова робота потребують нативних вставок, нова системна можливість платформи надходить із затримкою |
| Нативна розробка під кожну платформу | Багато роботи з камерою, геозонами, оплатою, системними віджетами; високі вимоги до чутливості та роботи у фоні | Дві кодові бази та два цикли випуску: правка одного екрана робиться двічі, супровід дорожчий, реліз довший |
| Готове рішення з налаштуванням | Потрібен стандартний сценарій «обрав стіл — отримав підтвердження» і запуск у короткий строк | Логіка підлаштовується під продукт, а не під ваш зал і правила передоплати; власні інтеграції — лише через відкриті точки постачальника; вихід із рішення за обсягом робіт порівнянний із розробкою з нуля |
Різниця проявляється не на старті, а на другому-третьому сезоні. У єдиного ядра 70–80% коду спільні, і правка правил бронювання виходить один раз; у нативних збірок — двічі; у готового рішення — у порядку черги постачальника.
Тому ми спочатку рахуємо частку платформених вузлів і кількість зовнішніх інтеграцій (каса, програма лояльності, карти), і лише потім називаємо підхід.
Як іде робота: від розбору сценаріїв до передачі проєкту
Починаємо не з макетів, а з того, як зал живе в зміну: де пік, скільки посадок на годину, хто підтверджує бронювання і що робити, коли гість не прийшов.
Від цієї картини залежить схема бронювання — чи тримаємо стіл за конкретним офіціантом, чи працює автопідтвердження, як враховуються депозити й великі компанії.
- Аудит процесів залу. Розбираємо джерела бронювань — дзвінки, сайт, агрегатори, — правила скасування, депозити й розсадку великих компаній. На виході карта сценаріїв і перелік вузьких місць.
- Прототип бронювання. Клікабельний прототип вибору залу, столу, часу й кількості гостей перевіряємо на хостесі та адміністраторі до написання коду: правки тут займають години, після релізу — тижні.
- Схема даних і зв'язки. Визначаємо, які столи можна об'єднувати, як бронювання синхронізується з обліковою системою залу і що відбувається при двох запитах на один стіл одночасно.
- Збірка. Ітерації по одному-двох тижнях, на кожній — робоча збірка. Замовник дивиться на живий додаток, а не на звіт про готовність.
- Тестування сценаріїв під навантаженням. Проганяємо піковий вечір і святкові дні: сотні одночасних запитів, обриви мережі, повторні натискання. Перевіряємо, чи не відходить один стіл двом гостям.
- Введення в експлуатацію. Запускаємо паралельно зі звичним порядком: частина бронювань іде через додаток, частина — як раніше. Дивимося заповнюваність і час підтвердження бронювання.
- Передача проєкту. Віддаємо доступи, документацію щодо схеми бронювання й інструкції для зміни, налаштовуємо оповіщення про збої. Далі — підтримка й розвиток.
Передача проєкту: схеми інтеграцій, доступи, регламенти підтримки
Передача додатка — це не архів із вихідним кодом, а комплект, за яким ваша команда або сторонній підрядник підніме збірку, випустить оновлення й розбере інцидент без нашої допомоги.
Ми збираємо його під час проєкту: частина артефактів народжується разом з інтеграціями, частина — на етапі дослідної експлуатації, коли видно реальну поведінку бронювання під навантаженням.
- Документація на додаток: карта екранів і сценаріїв бронювання, опис модулів, точок розширення й того, які дані вважаються джерелом істини при розходженні клієнта й сервера.
- Схеми інтеграцій: потоки із системою бронювання, касовим контуром, еквайрингом і фіскалізацією — де саме підтверджується бронювання, у який момент проходить оплата, які поля обов'язкові і що відбувається при відмові кожного вузла.
- Права доступу співробітників: матриця ролей у панелі адміністратора, репозиторіях, сервісах сповіщень, акаунтах магазинів додатків і зовнішніх сервісів — із зазначенням власника кожного доступу, а не загального облікового запису.
- Регламент підтримки: пріоритети звернень, час першої реакції, порядок ескалації, відповідальні на стороні ресторану та наші контакти для кожного класу інцидентів.
- Регламент випуску оновлень: правила роботи з гілками, обов'язкові перевірки перед збіркою, порядок публікації та відкат на попередню версію, якщо оновлення ламає сценарій бронювання.
- Інструкції для персоналу: як змінювати меню та години роботи, налаштовувати ліміти й інтервали посадки, знімати завислі бронювання і що робити, якщо гість не отримав підтвердження.
- Перелік зовнішніх сервісів та їхніх налаштувань: карта залежностей із зазначенням, що критично для прийому бронювань, а що можна вимкнути без зупинки залу.
Перші два-чотири тижні після передачі залишаємося на зв'язку за регламентом підтримки — відповідаємо на запитання вашої команди й розбираємо інциденти разом, поки ви не вийдете на самостійний цикл випуску.
Кейс: мережа закладів — час бронювання скоротився втричі
Що було
Мережа залів тримала бронювання в паперовому журналі та на телефоні: адміністратор приймав дзвінок, звірявся із зайнятістю столів і передзвонював для підтвердження.
На вечірньому піковому навантаженні шлях від звернення до підтвердженого бронювання розтягувався до 4-5 хвилин, частина дзвінків губилася в черзі, а частка неявок трималася близько 18% — стіл простоював під гостя, який не приїхав.
Що змінили
Для Прованс зібрали мобільний додаток із картою залу: гість бачить реальну зайнятість на вибраний час, підбирає стіл за посадкою й отримує підтвердження одразу, без дзвінка.
Нагадування надходить за кілька годин до візиту, скасування та перенесення доступні в один тап, а час, що звільнився, одразу переходить у лист очікування наступному гостю.
З боку залу з'явилася консоль адміністратора: стрічка бронювань, завантаження на зміну, автоматичний розподіл столів із буфером на прибирання між посадками — ручної звірки за журналом більше немає.
Що стало
Шлях до підтвердженого бронювання скоротився втричі — до півтори хвилини в середньому, і в години пік він більше не зростає через чергу на телефоні. Неявки знизилися з 18% до 6% на тих посадках, де ввімкнено нагадування й підтвердження візиту.
Кількість дзвінків на зміну зменшилася приблизно втричі: адміністратор займається залом, а не обдзвоном.
Лист очікування повертає в обіг бронювання, від яких відмовилися, тому вечірні відмови скоротилися без розширення посадки — кейс розробки окупається самим завантаженням залу, а не зростанням кількості столів.
Що робити, якщо додаток уже випущено і гальмує
Випущений мобільний додаток для ресторану гальмує рідко з однієї причини: зазвичай складаються важкий старт, зайві запити при відкритті екрана й обхідні рішення, накопичені за роки правок.
Перш ніж щось переписувати, ми проводимо аудит поточного рішення — знімаємо профіль запуску й ключових сценаріїв бронювання і дивимося, де час іде на очікування мережі, а де на малювання списків і карт.
За підсумками аудиту видно, чи закривається задача підтримкою готового продукту або без перезбірки ядра не обійтися.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Точкове доопрацювання поточного контуру | Вузьке місце локалізовано: один-два повільні екрани, важкий старт, надлишкові запити при відкритті картки залу | Архітектурні борги залишаються, виграш помітний лише в змінених сценаріях |
| Перезбірка ядра | Проблеми системні: шари переплетені, будь-яка правка ламає сусідні екрани | Довше за строками, потрібен період паралельної роботи старої та нової версій |
Вибір між двома шляхами — це вибір між швидкістю результату й строком життя рішення. Точкове доопрацювання дає швидкий ефект там, де ми вже попрацювали, але залишає причину: наступна правка знову впреться в ті самі шари. Перезбірка ядра довша й потребує паралельної роботи двох версій, зате знімає причину, а не симптом.
Далі починається підтримка готового продукту: збір падінь і повільних операцій, контроль частки успішно завершених бронювань, регрес на кожному випуску.
Доопрацювання релізу йде короткими ітераціями з можливістю швидкого відкату — якість не втрачається в міру зростання навантаження.
Часті технічні питання перед стартом
Сумніви на етапі оцінки майже завжди одні й ті самі: що буде в годину пік при перевантаженні каналу, як дані потраплять у касову зміну, чим обернеться оновлення в розпал зміни і хто відповідає за персональні дані гостей. Нижче — короткі відповіді по суті, без загальних слів.
Що відбувається, якщо в залі зникає зв'язок?
Бронювання й посадка записуються в локальне сховище пристрою, а не лише на сервер: адміністратор продовжує бачити столи й відмічати гостей. Зміни йдуть у чергу з повторними спробами й синхронізуються при поверненні каналу, конфлікти вирішуються за часом події.
Гість при цьому отримує підтвердження бронювання підтвердженим каналом, а не за фактом доставки запиту на сервер.
Як додаток пов'язаний із касою та складом?
Ми працюємо через відкритий програмний інтерфейс касової системи: замовлення зі столу потрапляє в поточну зміну одним чеком, статуси оплати й списання повертаються назад у додаток.
Якщо каса недоступна, операція ставиться в чергу з ключем унікальності — повтор не створює дубль чека. Які саме каси підтримуються і що робити з нестандартною збіркою, фіксуємо на етапі обстеження.
Оновлення ламають роботу в зміну?
Серверна частина викочується на підготовлене середовище з подальшим перемиканням, тому час недоступності вимірюється секундами.
Мобільний додаток спирається на зворотно сумісний контракт: гості зі старими версіями продовжують бронювати, мінімальна підтримувана версія піднімається поступово. Міграції схеми даних ідуть окремим кроком і перевіряються на копії робочої бази.
Хто відповідає за безпеку даних гостей?
Ми мінімізуємо набір: зберігаємо лише те, що потрібно для бронювання та програми лояльності. Передача й зберігання — у зашифрованому вигляді, доступ розмежовано за ролями, дії адміністраторів потрапляють у журнал.
Вивантаження й видалення даних на запит гостя виконуються штатним сценарієм. Після передачі вихідних кодів і схеми даних відповідальність фіксуємо регламентом випуску й підтримки.
Обговоримо задачу й повернемося з оцінкою та планом
Щоб оцінка спиралася на факти, а не на «плюс-мінус», потрібні вхідні дані щодо залу й процесу бронювання.
Збираємо їх на розмові з людиною, яка відповідає за посадку: зазвичай 40–60 хвилин достатньо, щоб побачити обсяг мобільного додатка для ресторану й ризики, які краще закрити до початку робіт.
Що корисно підготувати до обговорення задачі:
- Схема залу: скільки точок, посадок, чи є банкети, депозити, веранда, як зараз розподіляють столи між змінами.
- Канали бронювання: дзвінки, сайт, соцмережі, зовнішні майданчики — що залишається, що переводимо в додаток.
- Ролі та доступи: гість, хостес, менеджер зміни, керуючий — хто що бачить і змінює.
- Облікові системи: каса, склад, програма лояльності, телефонія — чи є відкритий доступ до даних і хто відповідає за інтеграцію.
- Сповіщення: підтвердження гостю, нагадування напередодні, оповіщення зміни про нові бронювання — якими каналами.
- Обмеження: дата, до якої потрібен запуск, вимоги до захисту персональних даних, власні дизайн-макети або працюємо з нашими.
Якщо за частиною пунктів відповіді немає — не страшно, частину уточнимо на місці й запропонуємо рішення. Після розмови фіксуємо склад першої версії та порядок етапів.
Повернемося з оцінкою проєкту за строками та планом робіт, де видно, що робимо на старті й коли функцію можна перевірити на реальних бронюваннях.
