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