Интеграция Битрикс24 с сервисом доставки: статусы заказов в сделке

Менеджер закрыл сделку, склад отгрузил товар, курьерская служба приняла посылку. Через три дня клиент звонит и спрашивает, где заказ. Менеджер открывает карточку в Битрикс24 и видит там стадию «Отгружено» и больше ничего. Трек-номер лежит у кладовщика в переписке, статус висит в личном кабинете службы доставки, а о том, что курьер дважды не застал получателя, в CRM никто не знает. Руководитель отдела продаж узнаёт об этом последним, обычно когда клиент уже оформил возврат.

Интеграция Битрикс24 с сервисом доставки нужна именно для этого: статусы заказа должны приходить в сделку сами, без ручного копирования. Способов подключения два, и выбирать между ними стоит до того, как подрядчик начнёт писать код.

Где теряется информация о доставке без интеграции

В компаниях, которые продают товар с доставкой, путь заказа после оплаты обычно разрывается на три системы. В CRM живёт сделка и история общения с клиентом. В учётной системе или складской таблице остаётся факт отгрузки. В кабинете курьерской службы хранится всё, что происходит с посылкой в пути. Пока заказов немного, менеджер держит всё в голове и переносит статусы руками. Когда заказов становится несколько десятков в день, ручной перенос превращается в отдельную работу, которую никто не хочет делать.

Последствия выглядят одинаково почти в любом бизнесе:

• клиент узнаёт о задержке раньше менеджера и звонит уже раздражённым;
• неврученные посылки возвращаются на склад, и никто вовремя не связывается с покупателем, чтобы договориться о повторной доставке;
• сделка закрывается как успешная в момент отгрузки, хотя деньги при наложенном платеже ещё не пришли, и отчёт по выручке расходится с реальностью;
• руководитель не видит, сколько заказов застряло в пути и у какой службы доставки больше всего возвратов.

В каждом из этих случаев событие происходит во внешней системе, а реагировать на него должен человек, который сидит в CRM и об этом событии не знает.

Два подхода к интеграции Битрикс24 с доставкой

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

Службы доставки внутри Битрикс24 и REST-обработчик

В Битрикс24 есть собственный механизм служб доставки, который работает вместе с товарами, оплатами и отгрузками. В русскоязычной справке Битрикс24 путь к настройке описан так: Сайты и Магазины > Еще > Платежи и Доставка > Службы доставки. Там же указано, что службы бывают автоматизированными, то есть подключёнными к внешнему сервису, и настраиваемыми, где стоимость и сроки вы задаёте сами. В перечне автоматизированных служб справка называет Почту России, DPD, СДЭК и Яндекс Доставку. Это ориентир на российский рынок, поэтому доступность конкретных служб для казахстанского портала нужно проверять в своём аккаунте, а не рассчитывать на неё заранее.

Если нужной службы в списке нет, её можно подключить через REST API. Для этого существует метод sale.delivery.handler.add: он регистрирует обработчик службы доставки, в настройках которого указываются адреса вебхуков. Документация Битрикс24 описывает три таких события: расчёт стоимости доставки, создание заказа на доставку и отмена заказа. Адрес для расчёта стоимости обязателен, два других добавляются, если внешний сервис поддерживает эти операции. Для работы всех методов доставки приложению нужны права sale.

Для статусов в CRM важнее то, что происходит после создания заказа. Когда Битрикс24 вызывает вебхук создания заказа, внешняя система отвечает ему своим идентификатором заявки. Дальше она может сообщать о ходе доставки методом sale.delivery.request.update. В него передаётся статус: произвольный текст, например «Курьер назначен», и семантика статуса, у которой два значения, process для заявки в работе и success для успешно завершённой. Можно передать и набор свойств: название и значение, например номер машины или телефон водителя, причём значение с тегом phone отображается как телефонный номер. По умолчанию свойства накапливаются, а параметр OVERWRITE_PROPERTIES заменяет их целиком. Флаг FINALIZE со значением Y завершает заявку. Для уведомлений по заявке предусмотрен отдельный метод sale.delivery.request.sendmessage.

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

Статусы на уровне сделки: вебхуки и поля CRM

Второй подход проще и встречается чаще. Многие компании в Казахстане оформляют отправку не в Битрикс24, а в кабинете курьерской службы, в учётной системе или через склад фулфилмента. Встроенные службы доставки при этом не используются, и сделка остаётся главным объектом, в котором работает менеджер.

В этом случае интеграция строится вокруг самой сделки. Внешний сервис или промежуточный скрипт получает статусы от службы доставки через её API и записывает их в Битрикс24 через входящий вебхук стандартными методами CRM: crm.deal.update меняет стадию и заполняет пользовательские поля, а crm.timeline.comment.add оставляет в таймлайне сделки комментарий с подробностями. В обратную сторону работает исходящий вебхук: робот на нужной стадии сделки отправляет данные внешнему обработчику, и тот создаёт отправление в службе доставки.

Плюс этого подхода в том, что он не зависит от торгового модуля и подходит под любую службу, у которой есть API. Минус в том, что логику сопоставления статусов, повторные попытки и обработку ошибок придётся писать и сопровождать самостоятельно или силами подрядчика.

Какие статусы доставки нужны в сделке

У служб доставки бывают десятки внутренних статусов: принят на сортировку, передан на магистраль, прибыл в сортировочный центр, передан курьеру. Тянуть их все в воронку продаж не нужно. Стадия сделки должна меняться только тогда, когда от менеджера требуется действие или когда меняется финансовый результат. Остальное достаточно записать в поле или в таймлайн.

Рабочая схема сопоставления для большинства интернет-магазинов и дистрибьюторов выглядит так:

Что происходит в службе доставки	Что меняется в сделке	Нужно ли действие менеджера
Отправление создано, присвоен трек-номер	Стадия «Передан в доставку», трек-номер записан в поле	Нет, клиенту уходит уведомление с трек-номером
Посылка в пути, промежуточные сканы	Только комментарий в таймлайне или поле «Текущий статус доставки»	Нет
Задержка сверх нормативного срока	Стадия не меняется, ставится задача ответственному	Да, предупредить клиента
Попытка вручения не удалась	Стадия «Проблема с доставкой»	Да, согласовать новую дату
Вручено, оплата при получении прошла	Стадия «Доставлено», при необходимости сделка закрывается успешно	Нет, можно запросить отзыв
Возврат отправителю	Стадия «Возврат», сделка не считается выручкой	Да, выяснить причину

Для хранения данных удобно завести в сделке несколько пользовательских полей: служба доставки, трек-номер, текущий статус текстом, дата последнего обновления и плановая дата вручения. Поле с датой последнего обновления окажется полезнее, чем кажется: по нему легко найти сделки, по которым служба доставки давно ничего не присылала.

Как устроен обмен данными: пошаговая схема

Для примера возьмём второй подход, со статусами на уровне сделки, как самый распространённый. Порядок работ обычно такой.

1. Описать воронку доставки. Перед программированием договоритесь, какие стадии появляются в воронке после оплаты и кто отвечает за каждую. Если стадий доставки много, их иногда выносят в отдельную воронку, куда сделка переходит после оплаты.
2. Создать поля в сделке. Трек-номер, служба доставки, текстовый статус, дата обновления. Коды пользовательских полей в Битрикс24 начинаются с UF_CRM_, и именно эти коды потом используются в запросах.
3. Составить таблицу соответствия статусов. Список статусов берётся из документации API конкретной службы доставки. Каждому статусу назначается одно из действий: сменить стадию, записать поле, поставить задачу или ничего не делать.
4. Настроить создание отправления. Робот на стадии «Готов к отправке» вызывает исходящий вебхук. Обработчик берёт из сделки адрес, контакт и состав заказа, создаёт отправление в службе доставки и записывает полученный трек-номер обратно в сделку.
5. Настроить получение статусов. Если служба доставки умеет сама присылать уведомления на ваш адрес, обработчик принимает их. Если нет, скрипт по расписанию опрашивает статусы всех активных отправлений. Затем по таблице соответствия он обновляет сделку.
6. Добавить журнал и контроль ошибок. Каждый входящий статус и каждый ответ Битрикс24 записываются в лог. Без этого через месяц никто не сможет объяснить, почему конкретная сделка застряла.
7. Протестировать на реальных отправлениях. Прогоните десяток посылок через все сценарии, включая неудачное вручение и возврат, и только потом включайте интеграцию для всех заказов.

Если заказы проходят через склад и учётную систему, стоит заранее решить, кто источник истины по факту отгрузки. Смежная тема разобрана в статье про автоматизацию склада и логистики через Битрикс24.

Пример: магазин отделочных материалов с доставкой по Казахстану

Пример условный, собирательный, но построен на типичной ситуации. Компания в Алматы продаёт отделочные материалы через сайт и отдел продаж, отправляет заказы по регионам через две курьерские службы. В день выходит от 40 до 60 отправлений. До интеграции трек-номера вносил кладовщик в общую таблицу, а менеджеры раз в день вручную сверяли статусы в двух кабинетах.

После внедрения схема стала такой. Сделка после оплаты переходит в стадию «Готов к отправке», робот вызывает обработчик, тот создаёт отправление в нужной службе в зависимости от города и записывает трек-номер в сделку. Клиенту автоматически уходит сообщение с номером для отслеживания. Скрипт раз в час забирает статусы по активным отправлениям. Промежуточные статусы пишутся в поле и в таймлайн, а неудачное вручение переводит сделку в стадию «Проблема с доставкой» и ставит менеджеру задачу со сроком в тот же день.

Первым делом менеджеры перестали тратить время на ручную сверку кабинетов. Руководитель увидел в отчёте, что у одной из служб доля возвратов заметно выше, и перераспределил направления. Выручка в отчётах стала считаться по факту вручения, а не по факту отгрузки, поэтому исчез разрыв между CRM и бухгалтерией по наложенному платежу. Цифры экономии здесь сознательно не приводятся: они сильно зависят от объёма заказов и от того, насколько аккуратно работали до интеграции.

Почему статусы перестают приходить в сделку

Интеграция с доставкой редко ломается громко. Обычно она тихо перестаёт обновлять часть сделок, и замечают это через несколько недель.

Вебхук создан от уволенного сотрудника

Входящий вебхук в Битрикс24 работает с правами пользователя, который его создал. Если этого сотрудника уволили и деактивировали, запросы начинают возвращать ошибку доступа. Лучше создавать вебхук от служебной учётной записи с понятным названием.

Изменили стадии воронки

Кто-то переименовал или удалил стадию, а скрипт по-прежнему передаёт старый код стадии. Сделка либо не двигается, либо уходит не туда. Коды стадий нужно держать в настройках обработчика, а не прописывать в коде, и проверять после каждой перестройки воронки.

Служба доставки поменяла API или список статусов

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

Трек-номер ввели вручную с ошибкой

Лишний пробел или буква вместо цифры, и статус по такому номеру никогда не найдётся. Если отправления иногда создаются руками, добавьте проверку формата номера и отметку в сделке, что статусы по ней не приходят.

Скрипт упирается в лимиты запросов

При массовом опросе статусов скрипт может упираться в ограничения на частоту запросов у службы доставки или у Битрикс24. Запросы стоит распределять во времени и группировать, а отправления в финальных статусах исключать из опроса.

Один статус приходит несколько раз

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

В сделке неполный адрес или телефон

Этот сбой случается ещё до первого статуса. Робот вызывает обработчик, а служба доставки отказывается создавать отправление: в адресе нет номера дома, телефон записан в свободной форме, у контакта не указан город. Если ответ с ошибкой никуда не выводится, сделка стоит на стадии «Готов к отправке» и выглядит так, будто всё в порядке. Ошибку от службы доставки нужно записывать в таймлайн и сразу ставить задачу менеджеру, а обязательные для отправки поля лучше проверять ещё до перехода сделки на эту стадию.

Что автоматизировать роботами после подключения статусов

Сама по себе интеграция просто доставляет данные в CRM. Пользу бизнесу она начинает приносить, когда на смену стадий навешаны автоматические действия. Роботы Битрикс24 срабатывают при переходе сделки на стадию, поэтому большую часть сценариев можно собрать без дополнительного программирования.

• На стадии «Передан в доставку» клиент получает трек-номер через подключённый канал: SMS, почту или мессенджер.
• На стадии «Проблема с доставкой» менеджеру ставится задача с коротким сроком и понятным описанием того, что случилось и что предложить клиенту.
• Через день-два после стадии «Доставлено» клиенту уходит просьба оставить отзыв.
• Если возвращается заказ дороже определённой суммы, об этом узнаёт руководитель.
• Для расходных товаров через заданный срок после вручения появляется новая сделка или задача позвонить клиенту.

Отдельно продумайте, что происходит с оплатой. Если клиент платит при получении, сделка не должна считаться выигранной до статуса вручения, иначе отчёт покажет выполненный план при деньгах, которые ещё едут с курьером.

С чего начать и когда звать подрядчика

Первый шаг не требует программиста. Выпишите, какие службы доставки вы используете, как сейчас создаются отправления и какие события по посылке требуют реакции менеджера. Уже на этом этапе часто оказывается, что половина проблем решается перестройкой воронки и парой роботов, а интеграция нужна только для автоматической передачи трек-номеров и статусов.

Дальше посмотрите, есть ли у вашей службы доставки открытый API и документация к нему. Проверьте в Битрикс24 Маркет готовые приложения под эту службу: иногда готовое решение закрывает задачу быстрее собственной разработки. Перед установкой уточните у разработчика приложения, какие статусы оно передаёт, работает ли со сделками или только с заказами и что происходит при смене тарифа портала.

Если готового решения нет или оно не подходит под вашу воронку, интеграцию лучше делать с подрядчиком, который потом будет её сопровождать. Службы доставки обновляют API, воронки меняются, сотрудники уходят, и интеграция без присмотра за полгода обрастает незаметными сбоями. Команда B2BPRO берёт на себя внедрение и настройку Битрикс24, включая интеграции с курьерскими службами, складом и учётом: от описания воронки доставки и таблицы статусов до обработчика с журналом ошибок и роботов на каждой стадии.

Частые вопросы

Можно ли подключить службу доставки к Битрикс24 без программиста?

Можно, если для вашей службы есть готовое приложение в Битрикс24 Маркет или она есть среди встроенных автоматизированных служб. Если ни того, ни другого нет, понадобится обработчик, который работает с API службы доставки и REST API Битрикс24.

Чем статусы в заявке на доставку отличаются от стадий сделки?

Статус заявки на доставку передаётся методом sale.delivery.request.update и относится к отправлению, созданному через механизм служб доставки Битрикс24. Стадия сделки описывает этап продажи в воронке. В интеграции на уровне сделки статусы службы доставки сопоставляются со стадиями и полями через таблицу соответствия.

Нужно ли переводить сделку на новую стадию при каждом статусе посылки?

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

Что делать, если статусы перестали приходить в Битрикс24?

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