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