Рабочая воронка показывает, где находится сделка и кто, что и к какому сроку должен сделать дальше.
РОП открывает канбан в пятницу вечером. В колонке «Переговоры» лежат сделки на крупную сумму. По нескольким клиентам менеджер ждёт ответ, у одной сделки готовят расчёт, в другой клиент месяц назад попросил вернуться позже, а ещё две давно выбрали конкурента. В отчёте это одна стадия и один прогноз.
Перенести старые карточки в архив кажется быстрым решением. Но так исчезает причина: у отдела нет правила следующего шага, срока и закрытия. В понедельник та же проблема появится в новых сделках.
Спешите? В коротких ответах разобрали, нужно ли закрывать сделку, если клиент молчит, и когда достаточно дисциплины менеджеров без роботов.
Зависшая сделка появляется там, где у неё нет следующего действия
Этапы сделки в CRM сами по себе не управляют продажей. Управляет правило: на каждой открытой сделке должен быть назначен следующий шаг с ответственным и сроком, либо должно быть зафиксировано основание, по которому работа завершена или отложена на конкретную дату.
Это важнее названия колонки. Сделка может находиться на этапе «Предложение отправлено» две недели и оставаться нормальной рабочей сделкой, если менеджер договорился о дате обратной связи и создал дело. А карточка, передвинутая вчера в «Переговоры» без дела, уже выпала из управления.
В Битрикс24 стадии можно изменять и добавлять, а в канбане видны количество и сумма сделок на каждом этапе. Канбан отвечает на вопрос «где карточки», но не на вопрос «какая из них требует действия сегодня». Официальная справка о стадиях описывает настройку этапов, а инструкция по работе со сделками описывает планирование дел и счётчики сроков.
Я бы не начинал с роботов и уж тем более с новых обязательных полей. Сначала договоритесь с отделом о двух состояниях открытой сделки:
- есть ближайшее действие: звонок, письмо, встреча, подготовка расчёта или внутреннее согласование, у него есть исполнитель и дата;
- активного действия пока нет, но есть подтверждённая причина ожидания и дата, когда менеджер обязан вернуться к клиенту.
Если ни одно состояние не подходит, карточка не должна бесконечно лежать в воронке. Её нужно перевести в отдельную отложенную работу с понятным сроком либо закрыть как проигранную с причиной.
Не смешивайте в одной колонке разные причины ожидания
Обычно зависание начинается не потому, что менеджер забыл передвинуть сделку. В одной стадии смешиваются разные ситуации, для которых нужны разные действия. «Клиент думает» может означать ожидание решения закупщика, подготовку коммерческого предложения, отсутствие бюджета, невозможность дозвониться или неготовность менеджера продолжать разговор. Руководитель видит общий объём и не может выбрать действие.
Сначала разберите выборку свежих карточек: например, по 10–15 открытых сделок из каждой длинной стадии. Цель: увидеть, что реально делает отдел и чем заполнена колонка.
Для каждой карточки зафиксируйте четыре поля в рабочей таблице или выгрузке CRM:
| Что проверить | Зачем это нужно | Какое решение это поддерживает |
|---|---|---|
| Возраст на текущем этапе | Отделяет свежую очередь от старых карточек | Где нужен допустимый срок по стадии |
| Последнее содержательное действие | Показывает, ведут ли переговоры или карточка просто хранится | Нужен ли разбор работы менеджера |
| Следующее дело и его дата | Проверяет, вернётся ли менеджер к клиенту | Кому напомнить или что эскалировать |
| Причина ожидания или отказа | Разводит разные сценарии внутри одной стадии | Нужна ли новая стадия, поле или правило закрытия |
Причины зависания обычно оказываются вполне приземлёнными. Менеджер ждёт расчёт от коллеги, но задача не связана со сделкой. Клиент попросил вернуться через месяц, а дата записана в комментарии. Стадия «Согласование» используется и для согласования цены внутри компании, и для ответа клиента. Или команда считает закрытие проигранной сделки признанием неудачи, поэтому карточку оставляют «на всякий случай».
Пока проигранные сделки лежат среди активных, РОП завышает прогноз, а причины отказа остаются неизвестными. Закрытая сделка не пропадает из истории.
Этап сделки должен фиксировать факт, а не намерение менеджера
Название этапа полезно только тогда, когда два сотрудника одинаково понимают момент перехода. «Новая заявка», «встреча назначена», «предложение отправлено», «счёт выставлен» описывают наблюдаемое событие. «В работе», «думает» и «почти готов» требуют дополнительного правила, иначе каждый вкладывает в них свой смысл.
Ниже приведена условная модель B2B-продажи услуги, а не шаблон или данные клиента «Код в деле». Она показывает, какие условия контроля нужны этапам завершения сделки.
| Этап | Когда сделка попадает на этап | Что обязано быть в карточке | Допустимый возраст и реакция |
|---|---|---|---|
| Новое обращение | Заявка создана, ответственный ещё не начал работу | Источник, контакт, ответственный | Срок первого ответа; при просрочке уведомить владельца очереди |
| Квалификация | Менеджер выясняет потребность и пригодность лида | Цель обращения, результат контакта, следующее дело | Согласованный срок; без дела сделка попадает в список контроля |
| Предложение отправлено | Клиент получил согласованный вариант | Версия или ссылка на предложение, дата следующей связи | До даты обратной связи менеджер ведёт дело, затем выполняет контакт или фиксирует новую договорённость |
| Согласование условий | Есть конкретный предмет согласования | Что согласовывают, кто принимает решение, срок ответа | Если срок прошёл, владелец стадии либо эскалирует вопрос, либо переводит сделку в отложенную работу/отказ |
| Счёт выставлен | Есть решение выставить счёт | Сумма, срок оплаты, дата проверки оплаты | Контроль к дате оплаты, затем повторный контакт или закрытие по факту |
| Успех или отказ | Результат продажи известен | Сумма и дата успеха либо причина отказа | Открытых дел по продаже не остаётся |
Не добавляйте отдельную стадию для каждого внутреннего действия. Подготовка расчёта и согласование скидки могут быть задачами внутри одного этапа. При двадцати колонках менеджер начнёт перескакивать между ними, а возраст этапа потеряет смысл.
Разделяйте этапы, когда различаются факт о клиенте, владелец следующего шага, допустимый срок или управленческая реакция. Так этапы сделки в продажах становятся рабочим языком отдела.
Возраст сделки полезнее считать по этапу, а не по дате создания
Старая сделка не обязательно проблемная. В проектной продаже клиент может согласовывать бюджет месяцами, и сам возраст карточки ничего не доказывает. Полезнее измерять время с момента входа в текущий этап и смотреть его рядом со следующим делом.
Для еженедельного контроля разделите открытые сделки на три списка: те, что находятся в пределах согласованного срока; те, у которых срок этапа закончился, но следующее действие назначено; и карточки без следующего дела либо с просроченным делом. РОПу в первую очередь нужен третий список. Это очередь для решения, а не показатель для публичного рейтинга менеджеров.
Простая формула для проверки выглядит так:
`Возраст этапа = дата и время проверки − дата и время входа в текущую стадию`
Сравнивать этот возраст имеет смысл с нормативом конкретного этапа. Например, если отдел сам установил для «Квалификации» один рабочий день, а для «Согласования условий» семь календарных дней, общий фильтр «старше трёх дней» будет ошибочно тревожить одни сделки и пропускать другие.
В обезличенной выгрузке для такой проверки понадобятся идентификатор сделки, текущая стадия, дата входа, ответственный, дата и статус ближайшего дела, дата последнего действия, сумма и причина закрытия. Если даты входа в стадию нет, проверьте историю изменений: возраст этапа нельзя подменять возрастом карточки.
Условная модель. В «Предложении отправлено» лежат 18 сделок. У десяти назначен звонок на будущую дату, у четырёх дело просрочено, ещё у четырёх следующего действия нет. Сначала руководитель разбирает восемь последних карточек, а не заставляет весь отдел передвинуть все 18 сделок. После разбора может оказаться, что две сделки стоит закрыть с причиной, трём назначить контакт, а для трёх поменять правило работы с расчётом. Это модель логики контроля, а не результат реального проекта.
Среднее время на стадии полезно для динамики, но не для оперативной очереди: одна старая карточка сильно меняет среднее. Для планёрки лучше список сделок старше срока и медиана возраста по стадии, если данных достаточно.
Правило закрытия защищает прогноз, а не наказывает менеджера
Закрывать сделку нужно не тогда, когда хочется сделать канбан красивее, а когда компания приняла решение прекратить активную продажу. Для этого заранее определите события, после которых менеджер обязан выбрать результат: клиент прямо отказался; выбрал другого поставщика; запрос нецелевой; бюджета нет в согласованном периоде; после согласованного числа попыток контакта связь не состоялась.
У этих причин должен быть ограниченный справочник. «Другое» допустимо, но только с коротким комментарием. Пятьдесят вариантов причин не дадут руководителю больше знаний, а одна причина «не получилось» не объяснит ничего.
Отдельно опишите сценарий «вернуться позже». Это не отказ и не вечное ожидание. Если клиент попросил связаться в следующем квартале, менеджер фиксирует дату, причину переноса и конкретное дело. Сделку можно оставить в этапе ожидания, если такой этап действительно нужен для прогноза и у него есть свой срок контроля. Если его нет, проще сохранить отложенный контакт как задачу и не включать сделку в активную воронку.
Не превращайте правило закрытия в гонку за процентом отказов. Если руководитель использует проигрыши как наказание, менеджер будет бояться закрывать карточки. Цель правила: отличать живую возможность от истории, по которой сейчас никто не действует.
Напоминания автоматизируют договорённость, а не придумывают её
После того как правила согласованы, часть контроля можно перенести в CRM. В Битрикс24 для дел доступны напоминания и счётчики; для каждой воронки можно настроить собственные интервалы уведомлений. Справка о напоминаниях уточняет: уведомление связано со сроком дела, а не заменяет планирование самого действия.
Робот на входе в стадию также может запланировать дело, назначить исполнителя и срок. Это удобно для повторяемого сценария: например, после перевода в «Согласование договора» поставить менеджеру звонок на следующий рабочий день. Официальное описание роботов показывает настройку такого дела и его связь со стадией.
Начните с одного-двух сценариев, где правило уже работает вручную:
- Сделка попала в «Квалификацию»: CRM создаёт дело «Связаться с клиентом» на срок, который утвердил отдел. Менеджер после разговора закрывает дело и либо назначает следующий шаг, либо переводит сделку по правилу.
- Сделка находится на этапе «Предложение отправлено» дольше своего норматива: CRM напоминает владельцу стадии, а через согласованный период добавляет карточку в список РОПа. Уведомление не должно автоматически закрывать сделку: система не знает, что происходило в разговоре с клиентом.
- В сделке нет активного дела: CRM создаёт задачу на проверку карточки или отправляет уведомление. Такой сценарий полезен только после того, как команда определила исключения: например, когда есть зафиксированная дата отложенного контакта.
Не настраивайте эскалацию руководителю на каждую просрочку. Если уведомления приходят десятками, их перестают читать. РОПу нужна очередь из сделок без следующего действия, карточек старше срока этапа и повторяющихся задержек.
Практический инструмент: карточка контроля зависших сделок на неделю
Используйте этот чек-лист перед еженедельной встречей отдела. Его можно заполнить по обезличенной выгрузке или прямо по списку сделок в CRM. Не начинайте с вопроса «почему плохая конверсия»; сначала соберите карточки, по которым требуется решение.
- Для каждой открытой стадии назначены владелец, наблюдаемое условие перехода и допустимый возраст.
- В выборке проверены сделки без следующего дела и сделки с просроченным делом.
- Для каждой проблемной карточки выбран один исход: действие назначено, срок ожидания подтверждён, вопрос эскалирован или сделка закрыта.
- Причины отказов выбираются из понятного справочника и не заполняются задним числом наугад.
- Отложенные контакты имеют дату возврата и не смешиваются с активным прогнозом без отдельного правила.
- РОП видит отдельный список сделок старше срока по этапу, а не только общую сумму в колонках.
- Автоматические напоминания повторяют утверждённые сроки и не создают поток бесполезных уведомлений.
После двух-трёх разборов посмотрите, какие этапы чаще дают карточки без следующего действия. Стадии-складу обычно не хватает условия перехода, владельца или сценария ожидания клиента.
Короткие ответы на частые вопросы
01Нужно ли закрывать сделку, если клиент не отвечает?
Закрывайте её после заранее согласованного правила контактов, а не через произвольное число дней. Менеджер должен зафиксировать попытки связи и выбранную причину отказа. Если клиент назвал дату, когда готов вернуться к разговору, назначьте дело на эту дату; не оставляйте карточку без следующего шага.
02Чем этапы завершения сделки отличаются от задач менеджера?
Этап фиксирует факт, который уже произошёл с клиентом: предложение получено, счёт выставлен, оплата поступила. Задача описывает действие, которое должен выполнить сотрудник. Когда в одной колонке пытаются хранить оба смысла, этап становится непонятным, а сделки начинают зависать.
03Что делать, если сделка в Битрикс24 зависла на этапе?
Сначала откройте карточку и проверьте последнее действие, ближайшее дело, его срок и причину ожидания. Затем выберите один исход: выполнить контакт, назначить новый срок с основанием, передать вопрос владельцу или закрыть сделку. Массовое перемещение карточек между стадиями без такого разбора только меняет картинку в канбане.
04Достаточно ли напоминаний, чтобы менеджеры не забывали о сделках?
Напоминание сработает по сроку уже созданного дела. Оно полезно, когда отдел заранее определил, какое дело должно появиться и когда его выполнять. Если менеджер не понимает, что считать следующим шагом, робот будет аккуратно напоминать о плохо описанном процессе.
05Когда достаточно таблицы, а не доработки CRM?
Таблица подходит, пока небольшой поток ведёт один человек и он может регулярно проверить каждую строку. Когда в сделках участвуют несколько менеджеров и коллег из других ролей, нужны история действий, напоминания, назначение ответственных и общий список просрочек. Но правила этапов и закрытия всё равно придётся согласовать до настройки системы.
Сделки перестают зависать, когда у каждой открытой карточки есть действие, подтверждённое ожидание с датой или закрытый результат. Начните с самой перегруженной стадии и закрепите правило на реальных карточках.
В воронке много старых сделок, но непонятно, где заканчивается ожидание и начинается потеря? На аудите процесса продаж разберём возраст сделок по этапам, правила следующего шага и причины зависания. После разбора будет ясно, какие правила можно закрепить в CRM, а где сначала нужно договориться о работе отдела.
