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