Представьте: вы – крупный производитель и ритейлер товаров для дома, который обрабатывает в сутки тысячи заказов по всей стране. Но при этом у вас нет единого алгоритма расчета стоимости доставки – из-за этого суммы почти всегда разные, иногда завышенные. Менеджеры вручную корректируют стоимость доставки до значений, которые не отпугнули бы клиента. При этом покупатели часто слышат разные цены от специалистов колл-центра и офлайн-магазинов. А после – оставляют жалобы или даже отказываются от покупки.
Как было раньше
Процесс расчёта доставки ритейлера не был системным, но это было и не нужно. Компания работала всего в двух городах присутствия – в Москве и Санкт-Петербурге, – и количество заказов позволяло менеджерам подсчитывали стоимость вручную, что тем не менее занимало немало времени. В своих расчётах сотрудники опирались на габаритность, вес заказа и дальность поездки.
Но с развитием бизнеса в регионах и открытием локальных складов отсутствие единого алгоритма и стандарта расчета стало проблемой. Иногда суммы за доставку получались слишком большими, особенно если адрес находился за чертой города. Расчет велся так: длину по прямой от склада до покупателя измеряли линейной в «Яндекс.Картах», умножали на фиксированную стоимость за километр и потом вручную снижали получившееся число до «приемлемого уровня». Единой системы ценообразования у менеджеров не было.
Ещё один нюанс – сезонность. Весной многие едут за город – на дачи или в загородный дом – и оформляют доставку туда. Количество дальних заказов с началом сезона заметно увеличивается – в 5-7 раз. Поэтому менеджеры тратят еще больше времени на ручной расчет стоимости доставки.
Ещё одна проблема, которая появилась с развитием бизнеса, – отсутствие единого механизма расчета доставки для всех сотрудников компании. Из-за этого были ситуации, когда менеджеры офлайн-магазинов озвучивали клиентам одну цену за услугу (предварительно снизив её до минимально возможного уровня, чтобы заказ был более привлекательным), а сотрудники колл-центра – другую, которая выше той, что назвали ранее. Реакция понятна: покупатели часто оставляли жалобы или отказывались от заказа.
Компания начала думать над решением проблемы. Одним из вариантов было подключить функциональность «Яндекс.Карт» к собственным сервисам через API. Это позволило бы менеджерам получать данные о протяженности маршрута, после чего система сама рассчитывала бы стоимость доставки аналогично калькулятору: протяженность в километрах, умноженная на стоимость (руб/км). Но в таком случае оставался открытым вопрос ценообразования – у персонала по-прежнему не было возможности объяснять покупателю, почему именно такая цена за доставку, а у его соседа по даче другая. «Так посчитала программа» – такой ответ недопустим с точки зрения менеджмента и клиентского сервиса.
Вместе с ритейлером стали изучать, как подходят к ценообразованию другие розничные сети (например, СТД «Петрович», Leroy Merlin и IKEA). Нам понравилось, что они разбивают территорию доставки на зоны. Готовых решений, которые бы соответствующим образом автоматизировали процесс, не нашли, поэтому выбрали собственную разработку.
Как создавали сервис
-
Сбор требований
При разработке и внедрении сервиса ритейлер определил для себя следующие технические особенности:
-
ускорение расчета для сотрудников, которые формируют заказы (менеджеры колл-центра и офлайн-магазинов);
-
понятность ценообразования для персонала и покупателя, которая зависит от региона, габаритности заказа и формата доставки («до двери» или самовывоз из ПВЗ);
-
простой интерфейс, понятный без инструкций, подсказки при вводе адреса, лёгкая навигация;
-
возможность использовать сервис без привлечения внешней ИТ-команды;
-
интеграция с внутренними ИТ-решениями (кассовой системой, интернет-магазином и др), чтобы рассчитывать стоимость по их запросам;
-
подключение к классификатору адресов и внешним сервисам малогабаритной доставки в пункты выдачи;
-
высокая доступность сервиса (24/7);
-
быстрая скорость отклика – не более 0,6 – 0,8 секунды при 100 одномоментных запросах на расчет;
-
возможность масштабирования.
Все эти требования соответствуют запросам современных высоконагруженных интернет-магазинов не только для В2С-сегмента, но и рынка В2В.
-
Выбор ИТ-архитектуры
Для сервиса мы выбрали следующий технологический стек: фреймворк Symfony, СУБД PostgreSQL, хранилище данных Redis и UI-библиотеку React. Было несколько предпосылок такого выбора:
-
ИТ-предпочтения производителя. На тот момент у компании уже было несколько сервисов на подобном стеке, и её это вполне устраивало. Решили не расширять набор языков программирования, фреймворков и ПО, чтобы не создавать проблемы с наймом и содержанием команды.
-
Надёжность и современность. Этот стек покрывает все технические требования компании и позволяет с минимальными усилиями создать требуемую функциональность. Также мы не раз обкатывали этот набор технологий на других проектах, и он отлично зарекомендовал себя с точки зрения масштабируемости и поддержки.
Мы планировали сервис минималистичным и максимально простым – в виде одностраничного (SPA) веб-приложения, поэтому у него достаточно стандартная архитектура.
-
Разработка сервиса
Чтобы этот сервис можно было как использовать самостоятельно, так и встроить в прочие ИТ-продукты компании, мы создали два вида интерфейсов:
-
простой графический, с картой и возможностью визуального выбора параметров доставки – можно использовать как готовое решение для менеджеров торговых точек и специалистов колл-центра;
-
API, которое позволяет использовать этот сервис в любых продуктах как источник знаний о доставке и её стоимости, оставляя свободу для создания визуальных интерфейсов.
Также мы продумали в сервисе небольшую панель администрирования. Она позволяет оперировать всем набором исходных данных, которые влияют на расчёты.
Панель администрирования
-
Интеграции
Ритейлер подключил к сервису интернет-магазин, благодаря чему покупатели видят те же цены на доставку, что и менеджеры и сотрудники колл-центра.
Заложенная изначально ИТ-архитектура позволила компании самостоятельно «прикрутить» ИТ-решение к сервисам доставки мелкогабаритных заказов в пункты выдачи.
Благодаря интеграции на карте отображаются пункты выдачи, где покупатели могут забрать малогабаритные заказы
-
Нагрузочное тестирование
Завершающий этап – тестирование для проверки соответствия сервиса требованиям быстродействия и работы под нагрузкой. На этом этапе мы изменили несколько алгоритмов работы с картами, чтобы повысить скорость ответов и обработки входящих запросов.
Сняли показатели с использованием Redis и без него. Наглядно подтвердили целесообразность применения этого хранилища
Для тестирования использовали самый простой и доступный на тот момент инструмент – Apache Benchmark (ab). Запустили серию из 100 000 запросов к сервису при 100 единовременных (строго по заданию). Отчёт показал, что мы укладываемся в запрошенные 0,6 – 0,8 сек даже с запасом.
Сложности
-
Отрисовка зон доставки
Сначала мы хотели сами рисовать зоны доставки без основы (только хардкор!) с детальным совпадением с границами регионов, как того хотел ритейлер. Но вскоре поняли, что отрисовка зон происходит не так быстро, как хотелось бы. Чтобы её ускорить, мы использовали свободно распространяемые зоны регионов и специализированное ПО для работы с картами Scribble Maps. Кстати, этот сервис оказался очень удобным – в нём много инструментов (линейка, ластик, слои, перемещение и объединение точек, поддержка карт KML и многое другое), которые сильно облегчают работу. В результате нам удалось сократить время отрисовки около трёхсот зон доставки почти в два раза.
Отрисовка зон в сервисе Scribble Maps
-
Попадание точки в полигон
Была сложная задача с точки зрения математики – сделать так, чтобы сервис корректно соотносил адрес и район доставки («полигон»).
Дело в том, что вся зона доставки – это своего рода полигон с множеством точек (адресов). Некоторые из них могут входить в состав друг друга (они называются «вложенными», или концентрическими), пересекаться или «перекрывать» другие полигоны (как в случае города Клин на скриншоте). Несмотря на то, что это, скорее, частные случаи, система должна определять для точки, которая относится сразу к нескольким полигонам, наименьшую стоимость. Это важно, потому что цена доставки в каждую из зон разная.
Например, город Ногинск, куда нужно доставить заказ, входит сразу в четыре полигона: маленький оранжевый вокруг самого города, а также в зелёный, светло-синий и большой оранжевый вокруг Москвы. Из этого перечня система должна определять только самый маленький, оранжевый – сам Ногинск. В этом случае ИТ-решение рассчитает корректную для покупателя стоимость доставки. Обеспечить эту функциональность и было нашей задачей.
Мы взяли за основу готовое Open Source решение. Но был нюанс: оно помогало ответить лишь на один вопрос – входит ли точка в конкретный замкнутый полигон. Этого было недостаточно. Из-за того, что математический алгоритм был сложный и ресурсоёмкий, решение не удовлетворяло требованиям по скорости ответа. Поэтому мы «допилили» и расширили это решение, оптимизировали код. И получили нужный нам результат: сервис корректно и быстро находит нужный полигон.
Результаты
Сервис позволяет менеджерам в магазине и колл-центре всегда называть правильную сумму стоимости доставки и легко объяснить, почему по одному адресу такая цена, а по другому – другая. Работа сотрудников стала быстрее: они просто вводят адрес в сервисе или сразу в интернет-магазине (зависит от того, где оформляют заказ) и моментально видят информацию о стоимости.
Сроки проекта – 6 месяцев, от запроса до демонстрации решения, готового к пилоту. Первый MVP показали уже через месяц. Бизнес отреагировал позитивно. Функциональным руководителям больше всего понравилось то, насколько менеджерам легко работать с сервисом (без обучения и инструкций), как быстро они получают информацию о стоимости доставки, а также универсальность интеграции с интернет-магазином и кассовым решением.
***
Если у вас остались вопросы или есть подобные задачи — заполните форму ниже или напишите нам на адрес omni@korusconsulting.ru, будем рады проконсультировать.
