Антон Дегтярёвпроектирование сделок в битрикс24: разбор чужих ошибок
Воронку в Битрикс24 почти всегда проектируют дважды. Первый раз — на внедрении, за два часа совещания, где схему рисуют так, как её видит руководитель. Второй раз — через полгода, когда отчёты перестали сходиться с тем, что происходит в отделе продаж. Второй раз дороже: в базе уже лежат сотни сделок с историей, и любое изменение стадий по ним бьёт. Ниже — семь ошибок, которые я разбираю на чужих порталах чаще всего, и порядок, в котором схему можно переделать на живой базе.
почему схему сделок переделывают через полгода
Схему сделок обычно рисуют до того, как в CRM появились сами сделки. На старте проверять её не на чем: менеджеры ещё не начали двигать карточки, отчёты пустые, и любая схема выглядит рабочей. Расхождение с реальностью проявляется на объёме — когда в воронке накопилось несколько сотен карточек и руководитель впервые открывает конверсию по стадиям.
Типовой симптом, с которым меня зовут на аудит: 40-60% сделок висят на одной стадии, а конверсия по воронке в целом показывает 8-12% и никак не помогает принимать решения. Это почти никогда не проблема менеджеров. Это значит, что стадии описывают не тот процесс, который в компании реально происходит.
Разница между первым проектированием и вторым — в цене ошибки. На старте перерисовать стадии стоит полчаса. Через полгода за каждой стадией стоят роботы, отчёты, права доступа и триггеры, а по старым карточкам уже собрана статистика, которую при неаккуратном переносе можно потерять целиком.
ошибка 1 — стадии описывают отчёт, а не работу менеджера
Самая частая ошибка. Стадии называют так, как удобно смотреть руководителю в сводке: «в работе», «на согласовании», «в процессе», «финальная стадия». Менеджер открывает карточку и не понимает, что физически должен сделать, чтобы перевести сделку дальше — а раз критерий непонятен, карточки двигают либо все разом в конце недели, либо не двигают вообще.
Рабочий критерий простой: стадия должна называться действием с проверяемым результатом. Не «на согласовании», а «отправлено КП» — есть письмо в таймлайне или нет. Не «в работе», а «проведён созвон» — есть звонок в карточке или нет. Если по стадии нельзя за две секунды сказать «да, это уже произошло», её формулировку надо менять.
Проверяю это так: беру 10 случайных сделок из середины воронки и спрашиваю двух разных менеджеров, на какой стадии каждая должна стоять. Если ответы расходятся больше чем по трём карточкам — проблема в формулировках стадий, а не в дисциплине. Базовые правила первичной настройки я разбирал отдельно в статье про то, как настроить воронку продаж в Битрикс24.
ошибка 2 — одна воронка на все типы продаж
В одной воронке живут первичные продажи, повторные заказы от текущих клиентов и сервисные обращения. Логика на старте понятная: «это же всё продажи, зачем плодить сущности». Через полгода эта воронка перестаёт что-либо показывать, потому что цикл первичной сделки — 30-45 дней, а повторный заказ от постоянного клиента закрывается за день-два.
Средняя конверсия по такой смеси — бесполезное число. Повторные сделки закрываются почти все и тянут показатель вверх, первичные проваливаются и тянут вниз, а руководитель видит усреднённые 8-12% и не понимает, где именно теряются деньги. Разделение на две-три воронки обычно даёт нормальные раздельные цифры: 20-30% по первичным и 80-90% по повторным.
Критерий разделения — не отдел и не менеджер, а разный набор шагов. Если в двух типах продаж совпадают не все стадии, а только часть, это две воронки. Если совпадают все, а отличается только сумма или клиент — это одна воронка с разными полями. Пять воронок с тремя сделками в каждой — тоже ошибка, но противоположная: дробить имеет смысл там, где сценарии реально расходятся.
ошибка 3 — обязательные поля на входе вместо полей по стадиям
В карточке сделки 25-30 полей, и половина помечена обязательными на первой же стадии. Менеджер, чтобы просто зафиксировать входящий интерес, должен заполнить бюджет, срок, источник, тип объекта и ещё пять реквизитов, которых он на первом контакте не знает. Дальше происходит предсказуемое: поля забиваются мусором — «уточнить», «0», «нет данных».
В Битрикс24 обязательность поля настраивается по стадиям, и это главный инструмент против мусора в базе. Разумная схема: на первой стадии обязательны 2-3 поля (контакт, источник, суть запроса), бюджет и срок становятся обязательными к стадии коммерческого предложения, реквизиты для договора — к стадии счёта.
На аудитах я почти всегда сокращаю набор обязательных полей на входе до трёх и переношу остальное вниз по воронке. Побочный эффект, который клиенты не ожидают: количество заведённых сделок растёт на 15-25% — не потому, что стало больше клиентов, а потому что менеджеры перестали избегать создания карточки ради экономии времени.
ошибка 4 — «проиграно» без справочника причин
Стадия «сделка провалена» есть у всех, а справочник причин отказа — у меньшинства. Причину пишут в свободное поле, и она заполняется в лучшем случае наполовину, а формулировки расходятся: «дорого», «не сошлись в цене», «ушёл к конкуренту по цене» — это в отчёте три разные причины, хотя по смыслу одна.
Рабочее решение — список из 6-8 фиксированных вариантов, который закрывает почти все реальные случаи: дорого, выбрал конкурента, отложил решение, нет бюджета, не тот профиль клиента, нет ответа, решили своими силами, дубль. Больше восьми пунктов менеджеры перестают читать и выбирают первый попавшийся, меньше пяти — теряется смысл справочника.
Обязательность причины ставится на переход в «проиграно», а не на карточку в целом. Тогда сделку нельзя закрыть молча, и через квартал у вас появляется распределение отказов, по которому уже можно принимать решения — например, что 30% отказов «нет ответа» означают дыру не в цене, а в скорости первого контакта. Как читать такие цифры дальше, я разбирал в статье про то, как найти узкое место воронки за 15 минут.
ошибка 5 — сделка живёт вечно
В воронке нет правила закрытия, и карточки копятся годами. Открываешь портал через год работы — 400 сделок «в работе», из них половина последний раз двигалась 5-8 месяцев назад. Формально это воронка на 30 миллионов, фактически — мёртвый груз, который ломает любой прогноз выручки.
Правило должно быть явным и жёстким: сделка без активности N дней автоматически уходит в «отложено» или в «проиграно» с причиной «нет ответа». Значение N берётся не с потолка, а из реального цикла сделки — обычно это две-три средних длительности цикла. При цикле в 30 дней ставлю порог в 60-90 дней.
Механика — робот на стадии с проверкой даты последней активности, плюс задача ответственному за неделю до автозакрытия. Это не «потеря» сделок: карточка никуда не девается, её всегда можно поднять обратно. Настройку самих роботов и триггеров я разбирал в отдельной статье — роботы и триггеры в Битрикс24.
ошибка 6 — новая воронка вместо смарт-процесса
Появилась задача учитывать монтажи, закупку под заказ, гарантийные обращения или согласование договора — и в портале заводят под это ещё одну воронку сделок. Дальше начинается путаница: одна и та же продажа лежит в двух сделках, сумма задваивается в отчётах, а руководитель не понимает, почему выручка в CRM больше, чем в 1С.
Признак того, что перед вами не воронка сделок, а смарт-процесс: у сущности нет собственной суммы продажи и собственного клиента-плательщика, она обслуживает уже существующую сделку. Монтаж не продаётся отдельно — он привязан к сделке. Закупка не имеет своей выручки — она обеспечивает сделку. Всё это живёт в смарт-процессах, связанных со сделкой, и в сумму продаж не попадает.
Практический пример такой схемы я подробно разбирал в статье про автоматизацию закупок на смарт-процессе — там процесс из шести стадий висит на сделке и не искажает воронку продаж. Правило простое: своя выручка — воронка, обслуживающий процесс — смарт-процесс.
ошибка 7 — туннели между отделами без правил
Туннели переносят сделку из воронки в воронку при достижении стадии — например, из продаж в производство. Инструмент полезный, но без правил он создаёт дубли: исходная сделка остаётся в первой воронке, копия появляется во второй, обе живут своей жизнью, и обе попадают в отчёты по сумме.
Договориться нужно до настройки, а не после: в какой воронке сделка считается «настоящей» для отчёта по выручке, что происходит с исходной карточкой (закрывается как успешная или остаётся открытой), и кто становится ответственным после перехода. Без этих трёх ответов туннель ломает и отчётность, и зону ответственности.
Моё рабочее правило: сумма продажи считается ровно в одной воронке — той, где сделка закрывается деньгами. Все последующие воронки работают как исполнение и в выручку не суммируются. Если это правило нарушено, расхождение с 1С будет расти каждый месяц, а искать его придётся руками.
как перепроектировать живую воронку без потери истории
Схему на работающем портале нельзя менять «на живую» в середине рабочего дня — это самый быстрый способ получить сотню карточек в неопределённом состоянии. Порядок, которым я пользуюсь на проектах, состоит из пяти шагов и занимает от трёх до пяти рабочих дней.
Шаг 1 — снять текущие цифры до изменений: конверсия по стадиям, среднее время на стадии, количество карточек в каждой. Без этой фотографии вы потом не докажете, что стало лучше. Шаг 2 — составить таблицу соответствия старых стадий новым: каждая старая стадия должна иметь ровно один целевой адрес, включая «отложено» и «проиграно».
Шаг 3 — отключить роботов и триггеры на изменяемых стадиях. Если этого не сделать, при массовом переносе карточек роботы отработают на каждой и клиентам уйдёт пачка писем и СМС — ошибка, которую совершают один раз. Шаг 4 — перенести карточки группами по 100-200 штук, а не все сразу, проверяя после каждой группы, что суммы и ответственные не поплыли. Шаг 5 — включить роботов обратно и сверить контрольные цифры из первого шага.
что делать со старыми сделками
Главный вопрос при переезде: тащить ли на новую схему весь архив. Мой ответ — нет, и это экономит несколько дней работы. Закрытые сделки (успешные и проваленные) переносить бессмысленно: они уже не двигаются, а история по ним читается и в старом виде.
Переношу только открытые карточки. По ним делю на три группы: активные (была активность за последние 30 дней) — переносятся вручную с проверкой каждой, спящие (30-90 дней) — переносятся группой в соответствующую стадию, мёртвые (более 90 дней без движения) — закрываются с причиной «нет ответа» и в новую схему не едут вообще.
Время переноса выбираю намеренно: вечер пятницы или выходной. Смысл в том, чтобы менеджеры в понедельник утром начали работать уже на новой схеме и не переучивались в середине недели. Плюс к этому — короткая встреча на 20 минут в понедельник, где я показываю новые стадии и критерии перехода. Без этой встречи через неделю карточки поедут по старой логике.
чек-лист перед запуском новой схемы
Прохожу по нему перед каждым переездом. Первое: у каждой стадии есть проверяемый критерий перехода, сформулированный действием. Второе: обязательных полей на первой стадии не больше трёх, остальные привязаны к стадиям ниже. Третье: у «проиграно» есть справочник причин на 6-8 пунктов и он обязателен при переходе.
Четвёртое: задано правило автозакрытия по неактивности с порогом в две-три длительности цикла. Пятое: обслуживающие процессы вынесены в смарт-процессы и не попадают в сумму воронки. Шестое: если есть туннели — зафиксировано, в какой воронке считается выручка. Седьмое: сняты контрольные цифры до переноса и роботы отключены на время миграции.
Если хотя бы один пункт не закрыт, запуск лучше отложить на день и закрыть его — переделывать после того, как по новой схеме пошли живые сделки, дороже примерно вдвое. Более широкую проверку портала целиком я собрал отдельно — чек-лист аудита Битрикс24 на 40 пунктов. А если вы ещё на этапе выбора, работать через лиды или сразу сделками, начните со статьи про то, когда нужен лид, а когда сразу сделка.