Чому мобільний застосунок пекарні гальмує на піку замовлень
Ранок у кондитерській — це 40-60 хвилин, у які надходить основна частина замовлень на день: корпоративні набори, торти на самовивіз, передзамовлення до відкриття.
Приймання замовлень на піку перетворюється на перевірку на міцність: застосунок, який удень відповідає за 300 мс, у це вікно починає втрачати сесії й показувати порожні кошики.
Найдорожчий збій — обрив оформлення замовлення на кроці оплати. Кошик живе в пам'яті екрана, і перехід у платіжний застосунок або короткий розрив мережі обнуляє його: клієнт повертається до порожнього екрана і або йде, або збирає замовлення заново.
Так з'являються дублі замовлень — кондитерська пече два торти замість одного, а оператор вручну шукає збіги за ім'ям і телефоном.
Окрема історія — навантаження ранкових годин на облік точки.
Якщо створення замовлення йде синхронним запитом у систему, яку бачить оператор, то при затримці її відповіді накопичуються незавершені транзакції: інтерфейс перестає реагувати, частина замовлень «зависає» в проміжному статусі.
Далі замовлення приймають телефоном і переносять в облік руками — із запізненнями та втраченими позиціями.
Розбираємо, як це закривається: де зберігати стан кошика, щоб він переживав розрив, як захиститися від повторного надсилання і що робити з чергою замовлень у ранковий пік.
Ефект від запуску: швидкість замовлення та повторні покупки
Ефект від застосунку вимірюється не кількістю встановлень, а тим, скільки замовлень проходить без дзвінка в точку і скільки гостей повертається.
Тому базові показники — час оформлення замовлення, частку повторних покупок, кількість звернень до продавця — ми знімаємо до запуску і порівнюємо з ними перші місяці роботи.
Оформлення: хвилини замість дзвінка
У застосунку гість бачить актуальний склад вітрини, обирає самовивіз або доставку й оплачує в один крок, тому час оформлення замовлення падає з кількох хвилин розмови до пари екранів. Адреса та склад замовлення залишаються в профілі — повторне замовлення збирається у два дотики.
Окремим сценарієм іде передзамовлення торта: конструктор начинки, коржів і декору з вибором дати та підказкою, за який час точку потрібно попередити.
Повторні покупки та розвантаження персоналу
Бали за замовлення й нагадування в ту годину, коли гість зазвичай бере каву або випічку, підвищують частку повторних покупок: розсилка йде із застосунку, а не силами продавців.
Навантаження на персонал точки падає — замовлення надходить на окремий екран, готовність позначається одним дотиком, оплата пройшла онлайн, і касиру не потрібно приймати замовлення телефоном і вбивати його вручну. Середній чек самовивозу зростає завдяки допродажу пари до випічки в один клік.
Публікація в Google Play і на другій платформі плюс аналітика воронки показують, на якому кроці гості відвалюються. Через кілька тижнів видно, які нагадування повертають гостей і який час самовивозу обирають частіше.
Формати розробки: єдина база, дві нативні збірки, шаблон
Пекарні потрібні обидві платформи: частина гостей замовляє на одній, частина — на другій, а передзамовлення й карта лояльності мають працювати однаково.
Різниця між варіантами не в тому, що бачить гість, а в обсязі коду, який команда веде після релізу, і в строках випуску застосунку.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Єдина кодова база | Каталог, передзамовлення, лояльність, повідомлення — інтерфейс однаковий на обох платформах | Важка графіка й системні жести просідають; потрібен інженер, який знає обидві платформи |
| Дві нативні збірки | Потрібні камера, оплата й повідомлення на межі можливостей системи | Подвійний обсяг робіт: дві черги правок, довші строки випуску застосунку |
| Готовий шаблон застосунку | Одна точка, короткий сезон, потрібен швидкий запуск замовлень | Обмежена логіка: власні сценарії лояльності та зв'язка з обліковою системою добудовуються окремо |
Якщо бізнес прив'язаний до сезону
Готовий шаблон застосунку закриває запуск за лічені тижні: вітрина, кошик і повідомлення вже є, змінюються оформлення та склад товарів.
Але власні механіки — набори до свята, передзамовлення торта, накопичувальні рівні — закладають до старту сезону: дописувати логіку в розпал попиту ризиковано.
Якщо точок кілька
Мережа виграє від єдиної кодової бази: одна логіка лояльності, один кабінет адміністратора, підтримка двох платформ силами однієї команди.
Нативну збірку під платформу беруть, коли потрібно вичавити з пристрою максимум — наприклад, стійку оплату на слабкому зв'язку в залі або миттєве фотографування чека.
Як проходить впровадження: від розбору точки до передачі збірки
Впровадження починається не з макетів, а з розбору точки: як приймають замовлення зараз, де накопичується черга в ранковий пік, хто закриває зміну і за яким папером звіряють виручку.
Із цього виростає схема даних замовлення — оплата — видача: саме вона визначає, що бачить гість і що потрапляє у звіт точки.
Робота йде етапами, кожен закінчується перевірюваним результатом:
- Розбір процесів точки: шлях замовлення від вітрини й передзамовлення до самовивозу, ролі співробітників, вузькі місця в годину пік.
- Схема замовлення — оплата — видача: статуси замовлення, способи оплати, прив'язка до зміни й точки, щоб звіти сходилися без ручного звіряння.
- Етапи розробки застосунку: каркас із каталогом і кошиком, потім особистий кабінет, повтор замовлення й повідомлення про готовність.
- Тестування на реальних замовленнях: кілька змін із справжніми гостями, включно зі скасуваннями, доплатами й позиціями, яких немає в наявності.
- Випуск оновлення: публікація збірки, порядок викочування виправлень і канал, куди надходять повідомлення про помилки.
- Передача й навчання персоналу точки: пам'ятки для каси й збирача, розбір спірних сценаріїв зміни.
Перевірка перед випуском
Тестуємо не за списком кнопок, а за потоком замовлень — повний день роботи точки на закритій групі гостей, із поверненнями й замовленнями на завтра. Позиція, яка закінчилася до вечора, має чесно зникати з каталогу, а вже оплачене замовлення — не ламати зміну.
Навчання персоналу точки
Зміна освоює застосунок за один розбір: де підтвердити готовність, як провести видачу за номером і що робити при розходженні оплати. Пам'ятка залишається на точці, а ми супроводжуємо перші дні роботи, поки потік замовлень не стане рівним.
Що ви отримуєте на руки: збірки, схеми, доступи, регламенти
Проєкт закривається не показом на дзвінку, а передачею працюючого контуру. Усе потрібне для експлуатації фіксуємо в акті — замовник перевіряє кожен артефакт і може запустити застосунок або доопрацювати його своєю командою.
- Збірки для магазинів застосунків — підписані та готові до вивантаження, плюс окрема збірка для тестування на телефонах співробітників.
- Передача вихідних кодів: повний репозиторій з історією змін, доступи оформлюємо на акаунт замовника, а не на наш.
- Документація застосунку: екрани й сценарії замовлення, структура даних, сторонні бібліотеки та їхні ліцензії.
- Політика доступу співробітників: ролі касира, пекаря, керуючого й власника з різними правами на замовлення, залишки та знижки.
- Регламент оновлень і порядок ескалації: до кого йде звернення при збої і в який строк чекати відповіді.
Карта інтеграцій
- Схема обміну з обліковою системою: які події — нове замовлення, списання, залишки — у який бік ідуть і як часто синхронізуються.
- Поведінка при обриві зв'язку: замовлення не губиться, йде в чергу й досилається, а гість бачить зрозумілий статус замість помилки.
Регламент випуску версій
- Календар: планові оновлення та позапланові правки, хто дає добро на викладку.
- Список сценаріїв, які зобов'язані пройти на тестовому контурі перед випуском.
- Відкат на попередню версію, якщо оновлення спіймало проблему в робочій збірці.
Кейс: мережа кондитерських прискорила приймання замовлень удвічі
Мережа кондитерських із дванадцятьма точками приймала передзамовлення телефоном і в переписці: оператор вручну переносив склад кошика в облікову систему.
У ранковий пік і перед святами оформлення займало до чотирьох хвилин, на касі зростала черга, а частина замовлень губилася в чатах. Частка скасувань з вини точки сягала 12%, і майже кожен третій гість телефонував уточнити, чи готове замовлення.
Ми зробили застосунок із передзамовленням до конкретного інтервалу видачі: покупець обирає точку, час і склад кошика, оплачує й отримує повідомлення про готовність.
Замовлення потрапляє одразу в чергу робочого місця касира, тому повторне введення руками зникло, а статус видно і гостю, і співробітнику. Обмін з обліковою системою 1С тримає залишки по вітрині й не дає оформити те, що точка не встигне зібрати.
Через три місяці: оформлення скоротилося з чотирьох хвилин до сорока секунд, частка скасувань — з 12% до 2,5%, звернення до підтримки точки впали втричі, дзвінки «чи готове замовлення» практично припинилися.
Однієї зміни касира стало достатньо на ранковий пік, без підмінного оператора. Повторні передзамовлення зросли до 34% — гості повертаються за тим самим тортом у той самий інтервал.
Що зробили інакше на другому етапі
Перша версія віддавала замовлення в загальну чергу, і кухня в пік отримувала десятки позицій одразу — скасування повернулися. На другому етапі ми обмежили кількість замовлень на точку за годину, ввели шаблони частих збірок і строк автоматичного підтвердження.
Якщо точка не підтверджує замовлення вчасно, інтервал закривається, а гість одразу бачить альтернативний час.
Чим відрізняється єдина кодова база від двох нативних застосунків?
Єдина кодова база — це один вихідний код, з якого збираються дві збірки застосунків під iOS і Android; нативний варіант — два незалежні проєкти різними мовами. На старті різниця майже непомітна: обидві схеми дають робочий продукт.
Вона проявляється в експлуатації, коли починаються регулярні оновлення, розбір падінь і виходи нових версій операційних систем.
Швидкість випуску оновлень визначається кількістю релізних контурів. Правка сценарію замовлення в єдиній базі проходить один цикл перевірки і в один випуск іде на обидві платформи.
У випадку з двома нативними збірками ту саму правку роблять двічі, тестують двічі й випускають за окремим графіком: поки друга платформа чекає випуску, користувачі бачать різну поведінку застосунку й надсилають різні звернення до підтримки.
Доступ до функцій пристрою — зворотний бік цього компромісу. Камера, повідомлення, оплата, геолокація, біометрія та сканування штрихкодів закриваються спільним шаром майже без втрат.
Складніше з фоновою роботою, зовнішніми сканерами й датчиками, віджетами на домашньому екрані, оплатою через вбудований чип: під кожну платформу пишеться нативний модуль, а інтерфейс до нього веде спільний код.
Тому правильне питання не «чи можна це зробити», а яка частка користувацьких сценаріїв лежить за межами спільного шару.
Вартість підтримки двох гілок зростає нелінійно: дві черги оновлень, подвійний прогін регресії на парку пристроїв, окремі виправлення під правила кожного магазину застосунків.
Єдина база тримає одну чергу робіт, але концентрує ризик — збій у спільному модулі йде одразу на обидві платформи. Звідси обов'язкові автотести на критичні шляхи й поетапне розкочування випуску.
Практичний критерій вибору простий. Якщо ядро продукту — вітрина, замовлення й програма лояльності, виграє єдина кодова база: оновлення виходять частіше, а підтримка не двоїться.
Якщо цінність у рідкісному обладнанні та глибокій роботі з периферією, частина логіки все одно залишається нативною, і виходить гібрид зі спільним шаром на бізнес-логіку.
Ми рахуємо частку коду, яка реально перевикористовується в обох застосунках, і за цією цифрою пропонуємо схему.
Інтеграції та оплата: що уточнюють до старту розробки
До оцінки фіксуємо чотири технічні вузли: з якою обліковою системою стикується застосунок, якими способами приймаємо оплату, як рахуються бали й штампи, і що відбувається із замовленням між самовивозом і доставкою кур'єром. Поки ці точки не описані, кошторис залишається діапазоном, а не планом робіт.
Перевіряємо не за документацією, а на стенді: копія меню й складу, тестові замовлення, прогін скасувань і повернень. Так видно, які розходження вилізуть у перший місяць роботи точки, — їх дешевше закрити до релізу, ніж після запуску.
Застосунок бачитиме залишки в реальному часі?
Якщо облікова система віддає дані через програмний інтерфейс, вітрина оновлюється із затримкою в кілька хвилин — цього достатньо, щоб не продавати продане.
При обміні вивантаженнями синхронізацію робимо частіше, а позиції з нульовим залишком за правилом переводимо в «під замовлення» або ховаємо з меню конкретної точки.
Які способи оплати реально підключити?
Онлайн-оплата карткою та за QR-кодом, оплата при отриманні, списання балів і подарункових сертифікатів. Повернення за скасованим замовленням проходить тим самим шляхом, що й платіж, — це закладаємо в логіку статусів одразу, інакше скасування доведеться закривати вручну в касі.
Де зберігається програма лояльності?
Бали й штампи надійніше тримати в обліковій системі точки, а не всередині застосунку: тоді каса й вітрина бачать один баланс, а iiko і подібні рішення залишаються єдиним джерелом правди.
Якщо облік ведеться в таблицях, виносимо лояльність в окремий сервіс із журналом операцій і захистом від подвійного списання.
Обговоримо задачу: що надіслати для оцінки та плану
Щоб оцінка розробки застосунку була предметною, а не «вилкою від і до», нам потрібні ввідні щодо процесів пекарні. Ми не просимо готувати технічне завдання — достатньо описати, як замовлення живуть зараз, і вказати, що з цього має перейти в застосунок. За цими даними збираємо план робіт з етапами, строками та складом робіт.
- Опис точки та точок продажів: формат (пекарня з посадкою, вітрина, острівець), години роботи, середня кількість замовлень за зміну, самовивіз і доставка — від цього залежить логіка слотів і завантаження кухні.
- Поточні канали замовлень: телефон, месенджери, соцмережі, агрегатори. Важливо зрозуміти, де який обсяг і де губляться замовлення — у пікові години, при підтвердженні чи на оплаті.
- Облікова система: каса, склад, рецептури, програма лояльності. Потрібно знати, чи є вивантаження меню й залишків і чи можна віддавати статуси замовлення назад в облік.
- Меню та приклади позицій: категорії, склад, алергени, варіанти розмірів і пакування, сезонні та передзамовні позиції.
- Ролі співробітників: хто приймає замовлення, хто збирає, хто підтверджує готовність і змінює статус — так проєктуємо права доступу й повідомлення.
- Програма лояльності: бали, купони, знижки за днями, персональні пропозиції. Визначає, що переносимо з поточних механік.
- Обмеження та орієнтири: строки запуску, бажаний склад першої черги, приклади застосунків, які подобаються або не подобаються.
Опишіть задачу у вільній формі — цього вистачить, щоб повернутися з оцінкою та планом робіт.
