Інтеграція CRM зі службою доставки повинна прибирати повторне введення та водночас зберігати контроль виконання замовлення. Менеджер один раз підтверджує продаж, система створює відправлення, зберігає ідентифікатор перевізника й оновлює стан до вручення, відмови або повернення.
Поява номера відправлення не завершує процес. Зміна адреси, скасування, кілька місць, післяплата, переадресація, зберігання та повернення впливають на комерційне замовлення. Події доставки мають запускати наступну дію, а не лише змінювати підпис.
Визначте межі відповідальності
CRM зберігає клієнта, домовленості й комерційний стан. Склад підтверджує фактичне комплектування. Перевізник відповідає за маршрут і фізичне переміщення. Інтеграція не повинна змушувати одну систему вгадувати факти іншої.
| Дані | Джерело | Одержувач |
|---|---|---|
| Одержувач, контакти, спосіб оплати | Підтверджене замовлення CRM | Служба доставки |
| Місця, вага, готовність до відвантаження | Склад | CRM і перевізник |
| Ідентифікатор і маршрут відправлення | Перевізник | CRM |
| Стан переміщення та вручення | Перевізник | CRM і сповіщення |
| Факт приймання повернення | Склад після перевірки | CRM та облік |
Якщо вагу визначає склад, менеджер не повинен вводити її приблизно. Якщо адресу підтверджує клієнт, зміна після пакування потребує окремого сценарію. Ці правила фіксують до реалізації API.
Передавайте лише підтверджене замовлення
Чернетка угоди не є відправленням. Зазвичай потрібні перевірені контакти, обраний спосіб доставки, остаточний склад замовлення та дозвіл на комплектування. Для окремих бізнесів додаються оплата, кредитний ліміт або ручна перевірка.
- CRM перевіряє обов’язкові дані та дозволений перехід.
- Склад підтверджує пакування або надає фактичні місця й вагу.
- Запит отримує унікальний внутрішній ідентифікатор операції.
- Перевізник повертає власний ідентифікатор і параметри.
- CRM зберігає зв’язок і не допускає випадкового повторного створення.
Не переносьте всі статуси перевізника у воронку
Детальні технічні стани корисні для діагностики, але менеджеру потрібні управлінські групи. Кілька подій переміщення можна об’єднати у «в дорозі», зберігаючи оригінальний код для перевірки.
| Група CRM | Події доставки | Дія |
|---|---|---|
| Готується | Створено, але ще не прийнято | Контроль фізичного передавання |
| У дорозі | Прийнято та переміщується | Очікування контрольного строку |
| Очікує одержувача | У точці видачі або передано кур’єру | Нагадування за правилами бізнесу |
| Доставлено | Вручення підтверджено | Закриття виконання та наступний контакт |
| Проблема | Відмова, затримка, неправильні дані | Завдання відповідальному |
| Повернення | Рухається назад або повернено | Приймання та фінансова перевірка |
Статус має запускати дію
Якщо створене відправлення не прийняте перевізником у контрольний строк, склад отримує завдання. Якщо клієнт довго не забирає посилку, CRM планує контакт. Якщо зафіксована відмова, угода не закривається автоматично, а очікує приймання товару та фінансового рішення.
Однакові події можуть надходити повторно. Повторний callback не повинен створювати дублікати завдань або повідомлень.
Зміна та скасування потребують окремих сценаріїв
До передавання перевізнику адресу або параметри можна контрольовано змінити. Після приймання доступні лише окремі операції служби доставки. Інтеграція має показати зовнішній результат, а не просто записати непідтверджене значення в CRM.
Скасоване відправлення не видаляють з історії. Зберігають стан, причину, час запиту та відповідь перевізника.
Повернення завершується після складської перевірки
Статус «повернено» підтверджує доставку посилки назад, але не кількість і якість товару. Склад має прийняти й перевірити її, перш ніж позиція стане доступною. Фінансовий контур окремо фіксує повернення коштів, комісію та вартість доставки.
| Ризик | Контроль інтеграції | Відповідальний |
|---|---|---|
| Дублі відправлень | Унікальний ключ і безпечний повтор | Інтеграція |
| Помилкова адреса | Перевірка та явна відповідь | Менеджер |
| Відправлення не передано | Строк між створенням і прийманням | Склад |
| Статус довго не змінюється | Поріг очікування та завдання | Логістика |
| Повернення не оприбутковано | Зв’язок статусу з документом приймання | Склад і фінанси |
Перевірки перед запуском
- створити звичайне та багатомісне відправлення;
- повторити запит після імітації втраченої відповіді;
- перевірити зміни до і після приймання перевізником;
- обробити неправильну адресу й недоступну послугу;
- пройти доставку, відмову та повернення;
- надіслати той самий статус двічі;
- тимчасово вимкнути зовнішню систему й не втратити події;
- звірити вартість і післяплату з обліком.
Якісна інтеграція не просто створює документ перевізника. Вона поєднує продаж, склад, доставку й повернення в один контрольований процес. Навколо ядра Business Reactor такий обмін доцільно будувати на єдиному замовленні та його подіях, щоб менеджер бачив бізнес-стан, а технічні деталі залишалися доступними для перевірки.
