Ascott Group — компания, которая производит отделочные материалы: например, обойный клей KLEO и декоративные наклейки на мебель и стены Decoretto. Товары продаются как в крупных торговых сетях вроде Леруа Мерлен и OBI, так и в небольших строительных магазинах. Всего торговых точек у компании сейчас около 2 500, и для работы с каждой из них Ascott нужны торговые представители.
Задача представителей — проверять, как продаются товары Ascott в конкретном магазине: хватает ли продукции, насколько удачно она выставлена в торговом зале, какие конкуренты представлены на соседних полках. Информация, полученная от торговых представителей, помогает Ascott принимать бизнес-решения более грамотно: увеличивать или уменьшать производство, корректировать цены, придумывать новые акции.
Собирать информацию от всех торговых представителей удобно в одном сервисе. До прихода к нам менеджеры в Ascott уже пользовались коробочным решением, однако его возможностей не хватало, а доработка вышла бы дороже создания приложения с нуля.
Нужно было разработать приложение, которое поможет Ascott своевременно получать информацию от торговых представителей и принимать оперативные бизнес-решения. Нужно было учесть:
Мы начали работу с аналитики: посмотрели карту экранов в коробочном приложении, выделили все его минусы и выяснили, какие экраны необходимо добавить в новое приложение. MVP подготовили за три месяца. Ключевая его функция — фиксация визитов. Это посещение магазинов торговыми представителями.
Визиты могут быть плановыми и внеплановыми. Состав работ определяется на сервере и приходит пользователю на экран стартовой информации. На нём торговый представитель выбирает тип визита: полный или укороченный, если нужно сделать только часть работ.
Визит собирается динамически из разных видов шагов, которые присылаются с сервера, их порядок может меняться:
Анкета — это информация о магазине, в котором продаётся продукция Ascott: где расположена торговая точка, какова площадь торгового зала, сколько в нём работает консультантов и сколько есть клиентов в данный момент.
Здесь фиксируются этапы погашения долга в конкретном магазине. Экран состоит из html-страницы и полей для заполнения.
Задачи в приложении фиксируются как внутри визита, так и отдельно в карточках клиента. Это список дел торгового представителя, которые он должен выполнить во время посещения магазина. Пользователь выполняет их и прикладывает результат: отписывается текстом, прикрепляет фотографии.
Слева направо показаны шаги: анкета, финансовая информация, задачи торгового представителя
Стандартное окончание визита — заказ новых товаров. Сотрудник выбирает договор, нужные позиции, дату доставки и контактное лицо. На этом же экране торговый представитель видит свой процент от суммы заказа: чем больше товаров заказал клиент, тем больше денег заработал сотрудник.
Перед завершением визита в приложении сотрудник проходит финальный шаг для подтверждения выполненных работ: проверяет заполненную анкету, задачи, детали заказа.
Для удобства работы торговых представителей мы добавили в приложение фэйсинг — автоматическое распознавание продукции на полках магазина по фотографии.
Коротко о технике #1: Синхронизация
У нас получалось 18 типов сущностей, 9 из которых могут как загружаться с сервера, так и отправляться на него. Поэтому приложение нуждалось в сложной синхронизации.
Синхронизация занимала много времени, и во время неё телефон блокировался: пользователь видел только уровень прогресса загрузки.
К тому же в некоторых магазинах (например, в подвальных помещениях) нет связи, поэтому приложение должно было уметь работать офлайн, а потом синхронизировать новую информацию.
Как и в случае с разработкой приложения для строительной компании ПИК, автоматическая синхронизация нам не подошла, поэтому для ускорения процессов мы выбрали ручную синхронизацию. Получилось так: утром сотрудник приходит в офис и вручную синхронизирует данные, днём работает в офлайн-режиме в магазинах, а вечером возвращается в офис и снова синхронизирует информацию.
Коротко о технике #2: Персистентное хранение заполняемых данных
Во время визита сотрудник Ascott вносит в систему довольно много информации: количество товара, фотографии магазинных полок, заказы. Если его телефон вдруг выключится, и приложение перезапустится, заполненные данные не должны потеряться.
Мы предусмотрели персистентное хранилище данных. При перезагрузке приложения торговый представитель может начать работу с незаконченного в прошлый раз этапа.
На втором этапе мы исправили ошибки приложения после тестирования пользователями и добавили новые функции:
Процентное отображение эффективности сотрудника, чтобы он видел процент выполнения плана и мог на него оперативно влиять.
Приложение отслеживает звонки сотрудника и записывает всю историю взаимодействия с клиентами, чтобы заказы не потерялись. Если представитель Ascott поговорил по телефону с каким-то незнакомым контактом, приложение предлагает создать новый контакт в базе данных и связать его с точкой продаж.
Через приложение рассылаются необходимые новости, чтобы каждый сотрудник был в курсе важных событий. Некоторые новости должны быть донесены всем сотрудникам. Новость считается прочитанной после показа в списке — тогда сервер помечает сотрудника, как ознакомившегося.
Чтобы не потерять клиента, если вдруг он решит поменять адрес, был добавлен функционал смены местоположения. Можно поставить местонахождение магазина по геопозиции. При клике на кнопку «указать местоположение» открывается экран, где пользователь ставит точку.
После второго этапа мы ещё несколько месяцев вели поддержку приложения: фиксировали и устраняли все возможные проблемы.
Мы договорились с Ascott, что ошибки в работе приложения делятся на уровни важности. Клиенту такое решение позволяет быть уверенным в том, что мы быстро приступим к изучению ошибки, если она критичная для работы приложения. Нам же градация дает возможность не начинать изучение мелких ошибок (тех, которые не влияют на основной флоу работы и не затрагивают многих менеджеров) сломя голову.
Проблема 1. Камера
Процесс фотографирования товаров через наше приложение сначала выглядел так: пользователь запускает системную камеру телефона, наводит ее на полки, делает снимок.
В это время системные оптимизаторы на телефонах типа Xiaomi или Huawei закрывали наше приложение, потому что оно находится в фоне, из-за чего после съёмки его приходилось запускать заново. По итогу фото в приложение не доходило: во время его создания сервис не работал, нужный кадр просто терялся.
Сначала эта проблема появилась у одного пользователя. Мы написали инструкции, что делать в таких случаях: почистить память и поставить приложение в приоритет, чтобы система не отключала его. На какое-то время это сработало, но через несколько месяцев проблема стала массовой. Тогда мы написали с нуля свою камеру внутри приложения, чтобы оно вообще не переключалось в фоновый режим.
Работала она так:
Теперь, если мы решим переписать системную камеру на внутреннюю в уже готовых приложениях, сделать это будет очень просто, потому что камера вынесена в библиотеку.
Проблема 2. Геопозиция
Иногда в анкете встречался пункт «поставить геопозицию». Это требовалось для первичного занесения в базу данных и на случай, если магазин куда-то переехал. На втором этапе мы разработали карту-пикер, где можно было выбрать геопозицию.
В какой-то момент местоположение перестало определяться. Выяснилось, что с GPS есть две проблемы:
Для решения мы просто сменили механику: текущая локация обновлялась при клике на кнопку «Мое местоположение» и открытии экрана.
Мы разработали полноценное приложение для торговых представителей Ascott Group, в котором есть:
Вся информация из магазинов через приложение сразу попадает в общую систему. Руководство может отслеживать ситуацию на рынке в настоящем времени и принимать эффективные решения.
Во время создания приложения мы постоянно консультировались с командой Ascott, чтобы сервис получился интуитивно понятным для торговых представителей.
Приложение работает независимо от наличия сети. Главное, чтобы менеджер синхронизировал данные в начале и конце рабочего дня.