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

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

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

Когда нужны разные воронки

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

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

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

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

Копировать или переместить сделку

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

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

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

Что передаётся вместе с работой

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

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

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

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

Логика настройки туннеля

Справка указывает путь «CRM → Сделки → Воронки → Воронки и туннели продаж». В этом разделе связывают исходную и целевую стадии. Туннель реализован роботом: для него доступны настройки очереди, времени, условия, названия, целевой воронки и стадии, ответственного. Набор действий проверяйте в своём портале.

Начните с исходной стадии. Она должна означать готовность к следующему процессу, а не удобный момент для менеджера. «Предложение отправлено» и «Заказ согласован» дают разные основания для запуска исполнения. Если стадия объединяет несколько смыслов, сначала уточните её правило, иначе туннель будет регулярно передавать неподготовленную работу.

1. Определите исходную воронку и событие готовности. Запишите, какое подтверждение уже должно быть в сделке.
2. Выберите целевую воронку и первую рабочую стадию. Название стадии должно подсказывать принимающей команде следующий шаг.
3. Выберите копирование или перемещение по последствиям для работы и учёта, а не по привычке настройщика.
4. Определите ответственного. Проверьте, может ли он принять объект и какие действия ему разрешены.
5. Задайте очередь, время и условие. Сопоставьте их с другими действиями на той же стадии.
6. Испытайте результат до включения для всей команды и зафиксируйте порядок исправления ошибок.

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

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

Как проверить ошибки и повторный вход

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

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

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

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

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

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

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

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

Третий случай - новая покупка прежнего клиента. Она может обоснованно создать отдельную работу, тогда как повторный технический вход старой сделки на стадию не должен выглядеть новой покупкой. Для различения полезно записать основание заказа и связь с исходной продажей. Конкретные поля и способ контроля выбираются при проектировании. Нельзя обещать, что совпадение контакта само решает задачу.

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

Как не посчитать продажу дважды

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

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

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

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

Приёмка и следующий шаг

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

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

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

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

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

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

Источники

• Битрикс24: туннели продаж, копирование, перемещение и настройка

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