Заявки для сети филиалов: как распределять

Когда у бизнеса один офис, вопрос распределения заявок не стоит — все лиды идут в одну точку, и максимум что нужно решить — кому из двух менеджеров передать следующий звонок. У сети из 5, 15 или 40 филиалов всё иначе: заявка, которая физически привязана к Красногорску, но досталась менеджеру в Люберцах, — это упущенная сделка. Клиент почти никогда не поедет в другой конец города, а перезвон «извините, вы не в нашей зоне, вот номер другого офиса» в 80% случаев заканчивается тем, что человек просто вешает трубку и идёт к конкуренту.

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

Почему распределение решает больше, чем объём заявок

Сеть филиалов часто оценивает эффективность рекламы одной цифрой — «сколько заявок пришло за месяц». Но если из 120 заявок 30 ушли не в тот филиал и обработались с опозданием на сутки, конверсия в сделку по сети падает не на 25%, а сильнее: клиент, которого перекинули между офисами, теряет доверие ещё до разговора с менеджером.

На практике разница в конверсии между «заявка сразу у нужного менеджера» и «заявка сначала попала не туда, потом её переслали» — от 1,5 до 3 раз. Это не гипотеза, это то, что видно в CRM любой сети после внедрения нормальной маршрутизации: одни и те же заявки, но другой путь до менеджера — и другой процент дошедших до сделки.

Привязка заявки к филиалу по геопризнаку

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

• Адрес из формы — клиент указывает город/район, система сопоставляет его с зоной ответственности филиала.
• Геолокация посадочной страницы — если у сети отдельный лендинг под каждый город (например, /okna-krasnogorsk и /okna-himki), заявка изначально привязана к филиалу через сам источник трафика.
• IP или гео из рекламного кабинета — грубее, но подходит как страховочный вариант, когда клиент не указал точный адрес.

Проблема встречается на границах зон: заявка из района, который формально относится к филиалу А, но который клиенту удобнее закрыть филиалу Б — например, у него есть свободный замерщик именно сегодня. Здесь чистая геопривязка без ручной корректировки работает хуже, чем гибридная схема (см. ниже про приоритеты).

Маршрутизация через CRM: правила, а не ручной разбор

Если заявки в сети распределяет один человек — администратор или РОП, который вручную смотрит адрес и пересылает в чат нужного филиала, — это работает до 10-15 заявок в день. Дальше начинаются задержки: администратор ушёл на обед, заявка легла в очередь на 40 минут, а конкурент уже перезвонил.

Рабочая схема — правила маршрутизации внутри CRM (amoCRM, Bitrix24 или отраслевая система), которые срабатывают автоматически по заранее заданным условиям:

1. Заявка попадает в CRM с меткой источника (город, лендинг, номер телефона для колл-трекинга).
2. Правило сопоставляет метку со списком филиалов и назначает ответственного менеджера в течение 30-60 секунд.
3. Менеджеру приходит уведомление в мессенджер или push — не письмо на почту, которое можно не заметить часами.
4. Если менеджер не взял заявку в оговорённое время (обычно 5-10 минут), она эскалируется на резервного сотрудника того же филиала или на РОПа сети.

Настройка такой цепочки занимает от нескольких часов до пары дней в зависимости от CRM и количества филиалов, но она снимает человеческий фактор почти полностью — заявка не может «потеряться в чате».

Баланс нагрузки между филиалами

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

Здесь помогает вторичное правило — балансировка по текущей загрузке:

• Филиал указывает в CRM свободные слоты или текущую очередь (актуально для сервисов, стоматологий, замерщиков).
• Если ближайший по гео филиал перегружен, заявка автоматически предлагается следующему по близости, а не встаёт в очередь молча.
• Клиенту при этом можно честно сообщить: «ближайшая свободная запись в филиале на Ленина — послезавтра, в филиале на Свердлова — уже завтра», и дать выбор.

Сети, которые внедряют такую балансировку, обычно выигрывают 10-20% заявок, которые иначе просто «утекли» бы из перегруженного филиала в никуда.

Конфликты: одна заявка — два филиала

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

Практическое решение — жёсткая иерархия правил при конфликте, зафиксированная на уровне CRM, а не «как договоримся»:

1. Приоритет у филиала, к которому привязан источник трафика (номер телефона колл-трекинга, конкретный лендинг).
2. Если источник общий — приоритет у филиала с меньшей текущей загрузкой.
3. Если оба условия равны — заявка уходит тому, кто первым отреагировал в CRM (защита от «залёживания»).

Приоритетный и резервный филиал

Хорошая практика — назначать каждой географической зоне не один, а два филиала: основной и резервный. Основной получает заявку первым, но если он не отвечает в течение контрольного времени (обычно 10-15 минут в рабочие часы, 30 минут вне их), заявка автоматически дублируется резервному, а не ждёт, пока кто-то заметит просрочку.

Это особенно критично вне стандартного рабочего дня — вечером, в выходные, во время отпусков сотрудников. Сеть из 8-10 филиалов может закрыть 90% нерабочих часов, если у каждой зоны есть резерв в соседнем филиале, вместо того чтобы держать отдельного дежурного администратора на каждую точку.

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

Отчётность по филиалам: что считать отдельно

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

• Количество заявок за период и их стоимость (если оплата за результат — стоимость может отличаться по городам).
• Скорость первого ответа менеджера — среднее время от поступления заявки до звонка.
• Конверсия заявка → запись/встреча → сделка, отдельно на каждом этапе.
• Доля заявок, эскалированных на резервный филиал (индикатор перегрузки основного).

Когда такая разбивка есть, разговор с руководителем слабого филиала переходит из «у нас плохие заявки» в конкретику: «заявки те же, что и у соседнего филиала с конверсией 34%, у вас — 11%, среднее время ответа 47 минут против 6». Это меняет тон разговора и обычно быстро меняет результат.

Типичные ошибки при масштабировании на несколько филиалов

По опыту настройки заявок для сетевых клиентов, ошибки повторяются из проекта в проект:

• Одна общая форма без указания города/района — заявки потом приходится разбирать вручную, что убивает скорость реакции.
• Общий номер телефона на всю сеть без переадресации по зонам — звонок принимает случайный свободный менеджер, который может физически не относиться к нужному филиалу.
• Нет резервного маршрута — заявка от филиала, где менеджер заболел или уволился, просто зависает без ответа.
• Метрики считаются только по сети целиком — слабые филиалы прячутся за средним показателем сильных.
• Правила маршрутизации держатся в голове у одного администратора, а не зафиксированы в CRM — при его отпуске или увольнении система рассыпается.

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

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

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