Антон Дегтярёвбитрикс24 для дистрибьютора: связка склад-crm
Менеджер дистрибьютора закрывает сделку на товар, которого на складе уже нет — это не ошибка человека, это дыра между CRM и учётной системой, и на моих проектах она встречается в 7 случаях из 10. У дистрибьютора «воронка как у всех» не работает: продажа идёт не по красивым этапам «звонок → встреча → счёт», а упирается в физический остаток на складе и дилерскую цену конкретного клиента. Разбираю, как чиню это связкой CRM и склада, не заменяя учётную систему целиком.
почему у дистрибьютора не работает «воронка как у всех»
Типовая воронка из коробки — звонок, встреча, коммерческое предложение, счёт, оплата — построена для продажи, где ключевое решение клиента про «купить или нет». У дистрибьютора решение почти всегда другое: клиент уже решил, что покупает, вопрос в том, есть ли нужный товар в нужном объёме прямо сейчас и по какой цене для конкретного дилера.
Из-за этого стандартная воронка либо простаивает (менеджер формально ведёт сделку через этапы, которые не отражают реальный процесс), либо превращается в имитацию: сделка «висит» на этапе «согласование», хотя по факту менеджер ждёт ответа от склада, есть ли товар, а не ответа от клиента.
Рабочая воронка для дистрибьютора строится вокруг проверки наличия и цены как первого реального шага, а не звонка. Это не значит, что нужно полностью переизобретать процесс — базовые принципы настройки воронки я разбирал в статье про настройку воронки продаж, здесь же ключевое отличие — воронка должна получать данные о наличии не из головы менеджера, а из системы учёта в реальном времени.
разрыв между CRM и складом — где именно врёт система
Без связки CRM и учётной системы менеджер видит в карточке товара то, что было актуально на момент последней ручной проверки или последней выгрузки — а не то, что есть на складе прямо сейчас. Частая ошибка на аудитах дистрибьюторов — остатки обновляются раз в сутки ночной выгрузкой, а не в реальном времени, из-за чего к обеду данные уже расходятся с физическим складом: часть товара за утро продали через другой канал, часть зарезервировали под другую сделку.
Результат — менеджер обещает клиенту товар, которого фактически уже нет, клиент соглашается на условия, а через день выясняется, что нужно либо ждать следующую поставку, либо предлагать замену. Это не единичный случай — при ночной синхронизации такая ситуация статистически повторяется на десятках сделок в месяц у активно продающего дистрибьютора.
Второй тип разрыва — цена. У дистрибьютора цена не одна, а зависит от объёма закупки, статуса дилера, региона. Если CRM не связана с прайсовой логикой учётной системы, менеджер либо считает цену вручную по таблице (риск ошибки и разного отношения к похожим клиентам), либо в CRM висит устаревший прайс-лист, обновляемый раз в квартал.
как устроена связка битрикс24 + 1с/wms по остаткам
Технически задача не требует замены учётной системы на CRM или наоборот — обе системы остаются на своих местах, но обмениваются данными через регулярную двустороннюю синхронизацию. От 1С или WMS в Битрикс24 идут актуальные остатки и цены по товарным позициям, привязанные к карточке товара в каталоге CRM. Из Битрикс24 в учётную систему уходит информация о резерве — как только сделка переходит в статус «подтверждена», товар должен резервироваться в учётной системе, а не оставаться доступным для продажи по другому каналу.
Ключевое отличие от разовой выгрузки — частота обновления. Для дистрибьютора с активным оборотом синхронизация раз в сутки практически бесполезна, нужна синхронизация с периодичностью в минуты, а для критичных позиций — резервирование в момент создания сделки, без задержки на ближайший цикл обмена.
Общие принципы связки CRM со складским учётом для менее интенсивного оборота (розница, малый опт) я разбирал в статье про интеграцию с Мой склад — там подход проще, потому что нет дилерской сетки и нет такой чувствительности к скорости синхронизации. Для дистрибуции с постоянным оптовым оборотом и учётом в 1С логика та же, но частота обмена и обработка резервов требовательнее.
дилерские цены и прайсы по сегментам клиентов
Вторая часть связки — не остатки, а цена. У дистрибьютора почти всегда несколько ценовых уровней: розничная, для мелкого опта, для ключевых дилеров с объёмной скидкой. Хранить эту логику вручную в голове менеджера или в отдельной таблице — источник ошибок и неравного отношения к похожим клиентам.
Решение — привязка каждого контакта или компании в CRM к ценовой группе, синхронизированной с учётной системой. Когда менеджер формирует коммерческое предложение или счёт, система автоматически подставляет цену по группе клиента, а не общий прайс с надеждой, что менеджер применит нужную скидку вручную.
Это также закрывает управленческий вопрос: если цена приходит из системы, а не из памяти менеджера, руководитель может быть уверен, что скидки применяются по правилам, а не по личной договорённости конкретного продавца с конкретным клиентом — что на дистрибьюторских проектах регулярно оказывается скрытой причиной падающей маржи, когда её начинают разбирать.
автоматический статус заказа от брони до отгрузки
Третий элемент связки — синхронизация статуса заказа между CRM и складом на всём пути от резерва до отгрузки. Без этого клиент узнаёт о готовности заказа только когда менеджер вручную позвонит на склад и уточнит — а это отдельная задержка и лишняя нагрузка на обе стороны.
Рабочая схема: сделка в статусе «подтверждена» автоматически создаёт резерв в учётной системе; при сборке заказа на складе статус меняется на «в сборке», и это отражается в карточке сделки без участия менеджера; при отгрузке — статус «отгружено» с датой, которую видит и менеджер, и, если настроено уведомление, клиент напрямую.
Такая синхронизация не требует сложной разработки — это типовой сценарий смарт-процесса или роботов Битрикс24, реагирующих на смену статуса в учётной системе через интеграционный слой. Основная работа не в написании кода, а в точном определении, какие статусы склада соответствуют каким статусам сделки — это нужно проговорить с логистикой и складом до настройки, а не после.
что делать с возвратами и пересортом в CRM
Дистрибуция всегда сталкивается с возвратами и пересортом (когда фактически отгружен не тот товар или не то количество), и если это не отражается в CRM, менеджер продолжает видеть искажённую картину по клиенту — например, задолженность, которая на деле уже закрыта возвратом.
Рабочий подход — отдельный статус или тип сделки «возврат/корректировка», связанный с исходной сделкой, а не создание полностью нового независимого обращения. Это сохраняет историю: видно, из какой изначальной поставки возник возврат, и не теряется контекст при разборе повторяющихся проблем с конкретным поставщиком или складской операцией.
Пересорт стоит фиксировать не как исключение, а как штатный процесс с понятным ответственным — обычно это логист, а не менеджер по продажам, и права на создание корректировок стоит настраивать отдельно, чтобы не смешивать функции продажи и складского учёта в одной роли (подробнее о том, как разграничивать такие роли, — в статье про права доступа в Битрикс24).
как измерять эффект — что смотреть через месяц
На одном из проектов дистрибьютора запчастей после настройки связки остатков число сделок, отменённых из-за фактического отсутствия товара на складе, снизилось примерно вдвое за первый квартал работы новой схемы. Это основной показатель, который стоит отслеживать в первую очередь — не общая выручка (на неё влияет слишком много факторов), а именно доля сорванных из-за наличия сделок.
Второй показатель — время от подтверждения заказа до фактической отгрузки. Если связка настроена верно, этот интервал должен сократиться за счёт того, что информация о готовности не ждёт ручного звонка на склад, а идёт автоматически.
Третий — расхождение между ценой в CRM и фактической ценой в учётной системе на момент оплаты. Если после настройки дилерских цен это расхождение не ушло в ноль — значит связка настроена только частично, и стоит вернуться к разделу про сегментацию цен и проверить, все ли ценовые группы клиентов действительно привязаны к системе, а не остались на ручном контроле у отдельных менеджеров.