Распределение лидов в Битрикс24: филиалы, дежурства и нагрузка менеджеров

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

Дмитрий Максимов14.09.20266 мин чтения

Керамические каналы с заслонками направляют шары в разные чаши: распределение заявок с учётом доступности и нагрузки.

Содержание

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

Распределение лидов в Битрикс24 начинается с правил принадлежности и готовности взять работу. Равное число назначенных карточек само по себе не означает равную нагрузку или быстрый ответ. Рассмотрим схему для филиальной сети: сначала принадлежность заявки, затем выбор сотрудника.

Разделите принадлежность клиента и выбор исполнителя #

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

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

Зафиксируйте приоритет правил #

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

Ситуация	Что определить первым	Что делать при недостатке данных
Повторное обращение клиента	Существующую связь и предмет запроса	Передать на проверку совпадения
Новый клиент с известным адресом работ	Территорию и направление	Уточнить нестандартную территорию
Заказ требует специальной компетенции	Допустимую группу исполнителей	Назначить владельца квалификации
Все подходящие сотрудники недоступны	Дежурного или очередь ожидания	Сохранить владельца и срок реакции

Результат полезно объяснять в карточке или техническом журнале: сработало правило региона, затем правило компетенции, выбран участник очереди. Одного поля «ответственный» недостаточно для разбора спорного назначения. Версия правил помогает понять, почему одинаковые заявки в разные месяцы могли распределяться иначе.

Где достаточно штатного робота #

У робота «Изменить ответственного» есть несколько способов выбора сотрудника, в том числе последовательный, и настройки учёта отсутствия и рабочего дня. Их поведение описано в документации Битрикс24 . Для простой очереди это разумная отправная точка.

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

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

Не смешивайте очередь чатов и ответственного в CRM #

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

В открытых линиях есть собственные настройки очереди и направления на ответственного . Проверяйте их отдельно от роботов лида. Иначе чат уйдёт в одну группу, а карточка — в другую, и обе команды будут считать, что ответить должна соседняя.

Как хранить результат решения #

Пример ниже — внутренняя диагностическая запись, не параметры REST-метода. Он показывает, какие сведения позволяют восстановить причину назначения. Названия филиалов и идентификаторы условные.

example-policy.jsonJSON

{
  "lead_id": "LEAD-DEMO-81",
  "routing_revision": "rules-3",
  "matched_rule": "installation_city",
  "eligible_team": "branch-demo-west",
  "assignment_status": "assigned",
  "reason": "next_available_member"
}

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

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

Повторные обращения требуют отдельного сценария #

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

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

Проверка перед включением автоматического распределения #

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

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

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

Можно ли распределять заявки просто по очереди? #

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

Что делать с заявками, пришедшими ночью? #

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

Поможем превратить очередь в управляемый процесс #

NetLabCS поможет настроить бизнес-процессы Битрикс24 : приоритет условий, дежурные группы, повторные обращения и контроль неназначенных заявок. Опишите вашу схему продаж : филиалы, источники обращений и случаи, в которых лид сейчас теряет ответственного.