Настройка CRM для компании с филиалами и командами

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

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

РегионФилиалКомандаМенеджерКомпания

Оргструктура и модель CRM — разные вещи

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

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

Филиал, команда и территория — три разных понятия

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

Кто и чьи записи будет видеть?

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

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

Модель видимости	Когда подходит	Побочный эффект
Жёсткое разделение	Рынки филиалов не пересекаются	Двойной контакт по общим клиентам
Иерархическая	Руководитель видит своих, но не соседей	Слабеет горизонтальное взаимодействие
Общее чтение, раздельная запись	К одному клиенту идут несколько филиалов	Ценовые условия расходятся между филиалами
Общий пул и присвоение	Поток заявок неровный, загрузка плавает	Невзятые записи стареют в пуле

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

Что происходит, когда один клиент попал в два филиала?

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

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

Одна воронка или своя для каждого филиала?

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

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

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

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

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

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

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

В какой филиал уходит входящий запрос?

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

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

В конце цепочки поставьте ловушку

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

Два филиала, одна сделка: кому засчитывается?

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

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

Как честно сравнивать филиалы?

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

Дашборд, ранжирующий филиалы по валовой выручке, награждает лучший рынок, а не лучшую команду.

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

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

Общее ядро и локальная свобода: где граница?

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

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

С чего начать и каких ошибок избежать

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

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

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