Пятёрочки
Мобильное приложение
для торговых представителей
компании Ascott Group
Как мы разработали удобный сервис для менеджеров, которые ходят
по магазинам-распространителям
Мобильное приложение
для торговых представителей
компании Ascott Group
Как мы разработали удобный сервис для менеджеров, которые ходят по магазинам-распространителям
Заказчик приложения — компания Ascott.

Компания производит отделочные материалы, а продают их разные магазины-распространители, например «Леруа Мерлен» или OBI.


Компания поставляет товары в 2600 магазинов — это показатель начала 2022 года. Поддерживать сотрудничество с этими магазинами — задача менеджеров, торговых представителей. Для них нужно было сделать удобное мобильное приложение.

В компании уже были сервисы для работы менеджеров. Сначала разработчики Ascott написали собственный веб-сервис. После этого купили коробочное 1С-приложение у других разработчиков, но его возможности и уровень поддержки заказчика не устроили.

Основные требования к будущему приложению

  • Главная задача
    Главная задача приложения — помочь заказчику своевременно понимать меняющуюся ситуацию на рынке и реагировать на нее. Компании нужно оперативно узнавать о новых конкурентах, продуктах, акциях, принимать ответные шаги
  • Офлайн-режим
    Многие магазины подобной продукции находятся в подвальных помещениях, и там нет доступа к сети. Поэтому сервис должен работать в офлайн-режиме, а потом загружать данные на сервер
  • Простота в использовании
    Новый сервис должен был быть максимально понятным и комфортным, чтобы не тратить время на обучение сотрудников
  • Контроль ввода
    Чтобы менеджер не мог ввести некорректные данные
  • Скорость использования
    Чтобы повысить скорость работы, количество кликов для основных сценариев нужно максимально снизить
Этап 1: MVP
Аналитика
Мы начали работу, сделали предварительный анализ работ и подготовили предложение UX-дизайна.

Посмотрели карту экранов в коробочном приложении 1С, выделили все минусы, которые не устраивали заказчика, выяснили, какие экраны необходимо добавить. Сначала мы показали наше предложение на упрощенных схемах, а потом отдали их в дизайн и подготовили кликабельный прототип.
Утвердив финальный состав работ для MVP, в декабре 2018 года мы начали разработку. Бэкенд делала сторона заказчика, а мы со своей стороны предлагали наиболее подходящие решения для мобильного приложения
Основная идея приложения
Пользователь приложения — торговый представитель компании Ascott. Его задача — ходить по магазинам-распространителям, общаться с менеджерами, предлагать свои товары. У нас уже был опыт создания таких приложений: похожее мы сделали для группы компаний ПИК.

Первую MVP-версию подготовили за 3 месяца. Ниже рассказываем возможности приложения на этом этапе.
Визит

Процесс, когда представитель приходит на торговую точку, проверяет количество товара, делает заказ.

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

Если заказчик еще не сотрудничает с магазином, торговый представитель проводит презентацию и предлагает Ascott в качестве поставщика.

Процесс, когда представитель приходит на торговую точку, проверяет количество товара, делает заказ.

Визиты — ключевая функция мобильного приложения. Они могут быть плановыми и внеплановыми. Если визиты плановые, сотрудник видит их в расписании: например, сегодня нужно сделать 2 визита. Если внеплановые, в расписании они не появляются.
Визит собирается динамически из разных видов шагов, которые присылаются с сервера. Их порядок может меняться.
Если заказчик еще не сотрудничает с магазином, торговый представитель проводит презентацию и предлагает Ascott в качестве поставщика. Если торговая точка уже является клиентом, состав работ для визита определяется на сервере и приходит в приложение в виде разных вариантов:
  • экран стартовой информации (где можно выбрать укороченный визит)
  • анкета
  • финансовая информация
  • задачи
  • заказ
Визит

Если торговая точка уже является клиентом, состав работ для визита определяется на сервере и приходит в приложение в виде разных вариантов:
  • экран стартовой информации (где можно выбрать укороченный визит)
  • анкета
  • финансовая информация
  • задачи
  • заказ
Экран стартовой информации

Здесь пользователь может выбрать, какой визит ему нужно оформить: полный или укороченный.

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

Укороченный визит — отдельный шаг: доставка, оплата или звонок.

Еще на стартовом экране показана лента активностей: это все процессы, которые в настоящее время происходят у сотрудника.


Здесь пользователь может выбрать, какой визит ему нужно оформить: полный или укороченный.

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

Еще на стартовом экране показана лента активностей: это все процессы, которые в настоящее время происходят у сотрудника.
Экран стартовой информации
Анкета
Анкета собирается на сервере для каждого клиента отдельно. Обычно при работе сотрудник сверяется с ней и выполняет поставленные задачи. Например, он может отвечать на вопросы такого рода:
«Где расположена торговая точка? Какова площадь торгового зала? Сколько продавцов в магазине? Сколько клиентов во время визита?»

Все варианты вопросов представлены ниже:
Фэйсинг

Возможность распознавания объектов на фотографии. Это позволяет реагировать на выставленные продукты в магазине.

Фотография отправляется на сервер, и бэкенд распознает нужную продукцию и ее количество, например: 40% — наша продукция, 60% — конкуренты.

Возможность распознавания объектов на фотографии. Это позволяет реагировать на выставленные продукты в магазине.

Фотография отправляется на сервер, и бэкенд распознает нужную продукцию и ее количество, например: 40% — наша продукция, 60% — конкуренты.
Фэйсинг
Финансовая информация

Этот шаг нужен, чтобы менеджеры заполняли сумму погашения долга в конкретном магазине. Экран состоит из html-страницы и полей для заполнения.


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

Задачи могут быть отдельными и внутри визита — в рамках одного из шагов. Также можно открыть карточку клиента и увидеть задачи внутри нее:
Заказ
Стандартное окончание визита — заказ новых товаров. Сотрудник выбирает договор, нужные позиции, дату доставки, контактное лицо, комментарии.

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

Приложение хранит список клиентов с контактной информацией.

Это, например, сетевые магазины в разных торговых центрах. Разные торговые центры — следовательно, разные клиенты.


Приложение хранит список клиентов с контактной информацией.

Это, например, сетевые магазины в разных торговых центрах. Разные торговые центры — следовательно, разные клиенты.
Клиенты
Максим Овчинников
Android-разработчик KTS
Технический раздел #1:
Синхронизация

Приложение нуждалось в сложной синхронизации: 18 типов сущностей,
9 из них могут как загружаться с сервера, так и отправляться на него. Всего 27 этапов синхронизации.

Этот процесс занимал много времени, поэтому мы вынесли его в отдельный экран: во время синхронизации телефон блокировался и пользователь видел только уровень прогресса загрузки.
Технический раздел #1:
Синхронизация

Приложение нуждалось в сложной синхронизации: 18 типов сущностей,
9 из них могут как загружаться с сервера, так и отправляться на него. Всего 27 этапов синхронизации.

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

Максим Овчинников
Android-разработчик KTS
По аналогии с приложением для строительной компании ПИК мы сделали ручную синхронизацию. Она хорошо ложится на режим работы сотрудника. Утром он приходит в офис и вручную синхронизирует данные. Затем в течение дня без доступа к сети работает на основе загруженных данных. Вечером возвращается в офис и снова синхронизируется.


Технический раздел #2:
Персистентное хранение заполняемых данных

Это свойство приложения, которое обеспечивает большую надежность данных.

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

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

Этап 2: Развитие
На 2-м этапе мы развили приложение, исправляли ошибки после первых тестирований пользователями, добавили новые функции:

  • рассчет эффективности менедежера KPI
  • активности — все текущие процессы
  • отслеживание контактов с клиентами
  • добавление потенциального клиента
  • события компании
  • установка геопопозиции
KPI

Это процентное отображение эффективности сотрудника.

Сотрудник ездит по магазинам, совершает визиты, выполняет задачи — у него рассчитывается KPI.

Это процентное отображение эффективности сотрудника. Сотрудник ездит по магазинам, совершает визиты, выполняет задачи — у него рассчитывается KPI.
KPI
Активности

Все рабочие процессы, которые проходят с клиентом.

Например, проведенный визит или сделанный заказ. Бэкенд автоматически добавляет все эти процессы в список активностей.


Все рабочие процессы, которые проходят с клиентом.

Например, проведенный визит или сделанный заказ. Бэкенд автоматически добавляет все эти процессы в список активностей.
Активности
Отслеживание коммуникаций с клиентами

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

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

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

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

При клике на кнопку «указать местоположение» открывается экран, где пользователь ставит точку.

При клике на кнопку «указать местоположение» открывается экран, где пользователь ставит точку.
Геопозиция
Синхронизация

Процесс синхронизации оптимизировали.

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

Блокировка на время синхронизации важна для двух вещей:
  • Чтобы сотрудник точно скачал все данные. Так он может совершать заказы и визиты в офлайн-режиме. Это важно, потому что есть магазины без связи, например подвалы.
  • Чтобы сотрудник не мог менять данные во время синхронизации — иначе может возникнуть несогласованность, которая приведет к ошибкам в работе

Процесс синхронизации оптимизировали.

Теперь пользователь видел, какая именно часть данных синхронизируется — визиты, клиенты и т.д. — и процентный прогресс завершения синхронизации.
Синхронизация
Блокировка на время синхронизации важна для двух вещей:
  • Чтобы сотрудник точно скачал все данные. Так он может совершать заказы и визиты в офлайн-режиме. Это важно, потому что есть магазины без связи, например подвалы.
  • Чтобы сотрудник не мог менять данные во время синхронизации — иначе может возникнуть несогласованность, которая приведет к ошибкам в работ
Этап 3: Поддержка
Итак, приложение готово.

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

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

    Время реакции — 8 часов

    Время начала устранения — по предварительному согласованию

  • Средний
    • Частичная неработоспособность заказов и визитов менее чем у 3 пользователей
    • Неработоспособность остальных разделов менее чем у 3 пользователей
    • Полная неработоспособность менее чем у 3 пользователей

    Время реакции — 4 часа

    Время начала устранения — 8-24 часов

  • Аварийный
    • Полная неработоспособность заказов и визитов более чем у 3 пользователей
    • Крэши приложения на старте и в заказах и визитах, связанные с его некорректной работой


    Время реакции — 1 час

    Время начала устранения — 1-8 часов


    

Максим Овчинников
Android-разработчик KTS
Технический раздел #3:
Проблема камеры

Процесс съемки выглядит так: пользователь запускает системную камеру телефона, наводит ее на полки, делает снимок.

В это время системные оптимизаторы на телефонах типа Xiaomi или Huawei закрывают приложение, потому что оно находится в фоне. Поэтому после съемки приложение фактически запускалось заново. Из-за этого фото в приложение не доходило: во время его создания сервис не работал, т.е. нужный кадр просто терялся.
Технический раздел #3:
Проблема камеры

Процесс съемки выглядит так: пользователь запускает системную камеру телефона, наводит ее на полки, делает снимок.

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

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

Раньше в наших приложениях всегда использовалась системная камера, поэтому собственную писали с нуля. Работала она так:
  • посылался запрос на открытие приложения «Камера» с расположением, куда сохранять фото
  • после съемки в приложение возвращался ответ: «Ок» или «Отмена (выход без фото)»
Теперь, если мы решим переписать системную камеру на внутреннюю в уже готовых приложениях, сделать это будет очень просто, потому что камера вынесена в библиотеку.

При написании библиотеки камеры использовалась библиотека от Google, CameraX. Подключить и использовать ее было достаточно просто: на Github имеется набор официальных семплов по работе.

Но кое-что все же пришлось придумывать самим, потому что на Github есть не все: режим вспышки, зум и предпросмотр фото. Конечно, не обошлось и без других задач. Например, сделанное фото иногда не переворачивалось при горизонтальной съемке.


Технический раздел #4:
Проблема геопозиции

Иногда в анкете встречался пункт «поставить геопозицию». Это требовалось для первичного занесения в базу данных, или если магазин куда-то переехал. На 2-м этапе мы разработали карту-пикер, где можно было выбрать геопозицию.

В какой-то момент местоположение перестало определяться.



Выяснилось, что с GPS было две проблемы:
  • Во-первых, пользователь может дать одноразовое разрешение приложению на определение геопозиции и перезапустить приложение. Начиная с 11-й версии Android, разрешение будет отозвано через определенный промежуток времени
  • Во-вторых, обновленная локация подгружалась с видимой задержкой

Для решения мы просто сменили механику: текущая локация обновлялась при клике на кнопку «мое местоположение» и открытии экрана.
РЕЗУЛЬТАТ
Оперативное видение рынка
Сейчас вся информация из магазинов сразу попадает в приложение. Руководство видит ситуацию на рынке в настоящем времени и принимает целесообразные решения
Удобство
Во время создания мы консультировались с командой Ascott, и приложение получилось интуитивно понятным для их менеджеров. Заказчик до сих пор не записал ни одного видеоурока
Работа оффлайн
Приложение работает независимо от наличия сети. Главное — синхронизировать данные в начале и конце рабочего дня
Надежность
Мы со своей стороны ведем поддержку приложения и своевременно устраняем все возникающие ошибки
Заказать разработку мобильного приложения
Не хотите писать? Позвоните нашему менеджеру по телефону +7 926 735-45-32 и расскажите про ваш проект






















Иконки от Tilda Publishing, ссылка — https://tilda.cc