Управление статусами лидов: жизненный цикл, правила перехода и предупреждение о зависании

Статусов лида не должно быть много: 6 статусов достаточно, чтобы охватить весь путь от получения до сделки: новый лид, контакт установлен, в переговорах, КП отправлено, сделка, закрыт. Если статусов больше 10, продавцы перестанут их аккуратно обновлять. Для каждого статуса...

询盘状态管理:6个状态,不多不少Inquiry lifecycle: 6 states, no more no less 状态越多越乱——80%的团队用了10个以上状态,真正有用的只有6个More states = more chaos — 6 is enough 新询盘New 未分配Unassigned 已联系Contacted 首响发出First reply sent 沟通中Negotiating 来回沟通Back-and-forth 已报价Quoted 报价已发Quote sent 成交/关闭Won/Lost 终态Closed 流转规则:只能前进不能后退,回退必须填原因Rules: forward only, backward needs reason 新→已联系(首响发出)→沟通中(买家回复)→已报价(报价发出)→成交/关闭New → Contacted → Negotiating → Quoted → Closed 停滞预警:每个状态设最大停留时长,超了自动告警Stall alert: max dwell time per state, auto-alert 已联系状态超过48小时无回复→预警;已报价超过7天无反馈→升级主管Contacted 48h no reply → alert; Quoted 7d no feedback → escalate 停滞预警三档Three-tier stall alert 黄灯:超最大停留时长50%→提醒销售跟进Yellow: 50% over → remind rep 橙灯:超最大停留时长100%→通知销售主管Orange: 100% over → notify manager 红灯:超最大停留时长200%→主管必须介入Red: 200% over → manager must step in
Шесть статусов жизненного цикла лида и три уровня предупреждения о зависании

Управление статусами лидов: жизненный цикл, правила перехода и предупреждение о зависании

Сначала вывод: Статусов лида не должно быть много: 6 статусов достаточно, чтобы охватить весь путь от получения до сделки: новый лид, контакт установлен, в переговорах, КП отправлено, сделка, закрыт. Если статусов больше 10, продавцы перестанут их аккуратно обновлять. Для каждого статуса нужно задать максимальное время пребывания, и при его превышении срабатывает автоматическое оповещение: контакт установлен, но 48 часов нет ответа — жёлтый сигнал; КП отправлено, но 7 дней нет обратной связи — оранжевый сигнал с эскалацией руководителю; превышение 200% — красный сигнал, руководитель обязан вмешаться. Контринтуитивный вывод: цель управления статусами не в том, чтобы продавец заполнял статусы, а в том, чтобы вы сразу видели, какие лиды застряли и как давно.

1. Шесть статусов: почему не восемь и не десять

Во многих CRM у команд больше десятка статусов лида: ждёт распределения, ждёт контакта, контакт установлен, в переговорах, КП отправлено, этап образца, изготовление образца, в переговорах по условиям, сделка, отказ, недействительный, дубликат, спам… Выглядит детально, но на практике продавцы их вообще не обновляют — чтобы сменить статус, нужно три клика, и проще не кликать. В итоге все лиды зависают в «в переговорах», и вы не понимаете, где реальный прогресс.

Статус Определение Условие входа Условие выхода Максимальное время пребывания
Новые запросы Только что получен, не распределён Форма успешно отправлена Назначен продавцу 24 часа
Установлен контакт Первый ответ отправлен, ждём ответа покупателя Продавец отправил первый ответ Покупатель ответил 48 часов
В переговорах Обсуждаем потребности и решение Покупатель ответил на первый ответ КП отправлено 7 дней
КП отправлено Коммерческое предложение отправлено, ждём ответа покупателя Письмо с КП отправлено Покупатель согласен или отказался 7 дней
Сделки Заказ подтверждён, договор подписан Покупатель подтвердил заказ Финальный статус, переходов больше нет —
Закрыть Сделка не состоялась, работа прекращена Явный отказ/недействительный/истёк срок Финальный статус, переходов больше нет —

Принцип этих шести статусов: каждый статус соответствует одному конкретному действию, и продавцу достаточно кликнуть в момент его совершения. Отправил первый ответ — нажал «контакт установлен»; покупатель ответил — нажал «в переговорах»; отправил КП — нажал «КП отправлено»; сделка состоялась или закрыта — нажал финальный статус. Промежуточные «этап образца» и «изготовление образца» не нужны — это для заметок, а не для статусов. Чем меньше статусов, тем охотнее продавцы их обновляют, и тем достовернее данные.

Пример: приходит запрос, и система автоматически начинает с статуса “Новый запрос”. Менеджер отвечает в течение 5 минут и нажимает “Связались”. На следующий день покупатель пишет, что ему нужно 500 единиц в Гамбург, и менеджер нажимает “В переговорах”. На третий день менеджер отправляет коммерческое предложение и нажимает “КП отправлено”. Через неделю покупатель подтверждает заказ, и менеджер нажимает “Сделка”. За весь процесс статус менялся всего четыре раза, и каждое изменение соответствует реальному действию. В этом и заключается практичность 6 статусов. О том, как SLA первого ответа сочетается с движением по статусам, читайте в SLA первого ответа на запрос и конверсия.

II. Правила перехода: только вперёд, назад — нельзя

У перехода статусов есть жёсткое правило: только вперёд, назад — нельзя. Из “Связались” нельзя вернуться в “Новый запрос”, из “В переговорах” — в “Связались”. Если покупатель говорит “я подумаю”, это не шаг назад, а остановка на месте — в статусе “В переговорах” или “КП отправлено”, до следующего касания. Откатить статус можно только в двух случаях: если запрос ошибочно назначили не тому менеджеру или если это дубликат. При откате обязательно указать причину, просто так нажать нельзя.

Действие Условие Действие системы Нужно ли подтверждение вручную
Новый запрос → Связались Менеджер отправил первый ответ Автоматически фиксируется время Нет, менеджер просто нажимает
Связались → В переговорах Покупатель ответил на письмо Система видит ответ и переводит автоматически Нет, автоматически
В переговорах → КП отправлено Менеджер отправил КП Автоматически фиксируется время отправки КП Нет, менеджер нажимает
КП отправлено → Сделка Покупатель подтвердил заказ Запускается процесс договора Да, нужно подтверждение руководителя
Любой → Закрыт Явный отказ/недействительный/истёк срок Обязательно указать причину закрытия Да, причина закрытия обязательна
Любой откат Ошибочное назначение / дубликат Обязательно указать причину отката Да, проверяет руководитель

Смысл правил перехода — не дать статусам “поплыть”. Например, менеджер три недели ведёт запрос, а потом, потому что давно нет движения, перетаскивает его из “КП отправлено” обратно в “В переговорах” и делает вид, что всё идёт нормально. Из-за такого дрейфа вам кажется, что запрос ещё жив, хотя на самом деле он уже мёртв. Поэтому при откате нужно указать причину и получить одобрение руководителя — менеджер не может откатить статус просто по своему желанию.

Причину закрытия указывать обязательно, и её нужно классифицировать. Обычно причин пять: отказ покупателя (слишком дорого / выбрал конкурента / пока не нужно), недействительный запрос (спам / конкурент / неверные контакты), нет ответа (три и более касания без реакции), дубликат (тот же покупатель отправил запрос повторно), другое. Если вы классифицируете причины закрытия, то увидите, на каком именно этапе умирают ваши запросы — из-за слишком высокой цены или из-за недостаточного числа касаний. О том, как выстроить цепочку касаний, читайте в Серия писем для работы с запросами.

III. Предупреждение о застое: три уровня оповещений

В управлении статусами страшна не путаница, а зависший статус, за которым никто не следит. Заявка две недели висит в статусе «Связались», менеджер забыл про неё, а вы даже не знаете — вот где происходят реальные потери. Предупреждение о застое задаёт максимальное время пребывания для каждого статуса: превысил — приходит автоматическое уведомление, и ни одна заявка не умирает тихо.

Уровень предупреждения Условие Кого уведомлять Требуемое действие Срок эскалации
Жёлтый сигнал Превышение максимального времени на 50% Менеджер, ведущий заявку Связаться в течение 24 часов Нет контакта 48 часов — переход на оранжевый
Оранжевый: эскалация Превышение максимального времени на 100% Менеджер + руководитель отдела продаж Руководитель подключается и разбирается Нет реакции 72 часа — переход на красный
Красный: вмешательство Превышение максимального времени на 200% Руководитель обязан вмешаться Руководитель сам ведёт заявку или закрывает её Результат нужен на этой неделе

Конкретный пример: максимальное время в статусе «Связались» — 48 часов. Жёлтый сигнал срабатывает на 72-м часу (48×1,5) и сообщает менеджеру: «Вы не трогали эту заявку уже 3 дня, свяжитесь с клиентом». Оранжевый — на 96-м часу (48×2), уведомление уходит и руководителю. Красный — на 144-м часу (48×3): руководитель обязан заняться заявкой лично — либо вести её сам, либо закрыть. Эта трёхуровневая система не даёт заявкам умирать беззвучно.

У разных статусов максимальное время разное. «Новая заявка» — 24 часа: она ещё не распределена, и медленное распределение ломает SLA первого ответа. «Связались» — 48 часов: если покупатель два дня не отвечает, интерес, скорее всего, пропал. «Общаемся» — 7 дней: неделя переписки без коммерческого предложения значит, что потребности ещё не согласованы. «КП отправлено» — 7 дней: неделя без ответа на предложение означает либо слишком высокую цену, либо покупатель сравнивает с конкурентами. За максимальным временем каждого статуса стоит момент, после которого «ждать дальше бессмысленно». Общий подход к скорингу и приоритизации лидов смотрите в Оценка и приоритизация заявок.

IV. Типичные ошибки в управлении статусами

Заблуждение Что делают Что получают Правильный подход
Слишком много статусов Больше 10 детальных статусов Менеджеры не обновляют, всё висит в «Общаемся» 6 статусов, каждому соответствует одно действие
Не задано максимальное время Статус висит сколько угодно Заявки тихо умирают, никто не замечает Для каждого статуса — максимальное время + предупреждение
Закрытие без указания причины Нажал «Закрыть» — и всё Непонятно, на каком шаге заявка погибла Причина закрытия обязательна, учёт по категориям
Произвольный откат статуса Менеджер откатывает, когда захочет Статусы дрейфуют, данные искажаются Откат только с причиной и одобрением руководителя
Предупреждения только по почте Оповещения приходят на email Менеджеры не читают почту, предупреждения не работают Всплывающее окно в системе + push в DingTalk/WeCom

Из этих пяти ошибок самая незаметная — последняя: предупреждения только по почте. Менеджер получает десятки писем в день, и письмо о застое тонет среди них. Правильно выводить предупреждения на главный экран рабочего места менеджера — прямо на дашборде CRM показывать: «У вас 3 заявки с жёлтым сигналом и 1 с оранжевым». Он открывает CRM и сразу это видит, не роясь в почте. О том, как проектировать наглядные дашборды, читайте в Панель мониторинга цитирований в AI-движках подход к дашборду.

Конечная цель управления статусами — не сделать CRM аккуратной на вид, а дать вам раз в неделю взглянуть на дашборд и сразу понять, сколько запросов застряло, на каком статусе, как долго и где нужно вмешательство руководителя. Управление статусами без предупреждений о застое — это просто цифры, на которые никто не смотрит. Связка сайта с CRM — обязательное условие для автоматической смены статусов, об этом читайте в Лиды с сайта в CRM.

FAQ: частые вопросы

Сколько статусов запроса оптимально?
Оптимально 6: новый запрос, связались, в переговорах, отправили КП, сделка, закрыт. Если статусов больше 10, продавцы перестанут их добросовестно обновлять, все запросы зависнут в «в переговорах», и вы не будете знать реального положения дел. За каждым статусом закреплено конкретное действие: отправили первый ответ — ставите «связались», покупатель ответил — «в переговорах», отправили КП — «отправили КП». Чем меньше статусов, тем охотнее продавцы их обновляют, тем достовернее данные.
Сколько запрос должен простоять в статусе, чтобы считаться застрявшим?
Максимальное время в статусе задаётся по каждому статусу: новый запрос — 24 часа (не распределили — застой), связались — 48 часов (после первого ответа покупатель молчит), в переговорах — 7 дней (слишком медленно согласуете потребности), отправили КП — 7 дней (КП отправлено, обратной связи нет). Превышение максимума на 50% — жёлтый сигнал продавцу, на 100% — оранжевый с эскалацией руководителю, на 200% — красный, руководитель обязан вмешаться. Три уровня оповещения не дадут ни одному запросу тихо умереть.
Покупатель говорит «надо подумать» — это какой статус?
Это не откат, а остановка на месте. Если вы ещё в переговорах — остаётесь в переговорах; если уже отправили КП — остаётесь в «отправили КП». «Надо подумать» — не смена статуса, а пауза в продвижении: ваша задача — назначить дату следующего касания, а не менять статус. Если к этой дате ничего не произошло, предупреждение о застое сработает само. Не откатывайте статус на шаг назад только потому, что покупатель сказал «надо подумать».
При закрытии запроса обязательно указывать причину?
Обязательно, и с классификацией. Пять категорий причин закрытия: отказ покупателя (слишком дорого / выбрал конкурента / пока не нужно), недействительный покупатель (спам / конкурент / неверные контакты), нет ответа по истечении срока (более трёх касаний без ответа), дублирующийся запрос, другое. Классифицируя причины закрытия, вы поймёте, на каком именно этапе умирают запросы — из-за слишком дорогого КП или из-за недостаточного числа касаний. Закрытие без указания причины — пустая работа.
Что делать, если продавец произвольно меняет статусы?
Задайте жёсткое правило: статус может только продвигаться вперёд, но не назад. Из «связались» нельзя вернуться в «новый запрос», из «в переговорах» — в «связались». Откат возможен только в двух случаях: запрос назначили не тому продавцу или обнаружили дубликат. Откат требует указания причины и проверки руководителем. Так вы не позволите продавцу вернуть запрос, с которым он работает уже три недели, обратно в «в переговорах» и делать вид, что работа идёт, — и не допустите искажения данных из-за дрейфа статусов.
Как доносить сигналы о зависших сделках до менеджеров, чтобы это работало?
Не ограничивайтесь письмами — они утонут в почте. Выводите сигнал на главный экран рабочего места менеджера: в CRM-дашборде сразу видно: «У вас 3 жёлтых запроса и 1 оранжевый». Открыл — и увидел. Параллельно отправляйте уведомления в DingTalk / WeCom. Жёлтый сигнал видит только сам менеджер, оранжевый — ещё и руководитель, а по красному руководитель обязан вмешаться лично. У каждого сигнала есть срок: жёлтый — связаться в течение 24 часов, оранжевый — руководитель подключается за 72 часа, красный — результат нужен на этой неделе.

В заключение

Управление статусами запросов только кажется вопросом настройки CRM. На самом деле это ваши глаза: видите ли вы свою воронку запросов или нет. Без управления статусами вы знаете лишь, сколько запросов пришло за месяц и сколько сделок закрыто, но не знаете, на каком шаге сколько потеряли. С управлением статусами вы сразу видите: в этом месяце 30 запросов застряли в статусе «КП отправлено», и 12 из них стоят больше недели — вот эти 12 и есть ваше узкое место.

Три шага к внедрению: сначала сократите статусы до 6, и каждому назначьте действие; затем задайте для каждого статуса максимальный срок пребывания и настройте три уровня сигналов о зависании; в конце сделайте причину закрытия обязательной и введите статистику по категориям. Когда эта система заработает, вам достаточно раз в неделю взглянуть на дашборд, чтобы понять, с кем поговорить и на каком шаге добавить усилий.

Запомните одну фразу: управление статусами нужно не для того, чтобы менеджеры заполняли формы, а для того, чтобы вы сразу видели, какие запросы застряли и как давно. 6 статусов плюс три уровня сигналов полезнее в десять раз, чем 15 статусов плюс дашборд, на который никто не смотрит.

Ли Яочао
Ли Яочао Эксперт Crater

Основатель · руководитель роста · команда бывших сотрудников Alibaba · фокус на выходе на зарубежные рынки

Основатель и руководитель роста 环形山 (Crater). За плечами — команда Alibaba. Специализируется на создании независимых сайтов для выхода китайских компаний на зарубежные рынки, Google SEO и GEO (оптимизации для генеративных движков). Руководил ростом с нуля нескольких внешнеторговых сайтов и DTC-брендов. Давно наблюдает, как большие языковые модели вроде ChatGPT и Gemini меняют способы привлечения зарубежных клиентов.

Стратегия роста на зарубежных рынкахОценка трендов GEOВыбор решения
1113篇分享
72статей в базе знаний