Несколько воронок Битрикс24: когда разделять направления и как настроить

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

Когда несколько воронок Битрикс24 действительно нужны

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

Признаки, что пора разделять:

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

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

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

Как устроены воронки и стадии в CRM

Прежде чем что-то создавать, стоит разобраться в базовой механике. В каждом Битрикс24 по умолчанию есть стандартная воронка с названием «Общая воронка». Удалить её нельзя, но можно переименовать и изменить порядок сортировки. Это удобно: если у вас пока одно направление, вы просто работаете в ней.

Новую воронку создают двумя путями:

• через раздел сделок: «Сделки» → «Воронки» → «Воронки и туннели продаж»;
• через настройки: «Сделки» → «Ещё» → «Настройки» → «Настройки CRM» → «Воронки продаж».

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

Стадии правят в слайдере «Воронки и туннели продаж» в режиме просмотра «Канбан» либо через раздел «Сделки» → «Ещё» → «Настройки» → «Настройки CRM» → «Справочники» → «Стадии сделки». Добавить стадию — нажать на плюс, редактировать или удалить — нажать на карандаш, изменить цвет — карандаш и заливка.

Что настраивается отдельно в каждой воронке

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

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

Сколько воронок можно создать

Лимит воронок зависит от тарифа. Условия меняются, поэтому актуальное число нужно сверять в описании тарифов. Не планируйте архитектуру «на вырост» без проверки лимита, чтобы не пришлось пересматривать схему.

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

Как разделить направления: одна воронка — один процесс

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

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

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

Как понять, что процесс действительно отдельный

Задайте три вопроса:

• у этого направления свой путь клиента от обращения до результата?
• им занимаются другие сотрудники, которым не нужны сделки соседнего направления?
• у него свои этапы, которые не совпадают с этапами другого направления?

Если на два вопроса ответ «да», отдельная воронка оправдана. Если процесс отличается только ответственным, но этапы те же, хватит одной воронки с распределением по ответственным.

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

Что делать со стадиями после разделения

После того как воронки созданы, стадии в каждой из них пересматривают заново. Не стоит копировать один набор стадий во все воронки: если процессы разные, а стадии одинаковые, смысл разделения теряется. Стадии должны отражать реальные этапы конкретного направления.

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

Передача клиента между направлениями: туннели продаж

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

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

• копировать — CRM создаст копию сделки в новой воронке, а оригинал останется в исходной;
• переместить — сделка уйдёт в другую воронку и исчезнет из исходной.

После выбора заполняют поля и сохраняют изменения.

Копировать или переместить: как выбрать

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

Простой критерий: нужна ли вам история в первом процессе после передачи. Если да — копирование. Если сделка в первом процессе больше не нужна и только создаёт шум — перемещение.

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

Зачем нужны роботы рядом с туннелями

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

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

Права доступа: кто что видит

Разделение воронок имеет смысл только вместе с правами доступа. В CRM можно настроить так, чтобы сотрудники видели только те воронки и сделки, которые относятся к их зоне ответственности.

Сотрудник видит только воронки с правом на просмотр сделок. Отсутствие права скрывает воронку из списка. Это позволяет развести менеджеров, диспетчеров и специалистов по качеству в разные рабочие пространства.

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

Что проверить перед настройкой прав

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

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

Отдельно стоит продумать, кто отвечает за права. Обычно это администратор портала или руководитель, отвечающий за CRM. Если ответственного нет, права «дрейфуют»: кто-то добавляет доступ по просьбе, кто-то забывает убрать при переводе сотрудника.

Таблица принятия решения: одна воронка или несколько

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

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

Ниже — учебный пример. Данные о компании и количестве объектов условные, это не реальный кейс и не статистика.

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

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

Действия.

1. Разделяют процессы на две воронки: «Продажи оборудования» и «Сервисное обслуживание». 2. В сервисной воронке перестраивают стадии под реальный путь: заявка, диагностика, согласование, выполнение, подтверждение, закрытие (названия могут отличаться). 3. Настраивают права доступа так, чтобы менеджеры продаж видели только воронку продаж, а сервисные специалисты — только сервисную. 4. На стадии «Отгрузка» в воронке продаж настраивают туннель, который копирует сделку в сервисную воронку для постановки на обслуживание. Оригинал остаётся в воронке продаж как история. 5. На стадии «Выполнение» в сервисной воронке настраивают робота, который отправляет клиенту сообщение о готовности и просьбу подтвердить работу.

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

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

Ответственный. За настройку воронок и стадий обычно отвечает администратор портала или специалист, который ведёт CRM. За содержание стадий — руководители направлений: они лучше знают реальный путь клиента. За права доступа — тот, кто отвечает за ролевую модель.

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

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

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

Что смотреть:

• сделки заводятся в правильные воронки без подсказок;
• стадии соответствуют реальным этапам, сотрудники не переставляют карточки «для порядка»;
• туннели срабатывают на нужных стадиях, копии и перемещения происходят как задумано;
• права доступа не мешают работе и не открывают лишнего;
• руководитель может по канбану понять состояние каждого направления;
• клиент получает уведомления в нужные моменты, а не молчит между этапами.

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

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

Типичные ошибки и ограничения

Разберём, что чаще всего идёт не так.

• Слишком много воронок. Дробление ради дробления усложняет работу: сотрудники путаются, куда заводить клиента, а руководитель получает фрагментированную картину.
• Одинаковые стадии в разных воронках. Если процессы разные, а стадии одинаковые, смысл разделения теряется.
• Забытые права доступа. Воронки создали, а права не настроили — и все видят всё. Или наоборот: закрыли доступ так, что сотрудник не может работать.
• Ручной перенос вместо туннеля. Если клиент регулярно переходит между направлениями, ручной перенос ведёт к потере данных и задержкам.
• Попытка удалить воронку с данными. Удалить воронку не получится, если это стандартная воронка с ID 0, если в ней есть сделки, если в корзине остались сделки этой воронки или к воронке привязаны шаблоны сделок. Сначала нужно очистить воронку от данных и связей.
• Настройка без тестового контура. Изменения сразу в рабочем портале не оставляют возможности откатиться, если что-то пойдёт не так.
• Отсутствие ответственного. Если за воронки никто не отвечает, они постепенно «зарастают» лишними стадиями и полями.

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

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

Какие исходные данные подготовить для оценки

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

• список направлений и краткое описание пути клиента в каждом;
• перечень этапов, через которые проходит сделка в каждом направлении;
• кто из сотрудников и отделов работает с каждым направлением;
• какие данные должны быть видны одним и скрыты от других;
• в каких точках клиент переходит из одного процесса в другой;
• какие автоматические действия нужны на стадиях (уведомления, запросы подтверждения);
• текущий тариф и лимит на количество воронок;
• текущую ролевую модель и список ролей.

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

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

Чек-лист перед созданием воронок

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