Интеграция доставки с CRM: какие данные передаются и как настроить обмен

Что ломается, когда CRM и доставка живут отдельно

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

Типичные последствия разрыва выглядят так:

• Двойной ввод и опечатки. Адрес, набранный второй раз, — это адрес с шансом на ошибку. Исполнитель уезжает не туда, а разбираться приходится уже в поле.
• Отставание статусов. Менеджер не видит, что происходит с заказом, и отвечает клиенту «сейчас уточню» вместо конкретного ответа. Каждое такое уточнение — звонок диспетчеру.
• Потерянные заявки. Сделка перешла на стадию «передано в доставку», но до диспетчера не дошла: никто не заметил, пока не позвонил клиент.
• Несходящаяся отчётность. В CRM одно число отгрузок, в операционной системе другое, и объяснить разницу может только сотрудник с хорошей памятью на детали.

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

Какие данные ходят между CRM и системой доставки

Обмен почти всегда двусторонний, и его полезно описать двумя короткими списками — что уходит из CRM и что возвращается обратно. Из CRM в систему доставки обычно передаются:

• заявка или заказ: номер, тип работ, состав, комментарий менеджера;
• адрес выполнения с уточнениями по доступу — подъезд, этаж, пропуск, кому звонить на месте;
• контакты получателя и согласованное окно времени;
• сумма и способ оплаты, если исполнитель принимает деньги;
• признак срочности или приоритета — чтобы диспетчер видел, что нельзя переносить на завтра.

Обратно, из системы доставки в CRM, возвращаются факты выполнения:

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

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

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

Способы обмена: API, вебхуки и выгрузка файлом

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

• Обмен через API. Системы обращаются друг к другу напрямую. Самый гибкий вариант: передаётся любой набор полей, логика полностью под контролем. Взамен требуется настройка и понимание, какой метод вызывается на каком событии.
• Вебхуки. CRM сама сообщает о переходе сделки на нужную стадию, а система доставки — об изменении статуса. Данные обновляются почти мгновенно и без лишних опросов, но нужно заранее продумать повторные попытки: если приёмник был недоступен, событие не должно бесследно пропасть.
• Выгрузка файлом. Заявки уходят пачкой по расписанию, например из таблицы. Самый быстрый старт: доработок не требуется, подходит, когда заказы формируются к утру и в течение дня меняются редко.
• Промежуточный коннектор. Отдельный сервис-мост согласует форматы, хранит соответствия и правила. Разумен, когда источник не один: часть заявок приходит из CRM, часть из учётной системы, часть из формы на сайте.

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

itlogist поддерживает интеграции с AmoCRM, Bitrix24, 1С и Excel — заявки попадают в работу из привычного источника, без ручного перебивания. Что происходит с заявкой дальше — распределение по исполнителям, маршруты на карте в реальном времени, мобильное приложение исполнителя с фотоотчётами и чек-листами, личный кабинет заказчика со статусами — собрано на странице Возможности itlogist.

Источник истины, ключ соответствия и обработка ошибок

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

• Ключ соответствия. По какому полю заявка в доставке сопоставляется со сделкой в CRM — номер сделки, внутренний идентификатор, номер заказа. Ключ должен быть один, неизменный и передаваться в обе стороны. Сопоставление по телефону или адресу разваливается на повторных заказах того же клиента.
• Источник истины по каждому полю. Кто главный по адресу, кто по времени доставки, кто по сумме. Если менеджер поменял окно в CRM, а диспетчер — в системе доставки, побеждать должен не тот, кто нажал позже, а тот, кто определён правилом.
• Единая статусная модель. Стадии воронки в CRM и статусы исполнения — разные сущности. Нужна явная таблица соответствия: какой операционный статус в какую стадию переводит сделку и какие переходы запрещены. Иначе сделка начнёт откатываться назад при каждой повторной попытке доставки.
• Поведение при ошибке. Что происходит, если адрес пустой, клиент не найден или приёмник не ответил. Рабочий сценарий: заявка не молча теряется, а попадает в очередь на повтор или в список для ручного разбора, и кто-то за этот список отвечает.

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

Порядок внедрения: от одного сценария к полному потоку

Интеграцию не стоит запускать сразу во всю ширину. Рабочая последовательность выглядит так и обычно укладывается в несколько коротких итераций.

• Опишите один сценарий целиком. Возьмите самый массовый тип заказа и пройдите его от стадии в CRM до отметки о выполнении. Нестандартные случаи — возвраты, частичные отказы, повторные выезды — добавляйте вторым шагом.
• Согласуйте карту полей. Та самая таблица из четырёх колонок. Пока она не подписана обеими сторонами, начинать настройку рано.
• Наведите порядок в данных. Нормализованные адреса, актуальные телефоны, комментарии по доступу. Интеграция ускоряет и передачу мусора тоже: плохой адрес просто быстрее доедет до исполнителя.
• Проверьте на тестовом потоке. Десяток заявок в обе стороны, включая заведомо ошибочные: без адреса, с дублем, с отменой после назначения.
• Уберите ручной перенос. Как только обмен пошёл, старый способ нужно отменить. Две параллельные схемы всегда заканчиваются расхождением данных и спором, какая из них правильная.
• Договоритесь о поддержке. Кто смотрит очередь ошибок, как быстро реагирует, что делает при недоступности одной из систем.

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

Порог входа здесь ниже, чем принято думать: запуск занимает 7 дней, без долгосрочных контрактов, а платформа рассчитана на команды от 5 до 100 исполнителей. То есть связку с CRM можно проверить на живом потоке заказов и сравнить с зафиксированной базой уже через месяц.