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