Без чёткой логики распределения заявки обычно расходятся одним из двух способов. Либо все хорошие лиды по негласной договорённости достаются одному сильному менеджеру, а остальные постепенно теряют мотивацию расти. Либо действует правило «кто первый увидел уведомление», и тогда самые расторопные разбирают тёплые заявки, а остальным достаются те, что похуже.
Оба сценария работают против компании: демотивируют часть команды, скрывают реальную загрузку менеджеров и делают результаты отдела зависимыми от пары человек. Разбираем, какие схемы автоматического распределения заявок есть в Битрикс24, как выбрать подходящую и какие ошибки чаще всего сводят автоматизацию на нет.
Зачем вообще автоматизировать распределение
Помимо очевидной справедливости, у автоматического распределения есть практический эффект: заявка не зависит от того, кто именно сейчас за компьютером. Менеджер в отпуске, на встрече или уволился, а система продолжает передавать новые обращения по заданному правилу, не дожидаясь, пока кто-то вручную заметит зависшую заявку.
Способы распределения заявок в Битрикс24
| Способ | Как работает | Когда подходит |
|---|---|---|
| По очереди | Каждая новая заявка уходит следующему менеджеру по кругу | Небольшой отдел с похожей квалификацией менеджеров и однородным потоком заявок |
| По загрузке | Учитывается число уже открытых сделок у каждого менеджера | Неравномерный поток заявок, разная скорость закрытия сделок у сотрудников |
| По источнику, объявлению или региону | Заявка закрепляется за менеджером на основе того, откуда она пришла | Территориальное деление или продуктовая специализация внутри отдела |
| Ручное распределение через дежурного | Дежурный сотрудник сам разбирает входящий поток и назначает ответственного | Заявки требуют предварительной квалификации перед передачей менеджеру |
На практике схемы часто комбинируют: например, распределение по региону определяет группу подходящих менеджеров, а внутри группы заявки расходятся по очереди или по загрузке.
Что делать с нерабочим временем и отсутствием менеджера
Любая схема распределения ломается, если не предусмотреть, что происходит, когда назначенный менеджер не может отреагировать. Здесь работает правило эскалации: если ответственный не связался с клиентом в течение заданного времени, заявка автоматически переходит следующему по очереди или дежурному, а не остаётся висеть в его личной воронке.
Отдельно стоит продумать заявки, поступившие вне рабочего времени. Если распределение продолжает назначать их конкретным менеджерам ночью или в выходные, они физически не могут быть обработаны быстро. Разумнее направлять такие обращения дежурному или в общую очередь на утро следующего рабочего дня с пометкой о времени поступления.
Частые проблемы при настройке распределения
- Ручные исключения для «любимых» менеджеров. Формально настроено честное распределение, но лучшие заявки регулярно вручную переназначаются одному и тому же сотруднику. Это быстро становится заметно остальной команде и подрывает доверие к системе.
- Очередь не учитывает отпуска и больничные. Менеджер в отпуске продолжает получать заявки по общему правилу, если его вручную не исключили из очереди на время отсутствия.
- Нет эскалации зависших заявок. Заявка назначена, но менеджер с ней не связался, и без контроля времени реакции это остаётся незамеченным, пока клиент не уйдёт сам.
- Распределение без учёта специализации. Сложный технический вопрос попадает к менеджеру без нужной экспертизы просто потому, что подошла его очередь, и клиент получает менее качественную консультацию.
Как проверить, что распределение работает честно
Регулярная проверка проще, чем кажется: достаточно сравнить количество заявок, полученных каждым менеджером за период, и среднее время до первого ответа по каждому из них. Если у одного сотрудника заметно больше заявок, а у другого стабильно меньше при формально одинаковом правиле распределения, это повод проверить настройки, а не производительность конкретного человека.
Такой контроль удобно вывести в отдельный отчёт, чтобы не сверять цифры вручную каждый раз. Какие показатели вообще стоит выносить на дашборд руководителя, мы разбирали в статье о BI-дашбордах и ключевых показателях.
Логика распределения для разных типов отдела продаж
- Небольшой отдел, два-три менеджера с похожей квалификацией. Простое распределение по очереди обычно полностью закрывает задачу без дополнительных условий.
- Средний отдел с разделением по продукту или региону. Сначала заявка попадает в нужную группу менеджеров по признаку, а внутри группы расходится по очереди или по загрузке.
- Крупный отдел с неравномерным потоком заявок. Распределение по текущей загрузке в сочетании с эскалацией зависших обращений даёт более ровный результат, чем простая очередь.
Частые вопросы
Можно ли совмещать несколько правил распределения одновременно
Да, и на практике это встречается чаще, чем использование одного правила. Например, сначала заявка фильтруется по региону или продукту, а затем внутри подходящей группы менеджеров распределяется по очереди или по загрузке.
Что происходит с заявкой, если все менеджеры недоступны
Без настроенной эскалации заявка просто остаётся у последнего назначенного сотрудника. С эскалацией она уходит дежурному или руководителю отдела, чтобы не оставаться без движения на неопределённый срок.
Можно ли вручную переназначить заявку после автоматического распределения
Да, ручное переназначение всегда остаётся доступным поверх автоматических правил. Вопрос в дисциплине: если ручные переназначения происходят систематически в пользу одних и тех же сотрудников, это стоит обсуждать отдельно, а не считать нормальной практикой.
Мешает ли автоматическое распределение работе с постоянными клиентами по договорённости
Нет, для таких случаев обычно настраивается отдельное правило: если у клиента уже есть закреплённый менеджер, повторное обращение направляется именно ему в обход общей очереди новых лидов.
Что делать дальше
Правильная схема распределения зависит от структуры конкретного отдела: размера команды, разброса по квалификации, неравномерности потока заявок в течение дня и недели. Готового шаблона, который одинаково хорошо работает для всех, не существует, логику нужно проектировать под реальные процессы компании.
КубикДата настраивает распределение заявок как часть комплексного внедрения Битрикс24, отталкиваясь от структуры конкретного отдела продаж, а не от универсального шаблона. Изучите наши кейсы или запишитесь на консультацию, разберём, какая логика распределения подойдёт именно вашей команде.
