Интеграция CRM со службой доставки должна убирать повторный ввод и одновременно сохранять контроль над исполнением заказа. Менеджер передаёт подтверждённый заказ один раз, система создаёт отправление, получает идентификатор перевозчика и далее обновляет состояние доставки до вручения, отказа или возврата.
Ошибка — считать задачу завершённой после появления номера отправления. Между продажей и доставкой остаются изменение адреса, отмена, частичная комплектация, наложенный платёж, переадресация, хранение и возврат. Эти события должны менять не только статус в CRM, но и следующий шаг сотрудника.
Определите границу ответственности систем
CRM хранит клиента, договорённости и коммерческое состояние сделки. Склад подтверждает фактическую комплектацию. Служба доставки отвечает за маршрут и физическое перемещение. Интеграция не должна заставлять одну систему угадывать данные другой.
| Данные | Источник | Получатель |
|---|---|---|
| Получатель, контакты, способ оплаты | Подтверждённый заказ в CRM | Служба доставки |
| Места, вес, готовность к отгрузке | Склад | CRM и перевозчик |
| Идентификатор и маршрут отправления | Перевозчик | CRM |
| Статус перемещения и вручения | Перевозчик | CRM и уведомления |
| Факт возврата товара | Склад после приёмки | CRM и учёт |
Если вес рассчитывается складом, менеджер не должен вводить его приблизительно. Если адрес подтверждает клиент, изменение после упаковки требует отдельного сценария. Эти правила фиксируют до подключения API.
Передавайте только подтверждённый заказ
Черновик сделки не является отправлением. Условием передачи обычно служат подтверждённые контактные данные, выбранный способ доставки, готовый состав заказа и разрешение на комплектацию. Для отдельных бизнесов добавляются оплата, кредитный лимит или проверка менеджером.
- CRM проверяет обязательные данные и допустимость перехода.
- Склад подтверждает комплектацию или передаёт фактические места и вес.
- Запрос получает уникальный внутренний идентификатор.
- Перевозчик возвращает свой идентификатор и параметры отправления.
- CRM сохраняет связь двух идентификаторов и запрещает случайное повторное создание.
Не копируйте сотни статусов перевозчика в воронку
Технические статусы нужны интеграции, но менеджеру важны управленческие состояния. «Создано», «принято отделением», «в сортировочном центре» и другие шаги можно объединить в понятные группы, сохранив исходный код события для диагностики.
| Группа CRM | События доставки | Действие |
|---|---|---|
| Готовится | Отправление создано, но не принято | Контроль фактической передачи |
| В пути | Принято и перемещается | Ожидание контрольного срока |
| Ожидает получателя | Прибыло в точку выдачи или назначено вручение | Напоминание клиенту по правилам бизнеса |
| Доставлено | Вручение подтверждено | Закрытие исполнения и следующий контакт |
| Проблема | Отказ, задержка, неверные данные | Задача ответственному |
| Возврат | Движется обратно или возвращено | Приёмка и финансовая проверка |
Статус должен запускать действие
Автообновление без реакции лишь переносит информацию. Если отправление не принято перевозчиком до контрольного времени, задача уходит складу. Если клиент долго не забирает заказ, CRM создаёт контакт менеджеру. Если зафиксирован отказ, система блокирует автоматическое закрытие сделки и ожидает решение по возврату и оплате.
Правила уведомлений должны учитывать повторяемость событий. Перевозчик может несколько раз прислать один статус, поэтому повтор не должен создавать десять одинаковых задач или сообщений.
Изменение и отмена требуют отдельного сценария
До передачи перевозчику адрес или состав заказа можно изменить в исходном заказе и пересоздать параметры контролируемо. После приёма отправления часть изменений доступна только как услуга перевозчика или новое отправление. Интеграция должна показать результат операции, а не просто сохранить новое значение в CRM.
Удалять отправление из CRM нельзя: теряется история. Корректнее хранить состояние отмены, причину, время запроса и ответ внешней системы.
Возврат заканчивается после приёмки, а не после движения назад
Статус перевозчика «возвращено» подтверждает доставку посылки отправителю, но не качество и количество товара. Склад должен принять возврат, проверить комплектность и решить, можно ли вернуть позицию в доступный остаток. Финансовый контур отдельно фиксирует возврат оплаты, комиссию и стоимость доставки.
| Риск | Контроль интеграции | Ответственный |
|---|---|---|
| Дубли отправлений | Уникальный ключ и безопасный повтор запроса | Интеграция |
| Некорректный адрес | Проверка до создания и явный ответ ошибки | Менеджер |
| Отправление не передано | Контроль срока между созданием и приёмом | Склад |
| Статус давно не меняется | Порог ожидания и задача | Логистика |
| Возврат не оприходован | Связь статуса с документом приёмки | Склад и финансы |
Как проверить интеграцию перед запуском
- создать обычное и многоместное отправление;
- повторить запрос после имитации потери ответа;
- проверить изменение до и после передачи перевозчику;
- обработать неверный адрес и недоступный способ доставки;
- пройти доставку, отказ и полный возврат;
- проверить повтор одинакового статуса;
- отключить внешнюю систему и убедиться, что события не потерялись;
- сверить стоимость и наложенный платёж с учётом.
Качественная интеграция не просто печатает документ перевозчика. Она соединяет продажу, склад, доставку и возврат в одну контролируемую цепочку. В ядре Business Reactor такой обмен логично строить вокруг единого заказа и его событий, чтобы менеджер видел бизнес-состояние, а технические детали оставались доступными для проверки.
