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

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

Минимальная модель состоит из трёх статусов: qualified, rejected и pending. Причину отказа заполняют только для rejected, а попытки связаться, возраст заявки и следующий звонок хранят как состояние обработки. Так один отчёт отвечает на вопрос о качестве обращений, а другой — о скорости и дисциплине продаж.

Сначала отделите решение от процесса

Статус должен описывать результат квалификации на момент среза:

Фраза «не дозвонились» сама по себе не описывает качество лида. Новая заявка вечером, обращение в выходной и человек после одной пропущенной попытки попадут в отказ чаще, чем старые записи, хотя разница возникла из-за времени обработки. Заранее задайте SLA: число попыток, каналы связи и срок, после которого контакт можно закрыть по отдельному процессному правилу.

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

Сделайте короткий справочник причин

Для старта достаточно четырёх кодов:

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

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

Проверьте учебный набор

В вымышленной таблице 12 уникальных лидов: четыре квалифицированы, пять отклонены и три остаются в работе. У отклонённых есть пять проверяемых причин; у записей pending код отказа пустой, а число попыток связи хранится в процессном комментарии.

Схема показывает структуру вымышленных данных, а не результаты реальной рекламной кампании.

Если механически отнести три записи pending к плохим лидам, доля отказов станет 8 из 12 вместо подтверждённых 5 из 12. Такой пересчёт не докажет качество рекламы: в него попадут заявки, по которым решение ещё не принято.

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

1. lead_id отсутствует или повторяется;
2. rejected не содержит допустимой причины;
3. у qualified или pending внезапно появился код отказа;
4. статус не входит в согласованный список.

Для учебного набора ожидаемый итог выглядит так:

status_counts=qualified:4,rejected:5,pending:3
reason_counts=duplicate:1,out_of_scope:2,outside_geo:1,spam:1
errors=0

Перед агрегацией сохраняйте исходные строки и дату среза. Статус свежего лида изменится после следующего звонка, поэтому отчёт без времени подготовки нельзя повторить. Если сравниваете кампании, дайте их лидам одинаковое окно квалификации — порядок расчёта разобран в статье как сравнить CPL, если часть лидов ещё в работе.

Передавайте в рекламу подтверждённый этап

Справочник причин нужен для диагностики внутри CRM. В рекламную систему обычно передают отдельное подтверждённое событие — например, qualified_lead или оплату — с устойчивым идентификатором, временем и нужной ценностью.

Google описывает enhanced conversions for leads как развитие импорта офлайн-конверсий: хешированные данные, переданные пользователем, помогают сопоставить последующий результат с рекламным взаимодействием. Это не исправляет неопределённый статус в CRM: сначала команда выбирает содержательное событие, затем настраивает передачу.

В Яндекс Метрике офлайн-событие передают с идентификатором посетителя или кампании, Target и временем конверсии; статус привязки и причину ошибки можно проверить в отчёте «Офлайн-конверсии». Не отправляйте свободные комментарии менеджеров вместо события и не используйте телефон или email как открытый код причины.

Общая схема связи CRM с рекламой описана в материале о качестве лидов и офлайн-конверсиях. Этот этап имеет смысл после трёх проверок: статусы взаимоисключающие, причины определены, а доля pending видна отдельно.

Примите отчёт по четырём условиям

Отчёт готов для рекламного решения, когда:

1. каждый лид имеет один устойчивый lead_id и один текущий статус;
2. rejected всегда объяснён кодом из версионируемого справочника;
3. попытки связи и ограничения бизнеса не спрятаны среди причин плохого качества;
4. выгрузка хранит дату среза, а сравниваемые кампании получили одинаковое время на обработку.

После этого смотрите не только общую долю отказов, но и состав причин по кампании, объявлению и посадочной. Рост outside_geo ведёт к проверке таргетинга и условий доставки; рост out_of_scope — к сверке запроса, объявления и предложения; spam — к защите формы и источнику трафика; duplicate — к логике CRM. Один показатель превращается в четыре разные задачи, и у каждой появляется владелец.

Источники

• Источник 1
• Источник 2
• Источник 3
• Источник 4
• Источник 5
• Источник 6

Материал подготовлен редакцией WiseLab с помощью AI. Источники и фактические утверждения проверены при подготовке.