Оформлюєте накладні вручну й шукаєте статуси на сайтах перевізників? Як CRM створює накладну із замовлення й тримає статус доставки в угоді.
Замовлення зібране, оплачене, клієнт чекає посилку — лишається відправити. І тут менеджер відкриває особистий кабінет служби доставки, заново вбиває адресу й телефон клієнта, вагу та вміст, створює накладну, копіює трек-номер (якщо не забув) назад у CRM. А за день клієнт пише «де моя посилка?», і менеджер знову йде на сайт перевізника — шукати статус вручну. Коли відправлень десятки на день, цей ручний шар з'їдає години й плодить помилки.
Інтеграція доставки в CRM прибирає цю подвійну роботу: накладна створюється прямо із замовлення, а трек-номер і статуси посилки автоматично повертаються в картку угоди. Розберемо, як це влаштовано й де проходять чесні межі.
Що відбувається без інтеграції
Поки відправлень мало, ручне оформлення стерпне. Але зі зростанням замовлень накладні «на сайті перевізника» стають джерелом помилок і втраченого часу:
- адресу й телефон набирають заново — одруківка, і посилка їде не туди;
- трек-номер забули перенести в угоду, і тепер його не знайти;
- статуси дивляться вручну на сайтах різних служб, у кожної свій кабінет;
- повернення помічають пізно — коли посилка вже їде назад.
Кожна така дрібниця б'є по клієнту вже після оплати, коли він чекає замовлення. А менеджер замість роботи з угодами займається переписуванням адрес і відстеженням чужих сайтів.
Як це працює: накладна із замовлення, статуси назад
Щоб CRM працювала з доставкою, вона інтегрується зі службою доставки через її API. Далі ланцюжок простий:
- Замовлення в CRM уже містить дані — адреса, телефон, товар і вага вказані в картці.
- Із картки створюється накладна обраної служби: дані підставляються автоматично, без повторного введення.
- Служба повертає трек-номер, і він одразу зберігається в угоді.
- Статуси підтягуються самі в міру руху посилки: відправлено, у дорозі, вручено, повернення.
Ключова ідея — адресу й дані вводять один раз, у замовленні, а не переписують у кабінет перевізника. Менше ручного перенесення — менше помилок і менше часу на рутину.
Статуси доставки прямо в картці
Коли статус посилки видно в угоді, знімається цілий потік дрібної метушні. Менеджер відповідає клієнту «посилка в дорозі, буде завтра», не заходячи на сайт перевізника. Керівник бачить по замовленнях, що вже вручено, а що застрягло.
Окремо важливі проблемні статуси. Якщо посилка зависла на сортуванні або пішла на повернення, це видно одразу — можна зв'язатися з клієнтом чи службою, поки ситуація свіжа, а не за тиждень, коли замовлення вже повернулося. Доставка — це фінал угоди, і саме на ньому найприкріше втрачати клієнта через дрібну неуважність.
Чому це важливіше, ніж здається
Здається, що оформити накладну вручну — хвилинна справа. Але помножте цю хвилину на десятки відправлень на день, додайте одруківки в адресах, загублені трек-номери й дзвінки «де посилка?» — і набігає відчутне навантаження. А головне, кожна помилка стається після оплати, коли клієнт уже заплатив і чекає: саме тут погана доставка перекреслює хороший продаж.
Коли вся історія відправлень живе в угоді, а не в кабінетах різних служб і в пам'яті менеджерів, бізнес отримує не лише швидкість, а й прозорість: видно, чим і коли відправляли, що дійшло, а що ні.
Шлях посилки: замовлення → накладна → трек → статуси
Найпростіше побачити логіку на схемі. Ліворуч — замовлення в CRM з адресою, товаром і клієнтом. Стрілка праворуч — накладна, створена із замовлення. Праворуч — служби доставки. Стрілка назад — трек-номер і статуси, що повертаються в угоду.
Обмін іде у два боки: із CRM у службу йде накладна з даними замовлення, а назад приходять трек-номер і статуси. Жодного ручного копіювання між вікнами.
Без інтеграції vs доставка й накладні в CRM
| Аспект | Вручну | У CRM |
|---|---|---|
| Оформлення накладної | вручну на сайті перевізника | із замовлення, дані підставляються |
| Адреса отримувача | набирають заново, ризик помилки | береться з картки клієнта |
| Трек-номер | копіюють вручну або гублять | сам зберігається в угоді |
| Статус посилки | шукають на сайтах перевізників | видно в угоді: у дорозі, вручено |
| Повернення | легко проґавити | статус «повернення» видно одразу |
| Кілька служб | у кожної свій кабінет | усі в одній системі |
Де межі: доставку виконує служба
Інтеграція економить час, але в неї є чіткі рамки, про які варто сказати прямо.
- Саму доставку виконує служба, а не CRM. Строки, збереження вантажу, робота кур'єрів — на боці перевізника. CRM створює накладну й показує статус через його API, але посилку везе служба.
- Інтеграція залежить від API конкретних служб. Можливості, поля й ліміти в перевізників різні; підключають ті служби, з якими ви реально працюєте, а не «будь-яку з коробки».
- Точність адреси — на тому, хто вносить дані. CRM підставить адресу з картки, але за її вірність відповідає людина: помилка в адресі — проблемна доставка.
- Це для товарного бізнесу. Інтеграція доставки потрібна там, де фізично відправляють посилки; для послуг вона не застосовна.
Під ваші служби та процеси
У готових коробкових рішеннях підтримка доставки часто обмежена парою служб і одним сценарієм. На практиці ж у кожного бізнесу свої перевізники, свої типи відправлень і своя логіка: хтось шле дрібні посилки, хтось — великогабарит, хтось працює з післяплатою. Тому інтеграцію доставки має сенс вбудовувати під вашу модель — під ті служби й ті процеси, які у вас реально є.
Часто замовлення приходять не по телефону, а із зовнішніх каналів — наприклад, з маркетплейсів; як це влаштовано, ми розбирали в матеріалі про інтеграцію CRM з маркетплейсами, і доставка логічно закриває цей цикл. А між оплатою та відправкою зручно, коли й гроші, і посилка ведуться в одній системі — про приймання платежів ми писали в статті про онлайн-оплати в CRM.
Перш ніж впроваджувати інтеграцію доставки, корисно прикинути, скільки годин на місяць іде на ручне оформлення накладних і пошук статусів посилок на сайтах перевізників — калькулятор економії часу допоможе перевести це в цифри.
Часті запитання
Що дає інтеграція доставки в CRM?
Вона дозволяє створювати накладні служб доставки прямо із замовлення, а трек-номер і статуси посилки повертає в картку угоди. Адресу й дані вводять один раз, а не переписують у кабінет перевізника.
Які служби доставки можна підключити?
Ті, у яких є API і з якими ви працюєте. Можливості в перевізників різняться, тому набір служб добирається під ваші напрями відправлень, а не «будь-яка з коробки».
Звідки береться адреса для накладної?
Із картки клієнта й замовлення в CRM. Дані підставляються в накладну автоматично, що знижує ризик одруківок порівняно з ручним введенням на сайті перевізника.
Як оновлюється статус посилки?
Статуси підтягуються зі служби доставки по її API в міру руху посилки — відправлено, у дорозі, вручено, повернення — і відображаються прямо в угоді, без заходу на сайт перевізника.
Хто відповідає за саму доставку й строки?
Служба доставки. CRM створює накладну й показує статус, але перевезення, строки та збереження вантажу забезпечує перевізник, а не система.
Багато відправляєте й тонете в накладних і трек-номерах на сайтах перевізників? Розкажіть про свої служби доставки — запропонуємо, як вбудувати оформлення накладних і відстеження саме під вашу модель роботи.
