Актуальность изменений названий статусов лидов
Много мыслей в последнее время, как сделать более продуманный список статусов лидов. В последние три года постоянно вносили в них изменений, но делали это точечно. В итоге система потеряла гибкость, нет удобства, нет подчинения какой-то одной стройной идее. Эволюционно расти у этой системы не получается, придется меняться революционно.
Названия статусов лидов до изменений
Итак, какие на момент анализа статусы у нас есть и что они обозначают:
| Статус | В какой ситуации используется |
|---|---|
| Не обработан | Устанавливается автоматически для всех новых |
| Позор | Указан номер телефона, но не получается связаться ни звонком, ни через мессенджеры |
| Робот | Нет номера телефона или не связывались, при этом вид лида означает, что человек запрашивал какой-то бесплатный файл на сайте |
| Нужен тест / демонстрация | Клиент хочет получить бесплатный тестовый перенос данных 1С (как правило делаем его на сервере заказчика с помощью специальной закрытой обработки). Кроме тестового переноса еще проводим демонстрацию нашего модуля по интеграции 1С с маркетплейсами |
| Ведется общение | Получилось связаться с клиентом. Конкретной задачи для оценки от клиента не получили. Тестовый или демо не нужны. |
| Нужна оценка | Как правило, есть задача на перенос данных 1С под ключ. Нужно получить от клиента заполненную анкету (у нас есть шаблон), посмотреть там статистику базы, разделить работу на этапы, оценить эти этапы в сроках и деньгах. |
| Элитный / горячий | Клиент "горячий", активно задает вопросы, планирует приобретение в ближайшие дни. Нужно общаться с ним, отвечать, помогать, тогда в ближайшее время будет покупка. |
| Сделали предложение цены | Статус почти не используется сейчас. Имеет в виду, что была нужна оценка переноса данных под ключ. Ее клиенту назвали. Клиент думает. |
| Выставлен счет | Выставлен счет в базе 1С Бухгалтерия и этот счет в статусе "Не оплачен" |
| Успешно завершен | Получена оплата от клиента (если речь про проект, то аванс получен). Оплата не только в бух. базе, но может быть еще банковской картой на сайте. |
| Сделка провалена | Был коммерческий интерес у лида, но в итоге продажа не состоялась |
| Спам | Либо лид касается MARQI (мастерская контрактного производство свечей, аромадиффузоров Сорокиной Ксении) - на сайте marqi.ru форма Битрикс24 размещена. Нам в упр. базе 1С эти контакты не нужны, поэтому помечаем как спамеров. Либо указаны ненастоящие контакты - емэйл или телефон не существуют |
| Дубль | Уже есть лид этого клиента. В комментарии надо указать ссылку на оригинальный лид. |
Особенности работы компании
- Компания называется MoscowSoft, разрабатывает и продает собственные программные продукты на платформе 1С
- Сайт основной: https://moscowsoft.com, но также есть еще два дополнительных сайта, на них тоже размещены лид-магниты, различные формы для получения контактов и отправки файлов людям.
- Продажи только B2B
- Настроено большое количество лид-магнитов (на сайтах есть возможность запросить бесплатные обработки, чтобы их получить нужно указать адрес электронной почты и номер телефона). По таким запросам создается лид в CRM-системе и стартует автоматическая цепочка электронных писем.
- У компании есть управленческая база на 1С, где размещены алгоритмы, которые стараются помочь в работе с лидами. Например, статус сейчас автоматически меняется на "Выставлен счет", если в базе 1С Бухгалтерия появляется счет на оплату со статусом "Не оплачен" с таким же контактным лицом, как указано в CRM у существующего лида. Если выставляется счет, а лида нету, то лид будет в CRM создан автоматически. Если поступает оплата по счету, счет в базе 1С Бухгалтерия становится оплаченным, и лид в CRM переходит на статус "Успешно завершен".
- CRM-система - это Битрикс24. Облачная версия.
- Есть два сотрудника, которые работают с лидами. Все лиды поделены между ними для распределения нагрузки и для того, чтобы точно было известно, кто ответственный по каждому лиду.
- Основные виды сделок, которые мы заключаем с клиентами: продажа лицензии без техподдержки (тариф Lite), продажа типовой лицензии с поддержкой на некий период (тариф PRO или продажа лицензии на интеграцию с маркетплейсами), продажа лицензии с доработками под базы 1С заказчика (тариф Special), продажа почасовых работ, продажа проекта переноса данных 1С. Работа по каждому из этих видов сделок, конечно, отличается. Сложнее и дольше всего проходит продажа проектов переносов данных 1С.
Пожелания к новому списку статусов
- Сейчас все статусы поделены на те, при которых разрешено продолжать отправлять цепочку емэйл-писем и при которых нельзя. Это сделано для того, чтобы, если с человеком был уже нормальный контакт, предлагать ему индивидуальное решение проблемы, а не обобщенные какие-то наши статьи. Поэтому сейчас рассылка писем автоматических разрешена только на статусах: Не обработан, Робот, Позор. Считается, что во всех остальных статусах человек смог связаться и предложил более подходящее клиенту решение его задачи.
- Хочется, чтобы статусы соответствовали классической схеме работы в CRM-системе: связаться, узнать "боль" клиента, предложить индивидуальное решение, снять возражения, "дожать" до продажи. Текущий список статусов совсем не соответствует этому и не помогает.
- Очень хочется, чтобы названия статусов были сделаны по SMART. То есть содержали название того действия, которое нужно совершить.
- Нужна инструкция к каждому новому этапу (или старому, если его оставляем)
Правила для сотрудников по работе в CRM
- Если в новой заявке номер телефона указан, нужно обязательность связаться, то есть позвонить на этот номер телефона. Даже если человек запросил некую бесплатную обработку.
- В приоритете всегда обработка новых заявок, то есть тех, что находятся в статусе "Не обработан". Причина: это люди с болью, они ищут решение своей задачи в интернете. Если не мы с ними свяжутся, конкуренты поговорят с ними и придумают, как помочь им. То есть "каждый недозвонившийся клиент - это клиент конкурента".
- Если контакт не берет трубку, нужно написать ему в доступный мессенджер.
Косметическое переименование по SMART
У нас была вот такая идея по переименованию статусов, чтобы они были по методике SMART. Но она не соотносится с идеей о том, что работа с лидами должна быть из основных таких этапов: узнать боль, сделать индивидуальное предложение, подогреть, устранить возражения, дожать. Поэтому такие статусы использовать не надо. Это просто пример, как старые статусы сделать более SMART:
- Вместо "Не обработан" сделать "Узнать задачу"
- Вместо "Позор" также остается "Позор"
- Вместо "Робот" также "МегаПозор"
- Вместо "Нужен тестовый или демо" пусть будет "Доделать тестовый перенос / провести демонстрацию"
- Вместо "Ведется общение" пусть "Написать"
- Вместо "Нужна оценка" пусть будет "Отправить оценку"
- Вместо "Элитный / горячий" пусть будет "Позвонить"
- Вместо "Сделали предложение стоимости" пусть "Запросить реквизиты"
- Вместо "Выставлен счет" пусть будет "Получить срок оплаты счета"
- Вместо "Завершить сделку" пусть "Отправить документы в ЭДО на подпись".
Что в этом списке плохо и нужно поменять: статус "написать" или "позвонить" неверный. Ведь звонить надо как в самом начале, когда это новый необработанный лид, так и на этапе, когда нужно узнать срок оплаты счета на оплату. Также есть идея, что нельзя слишком длинные названия статусов (они не поместятся на странице, ведь выводятся в ширину), но зато можно написать по методике SMART инструкцию по действиям на каждом из этапов.
Новая таблица статусов работы с лидами
| Статус | Когда устанавливаем этот статус | Действия менеджера на статусе |
|---|---|---|
| Квалифицировать лида | Автоматически для всех новых лидов из форм/лид‑магнитов на сайтах MoscowSoft и perenos1s.ru, когда заявка только что попала в CRM и с человеком ещё ни разу не связывались. | В приоритете в течение рабочего дня: позвонить по телефону, при недозвоне написать в мессенджер и на email, кратко представиться и понять, это ли ваш целевой B2B‑клиент, кто он (ЛПР/исполнитель) и в целом про что запрос (перенос, интеграция, Автообмен, лицензия и т.п.). Зафиксировать результат и либо перевести в «Собрать данные» (если получилось поговорить), либо в «Связаться» (если контакта не было). |
| Связаться | Это не новый лид, но первая попытка контакта не удалась: звонок(и) без ответа, мессенджер и email также пока без живой реакции — по смыслу заменяет «Позор» (и часть «Робот», когда контакты формально есть, но человек не отвечает). | Сделать согласованное число попыток контакта через разные каналы (звонки, мессенджеры, email) с интервалами, указанными в регламенте. Кратко напоминать, откуда заявка (какую форму заполнял, какой файл просил). Если клиент наконец выходит на связь — сразу переводить в «Собрать данные». Если после N попыток связи реакции нет, по внутренним правилам либо закрывать лид в «Сделка провалена» с причиной «Нет связи», либо оставлять только на автоматическом email‑подогреве. |
| Собрать данные | Удалось связаться, но задача ещё не сформулирована до конца: клиент сам до конца не понимает, что именно ему нужно (какие переносы, какая конфигурация, какой тариф), и вы тоже пока не можете однозначно предложить сценарий. | Задавать уточняющие вопросы о текущей и целевой конфигурации 1С, объёмах данных, сроках, бюджете, внутренних ограничениях. При необходимости отправить анкету, запросить базу/выгрузки, примеры документов. Пояснять возможные варианты (Lite/PRO/Special, проект переноса, почасовые работы) и помочь клиенту определиться с форматом. Как только стало понятно, что именно делать и что вам достаточно данных для оценки — переводить в «Завершить тестовый / демо» (если нужен тест/демо) или сразу в «Оценить, отправить КП». |
| Завершить тестовый / демо | Клиенту для решения нужно посмотреть продукт вживую или провести тестовый перенос (аналог текущего «Нужен тест / демонстрация»): демонстрация модуля интеграции, тестовый перенос УПП → ERP, и т.п. | Согласовать дату и формат демо/тестового переноса, собрать необходимые доступы и вводные, передать задачу техспециалисту. Контролировать, что демо/тест реально выполнены в обещанный срок. После выполнения созвониться или написать клиенту: уточнить, всё ли устроило, какие есть замечания или вопросы. Зафиксировать обратную связь и передать её техспециалистам при необходимости. Если по итогам демо клиент готов к обсуждению цены и формата — перевести в «Оценить, отправить КП». |
| Оценить, отправить КП | Формат помощи понятен, входные данные собраны (или демо проведено), и настал момент назвать клиенту конкретные варианты решения и стоимость — вместо старого статуса «Нужна оценка». | Совместно с командой оценить работы/лицензии: подобрать подходящий тариф (Lite/PRO/Special), объём проекта переноса или интеграции, возможные опции поддержки. Сформировать 1–2 варианта решения с ценами и сроками. Донести это до клиента удобным способом: по телефону, в мессенджере, по email (как формальное КП или простое текстовое письмо) — главное, чтобы клиент чётко понял: «вам подходит X, это стоит Y». Уточнить, когда клиент сможет принять решение, и затем перевести в «Довести до счета». |
| Довести до счета | Клиент или думает или в целом согласен с вариантом решения и ценой, но счёт ещё не выставлен: нет реквизитов, не согласованы формальные условия, клиент "думает, согласует, соберёт данные для бухгалтерии". | Мягко, но настойчиво довести ситуацию до выставления счёта: запросить реквизиты, помочь клиенту оформить внутреннюю заявку, при необходимости обсудить схему и сроки оплаты. Снять остаточные сомнения («точно ли это тот продукт», «точно ли того объёма работ хватит»). Как только реквизиты и договорённость по оплате есть — инициировать выставление счёта в 1С и перевести сделку в «Получить оплату». |
| Получить оплату | Счёт уже выставлен в 1С и отправлен клиенту, но оплата ещё не поступила; заменяет старый статус «Выставлен счет», но делает акцент на активной доработке до оплаты. | Уточнять у клиента статус согласования счёта внутри компании, напоминать о сроках оплаты, при необходимости подключать бухгалтера/финансиста со стороны клиента. Снимать новые возражения, если они появляются на этапе согласования. Следить за состоянием счёта в 1С; после поступления оплаты (из 1С или по информации от клиента/эквайринга сайта) перевести в «Отправить закрывающие». |
| Отправить закрывающие | Оплата уже получена (в 1С счёт оплачен, либо оплата поступила на сайт), сделка по сути успешна; это ваш статус успешного завершения, но с акцентом на обмен закрывающими документами (акты, УПД, договоры и т.п.). | Поблагодарить клиента за покупку, убедиться, что он получил лицензии/ключи/решения. Организовать и проконтролировать отправку всех закрывающих документов: акты, УПД, договор, допсоглашения (бумажно или через ЭДО). Убедиться, что клиент подтвердил получение документов и у бухгалтерий обеих сторон «всё сошлось». После этого можно либо оставить сделку в этом статусе как финальном, либо, при необходимости, переводить контакт в цикл сопровождения/допродаж в другой воронке. |
| Сделка провалена | Понятно, что покупка не состоится: клиент выбрал другое решение/подрядчика, заморозил проект, не утвердили бюджет, нет связи после долгого периода попыток и т.п. | Обязательно указать причину проигрыша в комментариях (цена, сроки, функционал, нет ресурса на внедрение, «ушёл к X», нет связи и т.п.). По возможности аккуратно спросить у клиента, что именно стало решающим фактором. Отключить клиента от активных «дожимающих» коммуникаций, при желании оставить только редкие нейтральные рассылки (новости продуктов). Использовать эти данные в аналитике, чтобы улучшать воронку. |
| Дубль | В CRM уже есть активный лид/клиент с теми же контактными данными, а новый лид дублирует существующий запрос (по смыслу сохраняет текущую логику статуса «Дубль»). | Найти основной лид/сделку, убедиться, что работа ведётся именно по нему. В дублирующем лиде оставить ссылку на основной, кратко зафиксировать, откуда пришёл дубль (какая форма, какой канал). Перевести дубль в этот статус и не вести по нему отдельной работы, чтобы не плодить хаос в истории коммуникаций и отчётах. |
| Спам | Лид не относится к вашему бизнесу (например, заявки по MARQI, нецелевые предложения, реклама) или явно содержит мусорные/несуществующие контакты — аналог текущего статуса «Спам». | Проверить, что это действительно не целевой B2B‑клиент MoscowSoft и не потенциальный покупатель ваших 1С‑решений. Перевести в «Спам», чтобы исключить из воронки и автоворонок. По возможности настроить/подкрутить формы и фильтры на сайтах и в интеграциях, чтобы уменьшить поток таких лидов в будущем. |
Как лучше выбирать статусы
Как лучше выбирать статусы - как состояние лида или какие свои действия нужно выполнить или какие действия выполнены? По этому вопросу вот какие мысли есть: По «науке» и best practices важнее не «глаголы vs состояния», а чтобы каждый статус был однозначен, проверяем по факту и привязан к понятным действиям менеджера.
Как это делают в методиках
- В современных подходах часто различают:
- Stage (стадия) — положение лида в пути покупателя: Qualification, Discovery, Proposal, Negotiation, Closed Won и т.п. Это именно состояние лида.
- Status / Disposition — «что с ним сделали»: Open, Attempting contact, Working, Nurturing, Disqualified и т.п.
- Для стадий/статусов рекомендуют:
- жёсткие entry/exit‑критерии, основанные на наблюдаемом факте («КП отправлено», «Демо завершено», «Счёт оплачен»),
- и привязку к ожидаемым действиям менеджера на каждом шаге.
То есть названия либо описывают состояние клиента, либо завершённое/ключевое действие, но в любом случае должны иметь чёткие критерии, а не «размытые» слова вроде «Работаем».
Состояние клиента vs действия менеджера
1. Названия по состоянию клиента
Примеры: «Новый лид», «Контакт установлен», «Квалифицирован», «КП получено клиентом», «Ожидаем решение», «Выиграно/Проиграно».
Плюсы:
- Отлично читается аналитика по воронке: видно, где клиенты «застревают» как покупатели.
- Легче стыковать маркетинг, продажи и отчётность (lifecycle-модель).
Минусы:
- Нужно отдельно описывать в регламенте, что делает менеджер на каждом состоянии.
- Сложнее зашить в одно поле «что уже сделано и что нужно сделать дальше».
2. Названия по ключевому действию (как вы предлагаете)
Примеры: «Связаться», «Собрать данные», «Завершить тест/демо», «Оценить, отправить КП», «Согласовать реквизиты», «Выставить счёт» и т.п.
Плюсы:
- Менеджеру интуитивно понятно «что делать сейчас» — статус сам по себе как task‑hint.
- Легче обучать новых сотрудников: название = приоритетное действие.
Минусы:
- Если действие не привязано к объективному факту, статус может становиться «растянутым» и неоднородным по смыслу: два лида в «Связаться», но по одному уже три раза звонили, по другому — ни разу.
- Отчётность по воронке чуть менее «читаема в терминах клиента», её придётся трактовать как набор внутренних шагов команды.
Почему не стоит смешивать две логики в одном поле
Ваше ощущение абсолютно совпадает с best practice: один справочник — одна ось смысла. Если в одном списке одновременно есть «Новый лид», «Работать», «КП отправлено», «Горячий», то:
- менеджеры начинают трактовать статусы по‑разному;
- отчёты и автоворонки сложно понять и поддерживать;
- менеджеру неочевидно, что именно от него ждут на каждом шаге.
Поэтому крупные команды либо:
- разделяют стадию (buyer state) и disposition/next step на два разных поля,
- либо, если поле одно, жёстко договариваются о единой логике — как вы и пишете.
Что рекомендовать в вашей ситуации
С учётом того, что вы:
- B2B, длинный цикл, много демо и проектов;
- хотите, чтобы сами названия подсказывали действия менеджера;
- и при этом у вас одно основное поле статуса в Битрикс24,
оптимально выбрать единый, action‑ориентированный стиль, но так, чтобы каждый статус описывал и проверяемый факт, и логичный блок действий. Это как рекомендуют делать для стадий: «Demo completed», «Proposal sent», «Negotiation», «Closed Won» — названия привязаны к событию, а внутри каждой стадии прописан набор активностей.
То есть:
- вы не смешиваете «эмоциональные» состояния типа «горячий», «тёплый» с глагольными статусами;
- но и не уходите в чисто абстрактные состояния — каждое имя статуса связано с конкретным шагом («Собрать данные», «Завершить тестовый/демо», «Оценить, отправить КП» и т.п.).
Если позже захотите «по науке» ещё шаг вперёд, можно:
- оставить ваши глагольные статусы как стадии сделки,
- а «температуру» клиента или тонкость состояния («холодный/тёплый/горячий») вынести в отдельное поле/тег, не смешивая это с основным статусом.













































