Интеграция с курьерскими компаниями: как связать сайт, склад и доставку

Где теряется время при ручной работе с доставкой

Менеджер получил заказ, скопировал имя и телефон покупателя, открыл кабинет службы доставки, перенёс адрес, указал вес и состав отправления. Потом вернулся в CRM, добавил трек-номер и отправил его клиенту. Если заказ изменился, часть действий приходится повторить.

Такой процесс может работать при небольшом потоке. Но с ростом числа отправлений появляются очереди на оформление, расхождения между системами и вопросы «Где мой заказ?», на которые сотрудник каждый раз ищет ответ вручную.

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

Что можно автоматизировать

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

Например, портал разработчиков СДЭК описывает логистические интеграции и готовые решения для оформления отправлений. В API Яндекс Доставки для экспресс-доставки и доставки в течение дня предусмотрены расчёт вариантов, создание и подтверждение заявки, получение информации и операции отмены. Условия и доступные функции этих сценариев различаются.

СДЭК, Яндекс Доставку или другую курьерскую компанию выбираем под географию, тип товара, сроки и договор бизнеса. Упоминание сервисов здесь не означает официального партнёрства или наличия готового модуля для любой платформы.

Как может выглядеть путь одного заказа

Представим интернет-магазин, который ведёт учёт в МойСкладе, передаёт сборку своему складу или фулфилменту и пользуется курьерской компанией. Это пример устройства процесса, а не описание уже внедрённого клиентского кейса.

1. Покупатель оформляет заказ. Магазин сохраняет товары, количество, выбранную доставку и необходимые контактные данные.
2. Учётная система принимает заказ. Проверяются артикулы, остатки и условие дальнейшей обработки: например, подтверждение менеджером или поступление оплаты.
3. Склад собирает отправление. Передаются задание и состав заказа. После упаковки уточняются фактические вес, габариты и число мест.
4. Заказ передаётся перевозчику. Интеграция получает результат оформления, сохраняет номер отправления и доступные документы.
5. Команда и клиент получают обновления. Статусы возвращаются в нужную систему, а проблемы попадают ответственному сотруднику.

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

Оплату, доставку и фискализацию тоже связывают отдельными правилами. Статус «доставлено» сам по себе не подтверждает поступление денег или формирование чека. Подключение платёжного сервиса и онлайн-кассы разбирается как отдельный участок интеграции — подробнее в статье об оплате на сайте.

Когда достаточно готового модуля, а когда нужна разработка

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

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

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

Что должно происходить при ошибках

Самая показательная проверка интеграции — работа в ситуации, когда ответ от перевозчика не пришёл вовремя, адрес оказался неполным или один заказ отправили повторно.

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

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

Как оценить пользу в часах

Возьмите один повторяющийся участок: оформление отправления и перенос трек-номера. Замерьте, сколько времени он занимает сейчас, и отдельно — сколько останется на проверку после подключения.

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

С чего начать интеграцию доставки

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

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

В Инфинитум Омниверс начинаем с карты процесса: проверяем возможности сервисов, определяем состав данных и выбираем первый этап. Затем настраиваем обмен, проверяем основные и ошибочные сценарии и передаём инструкции по работе.

Подробнее о направлениях: интеграции сервисов для бизнеса, автоматизация торговли и логистики, базы данных и внутренние системы.