Как выстроить стадии продаж в CRM — почему названия решают всё
CRM куплена, доска открыта, колонки расставлены. Кажется, что система работает. Через месяц руководитель отдела продаж открывает отчёт и видит: из пятнадцати сделок двенадцать стоят в колонке «Заинтересован» — какие-то три дня, какие-то три месяца. Никто не считает это проблемой, ведь CRM «работает»: открывается, заполняется, колонки на месте. Только эти колонки ничего не говорят.
Причина не техническая. Названия стадий описывают не действие клиента, а ощущение продавца в моменте. «Заинтересован», «тёплый», «на стадии раздумий» — ни одно из этих слов не проходит проверку. Два менеджера ставят одного и того же клиента в разные колонки, потому что смысл слова у каждого свой.
Стадия — это действие, а не настроение
У каждой колонки в CRM должен быть один тест: что клиент сделал? Не как менеджер это почувствовал — что произошло, и это можно проверить. «Заинтересован» ответа не даёт: кто, когда и как решил, что клиент заинтересован? У «встреча назначена» ответ есть — дата в календаре либо стоит, либо нет.
На практике разница выглядит так:
- Вместо «тёплый клиент»: «ответил на второй звонок, спросил цену»
- Вместо «на стадии раздумий»: «получил предложение, подтвердил, что открыл письмо»
- Вместо «почти закрыто»: «отправлен вариант договора, дата подписания согласована»
За формулировкой справа всегда стоит проверяемый след — отправленное письмо, встреча в календаре, подписанный документ. За формулировкой слева — состояние продавца в конкретный момент, а оно меняется день ото дня и у каждого работает по-своему. В отчёте можно написать «40% сделок на стадии раздумий», но эта цифра ничего не измеряет, если сама колонка не является измерением.
У каждой стадии должно быть условие выхода
Переименовать колонки недостаточно — у каждой стадии должно быть письменное условие выхода: после какого именно события сделка переходит дальше? Без такого условия сделка зависает в колонке надолго, потому что переносить её «не за что» — пока кто-то случайно не вспомнит.
Рабочий приём: на карточке стадии пишется одна строка — «Выход отсюда: клиент дал письменный ответ на предложение (да / нет / вопрос)». В большинстве CRM (HubSpot, Zoho, Bitrix24) для стадии есть отдельное поле описания, и оно чаще всего пустует не потому, что не нужно, а потому что никто не потребовал заполнить его письменно.
Только тогда среднее число дней на стадии, которое CRM считает сама, начинает что-то значить. Без условия выхода цифра «в среднем 12 дней» ничем не отличается от случайного числа на бумаге.
Название стадии — это вопрос: чем это доказано? Если ответа нет, это не стадия, а настроение.
Сколько стадий достаточно
Некоторые команды делают отдельную колонку под каждый внутренний шаг: назначен, связались, квалифицирован, встреча назначена, встреча прошла, предложение готово, предложение отправлено, переговоры, устное согласие, договор отправлен, подписан. Одиннадцать колонок. На бумаге выглядит точно, на практике каждая лишняя колонка — это ещё один клик, который нужно сделать вовремя, а несделанный вовремя клик делает отчёт лживым.
Меньше стадий, каждая привязана к внешне заметному следу, работает надёжнее: Контакт → Встреча → Предложение → Переговоры → Закрыто. Мелкие внутренние шаги между ними — подготовка предложения, второй звонок — остаются не колонкой, а списком задач внутри карточки сделки. Кому нужно, тот откроет карточку, а отчёт эти шаги не портят.
Как проверить стадии, прежде чем внедрять
Правильно названный список стадий может хорошо выглядеть на бумаге, а команда всё равно будет читать его по-разному. Есть короткая проверка на три шага — до того, как CRM настроена окончательно.
1. Опишите текущий процесс на бумаге
Без CRM опишите, что происходит на самом деле — не как должно быть, а как есть сейчас. Часто уже здесь видно: один и тот же шаг два человека в команде называют по-разному.
2. К каждому шагу задайте вопрос «чем это доказано»
Рядом с каждым пунктом списка запишите: чем менеджер подтверждает, что шаг пройден? Письмо, запись в календаре, подписанный документ — шаг без ответа ещё не стадия, ему нужно определение.
3. Проверьте на реальных сделках, потом переносите в систему
Новый список проверяется неделю на бумаге или в простой таблице, на настоящих сделках. Если команда не может договориться о смысле стадии на этом этапе, дешевле увидеть это сейчас, чем переделывать потом в уже настроенной CRM.
Проигранная сделка — тоже стадия, а не пропажа
Во многих пайплайнах проигранную сделку просто удаляют или отправляют в архив — статистика выглядит «чистой», но причина проигрыша нигде не остаётся. Это та же проблема, что и в средних стадиях, только на выходе: вместо действия записывается ощущение («клиент остыл»), а потом сделка забывается полностью.
Решение простое: «Проиграно» должно быть отдельной, финальной стадией с обязательным полем причины — цена, не подошли сроки, ушёл к конкуренту, пропала связь. Статус «Проиграно» без заполненной причины — это не стадия, а просто кнопка удаления.
Через три месяца это поле само превращается в отчёт: сколько сделок потеряно из-за цены, сколько — из-за конкурента. Это даёт реальное основание менять то, как составляется предложение. Сказать «реклама приведёт клиентов, а продажи разберутся сами» легко, но проверить это утверждение не на чем в системе, которая никогда не фиксирует причину проигрыша.
Зачем всё это нужно
Настройка не разовая — новый продукт, новый канал продаж или выросшая команда снова потребуют пересмотра стадий. Но принцип не меняется: каждая колонка — ответ на вопрос «чем это доказано».
Разница в результате ощутима. Когда стадии привязаны к действию, прогноз перестаёт быть догадкой и становится расчётом — CRM показывает, сколько сделок и на какой стадии находится, и из этого можно вывести реальный прогноз выручки. Новый менеджер тоже быстрее осваивается: смысл каждой колонки написан заранее, спрашивать никого не нужно.
Если нужно построить CRM с нуля или пересобрать стадии в уже работающей панели, наша услуга настройки CRM со стадиями, привязанными к действию как раз для этого — настраиваем процесс в HubSpot, Zoho, Bitrix24 или в системе, которую строим с нуля.
