В этой части расскажем о самом трудном — о бизнес-процессах, логистике и управлении продуктом. Переведём технические штуки на человеческий и поведаем о трудностях и ошибках, с которыми столкнулись. Приложение создавалось с акцентом на сборку товаров в маркете, но заложенная архитектура позволит масштабировать его как маркетплейс-решение для других партнёров. Поехали.
После авторизации через телефон, мы видим главный экран внутреннего приложения для сборщиков, курьеров и менеджеров. Он позволяет обрабатывать заказы на протяжении всего флоу от поступления в систему до его получения клиентом. В зависимости от ролей, которые есть у сотрудника в системе, отображаются различные комбинации вкладок.
Сборщик видит список заказов в системе, может принять или отложить заказ.
Менеджер может назначить заказ на сборщика, перенести на другое время или отложить его.
Помимо назначения менеджером, сборщик может проявить смекалку и принять заказ самостоятельно. Ему необходимо нажать на заказ и в открывшемся модальном окне выбрать кнопку «принять». Он может принять несколько заказов одновременно, но не более трёх. Для того, чтобы не возникло путаницы — каждый помечен своим цветом.
Для начала сборки заказа необходимо тапнуть по нему и откроется скрин заказа со списком сгруппированных товаров.
В работе. Список товаров, которые необходимо собрать. Свайп влево позволяет подтвердить, что товар собран и он переносит его на вкладку «Готово». Свайп вправо сигнализирует отсутствие и переносит товар на вкладку для «Замена». Если товар развесной, то мы запрашиваем скан штрихкода. При нажатии на товар открывается модальное окно с возможностью замены, подтверждения и сканирования штрихкода. Если указано больше 1 товара или у товара есть комментарий, то выводим проверочное окно.
Замена товара. Если клиент согласился на замену, то товар можно заменить на похожий. Процесс замены товара запутан большим количеством corner cases. К примеру, сначала сборщик проходит по торговому залу и собирает аналоги ненайденных товаров, затем перед кассой созванивается с клиентом и утверждает аналоги. Поэтому для этого есть отдельная вкладка.
Чуть-чуть закулисья :)
Контролёр выполняет роль оплаты заказа на кассе магазина. Он выбирает заказ, после чего ему необходимо провести его через кассу и оплатить заказ специальным QR-кодом.
После оплаты водитель видит заказ, который ожидает забора на «в ожидании». После того, как он возьмёт его в доставку, он может проложить маршрут в навигаторе и доставить заказ.
В дальнейшем предполагается интеграция с Яндекс.Маршрутизацией, которая будет наилучшим образом выстраивать порядок доставки заказов.
На каждом этапе фиксируется время, чтобы можно было отслеживать показатели эффективности и влиять на них.
В реальности подводных процессов гораздо больше и с каждой итераций продукт усложнялся и насыщался. В условиях запуска MVP задача стояла в том, чтобы не нарушить текущий процесс, а наоборот — ускорить. Поэтому, при разработке процесса деталям отдавалось больше значения.
