21 августа 2026 г. · Maksim Shchegolev

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

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

Хотите проверить это на своём сайте? Запустите бесплатную проверку видимости в ИИ, она занимает десять секунд и не требует почты.

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

Этот гайд отвечает за приоритет правил, владение заявкой и резервные очереди. Квалификация заявок с помощью AI даёт факты о соответствии профилю клиента и о готовности покупать. Автоматизация CRM хранит итогового ответственного менеджера, этап, задачу и историю. Скорость ответа на заявку задаёт таймеры и порядок эскалации, то есть измеряет то, что происходит после назначения.

Одним предложением

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

Почему заявки теряются при распределении?

Заявка теряется, когда она есть в системе, но ни один доступный человек не отвечает за следующее действие. Назначение, принятие и резервный путь это три разных события, и каждое ломается по-своему. Поле «ответственный» в CRM может быть заполнено, а менеджер при этом в отпуске, перегружен или просто не получил уведомление.

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

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

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

Рабочая подготовка данных делает пять вещей.

1. Приводит поля идентификации к канону. Почта в нижний регистр, телефон в единый международный формат, исходное значение сохраняется рядом с нормализованным. Номер из WhatsApp и номер из формы должны сравниваться как одно и то же.
2. Определяет компанию. Домен почты извлекается, бесплатные почтовые домены исключаются из сопоставления с компанией, а список псевдонимов позволяет считать два домена одной организацией, если так решил бизнес.
3. Сводит справочники. Страна, язык, продуктовая линейка и источник сопоставляются с фиксированным списком значений. Всё, что не сопоставилось, помечается, а не угадывается.
4. Прикрепляет данные об источнике. Первый источник, последний источник, кампания и канал приходят вместе с заявкой по модели из гайда про атрибуцию источников заявок. Правило, которое читает источник, не может ждать ночной пересчёт. Если источник визита берётся из Яндекс Метрики или из меток UTM, он должен попасть на карточку до назначения, а не после.
5. Фиксирует вердикт квалификации. Соответствие профилю клиента, готовность покупать и уверенность приходят из квалификации заявок отдельными полями, а не свободным текстом, который правилу придётся разбирать.

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

Какой должен быть порядок правил распределения заявок?

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

Шаг 1: дедупликация и повторное обращение

Клиенты возвращаются. Без шага дедупликации распределение производит близнецов. Сопоставляйте в порядке приоритета: известный идентификатор контакта в CRM, затем нормализованные почта или телефон, затем сессия чата, уже привязанная к человеку. Окно сопоставления задаётся явно, потому что «тот же человек через полгода» и «тот же человек через десять минут» это разные ситуации для бизнеса.

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

Шаг 2: владение компанией и сделкой

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

Шаг 3: фильтры допустимости

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

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

Шаг 4: распределение

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

Шаг 5: резерв

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

Как разрешать конфликты внутри одного шага

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

Чем назначение отличается от принятия и первого разговора?

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

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

Какие способы распределения заявок между менеджерами использовать?

Почти всегда получается гибрид. Таблица сравнивает способы по тем признакам, которые важны при выборе.

Распределение по кругу подходит по умолчанию только по-настоящему однородной команде. Оно раздаёт ходы, а не усилия. Менеджер с восемью зависшими сделками и менеджер с одной получают ход одинаково, поэтому очередь имеет смысл вместе с лимитом активных заявок, который пропускает того, кто уже перебрал согласованное число. Такой лимит это настройка под тип работы и размер команды, а не отраслевая константа. И в amoCRM, и в Битрикс24 правила распределения настраиваются, но ни одна из систем не решит за вас, чем именно считать нагрузку.

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

Распределение по территории требует явного ответа для непокрытых регионов до запуска, а не после первого промаха.

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

Как устроены резервные очереди и повторные попытки?

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

Вторая половина задачи это повторные попытки. Назначение пересекает границы систем, а границы падают.

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

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

Где хранить правила: в CRM или в отдельном слое?

Штатные средства CRM могут выполнять часть распределения или всё распределение целиком, если их поведение отвечает вашей политике. Из международных систем HubSpot описывает действие смены владельца записи и отдельно отмечает, что счётчик ротации привязан к конкретному действию, а не к общей нагрузке менеджера. Salesforce описывает правила назначения лидов, которые выбирают ответственного по упорядоченному списку критериев. На российском рынке ту же роль играют встроенные правила распределения в amoCRM и Битрикс24.

Отдельный слой окупается при двух ответах «да». Приходят ли заявки по каналам, которых CRM не видит, например через Telegram-бот или виртуальную АТС. И нужно ли, чтобы состояние назначения пережило объединение или удаление карточки в CRM. Если оба ответа отрицательные, штатных правил обычно достаточно. Границу систем подробно разбирает гайд Lead Hub или CRM. Распределение через отдельный узел это один из вариантов, а не обязательное требование, и спецификация правил в любом случае остаётся независимой от инструмента.

Как учитывать график работы, дежурство и отпуска?

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

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

Что записывать в журнал событий и версии правил?

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

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

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

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

Как тестировать распределение до запуска и проверять после?

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

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

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

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

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

Как распределять заявки из других стран и на других языках?

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

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

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

Какие метрики показывают сбои распределения?

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

Как задавать нормативы времени ответа?

Нормативы задаются от готовности клиента покупать, ожиданий канала, реального штата и риска, а потом проверяются на способность состава их выдержать. Оригинальное исследование MIT и InsideSales показало, что задержка снижала шансы дозвониться и квалифицировать заявку с сайта на том наборе данных, а Harvard Business Review в 2011 году опубликовал аудит 2 241 компании, где средний ответ среди тех, кто вообще ответил, составил около 42 часов. Оба источника задают направление и ни один не определяет правильный таймер для конкретного современного B2B-процесса. Измерьте своё назначение, принятие и первый содержательный разговор по отдельности, выберите норматив, который штат выдержит стабильно, и опишите резерв до того, как включите принуждение.

Какой тревожный признак виден оператору?

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

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

Другие схемы, которые повторяются от аудита к аудиту:

• Логика распределения живёт в промпте бота. Промпты меняются без согласования, а источником правды должен быть набор правил.
• Фильтр в CRM выдают за распределение. Фильтр показывает заявки, но не назначает их и не запускает таймер.
• Ручной призыв в общем чате. Нет журнала, нет события принятия, нет резерва.
• Личные номера WhatsApp у менеджеров. Ломает атрибуцию, ломает подмену на время отпуска, а история уходит вместе с сотрудником.
• Заявки в прогреве оставлены без ответственного. Прогрев тоже требует ответственного за последующий контакт.
• Очередь руководителя как постоянный резерв. Для исключений это нормально, но рутинный поток без совпадений маскирует дыры в данных о допустимости.
• Распределение по кругу выдают за балансировку нагрузки. Равные числа не равны равной работе, активную загрузку нужно считать отдельно.

Как спроектировать и внедрить изменение правил?

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

Дальше внедряйте в таком порядке.

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

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

Какие гайды дополняют распределение заявок?

Начните с обзорного гайда про операционный стек для заявок, затем прочитайте квалификацию заявок о фактах, которые читают правила, автоматизацию CRM о записях после назначения и Lead Hub или CRM о границе систем. Скорость ответа на заявку отвечает за таймеры и эскалацию, атрибуция источников заявок за поля источника, от которых зависит маршрут, адаптация менеджера по продажам за признак аттестации, а программный SEO за кластеры страниц, порождающие новые маршруты. Если часть входящего потока приходит из ответов нейросетей, посмотрите гайд про видимость в AI-ответах. Состав работ и пакеты указаны на странице тарифов, а разобрать текущую схему распределения можно на консультации. Сборку этих правил с оповещением о сбоях берём на себя в рамках автоматизации бизнеса.

Цены