Воронка CRM показывает состояние клиента и ближайшее действие. Для старта обычно достаточно девяти состояний: новая заявка, квалификация, запись, ожидается встреча, предложение, решение, оплата, работа, завершение или следующий продукт. Это не отраслевой стандарт. Схему нужно менять под реальный путь клиента.
Результат настройки - таблица с условиями входа и выхода, следующим действием и ответственным.
Почему база контактов не показывает работу
Карточка контакта отвечает на вопрос, кто этот человек и как с ним связаться. В ней хранятся имя, телефон, канал обращения, согласия и заметки. Но сама карточка не объясняет ситуацию по заявке.
Стадия описывает состояние процесса. Например, клиент выбрал время, но встреча еще не состоялась. Задача указывает, что и когда должен сделать конкретный человек: проверить анкету или отправить итог встречи.
Если эти сущности смешаны, в CRM появляются записи «думает», «теплый» или «написать позже». Через неделю они уже не объясняют, что произошло, какого решения мы ждем и кто продолжит работу.
Поэтому я разделяю три слоя:
- карточка хранит данные о клиенте и контекст;
- статус показывает положение заявки или действующего клиента;
- задача фиксирует действие, ответственного и срок.
Подробнее о составе карточки я писал в материале про клиентскую базу эксперта в CRM.
Почему больше статусов не означает больше контроля
Когда воронка плохо читается, хочется добавить подробности: «не ответил первый раз», «вернуться через месяц». Так статус заменяет задачи, заметки и причины отказа.
Контроля не прибавляется. Похожие названия выбираются по настроению, а отчет приходится расшифровывать вручную. «Назначена встреча» и «записан» могут обозначать одно событие. «Холодный» не сообщает, был ли контакт. «Думает до пятницы» смешивает состояние, срок и задачу, хотя эти данные меняются отдельно.
Название стоит проверить двумя вопросами: какое событие уже произошло и какое событие переведет карточку дальше? Если однозначного ответа нет, статус лучше уточнить или убрать.
Собираем путь из девяти состояний
Начните с реального маршрута, а не с интерфейса CRM. Выпишите события от обращения до завершения работы. Объедините шаги, между которыми нет отдельного решения или действия:
| Статус | Условие входа | Условие выхода | Следующее действие | Владелец |
|---|---|---|---|---|
| Новая заявка | Получено обращение с контактами | Начат содержательный контакт | Проверить источник и ответить | Консультант или помощник |
| Квалификация | Начат разговор о задаче и формате | Понятно, подходит ли следующий шаг | Уточнить задачу и критерии входа | Консультант |
| Запись | Клиенту предложена встреча | Выбраны дата и время | Согласовать слот и условия | Клиент, затем консультант |
| Ожидается встреча | Дата подтверждена | Встреча состоялась или отменена | Проверить подготовку и ссылку | Консультант или система |
| Предложение | Сформирован вариант работы | Клиент дал решение | Передать условия и назначить следующий контакт | Консультант |
| Решение | Клиент изучает предложение | Получено согласие или отказ | Связаться в согласованный момент | Консультант |
| Оплата | Клиент согласился на формат | Оплата подтверждена | Проверить платеж и начать онбординг | Ответственный за оплату |
| Работа | Обязательства сторон начались | Результат принят или работа прекращена | Вести задачи по продукту | Консультант |
| Завершение / следующий продукт | Текущий этап завершен | Зафиксированы итог и следующий шаг | Подвести итог и определить продолжение | Консультант |
Количество строк не универсально. Если предложение и решение происходят в одном разговоре, их можно объединить. Обязательной анкете до записи может понадобиться отдельное состояние. Новый статус нужен из-за реального перехода, а не ради списка.
Отказ, отсутствие связи, перенос и неподходящий запрос можно хранить как результат или причину закрытия, а не как отдельные стадии. Так основная воронка остается читаемой.
Правила смены статуса
Одинаковые названия еще не создают одинаковый процесс. Для каждой строки нужны правила перехода. Я фиксирую пять элементов.
- Событие. Что произошло: получен ответ, выбрано время, проведена встреча, подтверждена оплата.
- Обязательное поле. Что заполнить до перехода: источник, дату встречи, формат или причину закрытия.
- Задача. Какое действие появляется после перехода.
- Ответственный. Кто контролирует задачу и исключения, даже если сообщение отправляет система.
- Допустимый срок. Когда карточка считается зависшей и требует проверки.
Сроки нельзя копировать из чужой воронки. Они зависят от продукта, режима работы и договоренностей. Ответ на следующий рабочий день для одного специалиста нормален, для другого слишком поздний. Срок здесь - настраиваемая политика, а не обещание CRM.
Автоматизация уместна, когда правила уже работают вручную. Система может создать задачу или напомнить о проверке, но не определит смысл перехода. Настройку контакта после встречи я разбирал в статье про follow-up после диагностики.
При хранении контактов и заметок учитывайте законность обработки персональных данных, необходимый состав сведений и ограничения доступа. Конкретные требования зависят от ситуации и требуют юридической проверки.
Составной пример и аудит зависших карточек
Это составной пример, а не кейс клиента. Заявка из формы попадает в «Новую заявку», а консультант получает задачу проверить обращение. После разговора запрос подходит для диагностической встречи, и карточка переходит в «Запись».
Клиент выбирает время. В карточке появляются дата и задача проверить подготовку, статус меняется на «Ожидается встреча». После встречи специалист отправляет предложение и назначает следующий контакт. Карточка находится в «Решении», но не остается без задачи.
После согласия и оплаты начинается работа. В конце специалист фиксирует итог, закрывает обязательства и решает, уместен ли следующий продукт. Логику такого предложения я описал в статье о следующем продукте после консультации.
Этот пример объясняет процесс, но не доказывает рост продаж и не гарантирует, что девять состояний подойдут другой практике. Проверять нужно собственные переходы.
Раз в неделю отфильтруйте открытые карточки без будущей задачи и те, что находятся в статусе дольше принятого срока. По каждой проверьте:
- произошло ли событие для текущего статуса;
- заполнено ли обязательное поле;
- назначено ли следующее действие;
- понятен ли ответственный.
Если карточка зависла из-за исключения, не создавайте новый статус сразу. Проверьте, встречается ли такая ситуация снова. Редкий случай можно обработать задачей и заметкой, а устойчивый разрыв добавить в карту процесса.
Начните с таблицы на девять строк, проведите через нее несколько реальных заявок и уберите состояния, которые не меняют действие или ответственность. Хорошая карточка хранит прошлое и подсказывает следующий управляемый шаг.
Если вы выстраиваете продукт и путь клиента как единую систему, посмотрите программу для экспертов.