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

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

Зачем разделять сделки на направления в Битрикс24

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

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

Чем направление отличается от воронки, категории и роботов

В Битрикс24 эти термины путают, а разница принципиальная для планирования настройки.

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

Как создать новое направление сделки: пошагово

Создаётся направление в разделе CRM - Настройки - Направления сделок (или через шестерёнку на канбан-доске). Порядок такой:

• Заходите в настройки CRM и выбираете “Направления сделок”, жмёте “Добавить направление”
• Задаёте название (лучше сразу понятное менеджерам: “Опт”, “Розница”, “Сервис”, а не “Направление 2”)
• Указываете, наследует ли направление стадии из другого или строится с нуля
• Настраиваете список стадий и их порядок отдельно от остальных направлений
• Привязываете ответственного по умолчанию и отдел, которому доступно направление
• Добавляете пользовательские поля, специфичные для процесса (например, “Номер тендера” только для направления “Тендеры”)

На реальном проекте я обычно закладываю на настройку одного направления с нуля 3-5 часов: сюда входят стадии, поля, права и первичная проверка на тестовых сделках. Если направлений три и больше, имеет смысл сразу продумать, какие поля будут общими для всех (источник лида, сумма, дата закрытия), а какие уникальными, чтобы не плодить дубли в CRM-полях.

Настройка стадий под каждый процесс продаж

Стадии - это то, ради чего вообще заводят направления. Розничная воронка интернет-магазина с оплатой через Т‑Банк и доставкой СДЭК обычно выглядит так: “Новый лид” - “Оплата получена” - “Передано в СДЭК” - “Доставлено”. Оптовая воронка того же бизнеса устроена иначе: “Запрос КП” - “Согласование условий” - “Договор подписан” - “Отгрузка партиями”. Если это одна воронка, менеджеры либо игнорируют половину стадий, либо создают самодельные пометки в комментариях, которые никак не считаются в отчётах.

При проектировании стадий я придерживаюсь простого правила: на каждой стадии должно быть понятно, какое действие переводит сделку дальше, и кто это действие выполняет. Стадия “Согласование условий” без привязки к ответственному и без чёткого триггера перехода (звонок, письмо, подписанный документ) превращается в свалку, где сделки зависают на недели. Отдельно закладываю финальные стадии “Успешно” и “Провал” с обязательным полем причины отказа - без этого через полгода никто не сможет объяснить, почему конверсия просела.

Если процессы у направлений частично пересекаются (например, розница и опт одинаково проходят стадию оплаты), не нужно копировать название один в один - лучше сделать “Оплата (розница)” и “Оплата (опт)” с разными связанными полями, иначе в общих отчётах по всем направлениям стадии схлопнутся и аналитика собьётся.

Права доступа, роботы и интеграции для разных направлений

После того как стадии готовы, настраиваю права: кто видит направление целиком, кто только свои сделки, у кого есть доступ на редактирование сумм и скидок. В Битрикс24 это делается через роли в разделе прав доступа CRM, привязанные к направлению и отделу. Частая ошибка - оставить права “по умолчанию”, когда любой сотрудник видит все направления. На проекте с оптом и тендерами это означало, что розничные менеджеры видели закупочные цены партнёров, что для собственника было неприемлемо.

Роботы (автоматические действия на стадиях) настраиваются отдельно для каждого направления, даже если название стадии совпадает. Для интеграций с внешними системами использую вебхуки Битрикс24 и REST API - например, чтобы автоматически переводить сделку на стадию “Оплачено” при поступлении вебхука от Т‑Банка или менять стадию по статусу отправления от СДЭК. Такие связки часто собираю на n8n, чтобы не писать отдельный бэкенд под каждый триггер:

curl -X POST "https://ваш-портал.bitrix24.ru/rest/1/xxxxxxxx/crm.deal.update.json" 
  -H "Content-Type: application/json" 
  -d '{
    "id": 4821,
    "fields": {
      "CATEGORY_ID": 2,
      "STAGE_ID": "C2:WON"
    }
  }'

Обратите внимание на CATEGORY_ID - это как раз идентификатор направления, а STAGE_ID для не первого направления всегда идёт с префиксом вида C2:. Это частая причина, почему автоматизация, написанная для дефолтной воронки, перестаёт работать после добавления второго направления: без префикса API просто не найдёт нужную стадию. Если нужна такая настройка целиком под ключ, от подбора структуры направлений до интеграций с внешними сервисами, обычно проще заказать настройку и внедрение CRM-процессов под задачи бизнеса, чем разбираться с нюансами API самостоятельно вечером после основной работы.

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

За несколько проектов вывел набор ошибок, которые повторяются почти у всех, кто настраивает направления самостоятельно.

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

Вторая - смешение отчётности. Стандартные отчёты Битрикс24 по умолчанию считают показатели по направлению, но если менеджеры вручную переносят сделки между направлениями без чёткого регламента, статистика конверсии перестаёт быть достоверной уже через месяц.

Третья - забытые роботы на старых стадиях. При редактировании списка стадий существующего направления Битrix24 не удаляет автоматически роботов, привязанных к удалённой стадии, они остаются “осиротевшими” и продолжают дёргать интеграции с ошибками в логах. Проверять список активных роботов после любого изменения стадий - отдельный пункт в моём чек-листе после каждой доработки CRM.

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

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

Сколько направлений сделок можно создать в Битрикс24?

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

Можно ли перенести сделку из одного направления в другое без потери истории?

Да, перенос делается через смену поля CATEGORY_ID вручную в карточке или через API, при этом вся история звонков, писем и комментариев остаётся привязанной к сделке. А вот стадия при переносе не подставляется автоматически - нужно вручную выбрать соответствующую стадию в новом направлении, иначе сделка попадёт на первую стадию воронки.

Направления сделок в Битрикс24 доступны на всех тарифах?

На облачной версии функция направлений появляется начиная с тарифа “Стандартный” (на 2026 год это касается актуальной линейки тарифов), на базовом тарифе доступно только одно направление по умолчанию. На коробочной версии Битрикс24 направления доступны без ограничений тарифа с редакции “Стандарт” и выше.

Как быстро настроить направления, если процессы уже описаны на бумаге

Если стадии и условия перехода между ними уже зафиксированы (хотя бы в виде списка в Excel), настройка одного направления с полями и правами занимает от одного рабочего дня. Основное время уходит не на клики в интерфейсе, а на согласование с руководителями отделов, какие поля обязательны и кто должен видеть чужие сделки.