директор и машина · продажи · запись № 045 · · Давид Герштейн
План не сошёлся с фактом: разбор одной рабочей недели отдела продаж
На разобранной неделе план разошёлся с фактом на 19% (4,2 млн ₽ против 3,4 млн ₽ факта) не из-за лени менеджеров, а из-за трёх системных ошибок: план не разбит по блокам воронки, долгоживущие сделки искажают статистику, а критерии оценки не доведены до отдела. Решение — понедельная диагностика по стадиям с автоматическим светофором и разбором причин через ИИ, а не пересмотр плана вслепую.
Содержание · 5 разделов
Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные.
РОП Саша каждую пятницу сводит свою таблицу — и она у него ни разу не подводила. На неделе, которую разберём, проявились сразу несколько типичных ошибок плана продаж, и план впервые не сошёлся с фактом настолько заметно. План на неделю — 4,2 млн ₽ (легенда для отдела из 10 менеджеров с оборотом около 18 млн ₽ в месяц). Факт — 3,4 млн ₽. Минус 0,8 млн ₽ за пять рабочих дней, это −19% от плана. Закрыли 7 сделок из 16 запланированных.
Первая реакция — списать на «сезон» или «клиенты не готовы». Вторая, более полезная — разложить неделю по стадиям и найти, где именно теряется конверсия. Конверсия в продажу упала до 14% при плане 23%. При этом конверсия во встречу держалась на уровне 55% (49 встреч проведено) — до встречи клиенты доходили нормально. Проблема была дальше: из встречи в договор конвертировалось только 22% — эту воронку я разбирал отдельно в статье про потерянные заявки. Спасал неделю только средний чек: он вырос на 13,5% при плановых 10% — крупные сделки закрылись, мелкие просели.
На диаграмме — конверсия в продажу: план 23%, факт 14%. Конверсия во встречу при этом держалась на 55% — просадка не на входе в воронку, а ближе к финалу.
Саша посмотрел на цифры и сказал ровно то, что говорит в таких случаях: «Конверсия смешная, к 21-му числу мне становится страшно». Дальше начался разбор — не эмоциональный, а по шагам.
Ошибки плана продаж: пять причин, из-за которых план и факт расходятся
Когда план не сходится с фактом, дело почти никогда не в одной причине — обычно накладываются сразу несколько системных сбоев. Вот те, что нашлись при разборе этой недели и соседних с ней.
- План — это одна цифра, а не воронка по блокам. Если план считается по итоговой выручке, невозможно понять, где именно затык: на входе в работу, на сборе документов, на подготовке к финальному этапу или на последнем шаге. У компании из фактуры воронка логично делится на четыре блока: вход в работу, активная работа с документами, подготовка к финальному этапу, завершение. Пока план не разбит на эти блоки с отдельным нормативом по срокам, любой анализ отклонения — гадание.
- Долгоживущие сделки искажают статистику. При разборе пайплайна Саша наткнулся на сделку, которую сам считал живой — она провисела в работе полтора года без единого движения. Клиент не отвечал, но карточка оставалась в основной воронке и портила и конверсию, и средние сроки закрытия. Решение простое: вынести такие случаи в отдельную воронку по типу работ, чтобы они не путали аналитику по активным сделкам. Похожая механика уже применялась в этой команде на других сделках, которые «остывают»: их не закрывают сразу, а переводят в резерв на 2–3 месяца, и затем более опытный менеджер делает повторный заход — за пару лет практики это стабильно давало реанимацию части базы, а не потерю сделок задним числом.
- Критерии оценки не доведены до отдела. На вторичных звонках у компании включили автоматическую оценку звонков — но требования к содержанию звонка менеджерам никто не объяснил. Они звонят так, как звонили всегда, а система штрафует их за несоответствие правилам, которые они не видели. Итог — план по количеству звонков выполняется, а по качеству — нет, и никто не понимает почему.
- Расширение штата без контроля качества лидов. При трёх менеджерах в команде продажи были стабильно выше, чем при шести-семи. Причина не в квалификации новых сотрудников, а в том, что лидов стало больше, а внимания на каждого — меньше. После того как ввели контроль работы с базой, конверсия начала расти на 1 процентный пункт в месяц — но это уже отдельная история про управление, а не про план как документ.
- План не пересчитывается под отвлечения команды. В мае отдел переключился на допродажи действующей базе и сделал всего 15 холодных звонков вместо плановых 60+. Повторное касание 19 тёплых лидов из апреля дало 4 рекомендации — неплохой результат сам по себе, но план по новым звонкам никто не скорректировал. На бумаге — провал, по факту — осознанный манёвр, о котором не договорились заранее.
Ни одна из этих ошибок не видна в итоговой цифре «выручка за неделю». Все они видны только на уровне блоков воронки — и это подводит к механике.
Механика диагностики: как разложить план по шагам за один день
Задача — не переделать план, а построить регулярную диагностику, которая показывает, где именно план и факт расходятся, до того как это стало проблемой месяца.
- Данные. Источник — CRM (amoCRM или Bitrix24): стадия сделки, дата создания, дата последнего контакта, сумма, источник лида, ответственный менеджер. Ничего сверх того, что уже фиксируется в карточке. Здесь стоит держать в уме и обратную сторону: если даты в CRM сдвинуты или подделаны, светофор будет врать вместе с ними, поэтому источник данных стоит время от времени сверять руками.
- Разбивка на блоки. Воронка делится на четыре блока — вход в работу, документы, подготовка к финалу, завершение. Для каждого блока задаётся норматив: сколько дней сделка может в нём находиться, прежде чем считается зависшей.
- Светофор. Скрипт считает, сколько дней сделка уже в текущем статусе, сравнивает с нормативом блока и присваивает цвет: зелёный — в пределах нормы, жёлтый — превышение на 20–50%, красный — больше 50%.
- Дашборд. Обновляется ежечасно, показывает по каждому менеджеру: pipeline, конверсию договор→оплата, дату последнего контакта, источник сделки. Интегрирован с CRM так, что из строки отчёта можно кликом перейти в карточку сделки — без поиска вручную.
- Кто смотрит и когда. Каждый понедельник РОП разбирает красные сделки — не весь пайплайн, а только зависшие. Именно так Саша и нашёл сделку, которая провисела полтора года: она горела красным уже несколько месяцев, просто никто не смотрел на этот столбец отдельно от общей выручки.
| Менеджер | Стадия | Дней в стадии | Статус |
|---|---|---|---|
| Иванов | подготовка к финалу | 19 / норма 10 | жёлтый |
| Петров | документы | 34 / норма 7 | красный |
| Сидорова | вход в работу | 2 / норма 3 | зелёный |
Здесь же встроен отдельный отчёт по договорам — с суммой, датой выставления, отметкой, была ли встреча с клиентом. Он показывает, какие сделки закрываются после встречи, а какие — без неё, и позволяет точечно дожимать неоплаченные договоры, а не всю базу разом.
ИИ-связка: разбор причин отклонения и реактивация зависших
Диагностика по светофору отвечает на вопрос «где». Она не отвечает на вопрос «почему» — а без этого понедельничный разбор превращается в гадание по цвету. Здесь встроен второй слой — классификация причины по каждой красной и жёлтой сделке.
Схема конвейера: CRM → вебхук раз в час выгружает сделки, изменившие статус или превысившие норматив блока → скрипт формирует JSON по каждой сделке → дешёвая модель классифицирует причину зависания и предлагает действие → результат пишется обратно в CRM отдельным полем → попадает в дашборд.
Модель на этом шаге — дешёвая (GPT-4o-mini или аналог): задача массовая и по сути сводится к классификации по ограниченному набору категорий. Гонять на ней десятки сделок в час оправдано, гонять на дорогой модели — переплата без выигрыша в качестве.
Ты — аналитик отдела продаж. На входе JSON с данными одной сделки из amoCRM.
Определи:
1) вероятную причину зависания: нет_ответа_клиента / не_готов_платить / ждёт_документы / менеджер_не_звонил / другое;
2) статус светофора: зелёный / жёлтый / красный — жёлтый при превышении норматива стадии на 20-50%, красный — более 50%;
3) рекомендованное действие для менеджера одной короткой фразой.
Отвечай строго в формате JSON, без пояснений.
Входные данные:
{
"deal_id": "48213",
"stage": "подготовка_к_финалу",
"norm_days": 10,
"days_in_stage": 19,
"last_contact_date": "2026-05-02",
"manager_comments": [
"клиент просил перезвонить после майских",
"не берёт трубку третий день",
"написал в WhatsApp, не прочитано"
]
}
Пример ответа модели:
{
"deal_id": "48213",
"reason": "нет_ответа_клиента",
"traffic_light": "красный",
"action": "написать с нового канала, предложить конкретное время звонка"
}
Второй узел конвейера — бот реактивации «паузников»: клиентов, которые взяли паузу, но не отказались. Здесь логика компании была правильной: не тестировать риск на активной базе, а начать с тех, кто уже стоит без движения — терять там нечего, а выигрыш при успехе прямой. У этой же компании уже был прецедент, что подход рабочий: базу клиентов, отказавших менеджерам семь лет назад, переработали и предложили заново — в марте часть из них вернулась и купила на 170 тысяч ₽ суммарно. Это не автоматика, а ручной повторный контакт, но именно он и подсказал механику — конвейер с ИИ делает то же самое, только на «свежих» паузниках и без ручного перебора базы.
Модель на этом шаге — дороже (GPT-4o или аналог уровня Sonnet): нужно не классифицировать, а сгенерировать живое сообщение с учётом истории диалога и подобрать тон. Цена ошибки здесь выше — плохое сообщение может окончательно закрыть паузу отказом.
Ты — менеджер по работе с клиентами, которые взяли паузу. На входе история переписки (последние 10 сообщений) и причина паузы, определённая на предыдущем шаге. Составь короткое сообщение для реактивации: - обратись по имени, упомяни конкретную деталь из истории общения; - не дави и не проси решение прямо сейчас; - тон подбери по причине паузы: если "не готов платить" — сделай акцент на гибких условиях, если "думает" — предложи короткий созвон без обязательств; - не используй шаблонные фразы вроде "мы соскучились". Ответ в JSON: message, suggested_channel, priority (1-3).
{
"message": "Ирина, добрый день. Помню, вы взяли паузу на решение по срокам — если что-то поменялось, готов пересобрать план под ваш бюджет.",
"suggested_channel": "whatsapp",
"priority": 2
}
Инженерная обвязка. Вебхук и скрипт классификации крутятся на облачной функции (например, n8n или Google Cloud Function), запускаются по расписанию раз в час. Логи и ошибки — в отдельную таблицу Google Sheets, критические сбои (недоступность CRM, пустой ответ модели) — уведомление в Telegram-канал РОПа. При сбое — до трёх автоматических перезапусков, при неудаче сделка остаётся без обработки и просто попадает в общий список «требует ручного разбора» — ничего не теряется молча.
Цифры недели в одной таблице
| Показатель | План | Факт | Отклонение |
|---|---|---|---|
| Выручка за неделю | 4,2 млн ₽ | 3,4 млн ₽ | −19% |
| Сделок закрыто | 16 | 7 | −56% |
| Конверсия в продажу | 23% | 14% | −9 п.п. |
| Конверсия в встречу | — | 55% (49 встреч) | — |
| Конверсия встреча → договор | — | 22% | см. разбор воронки встреч |
| Рост среднего чека | +10% | +13,5% | +3,5 п.п. |
Смотреть на эту таблицу без разбивки по блокам воронки — значит видеть только итог. Показатель «конверсия в встречу 55%» говорит: маркетинг и первичный контакт работали штатно. Показатель «встреча → договор 22%» говорит: проблема на этапе закрытия, а не на входе. Это меняет разговор с отделом — не «звоните больше», а «разберём, что происходит на встрече».
Если отклонение недели не разовое, а повторяется из недели в неделю, масштаб потерь считается просто: (план − факт) × число недель в периоде. В нашем случае это 0,8 млн ₽ × ~4,3 недели ≈ 3,4 млн ₽ в месяц недополученной выручки — оценка, консервативная, потому что на практике отклонения редко одинаковы каждую неделю, но она задаёт порядок цифры, с которой стоит сверяться, прежде чем говорить «сезон поправит».
Риск не диагностировать вовремя: при повторяющемся отклонении в 19% компания теряет около 3,4 млн ₽ выручки в месяц — это не гипотеза, а прямой пересчёт цифр недели выше. Разовая настройка светофора стоит 18 000–24 000 ₽: дешевле один раз разложить воронку по блокам, чем месяцами списывать провал на сезон.
Экономика: что стоит диагностика и что она даёт
Стоимость внедрения — разовая настройка дашборда со светофором и подключение промпта классификации через API CRM: оценка 12–16 часов работы аналитика или интегратора при ставке около 1 500 ₽/час (типовая ставка для такой задачи, оценка) — это 18 000–24 000 ₽ разово.
Эксплуатация делится на два контура с разной ценой.
Классификация зависших сделок дешёвой моделью при потоке около 200 сделок в месяц на 10 менеджеров — это порядка 300 тысяч токенов в месяц (короткий JSON на входе и выходе, то есть примерно 1 500 токенов на сделку). По ценам уровня GPT-4o-mini это выходит в пределах 300–500 ₽ в месяц. Формула для своего случая: (число сделок в месяц ÷ 200) × 400 ₽ ≈ ваш расход. Например, при 50 сделках в месяц — это около 100 ₽/мес (оценка); сумма настолько мала, что проще один раз заложить её в бюджет, чем считать заново каждый квартал.
Бот реактивации «паузников» дороже за счёт модели и объёма текста: при 30–40 сделках в паузе в месяц и генерации персонального сообщения по каждой расход держится в районе 3 000–5 000 ₽ в месяц (оценка, зависит от длины истории переписки) — то есть примерно 100–125 ₽ за одно сгенерированное сообщение. Формула для своего случая: число паузников в месяц × 110 ₽ ≈ ваш расход. При 10 паузниках это около 1 100 ₽/мес.
| Компонент | Разовая стоимость | Ежемесячно |
|---|---|---|
| Настройка дашборда и светофора | 18 000–24 000 ₽ (оценка) | — |
| Классификация зависших сделок (дешёвая модель) | — | 300–500 ₽ (оценка, поток ~200 сделок/мес) |
| Бот реактивации «паузников» (дорогая модель) | — | 3 000–5 000 ₽ (оценка, поток 30–40 сделок/мес) |
| Итого | 18 000–24 000 ₽ | ~3 500–5 500 ₽ |
Для сравнения: средний чек сделки у разбираемого отдела — от 250 до 500 тысяч рублей. Если взять консервативный сценарий — из 30–40 паузников в месяц реактивируется хотя бы одна сделка с чеком 250 тысяч, — разовые вложения в настройку (18 000–24 000 ₽) окупаются этой одной сделкой больше чем в 10 раз, а ежемесячная эксплуатация (3 500–5 500 ₽) окупается ей же с запасом почти в 50 раз. Дальше диагностика работает уже не на разовый эффект, а на разницу между планом и фактом, которую иначе просто списали бы на сезон.
Частые вопросы
Почему план продаж не работает, даже если менеджеры выполняют норму звонков?
Потому что план обычно считает активность — звонки и встречи, а не конверсию между стадиями воронки. Если проседает переход от встречи к договору, количество звонков ситуацию не исправит.
Какие ошибки плана продаж встречаются чаще всего?
Общий план без разбивки по блокам воронки, долгоживущие сделки, которые искажают статистику, менеджеры не знают критериев оценки своей работы, расширение штата без контроля качества лидов и отвлечение команды на побочные задачи без пересчёта плана.
Что делать в первую очередь, если план продаж не сходится с фактом третий месяц подряд?
Сначала найти, на каком именно блоке воронки теряется конверсия — вход в работу, документы, подготовка или финал. Менять план или систему мотивации до этой диагностики бессмысленно: можно закрутить не тот вентиль.
#деньги #контроль и надёжность #аналитика и отчётность
Новые разборы — письмом, в день выхода. Без дайджестов ради дайджестов: нет статьи — нет письма.