Распределение лидов: правила очереди, нагрузки и передачи менеджеру

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

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

Зачем описывать правила распределения лидов

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

Если объединить эти процессы в одно действие без явных правил, появляются три симптома:

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

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

Для простой циклической очереди ИИ не требуется. Правило вида «выбрать следующего доступного сотрудника из списка» быстрее проверить как обычную детерминированную автоматизацию. AI-помощник уместен, если перед назначением нужно понять свободный текст клиента, определить вероятный продукт или запросить недостающие сведения. Даже тогда окончательный выбор должен подчиняться записанным ограничениям.

Какие данные нужны до назначения

Маршрут строят на данных обращения и состоянии команды. До выбора ответственного проверьте:

• Источник. Форма, почта, чат или другой канал. Источник помогает найти повторное событие и сохранить происхождение обращения, но сам по себе не всегда определяет менеджера.
• Продукт. Нужен для выбора специализации. Если продукт неизвестен, отправьте обращение в общую квалификационную очередь, а не угадывайте категорию.
• Регион. Используется, если территория влияет на обслуживание. При пропуске примените заранее выбранный регион по умолчанию или общую территориальную очередь.
• Язык. Ограничивает список сотрудников, способных продолжить разговор. Если язык не определён, назначьте общую очередь с базовым языком обслуживания или передайте определение человеку.
• Доступность менеджера. Учитывайте смену, отпуск, временное отсутствие и возможность принять новое обращение. Неизвестную доступность безопаснее считать основанием для резервной очереди, а не признаком готовности.
• Текущие активные лиды. Это исходное значение для распределения по нагрузке. Заранее определите, какие статусы считаются активными; иначе два отчёта дадут разные результаты.

Для каждого обязательного поля запишите резервный маршрут. Формулировка «назначить по возможности» непроверяема. Формулировка «если продукт не определён, поместить в квалификационную очередь и уведомить её владельца» задаёт наблюдаемое действие.

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

Как выбрать схему распределения

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

Для выбора по нагрузке можно зафиксировать проектное правило. Пусть E — множество менеджеров, которые находятся на смене, не отсутствуют, доступны и подходят по специализации, региону и языку. Для каждого кандидата m значение Aₘ равно числу его активных лидов. Тогда система выбирает кандидата с минимальным Aₘ. При равенстве использует позицию в циклической очереди. Если E пусто, лид остаётся в резервной очереди, а руководитель получает эскалацию.

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

Как собрать маршрут в CRM

Учебная последовательность выглядит так:

1. Принять событие из подключённого канала и сохранить исходные сведения.
2. Найти существующее обращение по согласованному ключу повтора.
3. Создать новую карточку или дополнить найденную, не теряя источник события.
4. Прочитать продукт, регион, язык и сведения о клиенте.
5. Получить состояние менеджеров и построить множество допустимых кандидатов.
6. Атомарно выбрать одного ответственного и записать назначение.
7. Запустить ожидание подтверждения; при тайм-ауте вернуть лид в очередь.

Официальная документация REST API Битрикс24 описывает лид как карточку со сведениями о заинтересованности клиента. В карточке доступны системные и пользовательские поля, а лид можно связать с контактами. Документация также предупреждает о двух режимах CRM: в классическом режиме лид остаётся отдельным объектом, а в простом создаваемый лид сразу преобразуется в сделку. Поэтому перед проектированием маршрута нужно проверить режим конкретного портала.

Для новой разработки документация Битрикс24 рекомендует универсальные методы crm.item.* с entityTypeId: 1; семейство crm.lead.* продолжает работать, но его развитие остановлено. Это важно при выборе операций чтения и обновления, но не доказывает готовность описанного маршрута в конкретном портале.

Отдельная документация Битрикс24 по Открытым линиям относится к обращениям из подключённых каналов общения. В ней описаны очередь сотрудников, равномерное распределение, строгая последовательность, передача одновременно всем, проверка доступности оператора, ограничение одновременных обращений и время перехода к следующему сотруднику. Там же предусмотрено направление идентифицированного клиента ответственному сотруднику. Эти возможности полезны как опора для проекта, но их нельзя автоматически переносить на любые формы и почтовые сценарии без проверки настроек портала, тарифа, прав и подключённых каналов.

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

Что происходит после назначения

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

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

Тайм-аут — параметр процесса, а не универсальный SLA. Его выбирают с учётом смены, канала и ожиданий клиента. В журнале нужно различать назначение, уведомление и подтверждение: доставленное уведомление ещё не означает, что менеджер принял лид.

Как исключить двойное назначение

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

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

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

Учебный пример распределения с возвратом в очередь

Ниже — синтетический пример для проверки логики. Имена, время, нагрузка и пятиминутный тайм-аут условны. Это не результат клиента, не выполненная настройка Битрикс24 и не обещание роста продаж.

В 10:00 работают три менеджера по оборудованию:

• Анна доступна, у неё один активный лид;
• Борис занят до 10:05, у него два активных лида;
• Вера отсутствует, активных лидов нет.

В 10:00:00 клиент отправляет форму. В 10:00:03 то же обращение приходит по почте. Оба события получают условный ключ K-104. Правило дедупликации связывает их с одной карточкой, поэтому второе событие дополняет историю источников и не запускает параллельное назначение.

В 10:00 в допустимое множество входит только Анна. Борис занят, Вера отсутствует, поэтому их меньшая или большая нагрузка не участвует в сравнении. Система назначает Анну и запускает условный тайм-аут на пять минут.

До 10:05 Анна не подтверждает приём. Первая попытка получает статус «тайм-аут», лид возвращается в очередь, а Анна временно исключается из повторного выбора. К этому моменту Борис доступен, Вера всё ещё отсутствует. Во второй попытке единственный допустимый кандидат — Борис. Он подтверждает приём в 10:07.

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

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

Как проверить маршрут и обсудить внедрение

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

Минимальный набор проверок:

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

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

Если нужна только известная очередь, начните с функций CRM и обычной автоматизации. AI-помощник продаж Switch On AI подходит для более широкого сценария: собрать недостающие сведения из диалога, записать согласованные поля в CRM и передать контекст менеджеру. Коммерческие решения и нестандартные условия при этом остаются за человеком.

Для проекта сначала проверяют текущую CRM, каналы, поля, права, признаки повтора и правила эскалации. Прототип показывает отдельный ключевой сценарий и не равен полноценному внедрению. Чтобы разобрать собственный маршрут, пришлите правила распределения и несколько обезличенных примеров обращений. Вместе можно определить, где достаточно очереди, а где действительно нужен AI-помощник. Соседнюю задачу — сбор, квалификацию и сохранение обращений — подробнее раскрывает материал об автоматизации обработки лидов.