Свяжитесь с нами
Спасибо

Мы получили заявку и свяжемся с вами в ближайшее время

ВЕРНУТЬСЯ НА ГЛАВНУЮ
Свяжитесь с нами
Ошибка

Не удалось отправить заявку, повторите позже

ПОПРОБОВАТЬ ЕЩЁ РАЗ
Как мы разрабатывали сервис расчета...
ВРЕМЯ ЧТЕНИЯ
~ 7 мин.
341

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

Руководитель группы аналитиков,
департамент e-commerce в ГК «КОРУС Консалтинг»


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

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

Как было раньше

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

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

Ещё один нюанс – сезонность. Весной многие едут за город – на дачи или в загородный дом – и оформляют доставку туда. Количество дальних заказов с началом сезона заметно увеличивается – в 5-7 раз. Поэтому менеджеры тратят еще больше времени на ручной расчет стоимости доставки.

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

Компания начала думать над решением проблемы. Одним из вариантов было подключить функциональность «Яндекс.Карт» к собственным сервисам через API. Это позволило бы менеджерам получать данные о протяженности маршрута, после чего система сама рассчитывала бы стоимость доставки аналогично калькулятору: протяженность в километрах, умноженная на стоимость (руб/км). Но в таком случае оставался открытым вопрос ценообразования – у персонала по-прежнему не было возможности объяснять покупателю, почему именно такая цена за доставку, а у его соседа по даче другая. «Так посчитала программа» – такой ответ недопустим с точки зрения менеджмента и клиентского сервиса.

Вместе с ритейлером стали изучать, как подходят к ценообразованию другие розничные сети (например, СТД «Петрович», Leroy Merlin и IKEA). Нам понравилось, что они разбивают территорию доставки на зоны. Готовых решений, которые бы соответствующим образом автоматизировали процесс, не нашли, поэтому выбрали собственную разработку.

Как создавали сервис 

  • Сбор требований

При разработке и внедрении сервиса ритейлер определил для себя следующие технические особенности:

  1. ускорение расчета для сотрудников, которые формируют заказы (менеджеры колл-центра и офлайн-магазинов);

  2. понятность ценообразования для персонала и покупателя, которая зависит от региона, габаритности заказа и формата доставки («до двери» или самовывоз из ПВЗ);

  3. простой интерфейс, понятный без инструкций, подсказки при вводе адреса, лёгкая навигация;

  4. возможность использовать сервис без привлечения внешней ИТ-команды;

  5. интеграция с внутренними ИТ-решениями (кассовой системой, интернет-магазином и др), чтобы рассчитывать стоимость по их запросам;

  6. подключение к классификатору адресов и внешним сервисам малогабаритной доставки в пункты выдачи;

  7. высокая доступность сервиса (24/7); 

  8. быстрая скорость отклика – не более 0,6 – 0,8 секунды при 100 одномоментных запросах на расчет;

  9. возможность масштабирования.

Все эти требования соответствуют запросам современных высоконагруженных интернет-магазинов не только для В2С-сегмента, но и рынка В2В.

  • Выбор ИТ-архитектуры

Для сервиса мы выбрали следующий технологический стек: фреймворк Symfony, СУБД PostgreSQL, хранилище данных Redis и UI-библиотеку React. Было несколько предпосылок такого выбора: 

  1. ИТ-предпочтения производителя. На тот момент у компании уже было несколько сервисов на подобном стеке, и её это вполне устраивало. Решили не расширять набор языков программирования, фреймворков и ПО, чтобы не создавать проблемы с наймом и содержанием команды.

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

Мы планировали сервис минималистичным и максимально простым – в виде одностраничного (SPA) веб-приложения, поэтому у него достаточно стандартная архитектура.

  • Разработка сервиса

Чтобы этот сервис можно было как использовать самостоятельно, так и встроить в прочие ИТ-продукты компании, мы создали два вида интерфейсов:

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

  2. API, которое позволяет использовать этот сервис в любых продуктах как источник знаний о доставке и её стоимости, оставляя свободу для создания визуальных интерфейсов.

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

1_панель администрирования.png

Панель администрирования

  • Интеграции

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

Заложенная изначально ИТ-архитектура позволила компании самостоятельно «прикрутить» ИТ-решение к сервисам доставки мелкогабаритных заказов в пункты выдачи.

2_пункты выдачи.png

Благодаря интеграции на карте отображаются пункты выдачи, где покупатели могут забрать малогабаритные заказы

  • Нагрузочное тестирование

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

3_нагрузочное тестирование 1.png3_нагрузочное тестирование 2.png

Сняли показатели с использованием Redis и без него. Наглядно подтвердили целесообразность применения этого хранилища

Для тестирования использовали самый простой и доступный на тот момент инструмент – Apache Benchmark (ab). Запустили серию из 100 000 запросов к сервису при 100 единовременных (строго по заданию). Отчёт показал, что мы укладываемся в запрошенные 0,6 – 0,8 сек даже с запасом.

Сложности 

  • Отрисовка зон доставки

Сначала мы хотели сами рисовать зоны доставки без основы (только хардкор!) с детальным совпадением с границами регионов, как того хотел ритейлер. Но вскоре поняли, что отрисовка зон происходит не так быстро, как хотелось бы. Чтобы её ускорить, мы использовали свободно распространяемые зоны регионов и специализированное ПО для работы с картами Scribble Maps. Кстати, этот сервис оказался очень удобным – в нём много инструментов (линейка, ластик, слои, перемещение и объединение точек, поддержка карт KML и многое другое), которые сильно облегчают работу. В результате нам удалось сократить время отрисовки около трёхсот зон доставки почти в два раза. 

4_Отрисовка зон в сервисе Scribble Maps.png

Отрисовка зон в сервисе Scribble Maps

  • Попадание точки в полигон

Была сложная задача с точки зрения математики – сделать так, чтобы сервис корректно соотносил адрес и район доставки («полигон»).

5_Полигоны_Клин.png

Дело в том, что вся зона доставки – это своего рода полигон с множеством точек (адресов). Некоторые из них могут входить в состав друг друга (они называются «вложенными», или концентрическими), пересекаться или «перекрывать» другие полигоны (как в случае города Клин на скриншоте). Несмотря на то, что это, скорее, частные случаи, система должна определять для точки, которая относится сразу к нескольким полигонам, наименьшую стоимость. Это важно, потому что цена доставки в каждую из зон разная.

Например, город Ногинск, куда нужно доставить заказ, входит сразу в четыре полигона: маленький оранжевый вокруг самого города, а также в зелёный, светло-синий и большой оранжевый вокруг Москвы. Из этого перечня система должна определять только самый маленький, оранжевый – сам Ногинск. В этом случае ИТ-решение рассчитает корректную для покупателя стоимость доставки. Обеспечить эту функциональность и было нашей задачей.

Мы взяли за основу готовое Open Source решение. Но был нюанс: оно помогало ответить лишь на один вопрос – входит ли точка в конкретный замкнутый полигон. Этого было недостаточно. Из-за того, что математический алгоритм был сложный и ресурсоёмкий, решение не удовлетворяло требованиям по скорости ответа. Поэтому мы «допилили» и расширили это решение, оптимизировали код. И получили нужный нам результат: сервис корректно и быстро находит нужный полигон.

Результаты

6_Зоны и тарифы доставки.png

Сервис позволяет менеджерам в магазине и колл-центре всегда называть правильную сумму стоимости доставки и легко объяснить, почему по одному адресу такая цена, а по другому – другая. Работа сотрудников стала быстрее: они просто вводят адрес в сервисе или сразу в интернет-магазине (зависит от того, где оформляют заказ) и моментально видят информацию о стоимости.

Сроки проекта – 6 месяцев, от запроса до демонстрации решения, готового к пилоту. Первый MVP показали уже через месяц. Бизнес отреагировал позитивно. Функциональным руководителям больше всего понравилось то, насколько менеджерам легко работать с сервисом (без обучения и инструкций), как быстро они получают информацию о стоимости доставки, а также универсальность интеграции с интернет-магазином и кассовым решением.

Опубликовано на Habr

***

Если у вас остались вопросы или есть подобные задачи — заполните форму ниже или напишите нам на адрес omni@korusconsulting.ru, будем рады проконсультировать.

Закажите бесплатную консультацию эксперта
 

Подпишитесь на наши обновления

Раз в месяц присылаем полезные материалы и новые статьи из блога.

Некорректно заполнен e-mail

Читайте также

10 идей для развития B2B-портала: глобальные tech-тренды ~ 6 мин. 24 апреля 2023
B2B E-COMMERCEOMNICHANNELТРЕНДЫ
Вячеслав Коган
Инхаус-разработка и аутсорсинг в ИТ-проектах: что выбрать ~ 8 мин. 19 апреля 2023
СТРАТЕГИЯТЕХНОЛОГИИ
Сергей Рабинович
15 технологий, которые меняют электронную торговлю прямо сейчас ~ 10 мин. 30 марта 2023
E-COMMERCEИНТЕРНЕТ-МАГАЗИНЫМАРКЕТПЛЕЙСЫТЕХНОЛОГИИТРЕНДЫ
КОРУС Консалтинг
Подпишитесь на наши обновления

Раз в месяц присылаем полезные материалы и новые статьи из блога.

Некорректно заполнен e-mail


наверх
ЧИТАЙТЕ НАС В TELEGRAM
еКОМната — нишевое медиа о e‑commerce и B2B. Только экспертиза, цифры и кейсы
ПОДПИСАТЬСЯ