Несколько отделов в Битрикс24: переносить сделку между воронками или создавать связанные процессы

Если один заказ проходит через продажи, тендерный, договорный или технический отдел, начинать стоит не с количества воронок. Сначала нужно определить самостоятельный результат каждого процесса, границы ответственности и то, кто должен видеть заказ целиком.

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

На этом этапе возникает логичный вопрос: как правильно разложить такой процесс в Битрикс24?
Самое очевидное решение - создать отдельную воронку для каждого отдела и передавать одну сделку дальше.

Технически Битрикс24 это позволяет.
Воронки можно связать туннелями, а сделку - автоматически скопировать или переместить в следующую воронку.

Но я бы начинал не с вопроса «сколько нам нужно воронок». Сначала нужно определить:

Какой законченный результат производит каждый отдел и кто отвечает за заказ целиком?
От ответа зависит, нужна ли одна сделка, несколько связанных сделок, смарт-процесс или отдельный верхнеуровневый объект.

Коротко

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

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

Для такого процесса в Битрикс24 можно рассматривать несколько вариантов:

1. Перемещать исходную сделку между воронками.
2. Завершать предыдущую сделку и создавать новую связанную сделку.
3. Оставить продажу сделкой, а следующий процесс вести в смарт-процессе.
4. Если процессов много и над ними есть единый ответственный, отдельно спроектировать верхний уровень заказа или проекта.

Универсально правильного варианта нет.
Количество воронок должно следовать из реальной работы компании, а не из количества отделов в организационной структуре.

Когда одной воронки достаточно

Представим обычную B2B-продажу.
Менеджер общается с клиентом.
Инженер помогает сделать расчёт.
Юрист проверяет договор.
Руководитель согласовывает скидку.

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

Совсем другая ситуация возникает после договора. Допустим, дальше начинается монтаж: Новая работа -> Подготовка -> Выезд назначен -> Работы выполняются -> Работы завершены -> Документы оформлены
У монтажа:

• другой ответственный;
• другие стадии;
• другие сроки;
• другой результат;
• свои причины задержек.

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

Четыре варианта архитектуры

Когда можно перемещать одну сделку

Битрикс24 позволяет соединять воронки туннелями.
У туннеля есть два основных сценария:

• копировать - в следующей воронке создаётся новая сделка, а исходная остаётся на месте;
• переместить - та же сделка переходит в следующую воронку и исчезает из предыдущей.
  Это штатная возможность Битрикс24. Подробнее она описана в официальной справке по туннелям продаж. Перемещение может быть нормальным решением, если компания действительно воспринимает путь клиента как один непрерывный процесс, а предыдущему подразделению не требуется сохранять отдельный законченный объект.

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

• входящие сделки;
• конверсию;
• длительность продажи;
• выигранные и проигранные сделки.

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

Поэтому правило не такое:

сделки нельзя переносить между воронками.

А такое:

Перед перемещением сделки нужно понять, должен ли предыдущий процесс остаться самостоятельным измеримым результатом.

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

Когда лучше создать новую сделку

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

После этого автоматически создаётся новый объект: Исполнение договора или: Монтаж. Тогда получается:

Продажа
   |
   v
Договор подписан
   |
   +--> продажа успешно завершена
   |
   v
Создаётся связанный процесс исполнения

Продажи сохраняют собственную историю и статистику.
Исполнение получает свои стадии, сроки и ответственных.

Битрикс24 позволяет штатно создавать копию сделки в другой воронке. Исходная сделка при этом остаётся в первой. В роботе повторных продаж также можно отдельно управлять копированием таймлайна. Это описано в справке по копированию сделки. Но здесь возникает следующий архитектурный вопрос.

Если сделок две, где хранить главные данные

Допустим, есть: Продажа и: Исполнение.
Что произойдёт, если срок поменяли только в одной карточке?
Где хранится актуальная сумма договора?
Что делать при изменении контактного лица?
Какие данные относятся к клиенту, а какие только к конкретному процессу?

Поэтому само копирование сделки ещё не решает архитектуру. Нужно заранее определить:

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

Иначе вместо одной перегруженной карточки можно получить две несогласованные.

Когда вместо сделки лучше смарт-процесс

Не вся работа компании является продажей. После коммерческого этапа могут начинаться:

• монтаж;
• производство;
• исполнение договора;
• техническое обследование;
• сервис;
• рекламация;
• тендерная работа;
• внутреннее согласование.

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

Например:

Сделка "Продажа"
       |
       v
Договор подписан
       |
       v
Смарт-процесс "Исполнение"
       |
       +-> Подготовка
       +-> Работы
       +-> Контроль
       +-> Документы
       +-> Завершено

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

• клиент;
• сумма;
• КП;
• договор;
• следующий коммерческий шаг.

В исполнении могут быть важны:

• объект;
• адрес;
• инженер;
• состав работ;
• сроки;
• технические документы;
• результат выполнения.

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

Шесть вопросов перед разделением процессов

До настройки воронок я бы ответил на шесть вопросов.

1. Что является результатом отдела?

Не действие, а законченный результат. Например:
Договор подписан
Тендер завершён
Работы выполнены
Отчёт передан клиенту

2. Где заканчивается ответственность отдела?

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

3. Нужна ли отделу отдельная аналитика?

Например, для продаж важны:

• конверсия;
• сроки сделки;
• причины отказов.

Для исполнения:

• количество работ в очереди;
• просрочки;
• срок выполнения;
• причины задержек.

Если управленческие вопросы разные, это аргумент в пользу разделения.

4. Может ли следующий процесс существовать самостоятельно?

Одна продажа иногда порождает не одну последующую работу. Например:
1 договор -> 5 объектов
или:
1 продажа -> регулярное сервисное обслуживание

Тогда схема «одна сделка просто переезжает дальше» может плохо описывать реальность.

5. Какие данные должны передаваться между процессами?

Нужно заранее разделить:

• общие клиентские данные;
• коммерческие данные;
• договорные данные;
• данные исполнения.

6. Кто отвечает за заказ целиком?

Это один из самых важных вопросов.

Что должен видеть владелец всего заказа

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

Продажа
   |
   v
Тендер / договор
   |
   v
Исполнение
   |
   v
Закрывающие документы

У каждого подразделения всё организовано правильно. Но руководителю проекта может быть нужно открыть одну карточку и увидеть:

• клиента;
• договор;
• сумму;
• оплату;
• текущий этап;
• ответственного;
• сроки;
• проблемные места.

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

Заказ / проект
|
+-> Продажа
|
+-> Договорный или тендерный процесс
|
+-> Исполнение
|
+-> Сервис

Технически такой контур можно строить разными способами. Например, цифровые рабочие места Битрикс24 позволяют объединять несколько процессов и связывать их между собой. Это описано в официальной справке по цифровым рабочим местам.

Но сначала нужно подтвердить саму бизнес-потребность.
Не стоит создавать «главную карточку заказа», если никто на самом деле не собирается ей пользоваться.

Почему четыре отдела и четыре услуги не означают 16 воронок

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

Допустим, есть 4 отдела:

• телемаркетинг;
• продажи;
• тендерный;
• технический.

И 4 услуги:

• обслуживание;
• монтаж;
• проектирование;
• лабораторные работы.
  Механически можно получить: 4 × 4 = 16 воронок. Но это почти никогда не должно быть исходной точкой проектирования.
  Допустим: Продажа монтажа и Продажа обслуживания проходят через одинаковые стадии: Запрос -> Квалификация -> Расчёт -> КП -> Договор

Тогда достаточно поля: Тип услуги. Отдельная воронка появляется тогда, когда реально отличается процесс:

• стадии;
• ответственность;
• сроки;
• документы;
• результат;
• автоматизация.

Количество услуг само по себе этого не доказывает.

Пример архитектуры

Возьмём условную B2B-компанию.
Сначала новый клиент проходит коммерческий процесс. Дальше возможны разные маршруты:

• обычный договор;
• тендер;
• техническое исполнение.

Одна из возможных архитектур:

Первичный контакт
       |
       v
     Продажа
       |
       +------> Тендерный процесс
       |              |
       |              v
       +----------> Договор
                       |
                       v
              Техническое исполнение
                       |
                       v
                   Завершено

При такой модели можно сохранить:

• отдельный результат продажи;
• отдельный тендерный процесс;
• отдельное исполнение;
• связь между всеми объектами.

Это не универсальный шаблон.
Для другой компании правильнее оставить одну воронку.
Для третьей - использовать несколько сделок.
Для четвёртой - сделку и смарт-процесс.

Поэтому списка требований к Битрикс24 часто недостаточно для выбора архитектуры. Нужно понять реальные границы процессов и ответственность сотрудников.

Что определить до настройки Битрикс24

Перед созданием нескольких воронок ответьте на шесть вопросов:

1. Какой законченный результат производит каждый отдел?
2. В какой момент его ответственность заканчивается?
3. Нужно ли отдельно измерять этот процесс?
4. Какие данные получает следующий отдел?
5. Кто отвечает за заказ целиком?
6. Что этот человек должен видеть в одном месте?

После этого количество воронок обычно становится следствием модели, а не предметом спора.

Если CRM только внедряется или давно не используется регулярно, не обязательно сразу строить максимальную архитектуру. Иногда правильнее сначала запустить минимальный рабочий контур и расширять его по мере накопления реальных данных. Этот подход мы подробнее разбирали в статье про этапы внедрения Битрикс24 в отдел продаж.

Главное

Битрикс24 позволяет:

• создавать несколько воронок;
• соединять их туннелями;
• перемещать сделки;
• создавать копии сделок;
• использовать смарт-процессы;
• связывать отдельные процессы между собой.

Но функция Битрикс24 не должна определять бизнес-архитектуру. Сначала нужно понять процессы.

Если это одна работа с одним конечным результатом - вероятно, достаточно одной воронки.

Если подразделение получает самостоятельную работу со своим результатом и аналитикой - процесс стоит рассматривать отдельно.

Если следующий процесс должен жить независимо - имеет смысл сохранить результат первого и создать связанный объект следующего.

Если над несколькими процессами есть один ответственный - отдельно решите, как он будет видеть заказ целиком.

По моем нению, хорошая CRM в итоге должна отвечать сразу на два вопроса:

Что сейчас должен сделать конкретный сотрудник?

и

Что сейчас происходит с заказом в целом?

Если система уверенно отвечает только на один из них, архитектуру ещё стоит проверить.

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

Можно ли сделать несколько воронок в Битрикс24?

Да. В Битрикс24 можно создавать отдельные воронки сделок и настраивать для них свои стадии. Возможности и количество воронок зависят от тарифа.

Можно ли автоматически передавать сделку между воронками?

Да. Туннели продаж позволяют автоматически переместить сделку или создать её копию в другой воронке. При копировании исходная сделка остаётся на месте, при перемещении исчезает из исходной воронки.

Что лучше - копировать или перемещать сделку?

Зависит от процесса. Если предыдущему отделу важно сохранить отдельный законченный результат и аналитику, копирование или создание отдельного связанного процесса часто удобнее. Для одного непрерывного процесса перемещение может быть достаточным.

Когда использовать смарт-процесс?

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

Нужна ли отдельная воронка для каждого отдела?

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

Нужна ли отдельная воронка для каждого вида услуги?

Нет. Если разные услуги проходят одинаковые стадии и отличаются только набором данных или параметрами, часто достаточно поля с типом услуги. Отдельную воронку стоит рассматривать, когда отличается сам процесс.