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