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