Как мы запускали сервис доставки товаров на такси09.07.2021 12:01

Использование такси для доставки товаров — это «новая нормальность». И все потому, что 2020 год подтолкнул ритейлеров к расширению мобильности и стимулировал развитие способов доставки, а уж тем более быстрых. Таксисты уже доставили более полумиллиона заказов из магазинов М.Видео и Эльдорадо, но чтобы новый сервис был качественным, нам пришлось серьезно поработать.

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

В марте 2020 года, когда значительная часть розницы закрылась и продажи стали проседать, использование такси стало одним из тех решений, которые позволили поддержать дистанционную торговлю. Кстати, таксисты тоже были «только за», люди сидели по домам и количество поездок в городах сильно сократилось. Доставки стали осуществляться не только из магазинов, но и со складов, в результате агрегаторы такси глубоко интегрировались в нашу систему логистики.

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

Работа с таксопарками

Для взаимодействия со службами такси нужно было разработать специальный инструментарий. Все начиналось достаточно просто. Агрегаторы используют открытые API, чтобы интегрировать свои сервисы с любыми другими клиентскими системами. Мы запросили доступ, и наши разработчики приступили к созданию модуля.

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

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

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

Один провайдер хорошо, а чем больше, тем лучше!

Вторым нашим партнёром стала компания CallToVisit и её b2b-сервис по организации перевозок. CallToVisit — это агрегатор провайдеров такси. В результате заказа такси через CallToVisit к нам может приехать машина от Яндекс Go, Gett, Ситимобил, Maxim и других сервисов.

В отличии от Gett, CallToVisit API использует для формата запроса Form Data вместо Json. Не беда! В кратчайшие сроки мы написали необходимый адаптер и ввели его в эксплуатацию. Сначала мы использовали API для обычных поездок на такси, но затем CallToVisit выпустили API специально для доставок. CallToVisit сейчас и в процессе интеграции оказывали нам полную техническую поддержку с быстрыми ответами на наши вопросы, за что мы им очень благодарны.

Почему мы сразу не выбрали только CallToVisit и зачем нам другие интеграции? Тут есть пара моментов: 1 — не складывайте все яйца в одну корзину (отказоустойчивость), 2 — интеграция с провайдерами напрямую также даёт доступ к их уникальным фичам и возможностям. Поэтому между или мы выбираем И!

Буквально в эти дни мы вводим в эксплуатацию нашего нового партнёра — провайдера такси Яндекс Go. И у него также своё API со своими особенностями. Богатая функциональность, подробная документация, оперативная тех.поддержка и приобретенный ранее опыт сделали процесс интеграции легким и невероятно быстрым. Всеми колёсами едем в прод с ветерком!

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

Для каждого партнера у нас есть свой микросервис-адаптер к API провайдера такси.

1. Адаптер читает сообщения с запросами на создание доставки из топика Kafka.
2. Доставка может быть исполнена сейчас (экспресс) или в будущем (отложенная). Если экспресс, то выполняем незамедлительно, иначе сохраняем в БД и запустим позже.
3. Когда приходит время выполнить доставку, то адаптер при необходимости собирает для запроса дополнительную информацию (например, таймзону магазина или доступный тариф провайдера) и делает запрос на создание доставки в API.
4. В ответе от провайдера Адаптер получает, в общем случае, идентификатор доставки провайдера и её статус.
5. Адаптер делает запись в своей БД о новой исполняющейся доставке.
6. Раз в N единиц времени просыпается cronJob, который просит Адаптер сходить в API провайдера и получить последние изменения по доставке — статус, информацию о водителе, предполагаемую или финальную цену поездки и т.п.
7. Если Адаптер видит, что информация по доставке изменилась, то он отправляет сообщение с обновлениями в топик Kafka и также сохраняет их у себя в БД.
8. Когда доставка изменяет свой статус на финальный, то это значит, что поездка закончена, и Адаптер удаляет её из своей БД

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

После этого система исполнения заказов читает из Kafka обновления по доставкам и сохраняет их. Если доставка долго находится в ожидании, то система исполнения заказов отменяет её через адаптер ранее выбранного провайдера. После этого происходит выбор следующего по приоритету партнёра и попытка создания поездки через него.

В процессе доставки товара через такси с системой исполнения заказов взаимодействуют наши фронтальные системы (bff). Они получают информацию по заказу и проверяют статус его доставки. Это позволяет отобразить в едином рабочем веб-интерфейсе сотрудника магазина все данные в удобном виде с необходимым набором возможных действий.

Сейчас на очереди доставка ко времени, оплата у порога, пешие курьеры, доставка из магазина в магазин, переход на callback-модель получения обновлений о доставке, переезд системы исполнения заказов в Camunda и много другого, что выведет сервис на новый уровень комфорта для наших клиентов.

Техническая сторона вопроса

Как внешний заказчик, фактически на каждую доставку мы вызывали такси с доставкой до подъезда за 2 часа. После первых обкаток возникли сложности, которые потребовали более тонкой настройки инструмента.

1. Качественная настройка географии. Мы должны были определить, откуда и куда нужно везти товар. Например, когда клиент находится по одному адресу и указывает доставку в иное место, а склад находился в другом городе, наши собственные системы должны тщательно проработать логистику, чтобы менеджерам не приходилось вручную вылавливать казусы с географией.

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

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

4. Упрощение взаимодействия таксиста и склада. Чтобы не терять время на получение товара, нам пришлось разработать дополнительный функционал к системе оформления заказов. Цель была в том, чтобы таксист получал номер заказа, а на складе для него уже были правильно оформленные документы. Мы, конечно, хотели бы полностью отказаться от бумажных документов, но пока не все наши партнеры к этому готовы. Для отгрузки используются накладные, а клиент должен получить гарантийный талон и чек о покупке.

Ошибки, проблемы и их решения

Конечно, на этом пути были и подводные камни. Один раз, еще на раннем этапе одному из покупателей, который оформил заказ в московском магазине, потребовалась доставка во Владимирскую область.

В результате фен прокатился пару сотен километров на такси, снизив финансовые результаты проекта (хотя лишь временно), а мы получили важный опыт и расширили работу алгоритмов.
Бывали ситуации, когда курьер, получив отличный телевизор, айфон или ноутбук, исчезал с радаров. Такие случаи были единичными, и решались в правовом поле. Конечно, заказ отправлялся повторно, а к таксисту применялись логичные санкции. Благо, мы знаем, кто он, на какой машине, и когда его последний раз «видели» сервисы агрегатора.

Поскольку в нашей стране живут очень изобретательные люди, некоторые пытались обмануть систему и отменяли заказ, когда водитель уже вручал им товар. Таксист — лишь наш партнер, он не может моментально отследить изменение статуса. Такие кейсы отрабатывала сервисная служба, которая связывалась с клиентом, объясняла противоправность его действий. В 99% случаев люди понимали, что их хитроумный замысел раскрыт, и оплачивали товар.

Развиваем сервис — развиваем логику

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

Новый сервис улучшил нашу бизнес-логику. И дело не только в том, что мы сделали доставку комфортнее для покупателей. Сам сервис работает корректно и в режиме реального времени позволяет заказать доставку на сайте, отследить ее выполнение и оставить отзыв.

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

Нашего запаса прочности хватит, чтобы увеличить кол-во поездок минимум в 10 раз, и это без потери качества и изменений в работе алгоритмов.

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

Новый продуктовый подход

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

В результате мы пошли следующим путем:

1. Запустили mvp в считанные дни: оформление доставок на такси вручную, чеки формировались сотрудником в магазине на обычной кассе, ручная обработка возвратов в магазин от таксиста и тд. Также вручную выполнялась выдача заказов на парковке сотрудниками магазина (М.Курьер)
2. Автоматизировали выдачу заказов М.Курьер: сотрудник в веб-приложении выполнял выдачу, клиент подтверждал выдачу смс-кодом, автоматически формировался чек.
3. Автоматизировали оформление доставки на такси для магазина: выполнили интеграцию с Gett, оформление доставки выполняется сотрудником в нашей системе по имеющимся в системе данным, не нужно переносить данные в личный кабинет агрегатора такси.
4. Подключили еще одного агрегатора — C2V
5. Автоматизировали оформление экспресс-доставки для клиента: теперь клиент вводит только адрес доставки и система автоматически выбирает магазин из которого будет выполняться доставка по набору критериев.
6. Запустили функционал «гибкой» цены экспресс-доставки: цена может зависеть от набора критериев: стоимости заказа, расстояния до клиента и т.д.

Творческие планы

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

Самое главное позади — мы собрали работоспособную команду, реализовали архитектуру, которая сделала этот сервис масштабируемым, способным самостоятельно обрабатывать любые известные нам запросы, возникающие на пути доставки заказа клиенту с минимальным участием человека. Остались приятные хлопоты — интегрировать сервис во фронты. Следите за новостями!

P.S. Хотите работать в нашей команде над интересными проектами? Добро пожаловать на борт!