Кейс: как для крупного ритейлера мы создали систему, которая рассчитывает стоимость доставки заказов по городам

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

Стало понятно, что необходимо внедрить единую для всех сотрудников систему, которая автоматически рассчитывает стоимость доставки заказов покупателям. В этом кейсе руководитель группы аналитиков департамента e-commerce ГК «КОРУС Консалтинг» Артем Кияшко рассказывает о том, как удалось создать и внедрить такой сервис. 

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

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

Ситуацию осложняла сезонность. Весной стартует дачный сезон, и покупатели начинают оформлять доставку в загородные дома. Число таких заказов по весне вырастает в 5-7 раз — как и время менеджеров, затраченное на индивидуальный подсчет каждой доставки.

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

Сначала предложили вариант подключить ко внутренним сервисам компании функциональность «Яндекс.Карт» через API. В таком случае менеджеры получили бы информацию о расстоянии маршрута, а система автоматически бы подсчитывала стоимость доставки, умножая цену одного километра на расстояние целиком. Но такой подход не решил бы проблему единого ценообразования. Сотрудникам все равно бы пришлось объяснять, почему у конкретного покупателя одна цена, а у его соседа по участку — другая.

Изучая опыт других ритейлеров — IKEA, Leroy Merlin или СТД «Петрович» — обратили внимание, как игроки рынка делят пространство на зоны доставки. Однако поняли, что на рынке, тем не менее, нет готовых решений, которые позволили бы полностью автоматизировать процесс и создать единый алгоритм ценообразования. Поэтому решили пойти по пути разработки собственного ПО с нуля. Для этого пригласили команду департамента e-commerce ГК «КОРУС Консалтинг».

Прежде, чем заняться разработкой, аналитики ГК «КОРУС Консалтинг» собрали все требования к новому сервису и систематизировали их. Среди них:

1. увеличение скорости расчета для менеджеров, которые обрабатывают заказы в колл-центре и магазинах;
2. унификация ценообразования понятным: цена должна формироваться в зависимости от габаритов заказа, региона, и типа доставки (самовывоз из пункта выдачи заказов или доставка «до двери»);
3. создание понятного интерфейса с подсказками при вводе адреса;
4. внедрение такого сервиса, с которым команда ритейлера будет справляться самостоятельно;
5. интеграция сервиса с внутренними системами ритейлера — кассовой, интернет-магазином и др — для того, чтобы считать цену доставки по их запросу;
6. интеграция с классификатором адресов, а также сторонними сервисами доставки малогабаритных грузов в ПВЗ;
7. круглосуточная доступность системы;
8. быстрая работа системы: скорость отклика должна составлять не более 0,6-0,8 сек при 100 одномоментных запросах на подсчет;
9. возможность масштабировать сервис по запросу.

Технологический стек, на котором мы остановились в рамках разработки сервиса: быстрое хранилище данных Redis, база данных PostgreSQL, фреймворк Symfony, UI-библиотека React.

Такой стек выбрали по следующим причинам:

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

Архитектура сервиса достаточно стандартная — это одностраничное (SPA) веб-приложение. Это связано с тем, что мы хотели создать простую и минималистичную систему. 

Для новой системы мы разработали 2 типа интерфейсов для того, чтобы команда ритейлера могла использовать систему как самостоятельный продукт, так и интегрировать его с другим внутренним ПО компании. Интерфейсы выглядели следующим образом:

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

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

На этом этапе было важно подключить к системе онлайн-магазин и сервисы доставки малогабаритных посылок в ПВЗ.

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

Благодаря функциональной ИТ-архитектуре сервиса, ритейлер смог силами собственной команды интегрировать в систему сервисы доставки малогабаритных посылок в ПВЗ.

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

Чтобы провести тестирование, воспользовались одними из самых доступных в то время инструментов — Apache Benchmark (ab) и Apache JMeter.

В рамках тестов согласно техзаданию к сервису запустили серию из 100 тысяч запросов при условии сотни единовременных. В результате, по данным отчета, уложились в заявленные 0,6-0,8 секунд с запасом.

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

В процессе мы поняли, что это занимает больше 3-4 недель, которые мы закладывали на эту задачу. Поэтому мы приняли решение использовать специальное ПО для работы с открытыми пользовательскими картами Scribble Maps в сочетании с доступными зонами регионов.

Scribble Maps удобен тем, что в работе с картами позволяет использовать ряд инструментов графического дизайна — маркер, заливку, карандаш, ластик и другие. Это сильно облегчило нам работу.

В результате триста зон доставки мы нарисовали в два раза быстрее.

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

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

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

Еще один пример: город Ногинск. Ногинск входит одновременно в 4 полигона:

— крупный оранжевый полигон вокруг Москвы;

— маленький оранжевый вокруг Ногинска;

— средние по размеру областные синий и зеленый полигоны.

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

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

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

Теперь сотрудники офлайн-магазинов и колл-центра всегда называют покупателю одну и ту же корректную стоимость доставки, а также разбираются в политике ценообразования и могут объяснить ее клиентам.

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

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