Как понять, проблема в рекламе или в отделе продаж?

Фраза «лиды плохие» так же мало полезна, как «продажи не умеют продавать». Для диагностики нужно отделить качество входящего потока от качества обработки. Маркетинг отвечает за fit и формирование спроса, продажи — за своевременную квалификацию и движение сделки, но граница не абсолютна: плохой оффер влияет на sales, а плохой follow-up искажает оценку рекламного канала. Поэтому нужны общие MQL/SQL, причины rejection и сравнение conversion по источникам и менеджерам.

У вопроса «Как понять, проблема в рекламе или в отделе продаж?» есть практический смысл только тогда, когда он связан с наблюдаемым решением. Не стоит делать вывод по одному признаку. Например, сигнал «маркетинг и продажи обвиняют друг друга;» важен в связке с «лидов много, сделок мало;», а результат разумно проверять через MQL-rate;, speed-to-lead; и contact rate;. Такой подход защищает от локальной оптимизации: показатель может улучшиться, а коммерческий результат — нет. Поэтому сначала фиксируется baseline, затем изменение процесса, и только потом сравнивается downstream-эффект.

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

1. Определите MQL до передачи в продажи.
2. Посчитайте MQL-rate по каналам.
3. Измерьте speed-to-lead и долю лидов в SLA.
4. Посчитайте MQL → SQL → opportunity по менеджерам и источникам.
5. Разберите причины rejection и lost deals.
6. Проведите выборочный аудит звонков/переписки для спорных сегментов.

Если 70% лидов из канала не соответствуют минимальному размеру компании, проблема ближе к targeting. Если fit высокий, но один менеджер превращает 40% MQL в SQL, а другой — 10%, это сильный сигнал sales execution. Если все менеджеры одинаково слабы, возможно, проблема в positioning или продукте.

• Низкий MQL-rate. Маркетинг/targeting/offer. Это не автоматический диагноз, а рабочая гипотеза: её нужно подтвердить данными конкретного сегмента, канала или когорты.
• MQL высокий, contact rate низкий. Speed-to-lead и follow-up. Это не автоматический диагноз, а рабочая гипотеза: её нужно подтвердить данными конкретного сегмента, канала или когорты.
• Contact высокий, SQL низкий. Qualification, positioning или product fit. Это не автоматический диагноз, а рабочая гипотеза: её нужно подтвердить данными конкретного сегмента, канала или когорты.
• SQL высокий, win rate низкий. Sales process, pricing, risk, competition. Это не автоматический диагноз, а рабочая гипотеза: её нужно подтвердить данными конкретного сегмента, канала или когорты.

• MQL-rate;
• speed-to-lead;
• contact rate;
• MQL → SQL;
• SQL → opportunity;
• win rate;
• rejection/lost reasons.

Сами по себе MQL-rate; и speed-to-lead; ещё не доказывают эффект. Их нужно сравнивать с исходным уровнем, учитывать сегмент и смотреть, что происходит дальше по процессу. Если локальная метрика улучшается, а rejection/lost reasons. ухудшается или не меняется, это повод проверить, не оптимизируется ли система на удобный, но слабый proxy-показатель.

• искать виноватый отдел;
• сравнивать менеджеров на разных сегментах без поправки;
• не фиксировать причины отказа;
• принимать «не дозвонились» за качество лида;
• оценивать рекламу по сделкам без учёта sales execution.

Причины часто смешаны. Слабый positioning может ухудшить и качество лида, и конверсию продавца. Поэтому диагностика должна искать bottleneck системы, а не юридическую границу ответственности.

• Что именно должно измениться, если ответ на вопрос «Как понять, проблема в рекламе или в отделе продаж?» внедрён правильно?
• Какой baseline по показателю «MQL-rate;» у нас есть сейчас?
• Кто владеет следующим действием и где оно фиксируется?
• Как мы отличим улучшение процесса от случайной волатильности?
• Какой сигнал заставит остановить или пересобрать гипотезу?

1. Зафиксировать текущий процесс и исходные данные до изменений.
2. Проверить два наиболее явных сигнала: «маркетинг и продажи обвиняют друг друга;» и «лидов много, сделок мало;».
3. Внедрить первые 1–2 шага из плана, не меняя одновременно всю систему.
4. Через согласованное окно сравнить MQL-rate;, speed-to-lead; и downstream-результат.

• ✓ есть чёткое определение результата, который хотим улучшить;
• ✓ есть данные до изменений — baseline;
• ✓ критерии одинаково понимают участники процесса;
• ✓ есть владелец следующего действия;
• ✓ эффект проверяется не одной метрикой, а по всей воронке;
• ✓ понятно, когда гипотезу нужно остановить или пересмотреть.