Причины отказа по рекламным лидам в CRM: классификатор и правила настройки

Чтобы настроить в CRM справочник причин отказа по рекламным лидам, разделите финальный статус карточки и причину потери. Справочник должен содержать взаимоисключающие значения, а сотрудник — выбирать одну основную причину при закрытии карточки. Для анализа CRM должна хранить связку «кампания — этап потери — причина — ответственный»: она показывает, где возникла проблема и какая команда может на нее повлиять.

Для этого нужны шесть действий:

1. Отделить статусы карточек от причин потери;

2. Разделить причины на технический брак (заявка без пригодных данных), дисквалификацию (исключение лида как неподходящего), временную неготовность и проигрыш квалифицированной сделки;

3. Задать для каждого значения критерии выбора и исключения;

4. Сделать поле обязательным на закрывающих стадиях;

5. Сохранять источник, кампанию, продукт, этап потери, ответственного и дату;

6. Строить отчеты по сопоставимым группам лидов.

Чем причина отказа отличается от финального статуса

Финальный статус показывает результат обработки карточки: лид дисквалифицирован, сделка проиграна, заказ отменен. Причина отказа называет подтвержденное обстоятельство, которое остановило движение по воронке: неверный контакт, неподходящая география, перенос закупки или отсутствие нужной функции продукта.

Статус отвечает на вопрос о результате обработки, а причина объясняет этот результат. Стадия «Закрыто» объединяет разные случаи: спам, неподходящие заявки, обращения с недозвоном и коммерческие потери. Такой отчет не показывает, нужно ли менять таргетинг, работу менеджера или предложение компании.

Чем нецелевой лид отличается от проигранной сделки

Нецелевой лид не проходит квалификацию (проверку соответствия лида заранее установленным критериям). Например, компания обслуживает конкретную территорию, а обращение пришло из другого региона. Проигранная сделка прошла квалификацию и дошла до коммерческого этапа, но покупатель отказался от предложения или выбрал другой вариант.

Для этих случаев в отчете нужно использовать разные знаменатели (базы для расчета долей). Нецелевые обращения помогают оценить состав входящего потока и правила квалификации. По проигранной сделке видно, что могло повлиять на решение подходящего покупателя: продукт, цена, конкуренция или процесс продажи.

Какие причины отказа нужны для рекламных лидов

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

Отдельно стоит учитывать недозвон: это операционный статус, а не причина временной неготовности, и он не подтверждает отсутствие спроса. Пока менеджер не поговорил с человеком, CRM хранит только результаты попыток связи. Компания сама решает, сколько длится цикл контакта и какие попытки в него входят: подтвержденного универсального норматива нет.

Как устроить справочник причин без пересекающихся значений

Для карточки причины недостаточно короткого названия из выпадающего списка. Рабочий шаблон содержит поля «группа», «причина», «определение», «когда выбирать», «когда не выбирать», «ответственная команда» и «следующее действие». В интерфейсе сотрудник может видеть короткое название, а полное правило — в подсказке или регламенте.

Как заменить неоднозначные формулировки проверяемыми

Для каждой причины нужны однозначное определение, проверяемое условие выбора и явные исключения. Нельзя назвать универсальное оптимальное количество значений: короткий список скрывает разные ситуации, а чрезмерно подробный мешает сотрудникам выбирать стабильно. Качество справочника проверяют по тому, одинаково ли сотрудники классифицируют одни и те же случаи.

Как выбрать одну основную причину, если факторов несколько

Редакция рекомендует выбирать наиболее ранний подтвержденный фактор, который остановил продвижение по воронке. Дополнительные обстоятельства указывают в отдельном поле или структурированном комментарии. Бизнесу нужно адаптировать правило к своей модели продаж, особенно когда один фактор связан с квалификацией, а другой возник после коммерческого предложения.

Дерево выбора основной причины

Менеджер проходит четыре вопроса по порядку:

1. Заявку оставил реальный человек и указал рабочие контактные данные? При отрицательном ответе выбирают технический брак;

2. Лид соответствует утвержденным критериям географии, сегмента и задачи? При отрицательном ответе выбирают дисквалификацию;

3. У лида сохраняется потребность, и он назвал срок, когда вернется к обсуждению? При положительном ответе выбирают временную неготовность;

4. Лид прошел квалификацию и окончательно отказался от покупки? При положительном ответе выбирают причину проигрыша сделки.

Например, лид находится вне обслуживаемой географии и считает доставку дорогой. Сначала выяснилось, что лид находится вне обслуживаемой географии, и только потом начали обсуждать цену, поэтому основной причиной станет «вне географии». Реакцию на стоимость доставки можно сохранить в комментарии, если она полезна операционной команде.

В другом случае квалифицированный покупатель выбирает конкурента из-за отсутствия интеграции. Основной причиной станет «продуктовый разрыв», а название конкурента и интеграции сохранят в дополнительных полях. Значение «конкурент» без критерия выбора не подсказывает компании, какое решение принять.

Какие данные сохранять вместе с причиной отказа

Причину можно использовать в рекламной и коммерческой аналитике, если CRM связывает ее с данными об обращении. Для закрытой карточки нужны следующие данные:

• Исходный источник обращения и рекламный канал;

• Кампания, объявление и посадочная страница, если интеграция передает эти атрибуты;

• Продукт, услуга или категория запроса;

• Этап воронки, на котором подтвердили потерю;

• Основная причина и дополнительные факторы;

• Ответственный сотрудник или команда;

• Дата закрытия и подтверждающий комментарий.

Для атрибуции исходный источник показывает, откуда контакт пришел впервые, а последний — какое рекламное взаимодействие произошло перед сделкой или другой активностью. Если CRM хранит оба значения, в отчете нужно указывать модель атрибуции, то есть правило, по которому результат связывают с рекламным взаимодействием. Например, HubSpot различает Original Traffic Source и Latest Traffic Source у связанных со сделкой контактов или компаний, что подтверждает официальный справочник свойств сделок.

Как внедрить обязательный выбор причины в CRM

Причину фиксирует сотрудник, который закрывает карточку после подтвержденного исхода. Если сотрудник фиксирует причину задним числом, ему приходится восстанавливать обстоятельства по памяти, и он рискует формально выбрать ближайшее значение.

Поэтому обязательный выбор причины внедряют в такой последовательности:

1. Берут выборку закрытых карточек и выделяют реальные сценарии без привязки к старым названиям;

2. Распределяют сценарии по четырем группам и готовят черновой справочник с критериями;

3. Создают поле основной причины, поле дополнительных факторов и комментарий для оговоренных случаев;

4. Делают основную причину обязательной при переходе на закрытую, проигранную или дисквалифицированную стадию;

5. Обучают сотрудников на пограничных примерах и запускают пробный период;

6. Разбирают неоднозначные записи, уточняют определения и фиксируют версию справочника.

Как работает условная обязательность в Битрикс24 и HubSpot

Битрикс24 позволяет сделать пользовательские и некоторые системные поля обязательными на всех или отдельных стадиях. Без заполнения сотрудник не сможет сохранить или переместить карточку. Для сделок и смарт-процессов (настраиваемых процессов в Битрикс24) настройку задают отдельно в каждой воронке. Механика описана в официальной справке Битрикс24, обновленной 23 июля 2026 года. Доступность отдельных настроек зависит от тарифа.

В HubSpot пользователь может создавать свойства сделок, включая собственные поля; там также есть стандартное свойство Closed lost reason — причина проигрыша. Условные свойства стадии запрашивают данные при переводе записи на выбранный этап согласно официальной документации по воронкам HubSpot, обновленной 29 сентября 2026 года. Перед настройкой нужно сверить права, тарифные ограничения и актуальные названия элементов интерфейса.

Как контролировать качество причин отказа

При контроле качества нужно выявлять значения, которые сотрудники трактуют по-разному. Ни для «Другого», ни для неопределенных причин или недозвонов нет подтвержденной универсальной допустимой доли. Поэтому компания сравнивает показатели с историческими данными и учитывает свой процесс и состав трафика.

Регулярная проверка охватывает такие ситуации:

• Растет доля случаев, когда выбрано значение «Другое», а в комментариях повторяются одинаковые формулировки;

• В карточках указывают причину «Не отвечает», не выполнив полный цикл попыток связи;

• Менеджеры по-разному классифицируют сопоставимые лиды;

• Одна причина массово используется на разных этапах воронки;

• Выбранная причина расходится с перепиской или записью разговора;

• Если меняются продукт, география или правила квалификации, старые определения становятся неточными.

Если справочник меняется, старое значение лучше архивировать и связать с новым кодом через таблицу соответствия. Так можно сохранить исторические отчеты. Если причины объединяют, это нужно указать в версии классификатора, иначе одно название будет означать разные критерии в разных периодах.

Какие отчеты позволяют отделить проблемы рекламы от ошибок продаж

В основном отчете указывают кампанию, этап потери, причину, количество обработанных и потерянных лидов, продукт и ответственного. Кампании сравнивают, если совпадают период, продукт, география и правила квалификации. Если учитывать общую долю закрытых карточек, рекламе могут приписать потери, возникшие после квалификации.

Частоту конкретной причины внутри сопоставимой базы рассчитывают по формуле «Доля причины»:

Доля причины = Lr / Lp × 100%

где:

• Доля причины — расчетный показатель частоты выбранной причины;

• Lr — число потерянных лидов с конкретной причиной в выбранном срезе;

• Lp — число обработанных лидов в том же продукте, периоде и сегменте;

• 100% — множитель для представления результата в процентах.

После расчета причину связывают с этапом потери и зоной влияния:

В CRM-системе HubSpot можно начать с готового отчета Deal loss reasons. Он показывает сделки на этапе Closed Lost (этап закрытых проигранных сделок) и значения Closed lost reason с группировкой по владельцу или команде, согласно официальной документации Sales Analytics. Для рекламных атрибутов и собственных критериев сопоставимости может потребоваться отдельный отчет.

Почему запись менеджера не всегда раскрывает реальную причину

Причина, которую менеджер указывает в CRM, зависит от того, как он понял ответ клиента и насколько подробно выяснил обстоятельства отказа. За коротким значением «бюджет» или «цена» может скрываться недостаток продукта, ошибка продажи либо несбывшееся ожидание покупателя. Forrester, исследовательская и консультационная компания, рекомендует дополнять CRM-данные интервью после сделки, короткими опросами и анализом записей разговоров.

Sales guesses ≠ buyer truth

Beth Caplow и Kataleya Conard, VP, Principal Analyst; Research Associate, Forrester

Поэтому стоит отдельно анализировать крупные сделки и сегменты с повторяющимися потерями, а спорные причины отказа — перепроверять. Запись разговора показывает, задавал ли менеджер нужные вопросы. В опросе покупатель отвечает по заданной форме, а интервью раскрывает критерии выбора и контекст решения. У каждого метода есть ограничения, поэтому надежнее сравнить несколько источников и посмотреть, в чем они совпадают.

Какие данные об отказах можно передать в аналитику

Если CRM-статусы поддерживаются, это не значит, что пользовательский справочник причин передается целиком. Интеграция может принимать только общие статусы заявки или заказа, а подробные причины остаются в CRM или хранилище данных.

Например, Яндекс Метрика позволяет загружать из CRM статусы заявок и заказов и связывать результаты продаж с рекламными источниками. На основе классификации лидов можно создавать цель для качественных заявок, как описано в официальной документации Яндекс Метрики. В отчете по источникам заказов доступны статусы заказов, в том числе «Оплачен», «Отменен» и «Спам», согласно справке об источниках заказов из CRM.

Документация подтверждает, что статусы передаются, но не говорит, что так можно передать все пользовательские причины. Перед автоматической оптимизацией нужно проверить схему интеграции, соответствие кодов и качество разметки. Если оценка менеджера субъективна, нельзя автоматически считать, что она достоверно характеризует рекламную кампанию.

Заключение

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