Опт vs розница в заявке: правила маршрутизации

Почему одного поля «тип клиента» недостаточно

Типичная ошибка при настройке маршрутизации — доверять единственному полю из формы. Клиенты выбирают «физлицо» или «организация» интуитивно: ИП-дистрибьютор отметит «физлицо», потому что привык; закупщик крупной сети заполнит форму с личной почты и не укажет ИНН. Результат — оптовая заявка попадает к розничному менеджеру, который не знает прайс-листа для партнёров и теряет клиента за 15 минут.

Правильная классификация — это не одно поле, а три слоя верификации:

1. Декларативные данные — что клиент указал в форме (ИНН, тип документа, объём).
2. Обогащение — что система проверила автоматически (ОКВЭД по ИНН, домен email, история в CRM).
3. Квалификационный контакт — что уточнил менеджер или бот, когда данных недостаточно.

Только связка трёх слоёв даёт целевой показатель: < 5% ручных переназначений по типу клиента.

Таблица сигналов классификации

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

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

Decision tree: от заявки до назначения менеджера

Алгоритм из 7 шагов, который можно реализовать роботами Битрикс24 или триггерами amoCRM:

Шаг 1. Поступление заявки. Система фиксирует источник (форма сайта, B2B-портал, звонок, email) и запускает автоматическую проверку.

Шаг 2. Проверка истории в CRM. Есть ли контрагент с таким ИНН / email / телефоном? Если да — тип клиента берётся из карточки, заявка направляется к менеджеру последней сделки. Флаг «двойной сегмент» → ручное подтверждение.

Шаг 3. Обогащение по ИНН. ИНН указан? → запрос в СПАРК или Контур.Фокус → получаем ОКВЭД, ОПФ, статус организации. ИНН не указан → переход к шагу 6 (fallback).

Шаг 4. Классификация по ОКВЭД + объёму. ОКВЭД 46/51 или объём ≥ минимальной партии → оптовый трек. ОКВЭД 47 или физлицо без ИНН + объём < минимальной партии → розничный трек.

Шаг 5. Проверка дополнительных сигналов. Если ОКВЭД неоднозначен (например, ИП с ОКВЭД 47, но объём оптовый) → комбинируем: тип запрашиваемого документа + домен email + канал входа. Два и более сигнала указывают на опт → оптовый трек с флагом «требует квалификации».

Шаг 6. Fallback-очередь. Данных недостаточно для автоматической классификации → заявка в общую очередь с автозадачей «квалификационный звонок» и SLA 30 минут. Ответственный — дежурный менеджер или супервайзер.

Шаг 7. Назначение и SLA-таймер. После определения трека — назначение менеджера по правилу (не round-robin, а по специализации и загрузке), старт SLA-таймера согласно треку.

Чеклист обязательных полей формы и карточки лида

Минимальный набор для корректной автоматической маршрутизации:

• ИНН — обязательное поле для юрлиц и ИП; для физлиц — необязательное, но запрашиваемое
• Тип запрашиваемого документа — выпадающий список: «счёт-фактура / договор поставки» vs «чек / онлайн-оплата»
• Объём / количество — числовое поле; система сравнивает с порогом минимальной партии
• Email — автопарсинг домена для определения корпоративного vs публичного
• Канал входа — UTM-метки или источник лида (B2B-портал, форма сайта, звонок)
• Организационно-правовая форма — ООО / АО / ИП / физлицо (можно автоподставлять по ИНН)
• Комментарий / цель запроса — свободное поле; NLP-правило или ключевые слова («дилер», «партия», «перепродажа») как вспомогательный сигнал

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

SLA по трекам

Оптовый и розничный цикл сделки принципиально разные. Смешение SLA убивает конверсию в обоих треках.

Серые зоны: правила обработки

Серые зоны — не исключение, а норма. В смешанных каналах они составляют 15–25% входящего потока.

Физлицо с оптовым запросом. Нет ИНН, но объём ≥ минимальной партии или запрашивает договор поставки. Правило: направить в fallback с задачей «уточнить статус» — возможно, клиент оформляет ИП или закупает для организации. Не маршрутизировать автоматически в розницу.

Мелкий опт (объём ниже минимальной партии, но есть ИНН и ОКВЭД 46). Правило: оптовый трек с флагом «мелкий опт» — менеджер квалифицирует потенциал роста. Не отправлять в розницу только из-за объёма.

Клиент с историей в обоих сегментах. CRM находит сделки и в оптовой, и в розничной воронке. Правило: направить к менеджеру последней успешной сделки + флаг «двойной сегмент» + ручное подтверждение типа перед стартом воронки.

Новый контрагент без ИНН. Правило: fallback-очередь, SLA 30 минут на квалификационный контакт. Не маршрутизировать вслепую — без ИНН обогащение невозможно.

ИП с неоднозначным ОКВЭД. Правило: проверить объём + тип документа. Если оба сигнала указывают на опт — оптовый трек. Если противоречие — fallback.

Пример настройки в Битрикс24

В Битрикс24 маршрутизация опт/розница реализуется через роботы воронки и направления сделок.

Создайте два направления сделок: «Опт» и «Розница». Для каждого — отдельная воронка с собственными стадиями, ответственными и SLA-таймерами (через роботы «Уведомление» с задержкой).

Робот на стадии «Новая заявка»:

1. Проверяет поле «ИНН» — если заполнено, запускает вебхук на обогащение (СПАРК/Контур.Фокус через API или Zapier-аналог).
2. По результату обогащения заполняет поле «ОКВЭД» и «ОПФ» в карточке лида.
3. Условие: если ОКВЭД начинается с 46 или 51 И поле «Объём» ≥ значению из справочника → перемещает сделку в направление «Опт», назначает ответственного из группы оптовых менеджеров (по очереди с учётом загрузки).
4. Если условие не выполнено → проверяет тип документа и домен email. Два совпадения → «Розница». Иначе → стадия «Требует квалификации» + задача дежурному менеджеру.

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

В amoCRM аналогичная логика реализуется через триггеры и Digital Pipeline; интеграция с 1С позволяет подтягивать данные о минимальной партии и истории отгрузок напрямую в карточку.

Метрики здоровья маршрутизации

Без измерений невозможно понять, работает ли система. Минимальный дашборд:

• % автоматической классификации — цель > 85% заявок без ручного вмешательства
• % ошибочной классификации (ручных переназначений по типу клиента) — цель < 5%
• Доля fallback-очереди — цель < 10%; рост выше 15% — сигнал к пересмотру правил
• Speed-to-assignment — время от поступления заявки до назначения менеджера; отдельно для опт и розница
• Среднее время первого контакта vs SLA-норматив — по каждому треку
• Конверсия заявка → сделка по оптовому треку vs розничному треку — расхождение > 15 п.п. требует анализа
• % повторных клиентов в неверном треке — если существующий оптовый клиент попадает в розничную воронку при новом обращении; цель → 0%
• % заявок, где тип определён на этапе формы / обогащения / звонка — показывает, где теряется автоматизация

Снимайте эти метрики еженедельно в первые три месяца после запуска, затем ежемесячно.

Когда и как пересматривать правила

Правила маршрутизации — не константа. Они устаревают при:

• изменении минимальной партии или ассортимента
• запуске нового канала привлечения (маркетплейс, B2B-портал, партнёрская программа)
• росте доли ручных переназначений выше 8%
• изменении структуры команды продаж (новые специализации, регионы)
• появлении нового типа клиента (например, франчайзи или агент)

Плановый ревью — раз в квартал. Формат: РОП + RevOps + представитель IT смотрят метрики, разбирают кейсы из fallback-очереди за период, корректируют пороговые значения и условия роботов.

Фиксируйте каждое изменение правил с датой и причиной — это ваш аудит-лог для разбора инцидентов.

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

Смотрите также в блоге brezatech: как выбрать инструмент для аналитики данных до внедрения BI — и когда данных уже достаточно для следующего шага.