Мобільний застосунок для АЗС: де ламається сценарій заправки
Клієнт на заправці рідко порівнює застосунки за набором функцій — він вирішує одне завдання за пару хвилин.
Ламається зазвичай не інтерфейс, а зв'язка між смартфоном, колонкою та бек-офісом: ціна в мобільному застосунку для АЗС одна, на стелі інша, залишок на точці вже нульовий, а застосунок усе ще продає літр. Далі сценарій заправки розсипається, і людина повертається до звичної каси.
Оплата пального зі смартфона — найчутливіша ділянка. Якщо зв'язок на заправці просів, а операція не позначена як повторювана, гроші списуються, команда на відпуск не доходить, і клієнт залишається із замороженою сумою та без пального.
Симетрична помилка — подвійне списання під час повторної спроби, коли застосунок і сервер вважають винним одне одного в таймауті.
Окрема зона — облік залишків за точками, коли дані підтягуються регламентним обміном раз на кілька годин. Оператор вручну править ліміти, знімає блокування й закриває спірні чеки, а черга на касі зростає саме в пік на точці.
Чим більше ручних операцій на шляху клієнта, тим вища ймовірність, що після першої невдалої спроби застосунок просто видалять і більше не повернуться.
Розбираємо, як це закривається: де потрібна локальна логіка на пристрої, де — повторювані операції та звірка з АЗС, а де достатньо чесних статусів замість обіцянок.
Що змінюється на АЗС після запуску сервісу: ефект у метриках
Метрики впровадження мають сенс лише на тлі базової лінії, знятої до запуску. Перед першим релізом фіксуємо на конкретній точці: час від в'їзду до виїзду машини, частку завершених оплат, кількість ручних операцій за зміну, обсяг звернень до підтримки за тиждень.
Далі ті самі заміри повторюються через місяць і через квартал — на тій самій точці й у ті самі години пік.
- Час обслуговування на заправці. Оплата й чек переходять у застосунок, із циклу зникає похід до каси та очікування біля термінала. Цикл скорочується помітно, і це видно не за відчуттями, а за секундоміром на зміні.
- Частка успішних платежів. Збережений спосіб оплати, повтор спроби під час обриву зв'язку й зрозуміла причина відмови замість «оплата не пройшла» — частка завершених операцій зростає, а незавершені біля колонки зникають.
- Навантаження на оператора. Типові сценарії — оплата, чек, бонуси, паливні картки — закриваються в застосунку. Оператор залишається для нештатних ситуацій, і в години пік каса перестає бути вузьким місцем.
- Повторні покупки. Програма лояльності прив'язана до профілю, а не до паперового носія: загублена картка більше не означає втрату клієнта та накопичених літрів.
- Звернення до підтримки. Зникає цілий клас звернень через ручне введення номера колонки, суми та спірних чеків — замість розбору по телефону клієнт бачить історію своїх операцій.
Оплата підтягується через Apple Pay і Google Pay, тому частка успішних оплат — перша метрика, на яку варто дивитися після запуску. Порівнювати її треба із заміром до впровадження: без базової лінії цифри нічого не доводять.
Варіанти збірки: нативна, кросплатформна та вебверсія
На вибір впливають не лише терміни першої версії, а й вартість підтримки двох платформ, швидкість випуску змін і поведінка застосунку під час обриву зв'язку на точці.
В АЗС ці чинники пов'язані: чим більше нативного коду, тим стабільніша робота з обладнанням точки, але тим дорожча кожна зміна.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Нативна збірка під кожну платформу | Оплата, зв'язок з обладнанням точки, фонова робота й передбачувана поведінка без мережі | Дві кодові бази, кожна зміна випускається двічі, підтримка двох платформ потребує профільних інженерів |
| Кросплатформна розробка | Основна частина екранів — інтерфейс і логіка, нативних модулів мало | Частину модулів усе одно пишуть окремо; після великого оновлення платформи потрібна перевірка сумісності |
| Вебверсія без встановлення | Разовий захід: дізнатися ціну, знайти точку, оплатити з чужого телефона | Обмежений доступ до обладнання та фонових задач, залежить від браузера, слабший сценарій без мережі |
Як це впливає на роботу без мережі
Робота без мережі — головний критерій вибору. Застосунок має приймати операції за відсутності зв'язку й передавати їх після його появи, не втрачаючи порядок і не дублюючи нарахування.
Нативна збірка дає передбачуване локальне сховище та чергу, кросплатформна — той самий сценарій за акуратної роботи зі сховищем, вебверсія — лише за рахунок кешу браузера, що на слабких пристроях ненадійно.
На практиці частіше беруть комбінацію: кросплатформна основа для інтерфейсу й лояльності плюс нативні модулі під оплату та обладнання точки. Такий варіант зберігає одну команду на обидві платформи й не ламає офлайн-сценарій. Розбираємо, як це розподіляється у вашому випадку.
Етапи впровадження: від аудиту сценаріїв до передачі команді
Застосунок для АЗС майже не живе окремо від точки: він пов'язаний з паливно-роздавальними колонками, касовим вузлом, процесингом карток і системою лояльності.
Якщо почати збірку раніше, ніж описано сценарій відпуску пального та підтвердження оплати, переробляти доводиться весь контур — від інтерфейсу до обміну з касою. Тому йдемо від розбору інфраструктури до пілоту й передачі.
Як влаштована послідовність
- Аудит інфраструктури та сценаріїв — моделі колонок і контролерів, версії касового ПЗ, якість зв'язку на острівцях, поведінка черги в години пік.
- Схема інтеграцій — протоколи обміну з касою та процесингом, сполучення з лояльністю, оплата карткою, СБП і паливною карткою, правила звірки спірних операцій.
- Збірка та офлайн-режим — критичний шлях, черга операцій під час обриву зв'язку, повторні запити без подвійного списання й коректне відновлення сесії.
- Пілот на одній точці — обмежена група співробітників і водіїв, звірка результату зі звичайною заправкою, перевірка відкату без зупинки АЗС.
- Перевірка під навантаженням — ранкові та вечірні піки, недоступність процесингу, обрив каналу: дивимося, де накопичується черга операцій.
- Критерії приймання — час відпуску пального, частка успішних оплат, кількість звернень до підтримки, поведінка під час відмов.
- Передача в експлуатацію — регламенти оновлень і відкатів, конфігурації, інструкції для зміни, навчання підтримки й чергування на час обкатки.
Що залишається в замовника: код, схеми, регламенти, доступи
Передаємо не «готовий застосунок», а робочу систему разом із документацією: через рік ви зможете змінити підрядника або зібрати внутрішню команду, не відновлюючи логіку за поведінкою екрана. Артефакти фіксуємо в акті передачі — за кожним є власник і місце зберігання.
- Вихідний код і права — репозиторії мобільних клієнтів, серверної частини та адмінпанелі з історією змін; права передаються за договором, без модулів, які може правити лише автор.
- Схеми інтеграцій — обмін з паливними колонками, касовим вузлом, шлюзом оплат і програмою лояльності: послідовність запитів, обробка відмов, повторне надсилання.
- Описи інтерфейсів — точки обміну з полями й кодами відповідей плюс тестовий стенд, де обміни проганяються без реальної заправки.
- Регламент оновлень — порядок випуску версій: збірка, перевірка, публікація в магазинах застосунків, терміни оновлення за зміни зовнішніх сервісів.
- Матриця ролей і доступів — що бачать і змінюють оператор точки, керуючий, бухгалтерія та підтримка; окремо доступи до серверів і панелей.
- Інструкції для персоналу — пам'ятки для операторів АЗС: як провести оплату через застосунок, що робити під час відмови, куди передавати звернення клієнта.
Доступи видаємо на ролі, а не на конкретних людей — у разі звільнення співробітника нічого не доводиться шукати в листуванні. Зовнішні залежності позначаємо окремо: що працює на вашому боці, а що залишається в постачальника обладнання та оплати.
Кейс: як мережа з десяти точок прибрала чергу на касі
Що було до пілоту
Мережа з десяти точок жила як десять окремих бізнесів: своя каса, своя локальна база знижок, свій список постійних клієнтів.
Оператор вручну пов'язував номер колонки із замовленням, а накопичувальну знижку рахував на калькуляторі — у пікові години черга виходила за межі навісу, а помилка в номері колонки оберталася перерахунком і розбором із клієнтом просто біля каси.
Застосунок на старті вмів лише показати найближчу точку. Купити пальне через нього було не можна, тому втримати клієнта всередині мережі вдавалося лише ціною на стелі: щойно сусідня точка знижувала ціну, потік ішов туди.
Пілотне впровадження та метрики
Усі точки звели в один контур: єдиний довідник колонок, видів пального та змін, спільний профіль клієнта й один баланс бонусів, що діє на будь-якій точці мережі.
Клієнт обирає колонку в застосунку, оплачує та запускає відпуск пального сам — оператору залишається підтвердити операцію, а не набирати її вручну.
Пілот поставили на трьох точках, події оплат і запусків збирали в AppMetrica: це показало, на якому кроці клієнт відвалюється — вибір колонки, оплата чи підтвердження.
Середній час обслуговування в пік упав з чотирьох хвилин до сорока секунд у тих, хто платить із застосунку, а частка таких чеків зросла з нуля до третини обороту.
Навантаження на оператора знизилося: ручних операцій за зміну стало приблизно на 40% менше, помилки за номером колонки майже зникли.
Утримання рахували за поверненням на точку мережі протягом місяця — частка тих, хто повернувся, зросла на 18%, і перехід між точками перестав бути втратою: бонуси та історія покупок їдуть із клієнтом.
Що робити, якщо рішення вже впроваджує інший підрядник?
Повна перерозробка потрібна рідше, ніж здається: у застосунку для АЗС цінність несуть не рядки коду, а робочі зв'язки з касовим вузлом, контролерами колонок і офлайн-чергою операцій.
Типових ситуацій входу три — незакритий проєкт, задачі розмазані по кількох підрядниках, супровід без документації. Спершу розділяємо вузли, які можна залишити, і те, що доведеться змінювати.
Аудит наявної збірки відповідає на чотири питання: що відтворюється з вихідників, на яких середовищах збирається, які контракти із зовнішніми системами зафіксовані, де відмова каси залишить клієнта без оплати.
Паралельно відновлюємо документацію — схеми інтеграцій, модель даних, регламент випуску версій, матрицю доступів. Звідси видно, де вистачить доопрацювання без переписування.
| Варіант входу | Коли підходить | Обмеження |
|---|---|---|
| Доопрацювання поверх наявного коду | Код відтворюється, інтеграції живі | Залежність від рішень попередньої команди |
| Поетапна заміна модулів | Частина вузлів без коду або непрацездатна | Довше за термінами, потрібна сумісність версій |
| Повна перерозробка | Немає вихідників і доступу до середовищ | Перенесення історії та лояльності, пауза у випусках |
| Лише супровід | Продукт стабільний, потрібні підтримка й дрібні правки | Зростання функціональності — окремим планом |
Зміна підрядника впирається не в код, а в передачу супроводу: регламент релізів, моніторинг, доступи до середовищ, порядок реакції на інциденти на колонках. Фіксуємо це письмово до старту робіт — тоді перехід не перетворюється на простій. Опишіть, у якій точці проєкт зараз, — повернемося з оцінкою та планом входу.
Технічні сумніви перед стартом: коротко й по суті
Перед стартом спливають ті самі питання — і майже всі вони не про функції, а про те, як застосунок уживеться з уже працюючими системами АЗС. Нижче коротко, а деталі за кожним пунктом розбираємо на етапі оцінки.
Як застосунок зв'яжеться з нашою системою лояльності?
Дивимося, що вже є: обмін даними захищеним каналом, регулярні вивантаження чи ручні звірки. Якщо в системи є точка обміну — підключаємося до неї; якщо ні, проєктуємо обмін як частину робіт. Бали, знижки та рівні клієнта рахуються в одному місці, без подвійного обліку.
Що буде, якщо на АЗС зникне зв'язок?
Застосунок працює в офлайн-режимі: операція записується локально й іде на сервер, коли з'єднання повернулося. Черга зберігає порядок, дублі відсікаються за ідентифікатором операції, тому оплата й нарахування балів не задвоюються.
Чи можна запускати не все одразу?
Так, і зазвичай саме так і робимо. Спершу пілот на одній-двох станціях: базовий сценарій, оплата через застосунок, лояльність. Далі етапами додаємо функції — кожен етап завершується робочою версією, яку можна дати клієнтам, а не «половиною екрана».
Як проходить приймання робіт?
На реальних сценаріях: демонстрація на тестових даних, чек-лист перевірок за кожним сценарієм, окремо — поведінка під час обриву зв'язку й повторних операцій. Після приймання передаємо доступи, документацію та регламенти оновлень.
Що з підтримкою після запуску?
Залишаємося на зв'язку за регламентом: в інцидентів є класи й терміни реакції, оновлення виходять під нові версії операційних систем, а зміни в лояльності чи тарифах вносимо без перезбірки застосунку повністю.
Обговоримо задачу та повернемося з оцінкою й планом робіт
Щоб розмова була предметною, а не перетворювалася на огляд ринку, корисно одразу отримати зріз вашої мережі та поточного ландшафту систем. За ним ми розуміємо, де вузьке місце — у застосунку, в касовому контурі чи в обміні даними між ними, — і що взагалі реально винести на пілот.
- Склад мережі точок: скільки АЗС і модулів, міста й регіони, формати — класична заправка, автоматична, АГЗС, — і чи планується розширення.
- Поточні системи: касове ПЗ, процесинг паливних карток, програма лояльності, складський і бухгалтерський облік, хто їхній вендор і чи є відкриті інтерфейси для обміну.
- Вузькі місця: черги на касі, ручна звірка змін, повторне введення даних, відсутність офлайн-режиму під час падіння зв'язку.
- Минулі спроби впровадження: що робили, на якому етапі зупинилися й чому — це економить нам тижні на ті самі граблі.
- Вимоги до ролей і доступів: клієнт, оператор, керуючий точкою, головний офіс — хто які дії виконує.
- Обмеження: обладнання на точках, вимоги до роботи без мережі, правила зберігання й обробки даних клієнтів.
У відповідь ми надсилаємо план робіт за етапами: аналітика й прототип ключових сценаріїв, інтеграції з поточними системами, пілот на одній-двох точках, розкатка на всю мережу, режим підтримки.
До кожного етапу — склад робіт, що потрібно з вашого боку, та оцінка термінів смугою, а не однією цифрою: видно, де термін залежить від готовності інтерфейсів вендорів.
Опишіть задачу у вільній формі — повернемося з оцінкою та планом.
