Ключевые факты

Город: Москва
Ниша: фермерские продукты
Платформа: InSales + RetailCRM + RefGo
Тип работ: API-интеграция, backend-сервис, автоматизация доставки
Срок: 1–1,5 месяца

Контекст

К нам обратилась компания из сферы доставки фермерских продуктов. Магазин работал на InSales, заказы обрабатывались в RetailCRM, а доставку нужно было передавать в RefGo.

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

Менеджеры вели заказы в RetailCRM, смотрели состав, а потом вручную создавали каждый заказ в личном кабинете RefGo. Это занимало время и создавало риск ошибки при переносе.

Где была настоящая сложность

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

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

То есть система должна была не просто выгрузить состав заказа, а сначала:

·        определить, где в заказе охлаждёнка, а где заморозка;

·        рассчитать количество мест;

·        собрать для RefGo не список товаров из каталога, а служебную логистическую структуру.

Именно в этом и был поворот проекта.

Решение

Для начала нужно было сделать отдельный backend-сервис между RetailCRM и RefGo, который берёт заказ, разбирает его по правилам клиента, пересчитывает в места и только после этого отправляет данные в RefGo.

Стандартный сценарий тут не подходил. Передавать заказ как есть клиенту было нельзя. Это ломало их внутреннюю схему работы с доставкой.

Что сделали

1. Добавили признак температурного режима у товаров

На стороне InSales каждому товару задали параметр: охлаждёнка или заморозка.

2. Передали этот признак в RetailCRM

После этого в заказе RetailCRM уже были данные, по которым можно определить тип товара и дальше собрать заказ для логистики.

3. Поставили между системами отдельное приложение

Заказ из RetailCRM уходил не напрямую в RefGo, а сначала в приложение на отдельном сервере. Именно там происходил расчёт и преобразование заказа в нужный формат.

4. Реализовали нетиповую логику расчёта мест

Вместо передачи полного состава заказа сервис формировал логистические места по правилам клиента.

Если в заказе была только охлаждёнка:

·        общее количество мест — 1

·        товар — «Охлажденка»

·        вес — 5 кг

·        температурный режим — «Средние температуры»

Если в заказе была только заморозка:

·        общее количество мест — 1

·        товар — «Заморозка»

·        вес — 1 кг

·        температурный режим — «Низкие температуры»

Если были и охлаждёнка, и заморозка:

·        общее количество мест — 2

·        одно место под охлаждёнку

·        одно место под заморозку

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

5. Настроили двусторонний обмен

Приложение не только отправляло заказы в RefGo, но и принимало статусы обратно.

Подтверждённо в RetailCRM возвращались статусы:

·        отправлен

·        выполнен

·        отменен

За счёт этого менеджеры видели движение заказа прямо в CRM.

6. Сделали админку для управления интеграцией

В приложении были предусмотрены:

·        настройки API RetailCRM

·        настройки API RefGo

·        сопоставление статусов

·        ручной импорт заказов

·        создание и обновление заказа в RefGo

·        проверка заказа

То есть это была не просто техническая прослойка, а рабочий инструмент, которым можно управлять.

Результат

Точных цифр по времени клиент не считал, поэтому здесь без выдумок.

Но прикладной эффект был понятный:

·        сократилось время на обработку заказов;

·        снизился риск ошибок при переносе данных;

·        менеджерам стало проще передавать заказы в доставку;

·        логист получил более удобную схему работы с местами;

·        движение заказа стало видно в RetailCRM по статусам.

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

Финал

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

Не просто подключить RefGo к RetailCRM, а собрать между ними понятную схему, которая каждый день помогает менеджерам работать быстрее и спокойнее.