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

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

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