Распределение лидов: круговая очередь с допуском и лимитом нагрузки

Сначала выберите группу, затем способ распределения

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

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

В Dynamics 365 Sales правила рассматриваются последовательно, и после первого подходящего остальные не применяются. Среди вариантов распределения документация различает round robin и балансировку по нагрузке. Microsoft Learn: Assignment rules. Это конкретный пример; порядок и поведение вашей системы нужно проверить отдельно.

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

Определите, что занимает ёмкость менеджера

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

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

Microsoft описывает capacity продавца как число лидов и возможностей, с которыми он может работать одновременно; доступная ёмкость вычисляется через лимит и назначенные записи. Microsoft Learn: Seller attributes and capacity. Перечень состояний и объектов для вашей модели нужно проверить, особенно при нескольких типах работы.

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

Запишите круговую очередь однозначно

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

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

Названия похожих функций могут скрывать другую механику. HubSpot поясняет, что Rotate record to owner распределяет по счётчику назначений конкретного действия, а не по общему количеству объектов у сотрудника. HubSpot: Assign ownership. Поэтому спросите, где хранится очередь: глобально, по группе, по правилу или по отдельному действию.

Учебный пример: почему один менеджер получил три заявки

Все данные вымышлены. Все три сотрудника находятся на смене. A и C могут обрабатывать русский и английский язык, B — только русский. Лимиты A, B и C равны 4, 4 и 3 активным заявкам. До начала распределения у них соответственно 3, 1 и 2 дела.

Свободно 1 место у A, 3 у B и 1 у C. Всего 1 + 3 + 1 = 5 мест. Указатель начинается с A. Поступают шесть отдельных заявок: L1 на английском, L2 на русском, L3 на английском, L4, L5 и L6 на русском.

• L1 получает A. Его нагрузка становится 4, указатель переходит к B.
• L2 получает B. Его нагрузка становится 2, указатель переходит к C.
• L3 получает C. Его нагрузка становится 3, указатель переходит к A.
• Для L4 A уже заполнен. Подходит B: нагрузка становится 3, следующий указатель — C.
• Для L5 C и A заполнены. B получает заявку и достигает нагрузки 4.
• Для L6 свободного места нет. Она остаётся у координатора очереди.

Итог новых назначений: A — 1, B — 3, C — 1; всего 5. Итоговая нагрузка — 4 + 4 + 3 = 11 при общей ёмкости 11. Шестая заявка не исчезает и не создаёт перегрузку. Такое неравное распределение объясняется исходной занятостью, а не ошибкой круга.

Допустим, четыре назначенных обращения уже приняты, L5 ещё ожидает ответа менеджера, L6 остаётся в очереди. Тогда полный баланс нового потока равен 4 принятых + 1 назначенное + 1 в очереди = 6. Назначенные пять нельзя назвать пятью обработанными обращениями.

Одновременные запросы и повторные события

Два процесса могут одновременно увидеть последнее свободное место A. Критерий приёмки — проверка и фиксация назначения вместе с резервом ёмкости как одного согласованного результата. После успешного первого назначения второе должно пересчитать допустимость, а не использовать устаревшее число.

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

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

Отказ от назначения не должен запускать бесконечный круг

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

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

Поля и чек-лист приёмки

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

Проведите проверки:

1. Сотрудник следующий в круге, но не знает нужный язык: он пропущен.
2. Участник вне смены или его доступность неизвестна: применяется явное правило разбора.
3. Лимит заполнен ожидающими принятия задачами: новые назначения не превышают его.
4. Два запроса используют последнее место: подтверждается только одно назначение.
5. Повторено исходное событие: владелец и нагрузка не задваиваются.
6. Подходят два правила: выбран предусмотренный приоритет.
7. Ручное назначение изменяет нагрузку в согласованной модели.
8. Отказ освобождает один резерв и не запускает бесконечный цикл.
9. Все входящие обращения объясняются принятыми, ожидающими и исключениями.

Для SABSUS проверьте сценарий через CRM, роли сотрудников и автоматизацию Flow. Круг, лимиты и фиксация нагрузки являются требованиями к внедрению; их готовую поддержку нужно подтвердить в конфигурации.

Частые вопросы

Круговая очередь гарантирует одинаковое число лидов всем?

Только при одинаковой допустимости, доступности и принятой механике. В реальной очереди пропуски и ограничения закономерно меняют итоговое число назначений.

Что делать, если никто не подходит?

Оставить обращение в видимой очереди с координатором и причиной. Не назначать случайного человека и не считать заявку обработанной.

Когда освобождать ёмкость?

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

Источники

• Microsoft Learn: Assignment rules — приоритет правил и способы распределения.
• Microsoft Learn: Seller capacity — лимит и доступная ёмкость.
• HubSpot: Assign ownership — область счётчика кругового распределения.

Источники проверены 9 октября 2026 года. Алгоритм и пример очереди учебные.