Разработка мобильного приложения для АЗС (заправки)

Мобильное приложение для АЗС: где ломается сценарий заправки

Клиент на заправке редко сравнивает приложения по набору функций — он решает одну задачу за пару минут. Ломается обычно не интерфейс, а связка между смартфоном, колонной и бэк-офисом: цена в мобильном приложении для АЗС одна, на стеле другая, остаток на точке уже нулевой, а приложение всё ещё продаёт литр. Дальше сценарий заправки рассыпается, и человек возвращается к привычной кассе.

Оплата топлива со смартфона — самый чувствительный участок. Если связь на заправке просела, а операция не помечена как повторяемая, деньги списываются, команда на отпуск не доходит, и клиент остаётся с замороженной суммой и без топлива. Симметричная ошибка — двойное списание при повторной попытке, когда приложение и сервер считают виноватым друг друга в таймауте.

Отдельная зона — учёт остатков по точкам, когда данные подтягиваются регламентным обменом раз в несколько часов. Оператор вручную правит лимиты, снимает блокировки и закрывает спорные чеки, а очередь на кассе растёт именно в пик на точке. Чем больше ручных операций в пути клиента, тем выше шанс, что после первой неудачной попытки приложение просто удалят и больше не вернутся.

Разбираем, как это закрывается: где нужна локальная логика на устройстве, где — повторяемые операции и сверка с АЗС, а где достаточно честных статусов вместо обещаний.

Что меняется на АЗС после запуска сервиса: эффект в метриках

Метрики внедрения имеют смысл только на фоне базовой линии, снятой до запуска. Перед первым релизом фиксируем на конкретной точке: время от въезда до выезда машины, долю завершённых оплат, число ручных операций за смену, объём обращений в поддержку за неделю. Дальше те же замеры повторяются через месяц и через квартал — на той же точке и в те же часы пик.

• Время обслуживания на заправке. Оплата и чек уходят в приложение, из цикла исчезает поход в кассу и ожидание у терминала. Цикл сокращается заметно, и это видно не по ощущениям, а по секундомеру на смене.
• Доля успешных платежей. Сохранённый способ оплаты, повтор попытки при обрыве связи и понятная причина отказа вместо «оплата не прошла» — доля завершённых операций растёт, а незавершённые у колонки уходят.
• Нагрузка на оператора. Типовые сценарии — оплата, чек, бонусы, топливные карты — закрываются в приложении. Оператор остаётся для нештатных ситуаций, и в часы пик касса перестаёт быть узким местом.
• Повторные покупки. Программа лояльности привязана к профилю, а не к бумажному носителю: потерянная карта больше не означает потерю клиента и накопленных литров.
• Обращения в поддержку. Уходит целый класс обращений из-за ручного ввода номера колонки, суммы и спорных чеков — вместо разбора по телефону клиент видит историю своих операций.

Оплата подтягивается через Apple Pay и Google Pay, поэтому доля успешных оплат — первая метрика, которую стоит смотреть после запуска. Сравнивать её нужно с замером до внедрения: без базовой линии цифры ничего не доказывают.

Варианты сборки: нативная, кроссплатформенная и веб-версия

На выбор влияют не только сроки первой версии, но и стоимость поддержки двух платформ, скорость выпуска изменений и поведение приложения при обрыве связи на точке. У АЗС эти факторы связаны: чем больше нативного кода, тем стабильнее работа с оборудованием точки, но тем дороже каждое изменение.

Как это влияет на работу без сети

Работа без сети — главный критерий выбора. Приложение должно принимать операции при отсутствии связи и передавать их при её появлении, не теряя порядок и не дублируя начисления. Нативная сборка даёт предсказуемое локальное хранилище и очередь, кроссплатформенная — тот же сценарий при аккуратной работе с хранилищем, веб-версия — только за счёт кэша браузера, что на слабых устройствах ненадёжно.

На практике чаще берут комбинацию: кроссплатформенная основа для интерфейса и лояльности плюс нативные модули под оплату и оборудование точки. Такой вариант сохраняет одну команду на обе платформы и не ломает офлайн-сценарий. Разбираем, как это распределяется в вашем случае.

Этапы внедрения: от аудита сценариев до передачи команде

Приложение для АЗС почти не живёт отдельно от точки: оно связано с топливно-раздаточными колонками, кассовым узлом, процессингом карт и системой лояльности. Если начать сборку раньше, чем описан сценарий отпуска топлива и подтверждения оплаты, переделывать приходится весь контур — от интерфейса до обмена с кассой. Поэтому идём от разбора инфраструктуры к пилоту и передаче.

Как устроена последовательность

1. Аудит инфраструктуры и сценариев — модели колонок и контроллеров, версии кассового ПО, качество связи на островках, поведение очереди в часы пик.
2. Схема интеграций — протоколы обмена с кассой и процессингом, сопряжение с лояльностью, оплата картой, СБП и топливной картой, правила сверки спорных операций.
3. Сборка и офлайн-режим — критичный путь, очередь операций при обрыве связи, повторные запросы без двойного списания и корректное восстановление сессии.
4. Пилот на одной точке — ограниченная группа сотрудников и водителей, сверка результата с обычной заправкой, проверка отката без остановки АЗС.
5. Проверка под нагрузкой — утренние и вечерние пики, недоступность процессинга, обрыв канала: смотрим, где копится очередь операций.
6. Критерии приёмки — время отпуска топлива, доля успешных оплат, число обращений в поддержку, поведение при отказах.
7. Передача в эксплуатацию — регламенты обновлений и откатов, конфигурации, инструкции для смены, обучение поддержки и дежурство на время обкатки.

Что остаётся у заказчика: код, схемы, регламенты, доступы

Передаём не «готовое приложение», а работающую систему вместе с документацией: через год вы сможете сменить подрядчика или собрать внутреннюю команду, не восстанавливая логику по поведению экрана. Артефакты фиксируем в акте передачи — по каждому есть владелец и место хранения.

• Исходный код и права — репозитории мобильных клиентов, серверной части и админ-панели с историей изменений; права передаются по договору, без модулей, которые может править только автор.
• Схемы интеграций — обмен с топливными колонками, кассовым узлом, шлюзом оплат и программой лояльности: последовательность запросов, обработка отказов, повторная отправка.
• Описания интерфейсов — точки обмена с полями и кодами ответов плюс тестовый стенд, где обмены прогоняются без реальной заправки.
• Регламент обновлений — порядок выпуска версий: сборка, проверка, публикация в магазинах приложений, сроки обновления при изменении внешних сервисов.
• Матрица ролей и доступов — что видят и меняют оператор точки, управляющий, бухгалтерия и поддержка; отдельно доступы к серверам и панелям.
• Инструкции для персонала — памятки для операторов АЗС: как провести оплату через приложение, что делать при отказе, куда передавать обращение клиента.

Доступы выдаём на роли, а не на конкретных людей — при уходе сотрудника ничего не приходится искать по переписке. Внешние зависимости помечаем отдельно: что работает на вашей стороне, а что остаётся у поставщика оборудования и оплаты.

Кейс: как сеть из десяти точек убрала очередь на кассе

Что было до пилота

Сеть из десяти точек жила как десять отдельных бизнесов: своя касса, своя локальная база скидок, свой список постоянных клиентов. Оператор вручную связывал номер колонки с заказом, а накопительную скидку считал на калькуляторе — в пиковые часы очередь выходила за пределы навеса, а ошибка в номере колонки превращалась в пересчёт и разбор с клиентом прямо у кассы.

Приложение на старте умело только показать ближайшую точку. Купить топливо через него было нельзя, поэтому удержать клиента внутри сети получалось только ценой на стеле: как только соседняя точка опускала цену, поток уходил туда.

Пилотное внедрение и метрики

Все точки свели в один контур: единый справочник колонок, видов топлива и смен, общий профиль клиента и один баланс бонусов, действующий на любой точке сети. Клиент выбирает колонку в приложении, оплачивает и запускает отпуск топлива сам — оператору остаётся подтвердить операцию, а не набирать её вручную.

Пилот поставили на трёх точках, события оплат и запусков собирали в AppMetrica: это показало, на каком шаге клиент отваливается — выбор колонки, оплата или подтверждение. Среднее время обслуживания в пик упало с четырёх минут до сорока секунд у тех, кто платит из приложения, а доля таких чеков выросла с нуля до трети оборота.

Нагрузка на оператора снизилась: ручных операций за смену стало примерно на 40% меньше, ошибки по номеру колонки почти исчезли. Удержание считали по возврату на точку сети в течение месяца — доля вернувшихся выросла на 18%, и переход между точками перестал быть потерей: бонусы и история покупок едут с клиентом.

Что делать, если решение уже внедряет другой подрядчик?

Полная переразработка нужна реже, чем кажется: в приложении для АЗС ценность несут не строки кода, а рабочие связки с кассовым узлом, контроллерами колонок и офлайн-очередью операций. Типовых ситуаций входа три — незакрытый проект, задачи размазаны по нескольким подрядчикам, сопровождение без документации. Сначала разделяем узлы, которые можно оставить, и то, что придётся менять.

Аудит существующей сборки отвечает на четыре вопроса: что воспроизводится из исходников, на каких окружениях собирается, какие контракты с внешними системами зафиксированы, где отказ кассы оставит клиента без оплаты. Параллельно восстанавливаем документацию — схемы интеграций, модель данных, регламент выпуска версий, матрицу доступов. Отсюда видно, где хватит доработки без переписывания.

Смена подрядчика упирается не в код, а в передачу сопровождения: регламент релизов, мониторинг, доступы к средам, порядок реакции на инциденты на колонках. Фиксируем это письменно до старта работ — тогда переход не превращается в простой. Опишите, в какой точке проект сейчас, — вернёмся с оценкой и планом входа.

Технические сомнения перед стартом: коротко и по делу

Перед стартом всплывают одни и те же вопросы — и почти все они не про функции, а про то, как приложение уживётся с уже работающими системами АЗС. Ниже коротко, а детали по каждому пункту разбираем на этапе оценки.

Что будет, если на АЗС пропадёт связь?

Приложение работает в офлайн-режиме: операция записывается локально и уходит на сервер, когда соединение вернулось. Очередь сохраняет порядок, дубли отсекаются по идентификатору операции, поэтому оплата и начисление баллов не задваиваются.

Можно ли запускать не всё сразу?

Да, и обычно так и делаем. Сначала пилот на одной-двух станциях: базовый сценарий, оплата через приложение, лояльность. Дальше этапами добавляем функции — каждый этап заканчивается рабочей версией, которую можно дать клиентам, а не «половиной экрана».

Как проходит приёмка работ?

На реальных сценариях: демонстрация на тестовых данных, чек-лист проверок по каждому сценарию, отдельно — поведение при обрыве связи и повторных операциях. После приёмки передаём доступы, документацию и регламенты обновлений.

Что с поддержкой после запуска?

Остаёмся на связи по регламенту: у инцидентов есть классы и сроки реакции, обновления выходят под новые версии операционных систем, а изменения в лояльности или тарифах вносим без пересборки приложения целиком.

Обсудим задачу и вернёмся с оценкой и планом работ

Чтобы разговор был предметным, а не превращался в обзор рынка, полезно сразу получить срез вашей сети и текущего ландшафта систем. По нему мы понимаем, где узкое место — в приложении, в кассовом контуре или в обмене данными между ними, — и что вообще реально вынести на пилот.

• Состав сети точек: сколько АЗС и модулей, города и регионы, форматы — классическая заправка, автоматическая, АГЗС, — и планируется ли расширение.
• Текущие системы: кассовое ПО, процессинг топливных карт, программа лояльности, складской и бухгалтерский учёт, кто их вендор и есть ли открытые интерфейсы для обмена.
• Узкие места: очереди на кассе, ручная сверка смен, повторный ввод данных, отсутствие офлайн-режима при падении связи.
• Прошлые попытки внедрения: что делали, на каком этапе остановились и почему — это экономит нам недели на те же грабли.
• Требования к ролям и доступам: клиент, оператор, управляющий точкой, головной офис — кто какие действия выполняет.
• Ограничения: оборудование на точках, требования к работе без сети, правила хранения и обработки данных клиентов.

В ответ мы присылаем план работ по этапам: аналитика и прототип ключевых сценариев, интеграции с текущими системами, пилот на одной-двух точках, раскатка на всю сеть, режим поддержки. К каждому этапу — состав работ, что нужно с вашей стороны и оценка сроков полосой, а не одной цифрой: видно, где срок зависит от готовности интерфейсов вендоров.

Опишите задачу в свободной форме — вернёмся с оценкой и планом.