# Директор и машина — Продажи: полные тексты (часть 1 из 2)

Направление: Продажи — воронка и CRM · контроль менеджеров · прогноз и план
Хаб направления: https://davidgerstein.pro/prodazhi/
Материалов в файле: 8 из 10 по направлению.
Автор: Давид Герштейн. Цитирование свободное при указании источника.
Суммы пересчитаны на условную компанию: пропорции, механика и выводы реальные, абсолютные величины изменены. «оценка» = расчёт, а не замер.
Оглавление всех частей: https://davidgerstein.pro/llms.txt
Все направления одним файлом: https://davidgerstein.pro/llms-full.txt
Цифры и словарь понятий: https://davidgerstein.pro/cifry/ · машинная копия: https://davidgerstein.pro/cifry.json
Другие части этого направления: https://davidgerstein.pro/llms-prodazhi-2.txt

## Мотивация отдела продаж: процент, который перестали платить
URL: https://davidgerstein.pro/blog/kpi-menedzherov-oshibki/
Дата: 2026-08-27
Направление: Продажи
Цифры: 20% маржа, 30% сокращение цикла, 1% комиссия РОПа
Коротко: Мотивация отдела продаж ломается не в формуле расчёта, а в том, что правила меняют после того, как человек уже сделал ставку на них. Разбираю случай, где менеджеру начислили процент от прибыли, а через 4 месяца забрали задним числом — человек недополучил 36 000 ₽ (оценка). Показываю формулу с весами 0,5/0,3/0,2 на рост продаж, сокращение цикла и удержание клиента, с промптом для Bitrix24.

Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Если вы хоть раз меняли условия мотивации отдела продаж после того, как человек уже отработал квартал под старые, — у вас в компании лежит мина. Рванёт она не в отчёте, а в заявлении об уходе. Я рассказываю эту историю, чтобы вы не повторили: одно решение по мотивации обрушивает продажи быстрее любого кризиса. Планёрка, обсуждаем мотивацию отдела. Восемь менеджеров, оборот около 9 млн в месяц, средний чек в районе 180 тысяч. Саша, РОП, молчит, потом говорит: «Вот смотрите, у меня в таблице всё сходится третий месяц. А вы опять хотите пересчитать формулу». Классика — он верит только тому, что сам проверил на своей неделе. Разговор быстро сворачивает к главной теме встречи — ошибкам KPI менеджеров, которые обычно вылезают не в цифрах, а в правилах игры. Какие метрики ставить взамен — KPI менеджеров по продажам . И тут кто-то вспоминает старую историю. Год назад одному менеджеру обещали процент от прибыли — не от выручки, именно от прибыли его портфеля клиентов. Человек под это перестроил работу: меньше гнался за количеством сделок, больше — за маржой и за тем, чтобы клиент не отваливался через три месяца. Прибыль портфеля росла, но медленнее, чем закладывал собственник. И тогда долю забрали. Объяснение было простым: «Рост слабый — значит, управление неправильное». Это тот самый разрыв, о котором мы писали в материале лиды есть, а продаж нет — только тут разрыв был не между маркетингом и продажами, а между продажами и реальной прибылью. Вот это и есть ошибка KPI, о которой почти никто не пишет. Не в формуле дело. Дело в том, что правила поменяли после того, как человек уже сделал ставку на них. Как построить мотивацию отдела продаж, чтобы она работала Мотивация отдела продаж держится не на формуле, а на неизменности правил: условие действует только вперёд и никогда задним числом. В компании на 40 человек менеджеру начислили 3% от прибыли его портфеля, через 4 месяца долю забрали — человек недополучил 36 000 ₽ (оценка) и ушёл из компании. Сама формула при этом должна считать прибыль, а не вал: рабочая формула раскладывается на веса 0,5 на рост выручки, 0,3 на сокращение цикла и 0,2 на удержание клиента и считается автоматически по выгрузке из CRM. Ошибка, которую мы нашли на планёрке Проверьте, нет ли у вас такой же: она встречается везде, где мотивацию считают от вала, а не от прибыли. Мы стали разбираться, почему это вообще всплыло именно сейчас. Оказалось, у нас похожая мина заложена в текущей мотивации РОПа. Саша получает двойную выгоду: 1% с продаж своей команды и отдельно — комиссию за личные сделки. На бумаге это выглядит нормально. На практике это значит, что развивать команду ему невыгодно: личные продажи дают доход быстрее и предсказуемее. Собственник предложил перейти на единую схему — 1% что с личных продаж, что с командных, чтобы стимул был один: растить отдел, а не тянуть одеяло на себя. Решение правильное. Но внедрять его прямо сейчас побоялись. Причина честная: Саша пока мыслит горизонтом в один месяц. У него уже сложился определённый доход, и резкий переход мог демотивировать его раньше, чем он увидел бы эффект от роста команды. Договорились: два месяца двойная схема остаётся как переходная мера, к августу — только командная комиссия. Критерий перехода — полный боевой состав из четырёх менеджеров, а не календарная дата. О том, как мы вообще выстраиваем ввод новых людей в команду, — отдельная тема: онбординг, который работает без наставника-энтузиаста . Дальше — второй слой той же проблемы. Собственник посмотрел на классический KPI «рост продаж на 100 тысяч в месяц даёт плюс 20 тысяч прибыли» (это 20% маржи — цифра, которой мы дальше и оперируем) и спросил: а что, если тот же эффект на прибыль даёт не рост продаж, а сокращение цикла обслуживания на 30%? Или снижение операционных расходов на 20–30%? Деньги в компанию эти метрики приносят быстрее, чем новый вал сделок — просто потому что оборот денег ускоряется и затраты падают сразу, а не через квартал. То есть KPI, завязанный только на рост продаж, вознаграждает не того, кто реально усилил прибыль компании, а того, кто нагнал воронку. Ровно то же самое случилось год назад с тем менеджером: его судили по темпу роста, хотя он в это время улучшал маржу и удержание — метрики, которые в KPI просто не были заложены. Сколько потерял менеджер: расчёт, которого никто не делал Сделайте такой же расчёт по своим людям — вы увидите, за что они на самом деле получают деньги. На планёрке эту историю обсудили эмоционально, но никто не посчитал в рублях, о чём вообще шла речь. Восстановили задним числом, по памяти и по остаткам таблиц — получилось следующее (цифры оценочные, на легендированных пропорциях): Портфель клиентов менеджера давал оборот около 1,5 млн ₽ в месяц — это примерно одна шестая от оборота отдела в 9 млн ₽. При марже 20% прибыль портфеля — около 300 тыс ₽ в месяц. Обещанная доля — 3% от этой прибыли, то есть 9 000 ₽ в месяц сверху оклада. Совокупный доход менеджера с этой надбавкой был около 54 000 ₽ в месяц — то есть бонус за прибыль составлял примерно 17% его дохода. Схема продержалась 4 месяца, после чего долю забрали — менеджер недополучил ≈ 9 000 × 4 = 36 000 ₽ (оценка). При этом рост прибыли портфеля за этот период был — просто не такой, как хотел собственник: около 8% вместо ожидаемых 15%. То есть человека наказали не за отсутствие результата, а за то, что результат оказался медленнее плана, который никто заранее не проговаривал как порог. Именно отсутствие порога — это и есть корень ошибки. Если бы в условиях изначально стояло «доля выплачивается при росте прибыли от 15% за квартал, иначе действует базовая ставка», конфликта бы не было: человек знал бы правила заранее и либо согласился на них, либо нет. А так правила появились постфактум, и 36 тысяч стали не ценой невыполненного плана, а ценой доверия. Что сделали (или ещё думаем) Формулу целиком мы пока не переписали, и я не буду врать, что всё решено. Моя недоработка тут простая: год назад я не настоял, чтобы условия зафиксировали письменно, — казалось, что и так всем понятно. Сделали три вещи: Первое — зафиксировали письменно, что если KPI меняется, он не может действовать задним числом на уже отработанный период. Звучит очевидно, но именно это правило год назад никто не проговорил вслух, и получился конфликт, из-за которого человек ушёл с ощущением, что его обманули. Второе — двойную мотивацию РОПа не отменили резко, а дали переходный срок с понятным критерием выхода, а не просто «на глазок отменим, когда почувствуем». Третье — договорились, что в следующем цикле пересчёта KPI для менеджеров возьмём не только рост продаж, но добавим вес на скорость цикла обслуживания и на удержание клиента после оплаты. Ниже — как именно мы это считаем технически, а не просто «идея на словах». Саша, кстати, после истории про забранный процент перестал спорить про переходный период для своей мотивации. Сказал коротко: «Ну хоть предупредили заранее — уже не как в тот раз». Мотивация отдела продаж: как считать вклад в прибыль, а не вал Ваша формула должна учитывать маржу сделки, иначе вы платите одинаково за прибыльные и убыточные продажи. Формула, которую мы тестируем сейчас (веса черновые, откалибруем после первого месяца по факту): 0,5 на рост выручки, 0,3 на сокращение цикла и 0,2 на удержание клиента. При таких весах менеджер с меньшим ростом продаж, но быстрым циклом и высоким удержанием, набирает больше баллов, чем тот, кто просто нагнал вал — и это ровно та справедливость, которой год назад не хватило. kpi_score = 0.5 × revenue_growth_pct + 0.3 × cycle_reduction_pct + 0.2 × retention_rate × 100 Вес на рост продаж остался самым большим — 0.5, потому что выручка всё ещё главный источник кэша. Но 0.3 идёт на сокращение цикла (по факту — те самые 30%, о которых спрашивал собственник) и 0.2 на удержание клиента через 90 дней после оплаты. Это не заменяет план продаж, это его дополняет. Данные для расчёта берём из Bitrix24 через вебхук — выгрузка сделок за квартал по каждому менеджеру: ID, ASSIGNED_BY_ID, STAGE_ID, DATE_CREATE, CLOSEDATE, OPPORTUNITY, CONTACT_ID . Дальше это идёт в модель — считать средний цикл, ретеншн и рост к прошлому периоду руками для восьми менеджеров каждый месяц никто не будет, значит нужен промпт, который делает это по выгрузке. Пример ответа модели по двум менеджерам: Менеджер Рост выручки Сокращение цикла Удержание (90 дн.) KPI-скор 142 4,1% 28% 62% 22,7 158 11,3% −6% 41% 12,4 Менеджер 142 — KPI-скор 22,7 Менеджер 158 — KPI-скор 12,4 Видно сразу: у менеджера 142 рост продаж скромнее (4,1%), но он сильно сократил цикл (28%) и держит клиентов (62% ретеншн) — по старой формуле «только рост продаж» он проиграл бы менеджеру 158, хотя реально приносит компании больше устойчивой прибыли. Это ровно та ошибка, которая год назад случилась с человеком, у которого забрали процент. Инженерная обвязка: без дашборда формула — просто таблица на бумаге Отдельно от формулы мы делаем то, что нужно было сделать ещё год назад — динамический отчёт по воронке, обновляемый не раз в месяц, а ежечасно. Для каждого менеджера отчёт показывает: клиента, текущий статус, дату создания сделки, число дней в статусе и цветовой индикатор — зелёный/жёлтый/красный — по нормативным срокам стадии. Это тот же принцип, что мы описывали при разборе контроля качества звонков без ОКК : система не заменяет решение человека, она просто не даёт данным потеряться до момента, когда решение принимается. Без этого дашборда формула с весами на цикл и удержание — фикция: посчитать вручную для восьми человек за квартал средний цикл сделки и ретеншн через 90 дней никто физически не будет делать каждый месяц, значит расчёт просто не будет происходить, и разговор снова свернёт к вопросу «а кто сколько продал в штуках». Где ломается: первое — менеджер может искусственно держать сделку открытой подольше, если знает, что цикл ускорения оценивают только на закрытых сделках — тогда нормируйте расчёт по дате входа в стадию, а не только по факту закрытия. Второе — ретеншн через 90 дней ломается, если клиент ушёл не по вине менеджера, а потому что услугу оказали один раз и она больше не нужна — формула должна учитывать тип клиента, иначе накажет за физику продукта. Третье — если данные в CRM внесены с опозданием или задним числом (это отдельная и частая беда, разобранная в материале CRM врёт: как я поймал Битрикс24 на сдвиге дат ), скоринг посчитает искажённую картину, и KPI снова станет источником недоверия — тем же самым, из-за которого мы вообще затеяли пересчёт. Экономика: во что обходится ошибка KPI, если её не чинить Отдельный менеджер потерял 36 тысяч рублей (оценка выше). Но цена для компании считается иначе — через риск потери человека и стоимость его замены. Возьмём отдел из восьми менеджеров с оборотом 9 млн в месяц — то есть в среднем 1,125 млн на человека. Если из-за подобных историй с KPI хотя бы один менеджер в год увольняется (консервативная оценка — обычно уходит не «лучший», а тот, кто держит важный портфель), компания теряет: Простой и недобор нового человека — новый менеджер первые два месяца даёт в среднем 50% от нормы выработки: потеря ≈ 1,125 млн ₽ × 50% × 2 = 1,125 млн ₽ (оценка). Время РОПа и HR на подбор и онбординг — примерно 40 часов суммарно × 1 000 ₽/час (оценка ставки) = 40 000 ₽. Итого риск на одного ушедшего менеджера — около 1,17 млн ₽ в год (оценка), без учёта репутационного эффекта на остальных семь, которые теперь тоже не верят в письменные условия. Это не абстрактный «риск демотивации» — это конкретная цифра, которая объясняет, почему переходный период для Саши и письменная фиксация правил обошлись компании дешевле, чем повторение прошлогодней истории. Чек-лист на понедельник Проверить все действующие схемы мотивации на пункт: может ли условие измениться задним числом — если да, зафиксировать письменно, что не может. Для любой двойной или переходной схемы прописать не календарную дату отмены, а событие-критерий (как «четыре менеджера в штате» у нас). Выгрузить из CRM за прошлый квартал среднюю длину цикла и долю клиентов с активностью через 90 дней после оплаты — по каждому менеджеру, а не по отделу в целом. Прогнать промпт выше на реальной выгрузке и сравнить kpi_score с текущим рейтингом по валу продаж — посмотреть, кто теряет место в рейтинге и почему. Посчитать для своего отдела ту же экономику: оборот на менеджера × риск потери × стоимость замены — и решить, стоит ли откладывать пересчёт формулы ещё на квартал. Один вывод Ошибку KPI видно не в момент, когда считаешь формулу, а позже — когда человек чувствует, что его обманули по старым правилам. Поэтому единственное, что мы теперь проверяем перед любым пересчётом: не меняется ли KPI за спиной у того, кто уже сделал ставку на прежние условия. Если меняется — сначала предупреждаем и даём переходный срок, как с Сашей. Спор про саму формулу — веса 0.5/0.3/0.2, дашборд, промпт — это уже второй разговор, не первый. Пока формула не откалибрована на реальных месяцах, мы держим её как черновик и не привязываем к ней выплаты напрямую — только используем как второе мнение рядом с классическим планом продаж. За этой историей стоит навык руководителя, который придётся осваивать отдельно от умения считать формулы: проектировать мотивацию как контракт — с порогом, сроком и правилом изменения, — а не как настроение владельца в конкретном квартале. Мне этот навык дался дороже всего: я привык договариваться на словах, а словесные договорённости рассыпаются первыми, как только цифры идут не по плану. Проверьте свою систему мотивации на один вопрос: если вы завтра поменяете в ней правило, сможете ли объяснить каждому менеджеру, почему это справедливо? Если нет — не меняйте, пока не сможете. Как строить KPI, которые не разрушают доверие, — в бесплатном курсе . Что забрать вам из этой истории Любое изменение в мотивации ваших людей должно быть объяснимо на их языке и просчитано на их примерах до объявления. Иначе вы получите не рост показателей, а тихую потерю лучших сотрудников — самых мобильных на рынке.

## Почему конверсия отдела продаж падает, если менеджеры работают как обычно
URL: https://davidgerstein.pro/blog/konversiya-prodazh-oshibki/
Дата: 2026-08-26
Направление: Продажи
Цифры: 14% вместо 23%; 20 зависших сделок; +1 п.п. конверсии в месяц
Коротко: Конверсия отдела продаж чаще всего падает не потому, что менеджеры стали хуже работать, а потому что метрика считается по кривым данным: в разобранном кейсе 20 зависших сделок в CRM превратили честные 23% в 14%. Показываю на цифрах, как за один цикл диагностики найти настоящую причину падения и вернуть конверсию отдела продаж к плану.

Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Если вы открыли отчёт, увидели, что конверсия отдела продаж падает, и первым делом пошли искать, кто из менеджеров просел, — вы уже идёте не туда и потеряете на этом недели. Я тоже так начинал. В большинстве случаев это неверный вопрос. Ниже — причины, по которым конверсия отдела продаж падает без предупреждения, и порядок проверки, который вы пройдёте за вечер вместо месяца поисков виноватого. Понедельник, утро, планёрка. РОП присылает сводку за прошедшую неделю: план продаж — 1 500 000 ₽, факт — 1 200 000 ₽. Закрыто 7 сделок из 16 запланированных. Конверсия отдела продаж — то есть доля лидов, доходящих до сделки, — упала до 14% при плане 23%. Разница в девять процентных пунктов — это не «немного не дотянули». В деньгах это 300 000 ₽ за неделю, пятая часть недельного плана, которая просто не случилась. Показатель План Факт Продажи за неделю 1 500 000 ₽ 1 200 000 ₽ Закрыто сделок 16 7 Конверсия лид → продажа 23% 14% Конверсия в встречу — 55% (49 встреч) Конверсия встреча → договор — 22% Отклонение среднего чека от базы +10% +13,5% план конверсии 23% факт конверсии 14% лид → встреча 55% встреча → договор 22% Дальше — разбор одной такой истории. Я прогонял похожую диагностику в нескольких отделах продаж, и каждый раз первая версия — «менеджеры расслабились» — оказывалась либо неверной, либо верной от силы на четверть. Настоящая причина пряталась глубже, и в обычном отчёте по конверсии её не видно вообще. Почему падает конверсия отдела продаж Чаще всего конверсия отдела продаж падает не из-за менеджеров, а из-за грязных данных в воронке: в разобранном кейсе 20 сделок, не двигавшихся дольше 90 дней, сидели в знаменателе и превращали честные 23,3% в 14% в отчёте. Проверка занимает вечер: выгрузите из вашей CRM сделки старше 90 дней без движения и пересчитайте конверсию отдела продаж без них. Разница в 5–10 процентных пунктов означает, что у вас проблема в данных, а не в людях. Цифра, которая не сходится Если у вас сейчас похожая ситуация — отчёт показывает одно, а ощущение от продаж другое, — начните с проверки самой цифры, а не с поиска виноватых. РОП — назовём его Саша, скептик со стажем, у которого «моя таблица меня ни разу не подводила», — открывает еженедельную выгрузку и видит: 14% против плановых 23%. Первая реакция — паника пополам со злостью. Вот его слова с той планёрки: «Конверсия очень низкая в продажу... менеджеры, которые очень сильные, стоят на 21 число, ну просто смешные показатели, и тут уже мне становится страшно, я начинаю переживать конкретно». Странность в том, что показатели, которые обычно падают вместе с конверсией — число звонков, количество встреч, — держались на месте. Встреч провели 49, конверсия в них — 55%, из встречи в договор — 22%. Отдел работал в том же темпе. Значит, дело не в лени. Саша начинает перебирать версии — и первые две отваливаются одна за другой. Версии, которые не подтвердились Показываю их специально: вы наверняка начнёте с тех же гипотез, и полезно знать заранее, что они, скорее всего, окажутся ложными. Версия первая: менеджеры разучились продавать. Самая простая мысль руководителя: сменить мотивацию, забрать лиды у слабых и отдать сильным, устроить разбор полётов. Но при проверке по каждому менеджеру картина не бьётся: у тех же людей неделей раньше конверсия была в норме. За семь дней навык продавать не пропадает. Версия вторая: лидов стало меньше или они хуже качеством. Проверили — поток на входе не просел, встреч проводили не меньше обычного. Тема отдельная, я разбирал её подробно в другом материале: если лиды приходят, а сделки не закрываются, смотрите « Лиды есть, а продаж нет ». Версия третья: сезонность. Отклонили быстро — сравнили с тем же периодом прошлого года, разница объясняла максимум пару процентных пунктов, не девять. Три версии — и ни одна не тянет на причину такого провала. Значит, дело не в людях, не в потоке лидов и не в рынке. Оставалось лезть в саму воронку. Раскопки: сделка, которой полтора года Вот тут и нашлась настоящая причина — и в вашей воронке она, скорее всего, тоже есть. При разборе воронки по каждому менеджеру вылезла деталь: у одного из «сильных» висела сделка без единого реального движения полтора года. Саша смотрел на неё как на живую — помнил разговор с клиентом, помнил его интерес. Проверка показала: последний реальный контакт был 17 месяцев назад, а все «активности» в карточке — технические пересохранения полей другими сотрудниками, которые с клиентом даже не разговаривали. Это классический случай, когда менеджеры не вносят в CRM реальные данные , а система вместо этого фиксирует технические правки как признак живой работы. Сделка все эти месяцы сидела в общей воронке и в знаменателе конверсии — как будто по ней идёт живая работа. Дальше выяснилось: таких сделок в отделе набралось двадцать. И вот здесь версия наконец сходится с арифметикой. Формула простая: конверсия = закрытые сделки ÷ (все сделки в воронке − зависшие без движения). Подставляем числа Саши: в воронке 50 сделок (7 закрытых ÷ 14% факта), из них 20 зависли без движения дольше 90 дней. Убираем зависшие — остаётся 30 живых сделок. Пересчитываем: 7 ÷ 30 = 23,3%. Это и есть плановая цифра, с точностью до десятых. Двадцать мёртвых карточек в знаменателе — это и есть те девять процентных пунктов, которые искали три дня. На диаграмме ниже — как меняется конверсия, если убрать зависшие сделки из знаменателя. 14% было 23,3% стало До чистки воронка считалась по 50 сделкам, из них 20 висели без движения 90+ дней (одна — 17 месяцев). После исключения зависших знаменатель — 30 живых сделок, и конверсия 7 ÷ 30 = 23,3% почти в точности совпадает с плановой цифрой. Показатель До чистки После чистки Сделок в воронке 50 30 Из них без движения 90+ дней 20 0 Закрыто сделок 7 7 Конверсия лид → продажа 14% 23,3% Решение по самой долгоживущей сделке было не «закрыть и забыть», а вынести её (и подобные) в отдельную воронку по типу работ — так она перестаёт искажать сроки и конверсию по основному потоку, но остаётся в работе, если по ней когда-нибудь снова пойдёт движение. Риск, о котором молчат гайды по CRM: не спешите удалять зависшие сделки, увидев провал в девять процентных пунктов. Пока карточка не разобрана вручную, неизвестно, мёртвая она реально или просто плохо промаркирована — например, клиент попросил вернуться к разговору через квартал, и это тоже нужно учитывать в воронке, просто отдельным статусом. Опасность в другом: если почистить воронку один раз, но не починить процесс — не завести светофор по срокам, не сверить критерии KPI с отделом, — через три месяца накопится новая партия зависших сделок, и разбор придётся начинать с нуля. Ещё две причины, о которых вы вряд ли подумали Обе встречаются часто и обе не видны в стандартном отчёте — проверьте их у себя отдельно. Зависшие сделки — самая частая находка, но не единственная. Здесь важна оговорка: обе причины ниже всплыли не в кейсе Саши, а в двух других отделах, где я проводил ту же диагностику по той же схеме. Эффекты ниже не складываются в одну сумму с недельным провалом Саши — это отдельные, самостоятельные случаи, показывающие, что за одинаковым симптомом («конверсия упала») может стоять разная причина. Причина вторая: менеджер тонет в задачах без контроля. В одном отделе при трёх продавцах (руководитель, его напарник и ещё один менеджер) продажи держались стабильно выше, чем после расширения до 6–7 человек. Причина оказалась не в квалификации новых людей, а в качестве работы с лидами: их стало больше, чем отдел успевал нормально обрабатывать. Конкретный эпизод: в мае отдел отвлёкся на разовый апсейл (сделка на 80 000 ₽ по отдельному запросу) и сделал за месяц всего 15 звонков новым контактам вместо плановых 60+. При этом по 19 тёплым лидам из апреля, до которых всё же дошли руки для повторного касания, получили 4 рекомендации — то есть один звонок редко решает всё, нужна регулярная работа с базой. Считаем цену этого простоя (оценка). Формула: (план звонков − факт звонков) × совместная конверсия «звонок → договор» × средний чек = недополученная выручка. Совместная конверсия в примере Саши — 55% × 22% = 12,1% (звонок → встреча → договор). Недостача звонков в майском эпизоде — 60 − 15 = 45. Подставляем: 45 × 12,1% ≈ 5 сделок, которые не случились. При среднем чеке по плану (1 500 000 ₽ ÷ 16 сделок ≈ 93 750 ₽) это 5 × 93 750 ₽ ≈ 469 000 ₽ упущенной выручки за месяц — оценка консервативная, конверсия взята из другого отдела как ориентир, а не как точное значение для майского эпизода. посчитайте на своих цифрах план звонков в месяц факт звонков конверсия звонок→договор, % средний чек, ₽ недополученная выручка ≈ {X} ₽ в месяц формула: (план звонков − факт звонков) × конверсия «звонок→договор» × средний чек; оценка сверху После того как контроль вернули — еженедельные отчёты по звонкам и напоминания по базе вместо разовых закрытий крупных сделок в ущерб потоку, — конверсия начала расти на 1 процентный пункт в месяц. Это тот же прирост, что получил в итоге и Саша после чистки воронки, но причина и лекарство — разные. Причина третья: KPI, которых отдел не видел в глаза. В третьем случае при анализе вторичных звонков выяснилось: систему оценки для этих звонков настроили под конкретные критерии, но менеджерам о них никто не сообщил. В результате люди «звонили, как звонили», а система штрафовала их за несоответствие правилам, о существовании которых они не знали. Формально — низкая оценка качества звонков и просевшая конверсия по этому участку воронки. По факту — конфликт не между менеджером и клиентом, а между менеджером и невидимой ему инструкцией. Решение здесь не «дообучить менеджеров», а сначала сверить ручную оценку с автоматической на одной выборке звонков за неделю: если расхождение большое, значит дело в критериях, которые нужно сначала показать отделу, а потом уже спрашивать за их выполнение. О том, как устроен такой автоматический контроль качества звонков без отдела ОКК , я писал отдельно. Причина Что нашли Эффект (оценка) Зависшие сделки в знаменателе 20 сделок без движения 90+ дней, одна — 17 месяцев конверсия 14% → 23,3% после чистки Менеджер без контроля тонет в задачах 15 звонков вместо 60+ за месяц из-за отвлечения на разовый апсейл ≈469 000 ₽ недополученной выручки за месяц KPI, неизвестные отделу критерии оценки вторичных звонков не доведены до менеджеров штраф системой за невыполнение правил, о которых не сообщили Что делать, если конверсия отдела продаж падает, а причина не ясна Порядок проверки: сначала данные, потом процесс, и только потом люди. Обратный порядок стоит вам отношений с командой и всё равно не даёт ответа. Читать воронку как данные, а не как ощущение, — это отдельный навык руководителя, и он стоит дороже умения давить на отдел: давление даёт всплеск на неделю, чистый знаменатель — управляемую цифру на год. Порядок действий простой, но именно его обычно пропускают, бросаясь сразу к людям. Сначала — чистка воронки. Выгрузите сделки старше 90 дней без движения и посчитайте конверсию без них по формуле выше: закрытые ÷ (все сделки − зависшие). Если разница с текущим отчётом — 5–10 процентных пунктов, вы только что нашли грязные данные, а не плохих менеджеров. Долгоживущие нетипичные сделки лучше не удалять из системы, а выносить в отдельную воронку — так они не портят сроки и конверсию по основному потоку. Дальше стоит завести отчёт, который обновляется чаще, чем раз в неделю: по каждому менеджеру — клиент, статус сделки, дата создания, число дней в текущем статусе и простой индикатор-светофор (зелёный/жёлтый/красный) по нормативным срокам стадии. Это не убирает саму проблему, но делает застрявшие сделки видимыми до того, как они накопятся до двадцати штук и испортят месячный отчёт. Следующий шаг — проверка критериев. Возьмите одну и ту же выборку звонков за неделю и оцените её вручную и автоматически. Большое расхождение значит, что дело в самих критериях оценки, а не в людях, которые по ним работают. И отдельно стоит спросить у отдела: они вообще знают, по каким KPI их меряют? Если ответ «нет» — сначала сверьте оценки, потом уже вводите санкции за невыполнение правил. И отдельно — контроль потока задач менеджера. Если человек параллельно с плановыми звонками тянет разовые крупные сделки или административные задачи, отчёт по конверсии этого не покажет, а звонки при этом молча просядут вдвое-втрое. Простое сравнение «план звонков / факт звонков» за неделю ловит это быстрее, чем недельный отчёт по деньгам. Саша после чистки воронки получил не идеальные 23%, но честные 23,3%, с которыми можно работать — рост пошёл дальше, на 1 процентный пункт в месяц, потому что усилия перестали тратиться на разбор несуществующей проблемы. Отдельная и куда более мелкая статья расходов — время самого разбора: на диагностику одной зависшей карточки (поднять историю, найти последний реальный контакт, обсудить с менеджером) уходит в среднем 15–20 минут (оценка). На 20 карточек это 5–6 часов рабочего времени руководителя, при ставке около 700 ₽/час (оценка) — порядка 3 500–4 000 ₽ прямых временных затрат. Сумма скромная по сравнению с 469 000 ₽ упущенной выручки из майского эпизода — но именно эти полтора часа в неделю на разбор мёртвых сделок чаще всего оказываются той работой, которую руководитель не находит времени сделать, пока не приходит в панику от цифры 14% на планёрке. Готовый промпт: проверьте свою воронку за 10 минут Это ваш инструмент первой помощи: подставляете выгрузку — получаете гипотезы с оценкой влияния на деньги. Возьмите его как есть, подставьте свою выгрузку — и получите список гипотез, отсортированных по влиянию на деньги. Если под рукой выгрузка CRM, но разбираться в формулах руками некогда — скопируйте промпт ниже в любую нейросеть вместе с выгрузкой сделок (клиент, статус, дата создания, дата последнего движения, сумма): Пример ответа модели на такую выгрузку: Сделайте это на своей выгрузке сегодня, а разговор с отделом отложите до завтра: с цифрами он займёт двадцать минут вместо часа взаимных претензий. Как встроить такую диагностику в еженедельный ритм — в бесплатном курсе . И короткий вывод для вас. Падение конверсии почти никогда не бывает там, где его ищут в первый день. Начинайте с данных: проверьте, не тянутся ли в отчёт старые сделки, не изменился ли состав источников, не сдвинулись ли даты. В моей практике три из четырёх «падений» объяснялись именно этим — и ни одно из них не было виной менеджеров.

## Работа с клиентской базой, до которой семь лет не доходили руки: лиды, отказавшие когда-то, и дневник их реанимации
URL: https://davidgerstein.pro/blog/reanimaciya-bazy-avtomatizaciya/
Дата: 2026-08-26
Направление: Продажи
Цифры: 7 лет паузы · 1,5 года без движения одна сделка · 600 000 ₽ за первый месяц реактивации
Коротко: Автоматизация реанимации базы — это бот, который классифицирует причину паузы и тон для каждого зависшего лида из тех, что стоят без движения 90+ дней, а живые сделки менеджер закрывает сам после квалификации. Тестировать нужно на «паузниках», а не на активной базе, иначе сгорит доверие отдела. Под ключ это около 25 часов настройки, а не один промпт — дальше идёт обвязка, контроль и правила игры для менеджеров.

Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Если вы за последний год ни разу не открывали список тех, кто когда-то интересовался и не купил, — у вас в CRM лежит выручка, за которую вы уже заплатили. Дважды: рекламой и зарплатой менеджеров. Я сам годами смотрел на этот список как на архив. Оказалось — это склад. У вас в базе лежат сотни клиентов, которые когда-то интересовались и не купили. Вы за них уже заплатили — рекламой, временем менеджеров, работой маркетинга. И почти наверняка сейчас с ними никто не работает. Это самая дешёвая выручка, которая у вас есть: не нужно платить за привлечение, человек уже знает вашу компанию. Ниже — месяц работы по неделям: что мы сделали с такой базой, что сломалось и сколько это дало. В марте у нас случайно всплыла база отказников семилетней давности. Причины отказа стояли в CRM с тех времён: «не готов платить», «не готов разговаривать», «заявка не оставлена». Часть этих людей взяла трубку сейчас — и купила. И дело тут не в нашей гениальности: семь лет назад с ними работали менеджеры низкой квалификации, которые не дожали живого клиента. Так родилась идея автоматизации реанимации клиентской базы: не звонить всей истории руками, а сначала прогнать её через ИИ-классификатор. Дальше мы посчитали, во что это обходится, если так и оставить базу лежать. У нас 8 менеджеров, оборот около 9 млн ₽ в месяц, средний чек — 180 тысяч. Если хотя бы 10% сделок в pipeline зависает без движения дольше нормативного срока — это около 900 000 ₽ в месяц (9 млн × 10%), которые просто стоят и портят статистику. Не теряются безвозвратно, а замораживаются: никто не звонит, никто не закрывает, никто не убирает из воронки. Один такой замороженный контакт нашёлся уже в первую неделю работы — и стал личным уроком для нашего РОПа Саши. Подробности — ниже. Работа с клиентской базой: как реанимировать отказников и что это даёт Реанимация базы — это выгрузка сделок, которые стоят без движения дольше 90 дней, автоматическая классификация причины паузы и тона обращения дешёвой моделью, и звонок живого менеджера по готовой рекомендации. В компании на 40 человек первый месяц такой работы дал 4 сделки на 600 000 ₽ — из контактов, которые отказали до семи лет назад. Настройка стоила около 25 часов работы аналитика и разработчика, эксплуатация — единицы тысяч рублей в месяц на токены. Оговорка, без которой цифра врёт: деньги приносит не модель, а менеджер. Бот отбирает, с кем безопасно разговаривать, и подсказывает тон; закрытие сделки остаётся человеческой работой. И начинать нужно на «паузниках», а не на активной воронке — один неудачный тон в живой сделке съест всю экономию. Неделя 0: что решили Идея простая до банальности: не звонить всей базе руками, а сначала прогнать историю диалогов через модель, чтобы понять — с кем вообще имеет смысл разговаривать и как. Решили тестировать не на активных клиентах (там цена ошибки высокая — можно спугнуть человека, который платит прямо сейчас), а на «паузниках»: тех, кто стоит без движения месяцами и годами. Логика — минимизировать риск на тех, кому терять уже нечего, и только потом масштабировать на живую воронку. Задача бота на входе: прочитать историю переписки и звонков, определить причину паузы, выбрать тон обращения — и контролируемо, не массово, а пакетами, пинговать. Не «у нас акция, возвращайтесь», а обращение, которое отталкивается от того, почему человек ушёл в тот раз. Неделя 1: сегментация и неожиданная находка Первое, что вам нужно сделать со старой базой, — разделить её. Обзванивать всех подряд бессмысленно: у вас там и те, кто ушёл к конкуренту, и те, кому было просто рано. Первым делом полезли смотреть воронку целиком — иначе бот классифицировал бы мусор вперемешку с живыми сделками. И почти сразу нашли клиента без движения полтора года. Саша, наш РОП, сначала уверял, что это активная сделка: «моя таблица меня ни разу не подводила, я её помню, там просто долгий цикл». Открыли карточку — последний контакт полтора года назад, ни одного звонка, ни одного письма с тех пор. Решение — не удалять и не пытаться дожать здесь и сейчас, а вынести такие случаи в отдельную воронку по типу работ. Иначе они искажают среднюю длительность сделки и путают аналитику: система думает, что у нас нормальный цикл — полтора года, хотя на деле это просто забытая карточка. Саша после этого перестал спорить с дашбордом. Не потому что поверил в ИИ вообще, а потому что конкретно эта сделка была его личной, и он был уверен в обратном. Это тот случай, когда одна найденная ошибка убеждает сильнее десяти презентаций. Неделя 2: что сломалось Читайте внимательно — у вас сломается то же самое, и лучше знать об этом заранее. Сломалось не на стороне бота, а на стороне людей. Мы включили контроль вторичных звонков по паузникам — то есть после того как бот определял тон и повод, живой менеджер должен был позвонить в соответствии с этими рекомендациями. Оказалось, что менеджеры вообще не знали, по каким критериям система оценивает их звонки. Критерии были заведены в CRM для оценки ИИ, но их никто не довёл до отдела. В итоге менеджеры звонили «как звонили всегда», а система штрафовала их за несоответствие правилам, о которых они не подозревали. Скажу прямо: это была моя ошибка, не менеджеров. Критерии я завёл в CRM сам и решил, что раз они записаны — значит, отдел про них знает. Отдел не знал. Я две недели читал отчёты, где люди «нарушают правила», и злился на людей, вместо того чтобы проверить, доводил ли эти правила до них хоть кто-нибудь. Если у вас так же — вы не одиноки: на этом спотыкается почти каждый, кто включает контроль раньше, чем объясняет. Пришлось откатиться на шаг назад: сначала свести оценки бота и оценки РОПа вручную на одной и той же пачке звонков, убедиться, что они совпадают хотя бы в половине случаев, и только после этого объявлять отделу правила игры. Запускать контроль до того, как правила прозрачны — гарантированный саботаж. Параллельно всплыла ещё одна причина, почему база вообще зависла: в мае отдел отвлёкся на побочную задачу (апсейл по стороннему направлению) и вместо плановых 60+ звонков новым контактам сделал 15. 60 план в мае 15 факт в мае На диаграмме — план и факт звонков новым контактам в мае: отдел отвлёкся на побочную задачу по апсейлу, и база осталась без плановых касаний. Зато повторное касание по 19 тёплым лидам из апреля дало 4 рекомендации от клиентов — это около 21% конверсии повторного касания в рекомендацию, для сравнения: конверсия «первого звонка в никуда» в этой базе была близка к нулю. Повторное касание (19 лидов) 21% Один звонок в холодную ≈0% На диаграмме — разница между разовым холодным звонком и повторным касанием по той же базе. Вывод для нас был предельно практический: один звонок ничего не решает, работает только регулярный повторный контакт — именно это мы и заложили в логику бота дальше. Неделя 3–4: как выглядит автоматизация реанимации базы целиком Схема пайплайна, до которой мы дошли к концу месяца: Выгрузка сделок без движения из CRM (по расписанию) Классификация причины паузы и тона — дешёвая модель Фильтр «безопасно для контакта» — только те, кто когда-то отвечал Запись рекомендации в карточку + очередь на звонок менеджеру Платформа — amoCRM. Триггер — вебхук по смене статуса сделки на «долгая пауза» (мы завели отдельное правило: если 90+ дней без активности — статус меняется автоматически). Обработчик — облачная функция, которая забирает карточку через API, собирает историю переписки и отправляет в модель. Модель на первом шаге — дешёвая (класса GPT-4o-mini): это массовая пакетная разметка тысяч старых карточек, где важна стабильность и цена, а не креативность. Дорогая модель включается только на следующем шаге — когда нужно сгенерировать персональный текст обращения для уже отфильтрованного, «безопасного» сегмента. Промпт для первого шага — тот, с которого мы начали и который почти не меняли за месяц: Пример ответа модели на реальной по структуре карточке: Инженерная обвязка: обработчик крутится на облачной функции с ежедневным крон-запуском по выгрузке через API amoCRM, плюс отдельный вебхук на ручную смену статуса. Результат классификации пишется в кастомное поле сделки и дублируется в гугл-таблицу для контроля РОПа — так Саша видит очередь на звонок без захода в CRM. Если модель не вернула валидный JSON — два автоматических повтора, при третьей ошибке лид падает в очередь «на ручной разбор», а в Telegram-канал отдела уходит алерт с ID сделки. Расходы на токены мы отслеживаем отдельно — как именно считать реальные счета за ИИ, писал в разборе по своим счетам . Визуализация: что показала первая пачка Ниже — то, что было видно на дашборде к концу первого месяца. Это не эффект только от бота: часть цифр — это провал в работе с базой ещё до автоматизации, который и стал поводом её запустить. Метрика Значение Что показывает Звонки новым контактам (май, план vs факт) 15 из 60+ отдел отвлёкся на побочную задачу, база осталась без касаний Повторное касание тёплых лидов (19 контактов) 4 рекомендации (≈21%) один контакт не работает, нужна серия касаний Прирост конверсии при усиленном контроле (3 менеджера vs 5 без контроля) +1 п.п./мес дисциплина в работе с базой решает больше, чем численность отдела Мартовская реактивация паузников 4 сделки / 600 000 ₽ результат совместной работы бота-классификатора и живых менеджеров Прямая связь между звонком «как обычно» и звонком «по рекомендации бота» пока не измерена отдельно — мы не разносили эти два потока в первый месяц, и это наша методическая ошибка, о которой честно пишу ниже. Экономика: что это стоит и что дало Ваша арифметика будет похожей: затраты — время менеджеров на обзвон отобранных контактов, отдача — сделки, за привлечение которых вы уже заплатили однажды. Внедрение здесь не про покупку модели — про часы, которые ушли на выгрузку, разметку и обвязку. По нашей оценке ушло около 25 часов работы аналитика и разработчика суммарно: настройка вебхука, тестовый прогон на 200 карточках, доработка промпта после первых ошибок классификации. При условной ставке 1 500 ₽/час (для специалиста уровня middle) это порядка 37 500 ₽ разовых затрат на настройку. Эксплуатация — токены на пакетную классификацию тысяч старых карточек стоят немного: единицы тысяч рублей в месяц (берём консервативно 3 000 ₽/мес) при разовой обработке базы такого объёма, дальше — только новые «паузники», которых прибавляется по несколько десятков в месяц. Вклад бота отдельно от менеджеров — это не деньги в кассе, а сэкономленное время на квалификацию базы. Формула для своего случая: время на карточку вручную × количество карточек × ставка часа менеджера = стоимость ручной квалификации. У нас: 15 минут на карточку × 200 контактов = 3 000 минут = 50 часов; 50 часов × 1 000 ₽/час (ставка менеджера) ≈ 50 000 ₽ ручной работы, которую забрал на себя классификатор за пару дней прогона. посчитайте на своих цифрах минут на карточку карточек в партии ставка менеджера, ₽/час стоимость ручной квалификации ≈ {X} ₽ формула: минуты на карточку × количество карточек × ставка часа ÷ 60; оценка сверху, без учёта разгона на новые партии Если сложить это в грубую окупаемость первого месяца: 50 000 ₽ сэкономленного времени на квалификацию минус 37 500 ₽ настройки минус 3 000 ₽ токенов ≈ 9 500 ₽ чистой экономии уже в первый месяц — и это без учёта самих закрытых сделок, только время. С каждым следующим месяцем настройка не повторяется, платить нужно только за токены и время на новые партии карточек, поэтому реальная экономия со второго месяца растёт. Статья Сумма (оценка) Разово / ежемесячно Настройка (25 ч × 1 500 ₽/ч) ≈ 37 500 ₽ разово Токены на классификацию ≈ 3 000 ₽ ежемесячно Ручная квалификация 200 карточек вручную (альтернатива) ≈ 50 000 ₽ разово, если делать руками Чистая экономия в первый месяц (без учёта закрытых сделок) ≈ 9 500 ₽ разово Эффект от самой реактивации нельзя целиком приписать боту — здесь эффект составной. Бот отфильтровал безопасный сегмент и подсказал тон, но разговор и закрытие сделки — целиком работа живого менеджера с опытом. Без A/B-теста (мы его не ставили — см. методическую ошибку выше) честная консервативная раскладка вклада выглядит так: бот дал точный список «с кем можно говорить и как» и снял часы ручного разбора старых карточек — это ускорение и снижение риска спугнуть паузника неудачным тоном, а не сама конверсия в оплату. Решающий разговор, дожим и закрытие 4 сделок на 600 000 ₽ — заслуга менеджеров, а не модели. Если бы не бот, эти же 4 сделки, скорее всего, тоже нашлись бы — но позже, ценой ручного прогона всей базы, и с риском, что часть «паузников» получила бы неподходящий тон обращения и окончательно ушла. Отдельно — риск, который бот снял, а не создал: 900 000 ₽/мес зависшего pipeline при 10% сделок без движения (оценка) — это не деньги, которые бот заработал, а деньги, которые перестали быть невидимыми. Дальше их всё равно нужно закрывать руками. Где ломается. Не согласовали правила вторичного звонка с отделом заранее — менеджеры саботируют рекомендации бота молча: просто звонят по-старому, а в отчёте это выглядит как «бот ошибся». Тестировали сразу на активной базе, а не на замороженной — один неудачный тон обращения стоит живой сделки, а не только раздражённого «паузника». База не сегментирована по срокам паузы — классификатор одинаково относится к лиду, который молчит месяц, и к тому, кто молчит семь лет, а это разные разговоры и разная вероятность закрытия. Что осталось нерешённым Мы прогнали через бота только паузников старше 90 дней с суммой сделки выше среднего чека — то есть меньшую часть базы. Остальное ждёт: часть контактов вообще не сохранила читаемую историю переписки, и классификатору там нечего анализировать. Отдельно не решён вопрос со скорингом и распределением реактивированных лидов под конкретного менеджера — по опыту, если отдать их первому свободному, а не тому, кто умеет закрывать сложные случаи, конверсия провалится так же, как семь лет назад. Это следующий шаг, и пока это ручная работа Саши. Похожая проблема с квалификацией отказников без прозрачных критериев разбиралась ещё в одной статье — если у вас в отделе тоже штрафуют менеджеров за невыполнение правил, о которых те не знают, там есть разбор, как навести порядок без репрессий: внедрение контроля звонков без саботажа . Чек-лист: с чего начать в понедельник Выгрузить из CRM все сделки без движения дольше 90 дней и отдельно — дольше года. Вынести долгожителей в отдельную воронку по типу работ, чтобы не портили аналитику по срокам. Прогнать первые 100–200 контактов через классификатор причины паузы на дешёвой модели, не масштабируя сразу на всю базу. Посчитать свою окупаемость по формуле: часы настройки × ваша ставка + токены — против часов ручной квалификации × ставка менеджера на то же количество карточек. Согласовать с РОПом единые критерии вторичного звонка до включения бота в работу отдела. Настроить лог ошибок и алерт в Telegram на случай сбоя классификации или пустого ответа модели. Тестировать только на «паузниках» минимум месяц, прежде чем трогать активную воронку. Кстати, если после запуска подобной автоматизации выясняется, что без ручного контроля она перестаёт работать через пару недель — это не редкость, а типовой сценарий, разобранный в статье про автоматизацию, требующую надзора . И главное, что я вынес из этого месяца: новое здесь не бот. Новое — управленческий навык смотреть на базу как на актив со сроком годности и уметь поставить машину на ту часть работы, где человек просто устаёт. Я считаю, руководитель, который это умеет, скоро будет стоить заметно дороже руководителя, который умеет только раздать список на обзвон. Навык осваивается за месяц. Сам он не появится. Что сделать вам: выгрузите контакты, которые обращались полгода-год назад и не купили. Посчитайте, сколько их. Если больше сотни — у вас есть недельная задача, которая может закрыть месячный план без единого рубля на рекламу. Как сегментировать базу и поставить реактивацию на автомат — механика в бесплатном курсе для руководителей .

## Анализ воронки продаж врёт: клиент завис на 540 дней, а отчёт считал его живым
URL: https://davidgerstein.pro/blog/voronka-prodazh-oshibki/
Дата: 2026-08-25
Направление: Продажи
Цифры: 540 дней максимального простоя сделки · +1 п.п. конверсии/мес после контроля · 15 000 ₽/мес экономии времени РОПа
Коротко: Сделка провисела в воронке 540 дней, а отчёт всё это время считал её живой — потому что в CRM не было ни дней в статусе, ни даты последнего контакта, ни норматива по сроку. После светофора по нормативам и ИИ-скрининга красных сделок доля зависших сделок в пайплайне упала с 20% до 5%, а конверсия выросла на 1 п.п. в месяц.

Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Если ваш анализ воронки продаж показывает красивую картинку, а деньги не сходятся — отчёт врёт. Почти всегда по одной из трёх причин, которые разберу ниже на своём случае. Проблема не в CRM и не в аналитике. Проблема в том, что воронка собирается из данных, которые заносят люди, — и пока вы не проверили, как именно они это делают, любые выводы из отчёта строятся на песке. Саша, РОП отдела продаж на производстве под заказ (шесть менеджеров, оборот около 4 млн ₽ в месяц, средний чек — 180 тысяч), открыл фильтр «сделки старше 90 дней» и увидел клиента в статусе «Согласование договора». Дата создания сделки — полтора года назад (540 дней). Всё это время клиент числился активным: попадал в отчёт по конверсии, в план по срокам закрытия месяца, в разговор на планёрке «ну, работаем». На деле с ним никто не разговаривал восемь месяцев. Один такой клиент не разоряет компанию. Но это классическая ошибка воронки продаж: она врёт в статистике по всем сделкам сразу, а не только по одной. Конверсия по стадии «Согласование» считается по всем сделкам на этой стадии, включая мёртвую. Средний срок закрытия сделки в отчёте раздувается на недели. А менеджер, который её ведёт, раз в неделю тратит 10–15 минут на то, чтобы упомянуть её на планёрке. Формула проста: минуты на упоминание × число недель в месяце ÷ 60 × ставка часа = потери. У Саши это 10–15 минут × 4 недели ≈ 40–60 минут, округлим до часа; час × ~1 000 ₽/час (ставка менеджера, оценка) ≈ 1 000 ₽ в месяц ни за что. Само по себе не страшно. Страшно то, что пока команда обсуждает мёртвую сделку, никто не смотрит на сорок живых, у которых, возможно, тот же самый диагноз — просто их ещё не поймали. Почему анализ воронки продаж не видит зависшие сделки Потому что стандартный отчёт показывает стадию, а не время на ней. В компании на 40 человек сделка провисела 540 дней и всё это время попадала в прогноз: в CRM не было ни счётчика дней в статусе, ни даты последнего контакта, ни норматива по сроку этапа. Три этих поля — минимальный набор, после которого зависание становится видно в день его возникновения, а не через полтора года при ручной ревизии. Три системные причины, по которым врёт ваша воронка продаж Сверьте с собой: если хотя бы одна из трёх есть у вас, цифрам в отчёте верить нельзя. Стандартный отчёт по воронке в Bitrix24 у Саши выглядел так: колонка «Стадия», колонка «Сумма», колонка «Ответственный». Всё. Ни даты последнего контакта, ни количества дней в текущем статусе, ни норматива, с которым можно сравнить. Воронка показывала, ГДЕ клиент, но не показывала, сколько он там уже стоит. «Моя таблица меня ни разу не подводила», — сказал Саша, когда я предложил переделать отчёт. Через неделю его же таблица подвела его на этом самом клиенте: он был уверен, что сделка «в работе», потому что стадия называлась «Согласование», а не «Заморожено». Стадия — это не статус активности. Это ловушка, в которую попадают почти все воронки: название этапа подменяет собой факт движения. У отчёта «до» было три системные проблемы, и ни одна не про конкретного менеджера: Время в статусе не фиксировалось — видна только текущая стадия, а сколько сделка там уже провисела, никто не считал. Разовые заказы, годовые контракты и нестандартные долгие проекты сидели в одной воронке и портили друг другу статистику. Норматива по срокам не было в принципе — «долго» и «нормально» каждый менеджер определял на глаз, и глаза у всех разные. Похожая история с датами есть в CRM почти у каждого — иногда система сама сдвигает даты создания сделки, и тогда врёт не отчёт, а исходные данные. Это отдельная поломка, я разбирал её в статье про сдвиг дат в Битрикс24 . Здесь другой случай: даты честные, просто их никто не считает. Пересборка: как мы собирали новый отчёт Повторите этот путь у себя — он занимает неделю и не требует ни бюджета, ни подрядчика. Пересборка заняла три итерации, каждая — по результатам разговора с Сашей, который проверял всё на своей неделе и заворачивал то, что не билось с реальностью. Аудит стадий и нормативных сроков. Взяли реальную воронку производства на заказ: заявка → расчёт КП → согласование договора → производство → приёмка → оплата. По каждой стадии выставили норматив в днях — не из головы, а по медиане фактических сроков закрытых сделок за полгода. Сегментация по типам работ. Нестандартные проекты с индивидуальным циклом (заказчик тянет решение месяцами по объективным причинам — например, ждёт финансирование) вынесли в отдельную воронку. Это тот самый случай зависшего клиента: он не «плохая сделка», он просто из другой категории, и в общей статистике ему не место. Добавили поля в карточку сделки. Дата создания, дата последнего контакта, количество дней в текущем статусе (вычисляемое поле), источник сделки. Светофор по нормативам. Зелёный — в пределах норматива стадии. Жёлтый — превышение до 50%. Красный — превышение больше 50% или полное отсутствие контакта дольше 14 дней. Ежечасное обновление и переход в карточку. Отчёт тянет данные напрямую из CRM по вебхуку, обновляется каждый час, из строки отчёта можно кликом уйти в саму сделку — без поиска по ID. Кто и когда смотрит. Красные сделки — на утренней летучке РОПа, до разбора плана на день. Жёлтые — раз в неделю на общей планёрке отдела. Саша принял идею не сразу — со скрипом, после того как отчёт нашёл вторую такую же зависшую сделку, которую он лично считал живой ещё неделю назад. ИИ-конвейер поверх отчёта Машина здесь не рисует вам новые графики, а объясняет старые: почему сделка встала, что было последним касанием, есть ли смысл её реанимировать. Светофор — это арифметика: даты и нормативы, без ИИ. Ум в конвейер добавили на следующем шаге — когда встал вопрос, что делать с красными сделками. Их набиралось 6–8 штук на весь отдел одномоментно, и по каждой нужно было понять: сделка мёртвая или просто клиент взял паузу по объективной причине. Разбирать вручную — минимум 10 минут на сделку: 6–8 сделок × 10 минут ≈ час РОПа в день только на диагностику. Схема конвейера: CRM (Bitrix24) → вебхук по расписанию (раз в час) → облачная функция считает дни в статусе и красные/жёлтые сделки → для каждой красной сделки формируется запрос к языковой модели с историей переписки и комментариев → модель определяет вероятную причину паузы и предлагает тон обращения → результат пишется обратно в поле сделки и падает уведомлением в чат РОПа. Пример ответа модели: Модель на этом шаге — дешёвая (уровня GPT-4o-mini или аналог): задача классификационная, текста немного, объём запросов маленький — 6–8 сделок в день на весь отдел. Дорогая модель здесь избыточна, разница в качестве классификации причины паузы на этом объёме не окупает разницу в цене токена. Инженерная обвязка простая и в этом её ценность: облачная функция (или скрипт по крону на сервере компании) дёргает Bitrix24 REST API, считает дни в статусе, для красных сделок вызывает модель, пишет ответ обратно в кастомное поле сделки и дублирует в Google Sheets как лог. Если вызов к CRM или к модели падает — запись уходит в отдельный лист «ошибки» с таймстампом, и в чат РОПа летит короткое уведомление «отчёт не обновился, час X». Без такого лога вы не отличите «сделок сегодня мало» от «скрипт упал вчера ночью». Экран «после»: что видно теперь Ориентир для вашего отчёта: с одного взгляда должно быть понятно, где стоит очередь и кто за неё отвечает. Пример строк актуального отчёта (обезличено): Отчёт по пайплайну — светофор по срокам 45 сделок в пайплайне 7 сделок в красной зоне 540 дней — рекорд простоя Менеджер Клиент Стадия Дней в статусе Статус Менеджер 1 Клиент А Расчёт КП 4 зелёный Менеджер 2 Клиент Б Согласование договора 18 жёлтый Менеджер 3 Клиент В Производство 62 красный Менеджер 4 Клиент Г Приёмка 9 зелёный Менеджер 6 Клиент Е Оплата 27 жёлтый Клиент менеджера 5 (540 дней в «Согласовании договора») в этот отчёт больше не попадает — он вынесен в отдельную воронку нестандартных проектов, чтобы не искажать статистику остальных. Распределение открытых сделок отдела по светофору после трёх месяцев работы отчёта (оценка на основе типового пайплайна из 45 открытых сделок) — на диаграмме ниже: Зелёный 60% Жёлтый 28% Красный 12% Доля сделок без движения дольше 60 дней (то есть фактически зависших, а не просто медленных) снизилась с 20% до внедрения светофора до 5% после — оценка на типовом пайплайне отдела. Отдельно: качество работы с этим же пайплайном заметно зависит не только от отчёта, но и от численности отдела. У Саши уже был период, когда три менеджера (он сам, напарник и ещё один) продавали стабильно больше, чем позже шесть-семь человек — просто потому что лидов на каждого стало больше, а внимания на каждого — меньше. После того как ввели контроль по пайплайну, конверсия начала расти на 1 процентный пункт в месяц. Это заслуга комплекса мер — контроль пайплайна плюс перераспределение нагрузки, а не одного только светофора, и вклад именно отчёта здесь нельзя выделить в чистом виде. Что это стоит и что даёт Ваши затраты — время на разбор данных, а не деньги на инструменты. Отдача считается просто: возьмите свой средний чек и умножьте на количество сделок, которые сейчас висят в воронке мёртвым грузом. Внедрение: аудит стадий, нормативов и настройка вебхука с полями — 10–14 часов работы аналитика или толкового менеджера по CRM. По ставке ~1 500 ₽/час (оценка, инженерное время дороже линейного) это 10 × 1 500 = 15 000 ₽ — 14 × 1 500 = 21 000 ₽ разово. Эксплуатация: ежечасный опрос CRM — бесплатно в рамках лимитов вебхука; вызовы к дешёвой модели на 6–8 сделок в день — по опыту такие объёмы укладываются в единицы долларов в месяц, подробный разбор счетов за похожие сценарии — в статье про реальные расходы на ИИ . Эффект в деньгах, оценка на условной компании: отдел из 6 менеджеров, средний чек 180 тыс. ₽, в пайплайне одномоментно около 45 открытых сделок. Если 15% из них зависает дольше норматива — это 45 × 0,15 ≈ 7 сделок. Даже если из них закрывается позже половина, а половина теряется навсегда — это 7 × 0,5 ≈ 3–4 сделки в квартал без выручки, то есть 3,5 × 180 000 ≈ 630 000 ₽ в квартал недополученных продаж (оценка, консервативно). Отчёт не гарантирует, что все эти сделки будут спасены — но без него их даже не видно. посчитайте на своих цифрах сделок в пайплайне % зависших сверх норматива средний чек, ₽ % теряемых безвозвратно риск ≈ {X} ₽ за квартал формула: сделки в пайплайне × доля зависших сверх норматива × средний чек × доля потерянных безвозвратно; оценка сверху Отдельная выгода — время РОПа. Ручной разбор 6–8 красных сделок в день занимал у Саши около часа. Со скринингом моделью он тратит на ту же диагностику 10–15 минут — просматривает готовые причины и решает, что делать. Экономия примерно 45 минут в день: 45 мин × ~20 рабочих дней ÷ 60 ≈ 15 часов в месяц; 15 часов × ~1 000 ₽/час (ставка РОПа, оценка) ≈ 15 000 ₽ в месяц высвобожденного управленческого времени, которое пошло на работу с живыми сделками, а не на археологию мёртвых. Чтобы прикинуть цифру на своём отделе: возьмите число открытых сделок в пайплайне, умножьте на вашу долю зависших сверх норматива стадии, умножьте на средний чек и на долю тех, кого вы реально теряете (консервативно берите половину) — получите оценку риска за период. То же самое с временем: минуты ручной диагностики одной сделки × число красных сделок в день × рабочие дни ÷ 60 × ставка часа — это то, что вы платите за отсутствие скрининга сейчас. Показатель Значение Открытых сделок в пайплайне (пример) 45 Доля зависших сверх норматива (оценка) ≈15% → 7 сделок Из них теряются безвозвратно (оценка) ≈50% → 3–4 сделки/квартал Средний чек 180 000 ₽ Риск недополученной выручки за квартал ≈630 000 ₽ (оценка) Стоимость внедрения светофора (разово) 15 000–21 000 ₽ Экономия времени РОПа в месяц ≈15 000 ₽ (15 часов × 1 000 ₽/час) Срок окупаемости внедрения меньше полутора месяцев эксплуатации Где ломается. Светофор врёт, если менеджеры научились вручную «освежать» дату последнего контакта пустым комментарием, чтобы уйти из красной зоны — это гейминг метрики, а не работа с клиентом, и его нужно ловить отдельно. Нормативы по стадиям врут, если их не пересматривать: цикл производства меняется по сезону, а норматив остаётся прежним. И самое частое: сделка ведётся не в CRM, а в переписке в мессенджере — тогда для отчёта её не существует, светофор молчит, а клиент реально висит. Похожий случай был с крупным нестандартным проектом: переговоры шли в личных чатах, в CRM появилась только финальная стадия — отчёт увидел сделку, когда она уже была почти закрыта, и толку от диагностики не было. Та же логика — сначала честные критерии метрики, потом контроль по ней — сработала и в другом месте того же отдела: менеджеров стали оценивать по вторичным звонкам, не объяснив правил, по которым система их сравнивает. Подробный разбор этого случая без саботажа и цифры внедрения — в статье про контроль звонков . Чек-лист: с чего начать в понедельник Откройте воронку и отфильтруйте сделки старше 60–90 дней без указания причины — их не должно быть больше нескольких единиц на отдел. Проверьте, есть ли в карточке сделки поле «дата последнего контакта» и заполняется ли оно реально, а не автоматически при любом клике. Выпишите нормативный срок по каждой стадии — по медиане уже закрытых сделок за полгода, а не «как кажется». Вынесите нестандартные, долгоцикловые кейсы в отдельную воронку — не удаляйте и не мешайте с обычным потоком. Настройте вычисляемое поле «дней в статусе» и элементарный светофор — это делается без ИИ, за один день работы с CRM. Только после того как светофор устойчиво работает вручную минимум две недели, добавляйте автоматическую диагностику причины через модель — иначе автоматизируете хаос, а не процесс. Начните с проверки, а не с перестройки: выгрузите свою воронку и найдите сделки, которые стоят на этапе дольше нормы. Если таких больше четверти — ваш отчёт показывает вам не воронку, а склад. Как навести порядок и поставить контроль без ручного разбора — механика в бесплатном курсе для руководителей . Мой урок из этой истории Я почти месяц спорил с руководителем отдела о цифрах, пока не понял, что мы оба правы: он смотрел в CRM, я — в отчёт, и данные там расходились, потому что часть сделок заводилась задним числом. Спор был не о продажах, а о качестве данных, и никто из нас этого не осознавал. С тех пор у нас правило: любой спор о цифрах начинается с вопроса «откуда взялось число», а не «кто виноват». Экономит часы совещаний. Отличать «сделка идёт» от «сделка стоит» — отдельный навык руководителя, и он не про CRM, а про вопрос, который вы задаёте на планёрке. Не «что там у нас по клиенту», а «сколько дней мы с ним не разговаривали». На этой неделе откройте свой отчёт и задайте этот вопрос по трём самым крупным сделкам — если ответа в отчёте нет, вы уже знаете, что чинить первым.

## Отчёты Битрикс24 врут: как я поймал CRM на сдвиге дат задним числом
URL: https://davidgerstein.pro/blog/crm-vret-dannye-bitrix24/
Дата: 2026-08-08
Направление: Продажи
Цифры: 12,9% лидов со сдвигом дат · сверка по ID · сторож-снимок
Коротко: Отчёты Битрикс24 не сходятся между собой, когда две выгрузки за один период дают разные числа: данные меняются задним числом — в компании на 40 человек 12,9% лидов за месяц сдвинули дату создания. Проверяется сверкой дат с соседями по ID и ежедневным снимком базы, эффект от сторожа — около 31 000 ₽/мес (оценка).

Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Если ваши отчёты Битрикс24 не сходятся между собой — не спешите винить систему, подрядчика или собственные фильтры выгрузки. В моём случае причина оказалась куда неприятнее: данные менялись задним числом, и об этом никто не знал. Если две выгрузки из CRM за один и тот же период дают разные числа — это не вы что-то не так фильтруете. Возможно, ваши данные меняются под вами. У меня это выглядело так: 12,9% лидов за месяц изменили дату создания задним числом . Отчёты, планёрки, мотивация менеджеров — всё считалось на цифрах, которые тихо ползли. Эта статья — как обнаружить такое у себя, как доказать (себе и коллегам, которые скажут «ты просто неправильно выгрузил») и как построить сторожа, чтобы это не повторялось. Считаю на условной сервисной компании: 8 менеджеров, оборот ~9 млн ₽/мес, средний чек ~180 тыс. ₽, около 50 сделок в месяц. Почему отчёты Битрикс24 не сходятся между собой? Отчёты Битрикс24 расходятся не из-за фильтров выгрузки и не из-за того, что отчёт «неправильно настроен», — чаще всего данные под отчётом меняются задним числом. У меня за один месяц 12,9% лидов изменили дату создания уже после того, как попали в отчёты: сегодняшняя выгрузка за прошлый период отличается от вчерашней — и обе выглядят правильными. Проверяется это за вечер: сверить дату создания с соседями по ID и снять два снимка базы с разницей в сутки. Единичный сдвиг — скорее ручная правка. Тревога начинается, когда сдвиги кратны фиксированному интервалу (у меня — 18 и 36 часов) и накапливаются месяц к месяцу. Как выглядит, когда отчёты Битрикс24 не сходятся между собой Симптом первичен, диагноз — вторичен: если отчёт за прошлый месяц, снятый сегодня, отличается от того же отчёта неделю назад — данные меняются задним числом, а не отчёт «неправильно посчитан». У меня набор симптомов был такой, каждый по отдельности легко списать на случайность: отчёт за прошлый месяц, снятый сегодня, отличается от того же отчёта, снятого неделю назад; сумма лидов по дням не сходится с итогом за месяц; менеджер уверяет, что лид пришёл в пятницу, а в CRM он «создан» в среду; конверсия периода меняется без единой новой сделки. Обычная реакция — перепроверить фильтры и успокоиться. Я перепроверял фильтры три раза, прежде чем допустить мысль, что проблема в данных. Это нормально: гипотеза «система врёт» психологически дороже гипотезы «я ошибся». Но проверяется она за вечер, а не за квартал. Ещё один маркер, который я сначала пропустил: расхождение всегда росло к концу месяца, когда отчёты смотрели чаще — это подсказка, что источник сдвига связан не со случайным сбоем, а с регулярным процессом, который срабатывает по расписанию. Как доказать: сверка с соседями по ID Правило простое: в большинстве CRM (в Битрикс24 точно) идентификаторы записей растут монотонно, и это независимый свидетель против самой CRM. Если у лида с ID 10500 дата создания раньше , чем у лида с ID 10450, — одна из дат изменена. Сами номера подделать при обычной работе нельзя, а даты — можно. Методика в четыре шага: Выгрузите лиды за период с полями ID и «дата создания». Отсортируйте по ID. Дата создания обязана расти вместе с ним (с точностью до секунд одномоментных загрузок). Каждое место, где дата «проваливается назад» относительно соседей, — кандидат в сдвинутые. Снимите ту же выгрузку через сутки и сравните: записи, у которых дата изменилась между двумя снимками, — доказанные, а не гипотетические. У меня в один месяц таких оказалось 12,9%. Сдвиги были кратны восемнадцати часам и накапливались — то есть это был системный процесс, а не разовая правка руками. При отделе из 8 менеджеров и оценке потока лидов около 320 в месяц (по 10 лидов на менеджера в неделю, оценка) это дало примерно 41 сдвинутую запись. Источник в итоге нашёлся на стороне интеграций, но статья не о нём: в вашей CRM источник будет свой. Статья о том, что без ежедневного снимка данных вы этого не увидите никогда — сегодняшняя выгрузка всегда выглядит цельной, враньё видно только в сравнении со вчерашней. Разбивка сдвинутых записей по величине сдвига в моём случае выглядела так — я привожу её, чтобы показать: сдвиги не случайны, они группируются вокруг фиксированных интервалов, а это уже подпись конкретного процесса, а не шума. Величина сдвига Лидов (оценка) Доля от сдвинутых 18 часов 19 46% 36 часов 14 34% 54 часа и более 8 20% Итого сдвинутых 41 100% 18 часов — 19 лидов (46%) 36 часов — 14 лидов (34%) 54+ часов — 8 лидов (20%) Когда сверка по ID не сработает Метод с монотонными ID работает только там, где идентификатор — честный автоинкремент базы без переиспользования; в CRM с несколькими независимыми источниками ID (например, после миграции из старой системы) он даёт ложные срабатывания, и тогда нужен второй, внешний якорь. В Битрикс24 ID сделки или лида — автоинкремент на стороне базы, и в моём случае этого хватило. Но если у вас часть записей попала в CRM пачкой при переносе из другой системы, у них ID выданы задним числом одной партией — сверка по соседям покажет «провал» там, где на самом деле никакого воровства времени нет, это миграция. Отличить миграцию от систематической подмены несложно: у мигрированных записей сдвиг привязан к одной календарной дате у множества записей сразу — это ровно причина «migration» в промпте классификатора выше, а не «integration». Второй якорь, который я в итоге завёл параллельно с ID, — время прихода вебхука от формы на сайте. Оно логируется на стороне сайта, до Битрикс24, и задним числом его переписать некому. Сравнение «дата создания в CRM» против «время вебхука» ловит те случаи, где ID почему-то не монотонен или счётчик был сброшен. Если в вашей CRM нет ни надёжного автоинкремента, ни внешнего лога прихода лида — доказать прошлые сдвиги задним числом не получится вообще: остаётся только начать копить ежедневные снимки с сегодняшнего дня и ждать первого расхождения. ИИ-связка: классификация причины сдвига Как только сторож находит расхождение, второй вопрос — почему оно возникло: техническая интеграция, ручная правка менеджером или миграция данных. LLM здесь не заменяет разбирательство, а сортирует находки по вероятной причине, чтобы не тратить время инженера на каждую запись вручную. Схема простая: ежедневный diff двух снимков (получен через Битрикс24 REST API, метод crm.lead.list с полями ID и DATE_CREATE ) отдаётся модели пачкой, модель размечает вероятную причину и уверенность. Дальше инженер смотрит только записи с низкой уверенностью или с новой, ранее не встречавшейся причиной. Пример ответа модели на этот вход: Уверенность ниже 0,7 — сигнал руками проверить запись, а не доверять разметке. За месяц у меня таких пограничных случаев было около 15% от всех сдвинутых — терпимо для одного просмотра раз в неделю. Сторож: ежедневный снимок и сравнение Решение скучное и работает: раз в сутки автоматически снимается срез базы (ID, дата создания, стадия, ответственный, источник) и сравнивается с предыдущим снимком. Любое изменение задним числом попадает в отчёт: какая запись, что было, что стало. Инженерная обвязка минимальна: Забор данных: Битрикс24 REST API, вебхук на crm.lead.list с полями ID, DATE_CREATE, STAGE_ID, ASSIGNED_BY_ID, SOURCE_ID , постранично, раз в сутки по cron. Хранение: отдельная таблица (Google Sheets на старте, потом можно в PostgreSQL) — одна строка снимка на лид на дату среза. Сравнение: скрипт сопоставляет вчерашний и сегодняшний снимок по ID, находит расхождения в DATE_CREATE , формирует список. Сигнал: расхождения — в чат руководителю (Telegram-бот или системное сообщение в Битрикс24), не в лог-файл, который никто не открывает. Важно, куда идёт сигнал. Отчёт сторожа должен приходить туда, где его увидят, а не лежать в папке. Автоматизация, за которой надо ходить самому, не работает — сторож без громкого сигнала превращается в ещё один непрочитанный лог. Экономика: во что это выливается в деньгах Настройка сторожа заняла у меня около 6 часов (вебхук, скрипт снимка, сравнение, алерт), эксплуатация — около 300 ₽/мес (хранение снимков и вызовы API), эффект — около 31 000 ₽/мес (оценка). Расчёт по частям, чтобы не путать поток с запасом. Без сторожа РОП и финансист тратят на ручную сверку нестыкующихся отчётов около 4 часов в неделю на двоих — это 16 часов в месяц. При ставке около 1 000 ₽/час (оценка) это 16 000 ₽/мес чистого потока, который сторож экономит, потому что расхождение видно сразу, а не находится на планёрке методом «пересчитай ещё раз». Второй кусок эффекта — точность бонусов. При отделе из 8 менеджеров и 50 сделках в месяц по 180 тыс. ₽, если 12,9% лидов имеют недостоверную дату, это касается примерно 6 сделок в месяц (50 × 0,129 ≈ 6,45, округляю вниз), у которых стадия или срок в отчёте может быть посчитан неверно. На практике это выливается примерно в один неверно рассчитанный бонус в месяц — переплата или недоплата менеджеру около 15 000 ₽. Это не разовая находка, а повторяющаяся ошибка, которую сторож устраняет каждый месяц, поэтому её тоже можно складывать в поток: 16 000 + 15 000 = 31 000 ₽/мес. Что мы не считаем эффектом: сами 6 сделок на 1 080 000 ₽ оборота (6 × 180 000) — это не найденные и не потерянные деньги, а объём выручки, отчётность по которому раньше была в «серой зоне» неопределённости. Сторож не увеличивает выручку и не находит пропавшие сделки — он снимает неопределённость в её учёте. Складывать эту сумму с 31 000 ₽/мес было бы смешиванием запаса с потоком. Отдельно: точность бонусов — заслуга не только сторожа, а связки «сторож + пересмотр методики расчёта премии на снимке, а не на live-базе». Вклад одного сторожа в эти 15 000 ₽ отдельно не выделить, честнее говорить о комплексе мер. Что это меняет в отчётности Главное следствие: метрики периода нужно считать по снимку на дату закрытия периода, а не по живой базе — иначе прошлое продолжит меняться у вас под ногами. Правило Дашборд на непроверенных данных опаснее отсутствия дашборда. Красивая цифра придаёт уверенность — в том числе неверную. Аудит достоверности — обязательный первый этап любого проекта отчётности, и за годы работы с CRM я не видел ни одного аудита, который не нашёл бы расхождений. Практические следствия для отдела на 8 менеджеров и 40 человек в компании: метрики периода считать по снимку на дату закрытия периода, а не по живой базе; в отчёте показывать расхождения как расхождения, а не выбирать «правильную» цифру молча; любую интеграцию, у которой есть право писать в CRM, считать подозреваемой по умолчанию и логировать её правки; премии и KPI менеджеров пересчитывать по зафиксированному снимку, а не по текущему состоянию базы на момент выплаты. Отдельный разговор — как это преподнести команде, которая привыкла доверять цифре на экране. Я не пытался доказывать правоту на планёрке словами: показал два скриншота одного и того же отчёта за один период, снятых с разницей в неделю, и разницу в конверсии на них. После этого вопросов «а точно ли это баг» не осталось — расхождение видно глазами без единого слова про API и снимки. И общее: прежде чем строить на данных CRM что-либо умное — ИИ-отчёты, прогнозы, мотивацию — потратьте вечер на проверку монотонности дат. Это самый дешёвый аудит из всех возможных, и он регулярно окупает себя одним найденным сдвигом. Чек-лист понедельника Всё внедряется за один рабочий день, без дополнительного бюджета на инструменты — только время инженера или аналитика. Выгрузить лиды за последний месяц с полями ID и «дата создания», отсортировать по ID. Найти места, где дата «проваливается назад» относительно соседей по ID, — это кандидаты. Снять повторную выгрузку через сутки и сравнить с первой — подтвердить реальные сдвиги. Настроить ежедневный снимок через Битрикс24 REST API (метод crm.lead.list ) и cron-задачу. Написать скрипт сравнения снимков и алерт в мессенджер при найденном расхождении. Договориться с РОПом и финансистом, что метрики периода считаются по зафиксированному снимку на дату закрытия, а не по live-базе. Проверить, какие интеграции имеют право писать в CRM, и включить логирование их правок. Если после этого списка сторож за неделю не нашёл ни одного сдвига — тоже результат: у вас чистые данные, и это стоило проверить, а не считать само собой разумеющимся. И назову вещь своим именем. Сомневаться в собственных данных — это управленческий навык, такой же обязательный, как умение читать отчёт о прибылях и убытках. Руководитель, который перед решением спрашивает «откуда эта цифра и менялась ли она с прошлой недели», стоит дороже руководителя, который принимает экран за истину. Осваивается навык за один вечер сверки — а работает потом годами. Ваша проверка: снимите один и тот же отчёт дважды с разницей в две недели и сравните построчно. Если цифры разошлись — вы нашли то же, что нашёл я, и дальше вопрос только в масштабе. Как поставить контроль достоверности данных — в бесплатном курсе .

## Контроль работы менеджера в CRM — дашборд вместо штрафов и пустых карточек
URL: https://davidgerstein.pro/blog/menedzhery-ne-vedut-crm/
Дата: 2026-08-05
Направление: Продажи
Цифры: факт разошёлся с планом на пятую часть недельной выручки · конверсия 14% вместо 23% · +1 п.п. конверсии в месяц после контроля
Коротко: Менеджеры чаще не вносят данные в CRM не из лени, а потому что не знают правил оценки и не видят обратной связи: в разобранном примере это стоило компании 200 000 ₽ выручки за неделю против плана. Решение — не штрафы, а дашборд с датой последнего контакта и светофором по нормативным срокам стадий, дополненный автоматической подсветкой причины зависания сделки; после внедрения контроля конверсия росла на 1 п.п. в месяц.

Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Если ваши менеджеры не ведут CRM — не спешите вводить штрафы. Сначала ответьте себе на неудобный вопрос: а что менеджер получает от того, что заполнил карточку? Обычно ответ — ничего. Он тратит время, чтобы вам было удобно смотреть отчёты. С его стороны это чистые издержки, и любой нормальный человек будет их сокращать. За одну неделю условный отдел производственной компании недосчитался 200 000 ₽ выручки — план по деньгам выполнили лишь на четыре пятых. При плановой недельной выручке в 1 000 000 ₽ факт составил 800 000 ₽. Закрыли 7 сделок из 16 запланированных. Причина не в том, что менеджеры плохо разговаривали — во встречу конвертировалось 55% лидов (49 встреч), это нормальный показатель. Провал случился на следующем шаге: из встречи в договор дошло только 22% — притом что для выхода на плановую конверсию лид → продажа в 23% нужна была совсем другая цифра на этом шаге. При этом средний чек по факту оказался выше плана — 13,5% против плановых 10% — то есть часть провала по количеству сделок частично компенсировалась более крупными контрактами, но разрыв в выручке это не закрыло. Корень проблемы окажется банальным: менеджеры не вносят данные в CRM вовремя, и часть воронки просто исчезает из поля зрения. 10% 13,5% И когда руководитель полез разбираться, что происходит на шаге «встреча → договор», выяснилось: часть сделок просто зависла в статусе «переговоры» без даты следующего контакта, без комментария, без признаков жизни. Отдельно нашёлся клиент, который висел в воронке полтора года — без единого движения. Когда команда считала средний срок цикла сделки, эта одна карточка портила всю статистику: казалось, что цикл огромный, хотя на деле клиента просто забыли. Решение руководителя было быстрым — вынести его в отдельную воронку, чтобы не портил цифры. Это не решило проблему зависшего клиента. Это решило только проблему кривого отчёта. Этому посвящён отдельный материал: зависшие сделки в воронке . Оба случая — про одно и то же: менеджеры не вносят данные в CRM не из лени и не из саботажа. Систему никто не заставляет отвечать за пустую карточку — ни поощрением, ни последствием, ни даже понятным правилом, за что вообще отчитываться. Что делать, если менеджеры не вносят данные в CRM Начинать не со штрафов, а с двух колонок в отчёте — «дней в текущей стадии» и «дата последнего контакта» — плюс светофор по нормативному сроку каждой стадии. В разобранной неделе именно невидимые зависшие сделки стоили отделу 200 000 ₽: план по деньгам выполнили на 80%, закрыли 7 сделок из 16. Штраф за пустую карточку меняет поведение на день. Дашборд, который сам показывает застрявшую сделку, убирает саму возможность спрятать проблему. До включения любого контроля менеджерам нужно письменно объяснить, по каким критериям их оценивают, — иначе вы получите сопротивление, а не данные. Почему менеджеры не вносят данные в CRM Три причины, и ни одна из них не про лень ваших людей. В одной компании при разборе вторичных звонков нашли причину пассивности менеджеров: систему настроили оценивать разговоры по конкретным критериям, но самим менеджерам эти критерии никто не сообщил. Люди звонили, как звонили всегда, а система штрафовала их за несоответствие правилам, о которых они не подозревали. Со стороны это выглядит как саботаж: люди делают не то, что нужно. По факту — управленческая ошибка. Правила ввели, а отделу их не объявили. Решение оказалось контринтуитивным: сначала наладить сравнение оценок между собой, разобраться, что вообще система считает хорошим звонком, и только потом объявлять правила игры команде. Внедрять контроль раньше, чем менеджеры поймут, за что их оценивают, — гарантированный способ получить сопротивление, замаскированное под забывчивость и «не успел внести». Похожая логика в материале о том, как я строил контроль качества звонков без ОКК : там оценка без прозрачных критериев тоже сначала вызывала не улучшение, а глухое раздражение отдела. Где ломается Внедрять контроль или автоматическую оценку раньше, чем объявить менеджерам правила. Если человек не знает, за что его меряют, любая система контроля читается как придирка — и незаполненные карточки CRM становятся формой тихого протеста, а не следствием лени. Зависшие сделки: где в мёртвых карточках ваши деньги Посмотрите свои карточки без движения за месяц — обычно там лежит выручка размером с неплохую неделю. Долгоживущий клиент без движения — частный случай общей болезни: пайплайн копит сделки, которые формально «в работе», а по факту — цифровой мусор. Он занижает конверсию, завышает средний цикл сделки и прячет реальные проблемы отдела за красивой строчкой «в процессе». В другой компании отдельно выявили пайплайн клиентов, поставленных на паузу — они просто оставались без внимания и не возобновляли сотрудничество. Решили не смешивать их с активной базой, а протестировать реактивацию именно на «паузниках»: ИИ-бот анализировал историю переписки, определял вероятную причину паузы и подбирал тон обращения, прежде чем аккуратно напомнить о себе. Логика простая — тестировать риск там, где терять почти нечего, и только потом масштабировать подход на активных клиентов. Ещё нагляднее — история с реанимацией старых отказников. Компания подняла базу клиентов, отказавших менеджерам семь лет назад: не готовы платить, не готовы разговаривать, заявку так и не оставили. Все они когда-то брали трубку — просто работали с менеджерами низкой квалификации. В марте эти же люди вернулись и купили на 500 000 ₽ — это ощутимая часть месячного оборота условного отдела в 4 000 000 ₽. Зависшая сделка — не всегда мёртвый груз. Иногда это отложенные деньги, которые CRM не помогает найти, потому что никто не открывает старые статусы. Прежде чем гоняться за виновными в незаполненной CRM, стоит проверить саму систему на честность: я разбирал отдельно, как Битрикс24 может физически сдвигать даты и путать статусы . Метод сверки по ID оттуда применим и здесь — часть «зависших» сделок при ближайшем разборе оказывается ошибкой синхронизации, а не бездействием менеджера. Контроль работы менеджера: что реально показывает ваша воронка Отличайте две вещи: воронка показывает движение сделок, а не старание людей. Если вы будете судить по ней о человеке напрямую, получите красивые карточки и те же продажи. Возвращаясь к неделе с провалом плана на 200 000 ₽: цифры сами показали, где именно течёт воронка. Дело не в команде в целом — дело в одном конкретном шаге: встречи назначаются нормально (55%), но до договора доходит только 22%. На диаграмме — конверсия по каждому шагу воронки в сравнении с плановой конверсией лид → продажа. Руководитель отдела не скрывал тревоги: «конверсия очень низкая в продажу... мне становится страшно, я начинаю переживать конкретно». Честная реакция на цифры полезнее общих слов про эффективность. Показатель План Факт Продажи за неделю 100% 80% от плана Закрытые сделки 16 7 Конверсия лид → продажа 23% 14% Конверсия лид → встреча — 55% Конверсия встреча → договор — 22% Лид → встреча 55% Встреча → договор 22% Лид → продажа (факт) 14% Лид → продажа (план) 23% Есть и обратный пример, где контроль реально сработал. При меньшем составе отдела продажи стабильно держались выше, чем после расширения штата более чем в два раза. Причина проста — избыток лидов на менеджера просто снизил качество работы с каждым клиентом. После внедрения контроля конверсия начала расти на 1 процентный пункт в месяц. Медленно, но это заслуга управления. Наём новых людей сам по себе конверсию не поднял — эти два эффекта здесь стоит разводить сознательно. Дашборд вместо репрессий Ваша цель — сделать так, чтобы менеджеру было выгодно вести карточку, а не страшно её не вести. Разница в результате огромная. Штраф за пустую карточку меняет поведение на день. Дашборд, который сам показывает застрявшие сделки, меняет поведение системно — потому что убирает саму возможность спрятать проблему. В нескольких компаниях, где я наблюдал эту задачу, решение выглядело похоже. Один дашборд отслеживал pipeline по каждому менеджеру, конверсию договоров в оплату, дату последнего контакта с клиентом и источник сделки — с детализацией по месяцам, чтобы видеть заброшенные сделки без единого касания. Второй пошёл дальше: динамический отчёт по воронке, обновляемый ежечасно, с индикатором-светофором на каждой сделке — зелёный, жёлтый, красный — на основе нормативных сроков по стадиям. Не «сколько дней клиент висит вообще», а «сколько дней он висит сверх нормы для этой стадии конкретно». Воронка сделок — светофор по срокам стадий 80% факт продаж за неделю от плана 14% конверсия лид → продажа (план 23%) 47 дн. сделка #48213 в стадии «Переговоры» (норма 10 дн.) 2026-03-02 дата последнего контакта Сделка Стадия Дней сверх нормы Статус #48213 Переговоры 37 ждёт решения #48097 Договор 0 в норме #48150 Встреча 12 менеджер не дожал Третий вариант — дашборд по договорам: менеджер, клиент, сумма, дата выставления счёта, была ли встреча. Смысл — увидеть закономерность: закрываются ли сделки после встреч или без них, и дожимать точечно конкретных клиентов, а не отдел целиком. Блок воронки Что отслеживаем Признак затора Вход в работу Дата первого контакта, статус документов Нет движения дольше нормы стадии Активная работа с документами Комплектность, дата последнего запроса Комплект не собран, клиент молчит Подготовка к проверке Дата подачи, статус ответа Ответ просрочен, нет комментария Финал / закрытие Дата оплаты или отказа Статус завис без даты закрытия Логика всех решений одна, и один из руководителей сформулировал её коротко: «чем мне создавать два отчёта? Мне проще создать один». Разрозненные таблицы плодят пустые поля в CRM, потому что менеджеру физически неудобно вносить одно и то же в три места. Единый портал с данными по источникам, пайплайну и оплатам снимает барьер механически — не мотивацией, а конструкцией системы. Правило Дашборд без нормативных сроков по стадиям — просто красивая таблица. Светофор работает только тогда, когда для каждой стадии воронки прописано, сколько дней в ней нормально находиться. Без этого «застрявшая» сделка ничем не отличается от «нормальной» — обе просто висят одинаково зелёным. ИИ-связка: подсветка причины зависания Здесь вы получаете то, чего не даст ни один отчёт: не факт «сделка стоит», а причину — что было последним касанием, чего ждёт клиент, писал ли ему кто-нибудь вообще. Ручной светофор по срокам решает половину задачи — он показывает, ЧТО зависло. Не показывает, ПОЧЕМУ. На потоке в несколько сотен активных сделок в месяц у РОПа физически нет времени открывать каждую просроченную карточку и читать историю переписки. Здесь встраивается модель — не вместо человека, а как первый фильтр, который сортирует зависшие сделки по вероятной причине, прежде чем к ним прикоснётся менеджер. Схема конвейера: Bitrix24 (событие ONCRMDEALUPDATE при смене стадии) → облачная функция вычисляет «дней в стадии» и сверяет с нормативом из таблицы Google Sheets → если превышение — тело сделки уходит в дешёвую модель на классификацию → ответ модели записывается обратно в кастомные поля сделки через REST API → РОП видит готовую метку в дашборде, а не сырую историю переписки. Модель здесь нужна дешёвая (уровня GPT-4o-mini или аналог), не топовая: задача — классификация по короткому списку причин плюс черновик из 2–3 предложений, объём — сотни сделок в месяц. Дорогая модель на этом шаге — переплата без прироста качества: разница в точности классификации причины паузы для топовой и лёгкой модели на таком объёме текста практически не ощущается. Пример входных данных, которые уходят в модель (структура из Bitrix24-вебхука): Пример ответа модели: Инженерная обвязка: функция крутится на облачном сервере по расписанию раз в час плюс по вебхуку при смене стадии. Нормативы сроков хранятся в отдельной Google-таблице — их правит РОП без доступа к коду. Ошибки вызова API (таймаут, лимит) логируются в отдельный лист «Ошибки интеграции» и дублируются алертом в Telegram-канал отдела. Что при масштабировании на несколько воронок. Одна плоская Google-таблица с нормативами держится, пока в компании одна воронка и один РОП, который её правит. Как только воронок несколько — например, отдельно продажи и отдельно сопровождение — или отделов больше одного, плоский лист начинает путать нормативы: правки одного РОПа перезаписывают правки другого, а функция иногда читает таблицу в момент редактирования и забирает неполные данные. На этом объёме лист лучше разбивать по вкладкам с явным pipeline_id и department_id в каждой строке, а функцию — переводить с чтения «всего листа» на чтение конкретной вкладки по идентификатору сделки. Если воронок больше 3–5 и правки в норматив вносят разные люди одновременно, конструкция на Google Sheets исчерпывает себя — дальше нормативы стоит держать в отдельной таблице базы данных (хотя бы Airtable), а не в Google-листе. Отдельно — что делать, если ответ модели не лезет в схему: JSON без одного из полей, лишний текст перед скобкой, причина не из разрешённого списка. Приёмный код валидирует ответ по JSON-схеме до записи в CRM. Если валидация не прошла — автоматический retry с тем же промптом и явной пометкой «предыдущий ответ не соответствовал схеме, верни строго валидный JSON». Если после второй попытки схема снова не сходится — сделка не остаётся без метки: ей присваивается служебный статус «требует ручного разбора», и она попадает в отдельный фильтр дашборда, а не теряется молча, как это было бы с пустой карточкой без всякого ИИ. Здесь важна деталь, которую легко упустить: сам факт двойного сбоя должен куда-то эскалироваться, а не просто оседать строчкой в листе «Ошибки интеграции». Лог, который никто не читает, — это та же зависшая карточка, только на уровне инфраструктуры. Правило простое: если по одной и той же сделке подряд две неудачных попытки, или если за час накопилось больше пяти сбоев по разным сделкам, — в Telegram-канал уходит отдельный алерт с пометкой «требует внимания интегратора», а не рядовая запись в общий лог. Порог в «пять сбоев за час» — ориентир для старта; для конкретного объёма сделок в компании его стоит откалибровать на первой неделе работы. Без этого правила автоматизация превращается в ту же самую проблему, которую она должна была решить: где-то в системе тихо копится факт, что что-то не работает, и никто об этом не знает. Раз в неделю 10% автоматических классификаций проверяются вручную — сверяются с тем, что реально происходило со сделкой, чтобы не пропустить дрейф качества модели. Это тоже время, а не бесплатная строчка в регламенте — см. блок про экономику ниже. Экономика: сколько это стоит и что даёт Настройка дашборда со светофором и вебхука на ИИ-классификацию занимает ~15–25 часов работы интегратора, эксплуатация — ~3 000–6 000 ₽ в месяц на поддержку и вызовы модели, эффект от точечного спасения зависших сделок — ≈16 000–21 000 ₽ в месяц (оценка) на примере условного отдела. Дальше — не отчёт по деньгам разобранной компании, а рабочий шаблон расчёта на условном отделе из 10 менеджеров производственной компании с оборотом ~4 000 000 ₽ в месяц и средним чеком 60 000 ₽; ни одна цифра здесь не измерена по факту в компании из кейса — это метод, куда подставляют свои значения вместо примерных. Шаг 1. Сколько денег под риском. Консервативное допущение: без движения сверх нормативного срока может стоять до 10% активных сделок. При ~80 сделках в работе (по 8 на менеджера) зависших сверх нормы окажется около 8. 8 сделок × 60 000 ₽ чек ≈ 480 000 ₽ пайплайна под риском в месяц. Это не факт продаж — сумма, которая либо закроется с опозданием, либо сорвётся вовсе. Если в вашей CRM доля другая — подставьте свою цифру после выгрузки по чек-листу ниже, формула не меняется. Шаг 2. Сколько спасает подсветка. Консервативно: своевременная подсветка и дожим спасают 15–20% этой суммы. 480 000 ₽ × 15–20% ≈ 72 000–96 000 ₽ пайплайна, который реально можно спасти в месяц. Но пайплайн — ещё не деньги на счету. Шаг 3. Сколько реально попадёт в кассу. Чтобы получить реалистичную оценку выручки, пайплайн домножается на собственную конверсию встреча → договор — в нашем кейсе 22%. 72 000–96 000 ₽ × 22% ≈ 16 000–21 000 ₽ реалистичной выручки в месяц. Условие: «спасённая» сделка проходит тот же путь, что и остальные. Именно эту цифру сравниваем со стоимостью внедрения — не сырую оценку спасённого пайплайна. Шаг 4. Сколько экономит время РОПа. Без дашборда ручной разбор воронки — кто завис, кто не звонил, у кого просрочен статус — занимает 3–5 часов в неделю. При ставке ~1 000 ₽/час это 12 000–20 000 ₽ его рабочего времени в месяц. Автоматический светофор забирает эту работу почти целиком. Формула для своего случая: (число зависших сделок сверх нормы) × (средний чек) × (% спасения, консервативно 15–20%) × (конверсия встреча → договор) = реалистичная оценка эффекта в выручке в месяц. Стоимость внедрения. Дашборд с датой контакта, светофором по нормативам и вебхуком для ИИ-классификации — по практике 15–25 часов работы аналитика/интегратора, при ставке ~1 000 ₽/час это 15 000–25 000 ₽ разовых затрат — стоимость одной-двух недель работы штатного аналитика. Стоимость владения — то, что легко забыть вычесть. Разовым внедрением дело не заканчивается. Пересмотр нормативов сроков по стадиям (сезонность, новые услуги) — ~1 час РОПа в месяц, около 1 000 ₽. Еженедельная проверка 10% классификаций: при потоке в несколько сотен сделок в месяц это несколько десятков карточек в неделю, по 2–3 минуты на карточку — итого 2–5 часов в месяц, около 2 000–5 000 ₽. Итоговая постоянная стоимость поддержки — около 3 000–6 000 ₽ в месяц, то есть в 3–5 раз меньше разовых затрат на внедрение. Итог. Реализованная выручка (≈16 000–21 000 ₽/мес) перекрывает стоимость поддержки (≈3 000–6 000 ₽/мес) в разы. Плюс сэкономленное время РОПа — ещё 12 000–20 000 ₽/мес в пересчёте на ставку. Минус стоимость поддержки — величина на порядок меньше эффекта. Чистый эффект всё равно кратно превышает разовые затраты на внедрение (15 000–25 000 ₽). Окупаемость укладывается в первый-второй месяц эксплуатации. Отдельно — эксплуатация самой модели: при потоке в несколько сотен сделок в месяц и коротких промптах счёт за вызовы дешёвой модели обычно укладывается в 1 000–3 000 ₽ в месяц — это цена одного-трёх часов работы менеджера, не больше. Все цифры этого раздела — рабочий шаблон расчёта, а не измеренный факт: реальные значения зависят от вашей воронки и вашей базы клиентов. Важная оговорка. Рост конверсии на 1 п.п. в месяц из истории с расширением отдела дал не дашборд сам по себе, а весь комплекс контроля — включая ограничение числа лидов на менеджера. Вклад именно дашборда отдельный и более скромный: он ускоряет обнаружение проблемы для РОПа — недели ручного разбора воронки превращаются в минуты просмотра дашборда. Саму конверсию поднимает то, что происходит после обнаружения: звонок, дожим, решение. Автоматизация без надзора — та же проблема, вид сбоку Предупреждаю вас заранее: если вы решите проблему техникой, не решив её управленчески, вы получите те же пустые карточки, только заполненные машиной. Соблазн после всего этого — автоматизировать заполнение CRM целиком: пусть бот сам подтягивает статусы и закрывает неквалифицированные лиды. Отчасти это работает: при закрытии неквалифицированного лида менеджер проговаривает альтернативу по звонку, а SMS с дальнейшей ссылкой уходит автоматически — вручную это делали реже и хуже. Но полная автоматизация без контроля создаёт новую проблему вместо старой. Я подробно разбирал это на других кейсах в статье про автоматизацию, которая требует надзора : система, которую поставили и забыли, начинает врать так же, как забытая вручную CRM — просто по другим причинам. Применительно к нашей задаче: автоматическая классификация причины зависания снимает часть ручной работы с РОПа, но кто-то обязан раз в неделю проверять, что модель классифицирует верно. Иначе зависшая сделка получит автоматическую метку «ждёт решения» вместо реального «менеджер забыл позвонить» — и станет ещё незаметнее, чем была без всякой автоматизации. И вот что здесь стоит назвать вслух. Умение построить контур, в котором данные появляются сами — норматив по стадии, светофор, пятнадцатиминутный разбор только красных сделок, — это отдельный управленческий навык, а не работа айтишника. Руководитель, который умеет собрать такой контур, стоит дороже руководителя, который умеет только требовать заполнять карточки. Я сам шёл к этому годами: сначала делал красивые отчёты, которые никто не открывал, и злился на людей вместо того, чтобы чинить конструкцию. Чек-лист: с чего начать в понедельник Если на всё остальное нет времени — сделайте сегодня три вещи: Выгрузить из CRM список сделок без движения дольше 14 дней без комментария — это временный норматив, пока нет своего. Разослать менеджерам письменный список критериев, по которым оцениваются их звонки и сделки, — до включения любого автоматического контроля. Договориться с РОПом о еженедельном 15-минутном разборе только красных (просроченных) сделок — не всей воронки целиком. Остальное — по мере появления времени в течение недели: Добавить в таблицу или дашборд две колонки: «дней в текущей стадии» и «дата последнего контакта» — это можно сделать за один день в Google Таблице, не дожидаясь интеграции. Вручную проверить 5–10 «зависших» сделок: клиент правда неактивен или это ошибка внесения данных, как в разборе про CRM, которая врёт. Если планируете тестировать ИИ-классификацию причин, начните с сегмента «холодных» или паузных сделок, где риск минимален, прежде чем выкатывать на всю базу. Считать порог для вызова интегратора по конкретным цифрам, а не «на глазок»: если зависших сделок сверх нормы больше 10% пайплайна, если ручной разбор воронки у РОПа занимает больше 5 часов в неделю, или если поток сделок превышает 100 в месяц — это тот объём, где Google-таблица с ручным обновлением перестаёт справляться и нужен вебхук. Если своими силами за 2–3 недели не удалось: настроить вебхук на смену стадии в CRM, договориться с РОПом о нормативах по каждой стадии воронки, или найти в CRM поле, где физически хранится дата последнего контакта, — это сигнал звать интегратора или вендора CRM. Самодельная Google-таблица с ручным обновлением решает диагностику, но не автоматизацию; для конвейера с вебхуком и записью результата обратно в кастомные поля сделки нужен человек, который хотя бы раз настраивал такую интеграцию. Найти его дешевле, чем полгода терпеть пустые карточки CRM и объяснять на планёрках, куда делась выручка. Что сделать вам на этой неделе: спросите двух менеджеров, что им даёт заполненная карточка. Ответ определит, с чего начинать — с правил, с обучения или с того, чтобы убрать из CRM половину полей, которые никому не нужны. Как выстроить это так, чтобы данные появлялись сами, а не «по требованию», — в бесплатном курсе .

## KPI менеджера по продажам: что мерить, чтобы увидеть провал в среду
URL: https://davidgerstein.pro/blog/kpi-menedzherov-prodazh/
Дата: 2026-08-03
Направление: Продажи
Цифры: выполнение плана по выручке 80% · конверсия в продажу 14% при плане 23% · рост конверсии на 1 п.п./мес после внедрения контроля
Коротко: KPI менеджера работает, если это не одна цифра «план по выручке», а воронка: конверсия в продажу, конверсия во встречу, средний чек, дни в статусе. Контроль без микроменеджмента строится на дашборде со светофором по срокам, а не на прослушке звонков и требовании отчётов. После такого внедрения конверсия отдела росла примерно на 1 процентный пункт в месяц — без найма новых менеджеров и увеличения бюджета на лиды.

Спросите своего менеджера, что он должен сделать на этой неделе, чтобы выполнить план. Если в ответ услышите «продавать больше» — у вас нет KPI, у вас есть план по выручке и надежда. И если вы узнали здесь свой отдел — вы управляете продажами вслепую: провал вы увидите двадцать восьмого числа, когда чинить уже нечего. Разница принципиальная: план — это результат, на который менеджер влияет косвенно. KPI — это то, что он контролирует сам и что вы можете проверить в среду, а не двадцать восьмого числа, когда исправить уже нечего. Неделя: план по выручке выполнен на 80%. Закрыли 7 сделок из 16 запланированных. Конверсия в продажу — 14% при плановых 23%. Средний чек, кстати, выше плана: 13,5% против 10%. Во встречу конвертировали хорошо — 55%, встреч провели 49. А вот из встречи в договор — только 22%. Руководитель отдела в этот момент говорит буквально: «мне становится страшно, я начинаю переживать конкретно». Вот с этой раскладки и стоит начинать разговор про KPI менеджера по продажам. Не с одной цифры «выполнил план — не выполнил», а с воронки, где видно, на каком именно шаге теряются деньги. В этом примере деньги теряются не на входе (лидов и встреч достаточно) и не на сумме сделки (чек выше плана). Они теряются между встречей и договором. Это совсем другая проблема, чем если бы проседала конверсия во встречу — и лечится она по-другому. Какие KPI менеджера действительно работают KPI менеджера — это не план по выручке: план он получает как результат, влияет на него косвенно и узнаёт о провале в конце месяца. Рабочие показатели те, что человек контролирует сам и вы проверяете в среду: число сделок в движении, доля сделок без касания дольше семи дней, конверсия в следующий этап. Эти три показателя остались после месяца, в котором выручки не было, а объяснить причину никто не мог. Проверка на практике: у сильного и слабого менеджера сравнивайте не выручку, а эти три числа — разница в действиях объясняет разницу в деньгах. Почему план по выручке — это не KPI, а диагноз задним числом Мы у себя долго путали эти две вещи и потеряли на этом не один квартал. Я сам годами смотрел на одну строчку «план — факт» и был уверен, что этого достаточно. План не выполнялся, и я честно не понимал, за что хвататься: менять людей, менять цену, добавлять рекламы. Здесь ошибаются почти все, кто вырос из продавца в руководителя, — я в том числе. План по выручке говорит только одно: получилось или нет. Он не говорит, почему. Отдел из 6–7 менеджеров в одной компании стабильно продавал хуже, чем тот же отдел в составе 3 человек — руководителя, его напарника и ещё одного. Причина не в квалификации новых людей. Причина в том, что лидов на всех не хватило, и качество работы с каждым лидом упало. По плану выручки это не видно сразу — видно только через несколько месяцев, когда цифры уже просели. После того как ввели контроль на уровне воронки — не «сколько продали», а «сколько лидов, сколько встреч, сколько дней сделка стоит без движения» — конверсия начала расти на процентный пункт в месяц. Не потому что наняли новых людей или увеличили бюджет на лиды. Потому что стало видно, где именно теряются клиенты у конкретных менеджеров. Воронка вместо итоговой цифры Рабочий набор метрик для отдела продаж выглядит примерно так — и это то, что легло в основу дашборда, о котором дальше. В последнем столбце — фактические значения по той самой неделе с планом, выполненным на 80%, там, где данные вообще фиксировались: Метрика Что показывает Где искать проблему Значение за неделю (пример) Конверсия в продажу Итоговая эффективность менеджера Слишком общая, сама по себе бесполезна 14% факт / 23% план Конверсия лид → встреча Качество квалификации и первого контакта Скрипт, скорость реакции на заявку 55% (49 встреч) Конверсия встреча → договор Аргументация и умение закрывать сделку Навык менеджера, ценностное предложение 22% Средний чек Умение продавать пакеты выше базового Работа с апсейлом, знание услуг 13,5% / 10% план Дни в текущем статусе Скорость движения сделки по воронке Застрявшие клиенты, забытые лиды не фиксировалось до дашборда Дата последнего контакта Есть ли вообще внимание к клиенту Пайплайн без касаний не фиксировалось до дашборда Доля клиентов на одном менеджере Риск непрерывности при увольнении Нет передачи знаний внутри команды не фиксировалось до дашборда Три последние строки не зря помечены «не фиксировалось» — это честная часть картины: до внедрения дашборда эти данные просто не собирались, и именно их отсутствие не позволяло увидеть риски заранее. Вот как выглядит эта воронка на примере той самой недели — по стадиям, а не одной итоговой цифрой: Лид → встреча 55% Встреча → договор 22% Лид → продажа (факт) 14% Лид → продажа (план) 23% Из этой картинки понятно, что чинить нужно не скрипты первого звонка (со встречами всё нормально) и не квалификацию лидов на входе. Проблема — в переходе от встречи к договору. Это либо аргументация, либо цена, либо то, что клиенту не закрыли реальное возражение на встрече. Без разбивки по стадиям это выглядело бы просто как «конверсия ниже плана» — и время ушло бы на исправление не той части воронки. Правило KPI, который меряет только результат, а не процесс, всегда приходит с опозданием. Пока вы видите просевший план — деньги уже потеряны за 2–3 месяца до этого. Метрики процесса (дни в статусе, дата контакта, конверсия по стадиям) дают шанс вмешаться раньше. Мёртвые лиды и мёртвые сделки — считать отдельно Проверьте у себя: сколько сделок в вашей воронке не двигались две недели? Обычно это от четверти до половины, и в отчёте по выручке они не видны никак — а деньги там есть. В одной воронке нашёлся клиент без движения полтора года — из отдельной категории контрактов, которая по своей природе двигается медленнее остальных. Он искажал всю статистику: по нему считались сроки, средние показатели, конверсии — и всё это было неправдой, потому что клиент фактически не двигался. Решение простое: вынести такие случаи в отдельную воронку по типу работ, чтобы не путать «спящих» клиентов с активной работой. Похожая логика применима и на входе воронки: если в отдел приходит 200+ потенциальных обращений в месяц, а конверсия держится около 25%, недостаточно смотреть на итоговый процент — нужно понимать, сколько из этого пула вообще пригодно для апсейла прямо сейчас, а сколько застряло на этапе сбора документов и физически не может продвинуться дальше, сколько бы касаний ни делал менеджер. Другой пример — с базой отказников. Компания подняла лиды семилетней давности, которые когда-то отказали: не готовы платить, не готовы разговаривать, не оставили заявку. В марте часть из них вернулась и купила на сумму, заметную для месячного оборота компании. Важная деталь: все они раньше брали трубку и общались — просто им в своё время достался менеджер низкой квалификации. Это фиксация системной ошибки: слабый менеджер = потерянные деньги, которые можно вернуть, просто пересадив клиента на другого человека. Стоит сразу оговориться: этот результат дал не один инструмент, а комплекс мер — сегментация базы, ручной отбор «тёплых» отказников и пересадка на менеджера с другой квалификацией. Отдельно оценить вклад одной лишь автоматизации выборки в эту сумму по имеющимся данным нельзя, и приписывать её целиком скорингу было бы нечестно. Компания сейчас готовит автоматический инструмент, чтобы повторить этот результат уже не разово, а на потоке — но пока это план, а не факт, который можно было бы зашить в KPI. Для KPI менеджера это означает: нужна метрика не только по новым лидам, но и по работе с базой. Один менеджер в мае сделал только 15 звонков новым контактам вместо плановых 60+, зато повторное касание по 19 тёплым лидам дало 4 рекомендации. Вывод прямой: одного звонка недостаточно, нужна регулярная работа с базой как отдельный измеримый процесс, а не разовая акция. Больше про то, куда утекают лиды между маркетингом и продажами — в статье «Лиды есть, а продаж нет» . ИИ-связка: контроль без ручной прослушки Здесь машина закрывает вашу главную проблему с KPI: вы наконец видите не только результат, но и то, как работает ваш менеджер, — по всем разговорам, а не по трём, которые вы успели послушать. Отдельная история — про то, как ИИ начал оценивать вторичные звонки менеджеров по критериям, которые сами менеджеры никогда не видели. Требования к таким звонкам были прописаны в системе для настройки алгоритма, но до отдела продаж их никто не донёс. В итоге менеджеры звонили, как звонили всегда, а система штрафовала их за несоответствие правилам, о которых они не подозревали. Это типичная ошибка при внедрении любого автоматизированного KPI: сначала нужно проверить, что оценки ИИ и оценки живого проверяющего совпадают в целом, и только потом объявлять отделу правила игры. Рабочая схема конвейера, которая закрывает эту проблему, выглядит так: Что. Звонок менеджера завершается в телефонии, подключённой к CRM (например amoCRM или Bitrix24). Чем. Вебхук на событие «звонок завершён» отправляет запись во внешний сервис транскрибации, затем текст и метаданные (id менеджера, id сделки, длительность) — в дешёвую модель для первичного скоринга по критериям. Куда. Результат (баллы по критериям, итоговый скор, флаг эскалации) пишется обратно в карточку сделки CRM через API и параллельно — в общий дашборд. Кто и когда. Пограничные звонки (скор 40–60 из 100) автоматически уходят на повторную оценку дорогой моделью и попадают в очередь ручной проверки РОПа. Остальные просто накапливаются в статистике по менеджеру. Дешёвая модель здесь оправдана: объём звонков большой, а задача первого прохода простая — сверить факты по чек-листу, не рассуждая. Дорогая модель включается только на спорных случаях, где нужна интерпретация тона и контекста. Это тот же принцип, что и в контроле качества без штатного ОКК — подробнее про экономику такой связки в статье про контроль качества звонков без ОКК . Пример ответа модели на такой запрос: Инженерная обвязка Пайплайн крутится не «где-то в облаке», а на понятном сервисе-посреднике: небольшой скрипт или сценарий в n8n на отдельном сервере (или облачной функции), который слушает вебхук из CRM, дергает API транскрибации и API модели, пишет результат обратно через API CRM. Если модель вернула невалидный JSON или не ответила — до трёх повторов с задержкой, затем звонок автоматически падает в ручную очередь, а не теряется молча. Если пайплайн не отвечает вообще (сбой сервиса, кончилась квота API) — отдельное сообщение уходит в канал ответственного за инфраструктуру, а не в общий чат отдела продаж, чтобы не путать техническую ошибку с реальной проблемой у менеджера. Здесь же стоит держать в голове ограничение по личным данным: транскрипты звонков могут содержать чувствительную информацию о клиенте, и то, что можно отправлять во внешнюю модель, а что нельзя, — вопрос отдельный и заслуживает самостоятельного разбора. Где ломается KPI, о котором менеджер узнаёт постфактум по результату оценки, а не заранее в виде понятного правила, — это не мотивация, а рулетка. Она демотивирует быстрее, чем полное отсутствие KPI. Прежде чем включать автоматическую оценку в мотивацию, минимум месяц гоняйте её параллельно с ручной проверкой и сверяйте расхождения. Мотивация: процент с продаж — не единственный рычаг Здесь вам придётся принять решение, которое не понравится части команды. Но если вы платите только процент, вы платите за удачу так же, как за работу. С мотивацией менеджеров сложнее, чем кажется на старте. В одной компании руководителя отдела перевели на схему «1% с личных продаж + 1% с продаж команды» — чтобы стимулировать развитие отдела, а не только личный результат. Но внедрение отложили на месяц: испугались, что менеджер с недостаточным личным доходом потеряет мотивацию, пока привык мыслить горизонтом в один месяц, а не в перспективе роста команды. В другом случае руководитель отдела получал двойную комиссию — и как менеджер, и как руководитель, — что снижало его интерес развивать команду вместо личных продаж. Решение — временно сохранить двойную схему на два месяца, а затем перейти только на командную комиссию, привязав переход к конкретному критерию: укомплектованный состав из нескольких менеджеров. Есть и обратная сторона — конфликт ожиданий. Менеджеру когда-то обещали процент от прибыли, но когда рост замедлился, собственник эту долю забрал, списав всё на «неправильное управление». Формально это решение собственника. По факту — подрыв доверия к любой будущей схеме мотивации в этой команде. KPI и бонусы, которые можно отменить задним числом, работают только один раз — после этого людям нужны письменные договорённости, а не устные обещания. Похожая тонкость — с расчётом бонуса: менеджеру предложили не засчитывать доход от клиента, который должен был оплатить в следующем месяце, хотя раньше компания обещала учитывать такие переходящие платежи. Менеджер согласился в обмен на повышение бонуса — но осадок от смены правил остаётся, даже если формально стороны договорились. Не всякий провал по конверсии решается деньгами. Когда конверсия отдела держится на уровне 25–28% третий месяц подряд, руководитель формулирует это без обиняков: «конверсия 25-28% третий месяц подряд — это позор. Если такая конверсия, то я меняю сразу структуру мотивации и все рекомендации отдаю в отдел продаж, у которого конверсия 80%». Это тоже KPI-решение, просто не про размер процента, а про то, что низкая конверсия делает сам факт получения лидов от компании привилегией, которую можно потерять. Похожий случай — с менеджерами, которые теряют энтузиазм на холодных лидах из низкоконверсионного канала: здесь сработало не повышение комиссии (это подтвердило бы, что канал действительно «плохой»), а объяснение, что работа со сложными холодными сделками — часть роста квалификации, а не наказание. KPI, которые считают не только продажи Один из собственников предложил другой взгляд на цель. Вместо роста продаж в абсолютных цифрах (это дало бы сравнительно скромный прирост прибыли) — смотреть на сокращение цикла обслуживания клиента на 30% и снижение операционных расходов на 20–30%. Логика в том, что эти метрики сильнее влияют на чистую прибыль через ускорение оборота денег и снижение затрат, чем прямой рост выручки. Для менеджеров это тоже применимо: скорость закрытия сделки и снижение доли «зависших» клиентов иногда даёт бизнесу больше денег, чем ещё один процент к конверсии. И ещё один KPI — который вообще не сводится к числу. Менеджер провёл лид-менеджера через постепенное вовлечение: сначала наблюдение за встречами, потом ведение первых 7 минут, затем расширение роли, пока не сказал «иди и закрывай сама» — и она закрыла сделку. Ни один дашборд не покажет момент готовности человека к самостоятельной работе. Это тот случай, когда KPI по количеству проведённых встреч стажёром маскирует главное: готов он или нет. Дашборд вместо отчётов вручную Правило для вас: если руководителю отдела нужно больше двух минут, чтобы понять, кто из его людей отстаёт и почему, — дашборд не работает. Ваша цель не красота, а скорость реакции. Практический вывод из всей этой фактуры такой: KPI менеджера по продажам работает, только если он живёт в системе, а не в голове руководителя и не в еженедельном отчёте, который менеджер сам себе пишет. В нескольких компаниях в итоге пришли к одному и тому же решению — единый интерактивный отчёт вместо разрозненных документов: договоры по источникам, пайплайн по месяцам, оплаты и выставленные счета по каждому сотруднику. Логика простая: «зачем мне два отчёта, если можно один интерактивный, который обновляется сам, чем пять таблиц, которые нужно сверять руками». Технически это тот же дашборд, что и в связке со скорингом звонков, только источник данных — не транскрипты, а карточки сделок CRM. Ключевой элемент — светофор по срокам стадий: если сделка стоит в статусе «встреча назначена» дольше норматива (например, 3 рабочих дня без движения), карточка красится в жёлтый, а после недели — в красный. Руководителю не нужно спрашивать у менеджера «как там клиент» — достаточно открыть дашборд и увидеть все красные строки за секунду. Менеджеру не нужно писать отдельный отчёт «что происходило на неделе» — эта же таблица и есть отчёт, просто без ручного труда по её составлению. Именно это и убирает микроменеджмент из уравнения: контроль идёт не через вопросы «почему не позвонил», а через видимость процесса. Менеджер видит те же цифры, что и руководитель, — значит, разговор идёт про конкретную сделку и конкретный срок, а не про общее недовольство результатом. Экономика: во что обходится KPI менеджера без воронки Прикиньте свою цифру: сколько сделок в вашей воронке зависло и какой у вас средний чек. Это не потерянные деньги, но это деньги, которые лежат без движения, пока вы меряете только выручку. Давайте посчитаем не абстрактно, а на условном примере, чтобы цифры были осязаемы. Возьмём отдел из 8 менеджеров, где на каждого приходится примерно 20 лидов в месяц — итого около 160 лидов на отдел. Просадка конверсии на 9 процентных пунктов (именно такой разрыв был в разобранном примере: план 23%, факт 14%) на этой базе — это примерно 14 несостоявшихся сделок в месяц (160 × 9% ≈ 14, оценка). При условном среднем чеке в 150 тыс. рублей (цифра для примера, не из фактуры компании) это риск на уровне 2,1 млн рублей недополученной выручки в месяц — оценка, которая будет меняться в зависимости от реального чека и объёма лидов у конкретного отдела. Отдельно стоит посчитать цену ручных отчётов, которые дашборд убирает. Если РОП тратит на сведение недельных отчётов по менеджерам условные 3 часа в неделю, а каждый из 8 менеджеров тратит на подготовку своего отчёта ещё по 30–40 минут — это дополнительно 4–5 часов в неделю на отдел. При ставке около 1000 ₽/час (оценка) это порядка 16–20 тыс. рублей в месяц условной стоимости времени, которое уходит не на продажи, а на составление таблиц вручную. Дашборд не увеличивает выручку сам по себе — он лишь освобождает эти часы и делает видимой проблему на встрече-к-договору за недели, а не месяцы. Сам рост конверсии на процентный пункт в месяц, о котором шла речь в начале статьи, — результат того, что руководитель начал видеть проблему раньше и разбирать её точечно с конкретными менеджерами, а не разовый эффект одного лишь дашборда без последующей ручной работы с людьми. Осторожно с цифрами Приведённые расчёты — иллюстрация логики «конверсия × база лидов × чек», а не прогноз для вашей компании. Подставляйте свои значения: базу лидов, реальный средний чек, фактический разрыв план/факт по конверсии — и оценка станет пригодной для решения, стоит ли вкладываться в дашборд именно сейчас. Чек-лист на понедельник Выгрузить из CRM воронку по стадиям за последний месяц отдельно от итоговой конверсии: лид → встреча, встреча → договор, договор → оплата. Найти стадию с самым большим провалом относительно нормы — именно туда, а не в скрипты первого звонка, направить внимание на этой неделе. Проверить долю сделок без движения дольше норматива (3–7 рабочих дней в зависимости от цикла) — если такой метрики ещё нет, завести её первой, раньше любых KPI по звонкам. Вынести в отдельную воронку контракты с заведомо более долгим циклом, чтобы они не искажали средние сроки и конверсии по основному потоку. Если планируете автоматическую оценку звонков — сначала прогнать её месяц параллельно с ручной проверкой РОПа и свериться в расхождениях, и только потом объявлять правила отделу. Перед изменением схемы мотивации — зафиксировать её письменно и не менять задним числом: разовое нарушение обещания стоит доверия ко всем будущим KPI. Посчитать для своего отдела оценку риска по формуле «база лидов × разрыв конверсии план/факт × средний чек» — и сравнить с ценой внедрения дашборда или скоринга, прежде чем в них вкладываться. Начните с малого на этой неделе: возьмите двух менеджеров — сильного и слабого — и сравните не выручку, а действия. Сколько звонков, сколько дошло до встречи, сколько сделок висит без движения. Разница в действиях объяснит вам разницу в выручке лучше любого разговора о мотивации. Как поставить на это машину, чтобы видеть картину по всем менеджерам, а не по двум, — механика в бесплатном курсе для руководителей . Как мы к этому пришли Мы жили на плане по выручке несколько лет и считали, что это нормально. Перелом случился, когда я попробовал разобрать неудачный месяц: выручки нет, а объяснить почему никто не может. Менеджеры говорят «рынок», руководитель отдела разводит руками, и спорить не с чем — цифр под этими объяснениями нет. Мы тогда добавили три показателя, которые менеджер контролирует сам: сколько сделок он двигает, сколько висит без касания, какая доля доходит до встречи. Дальше стало неинтересно спорить: у одного все три показателя в норме и провал по выручке — значит, вопрос к продукту или цене. У другого половина сделок неделю без движения — вопрос к нему. Никакой магии тут нет, и вам не нужны ни системы, ни бюджет. Нужна готовность смотреть не только на результат, но и на работу, которая к нему ведёт. Скажу прямо: читать воронку по стадиям — такой же базовый навык руководителя, как читать отчёт о движении денег. Раньше директор мог этого не уметь и оставаться сильным директором. Сейчас не может. Тот, кто видит, на каком шаге встала сделка, управляет отделом. Тот, кто видит только итог месяца, управляет своей надеждой. Я на этот навык потратил не один квартал — и это была самая окупаемая учёба за всё время. Начните на этой неделе с одного: посчитайте, сколько сделок у каждого менеджера стоит без касания дольше семи дней. Эта цифра скажет вам о работе отдела больше, чем месячный отчёт по выручке. Как поставить такой контроль на автомат — в бесплатном курсе для руководителей .

## Контроль заявок на стыке отделов: где конверсия падает с 55% до 22%
URL: https://davidgerstein.pro/blog/poteryannye-zayavki/
Дата: 2026-07-15
Направление: Продажи
Цифры: разрыв конверсии встреча→договор 55%→22% · шестизначная сумма в евро с реанимации 7-летней базы лидов · 1,5 года без движения по одной сделке
Коротко: Заявки теряются не потому, что менеджеры плохие, а потому что в момент передачи — между статусами, между отделами, при увольнении сотрудника — за клиента никто конкретно не отвечает: в разобранном отделе конверсия встреча→договор падает с 55% до 22% именно на этом стыке. Решает не мотивация и не разговоры на планёрке, а отчёт с датой последнего касания, нормативным сроком по стадии и именем ответственного. Считать эффект надо в деньгах: каждый потерянный процент конверсии имеет цену, и она известна заранее.

Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Самая обидная потеря в бизнесе — не проигранный конкурс и не ушедший к конкуренту клиент. Это заявка, на которую просто никто не ответил. Проверьте себя сразу, до всякой теории. Если вы не можете за минуту назвать, сколько заявок за прошлую неделю остались без единого касания и кто по каждой отвечает поимённо, — у вас эти заявки есть. Не «может быть, есть», а есть. Вы их просто не видите: в отчёте они лежат в одной куче с живыми. Вы за неё заплатили: реклама, сайт, работа маркетолога. Человек поднял руку и сказал «мне интересно». А дальше цепочка порвалась — и вы об этом даже не узнали, потому что в отчёте эта заявка есть, а в продажах её нет. В CRM одной компании нашёлся клиент без единого движения полтора года. Не отказ с причиной, не пауза по документам — просто карточка, которая зависла и годами тихо портила статистику отдела. Руководитель наткнулся на неё случайно, когда разбирал воронку по срокам жизни сделок. Это и есть потерянная заявка в продажах в чистом виде: она не удалена, не закрыта, у неё просто нет хозяина. Я третий год ставлю ИИ и системы отчётности в отделы продаж среднего бизнеса и вижу одну и ту же картину раз за разом. Заявки почти никогда не теряются в момент создания — лид попал в CRM, кто-то ему позвонил. Они теряются на стыках: когда лид переходит от маркетинга к продажам, от одного менеджера к другому, когда сделка меняет статус в воронке. В эти секунды никто конкретно не отвечает за клиента — и он проваливается в щель между процессами. По одной компании на неделе, где я разбирал воронку, факт не дотянул до плана продаж на пятую часть — как раз из-за таких проваленных передач, а не из-за того, что менеджеры вдруг разучились продавать. Где рвётся контроль заявок и как это проверить за пятнадцать минут Четыре типовых разрыва: заявка попадает в общий пул без ответственного, ответ приходит позже суток, статус меняется вручную и по памяти, повторные обращения не связываются с исходным. Работают обычно минимум два. Проверка занимает пятнадцать минут: возьмите заявки за неделю и найдите те, где нет ни одного касания клиента. Каждая такая строка — оплаченный рекламой и выброшенный шанс. Где именно рвётся ваша цепочка Четыре типовых разрыва. Пройдите по ним и отметьте, какие есть у вас, — обычно работают минимум два. Три точки разрыва встречаются в разных отделах продаж почти одинаково. Первая — смена статуса без владельца. Сделка перешла с этапа переговоров на этап «ожидание документов», и в этот момент менеджер решил, что мяч на стороне клиента. Клиент решил ровно то же самое про менеджера. Оба ждут. Через полтора года получаем зависшую карточку, которую случайно находят при аудите воронки. Вторая — увольнение или ротация менеджера. В одной из компаний, где я работал, ключевой менеджер ушёл, и стало неясно, кто обслуживает его клиентов. Несколько из них общались только с ним лично — без параллельного контакта, без дублирующей записи в CRM о договорённостях, что перекликается с типичной проблемой, когда менеджеры не вносят данные в CRM вовремя. Один клиент был привлечён буквально накануне увольнения, с ним ещё никто не успел даже созвониться повторно. Передачи не было — было исчезновение. Третья — межотдельная передача лидов , тот самый разрыв между маркетингом и продажами , где лиды есть, а сделок нет. Маркетинг сдал лид в продажи, продажи — в операционный отдел на исполнение. На каждом шаге теряется контекст: чего хотел клиент, что ему обещали, в какое время удобно звонить. В одной компании менеджеры передавали клиента операционному отделу устно или короткой строкой в задаче. Отдел начинал звонить наугад, клиенты не брали трубку — просто потому что не понимали, кто и зачем им звонит. Позже формат передачи изменили: менеджер стал давать детальный портрет клиента и его ожидания, операционный отдел получил доступ к календарю менеджера и назначал звонок на согласованное время. Клиенты стали отвечать заметно охотнее — но это отдельное решение, не автоматизация, и его эффект я здесь не смешиваю с ИИ-инструментами ниже. Правило Если у заявки в момент передачи нет конкретного человека с именем и сроком реакции — она не передана, она потеряна. «Отдел разберётся» ответственностью не считается, это способ спрятать разрыв до следующего аудита воронки. Заявки без ответственного: что покажут ваши цифры Возьмите свою выгрузку за неделю и посмотрите три вещи: сколько заявок без ответственного, сколько без единого касания и сколько получили ответ позже суток. Три числа, которые дадут вам полную картину. Проверьте прямо сейчас, не откладывая: сколько заявок за прошлую неделю не имеют ответственного или не получили ни одного касания. Эта цифра обычно отрезвляет сильнее любой статьи. Недельная динамика одного отдела продаж хорошо показывает, как выглядит разрыв в цифрах, а не в ощущениях. Факт продаж за неделю — 80% от плана. Закрыто 7 сделок из 16 запланированных. Конверсия в продажу — 14% при плане 23%. При этом конверсия во встречу держалась на уровне 55% — 49 встреч фактически состоялось, то есть люди доходили до разговора, и до этого момента процесс работал нормально. Показатель План Факт Сумма продаж за неделю 100% 80% от плана Закрытых сделок 16 7 Конверсия в продажу 23% 14% Средний чек (отклонение от базового) 10% 13,5% Конверсия во встречу — 55% (49 встреч) Конверсия встреча → договор — 22% Разрыв между 55% и 22% — это ровно то место, где заявка формально ещё жива (встреча состоялась), но реально уже потеряна. Клиент дошёл до разговора и не дошёл до договора, а в большинстве отчётов, которые я видел до внедрения детализации, воронка вообще не разбивается на такие подэтапы — есть только «было» и «не было». На диаграмме — обе конверсии рядом: видно, где именно происходит основной провал. Лид → встреча 55% Встреча → договор 22% Конверсия в продажу, план 23% Конверсия в продажу, факт 14% Похожая история про май того же отдела: команда отвлеклась на апсейл действующей базе (на кону было направление с потенциалом около 500 000 ₽ в месяц) и перестала системно звонить новым контактам. План на месяц — 60+ звонков, сделали 15. При этом повторное касание по 19 тёплым лидам, оставшимся с апреля, дало 4 рекомендации. Ресурс, который просто лежал без внимания, оказался продуктивнее нового потока — потому что до него наконец дошли руки. Это тоже потерянная заявка, только растянутая на месяц: не пропала, а простояла без движения ровно до момента, пока кто-то не вспомнил о её существовании. Механика по шагам: как найти и закрыть ваш разрыв Пройдите этот путь на своих данных: сначала находите, где рвётся, потом ставите ответственного, потом закрываете техникой. В обратном порядке не работает — автоматизация поверх бардака делает бардак быстрее. Порядок для вас — от простого к сложному. Первый шаг даст результат в тот же день, остальные потребуют недели. Порядок, который реально работает — без сложной автоматизации на старте. Шаг 1. Откуда данные. Выгружаете из CRM (Bitrix24, amoCRM или любая другая) все сделки с датой последнего изменения статуса, датой создания, текущим этапом и ответственным менеджером. Это стандартный экспорт, доступен в любой системе без доработок. Здесь важна оговорка: дата в поле CRM не всегда равна дате реального последнего касания — иногда система показывает дату технического сдвига, а не звонка. Прежде чем строить на этих данных отчёт, стоит свериться с логами звонков хотя бы выборочно, я подробно разбирал этот случай отдельно, когда Bitrix24 сдвигал даты сам . Шаг 2. Что считать разрывом. Для каждого этапа воронки задаёте нормативный срок — сколько дней сделка может провести на этом статусе, прежде чем это станет проблемой. Норматив берётся не из головы, а из истории: смотрите медианное время на этапе у сделок, которые в итоге дошли до продажи, и берёте его как ориентир с запасом. Шаг 3. Кто и что делает с превышением. Сделки, превысившие норматив, помечаются как зависшие. Дальше — развилка: часть из них реально мёртвая (клиент год не отвечает, есть смысл вынести в отдельную воронку реактивации, чтобы не портить статистику активных сделок), часть — живая, но без ответственного (тут нужен именно контакт, а не архивация). Именно так поступили с клиентом, зависшим на полтора года: его не удалили и не форсировали звонком «на всякий случай», а перенесли в отдельную воронку, чтобы он перестал искажать конверсию остальных сделок. Шаг 4. Куда попадает результат. Не в отдельный файл, который никто не открывает, а в дашборд, доступный руководителю отдела и самим менеджерам, с прямым переходом в карточку сделки — чтобы разбор занимал секунды, а не поиск по CRM. Рабочий вариант такого отчёта: по каждому менеджеру клиент, статус, дата создания сделки, количество дней в текущем статусе и светофор — зелёный, жёлтый, красный — по нормативному сроку стадии. Обновление раз в час достаточно для отдела продаж, ежесекундная точность тут не нужна. Шаг 5. Кто и когда смотрит. Руководитель отдела — ежедневно, по красным меткам. Собственник или коммерческий директор — раз в неделю, по агрегированной динамике: растёт ли доля зависших сделок или падает. ИИ-связка: реактивация ваших зависших сделок Если разрыв у вас на входе, а не в старой базе, начните с другого конца: как устроена автоматизация обработки заявок — от письма до задачи с ответственным. Прежде чем покупать новые лиды, посмотрите на старые: у вас в базе почти наверняка лежат сотни контактов, до которых не дошли руки. Ваши старые заявки — это не мусор, а оплаченная база, до которой не дошли руки. Машина разбирает её и приносит вам список тех, кому есть смысл написать сегодня. Ручной разбор зависших сделок работает, пока их немного. Когда база вырастает до сотен клиентов на паузе, нужна первая линия автоматической сортировки — не для того, чтобы заменить менеджера, а чтобы не звонить всем подряд одинаковым текстом. Конвейер выглядит так: CRM (amoCRM или Bitrix24) → вебхук при переходе сделки в статус «пауза» дольше нормативного срока → запрос к модели с историей переписки и звонков → результат (причина паузы, тон, черновик сообщения) пишется в кастомное поле сделки и создаёт задачу менеджеру на согласование → менеджер утверждает или правит текст → отправка. Автоматика не отправляет сообщение сама — она готовит черновик, решение остаётся за человеком. Это осознанное ограничение: компания, с которой я работал, сначала тестировала реактивацию именно на «паузниках» — клиентах, которые и так не двигались, — чтобы не рисковать активной базой, если модель ошибётся с тоном. Модель здесь — дешёвая (уровня gpt-4o-mini или аналогичной по цене): задача классификационная и генерирует короткий текст, ей не нужна глубокая аналитика или длинный контекст. Дорогую модель имеет смысл подключать только на этапе разбора сложных возражений в живом диалоге, а не на массовой сортировке базы. Пример ответа модели: Второй, более простой сценарий — для компаний, у которых пока нет ресурсов на вебхуки в CRM. Выгрузка зависших сделок в Google Sheets, скрипт на Apps Script раз в сутки отправляет строки в модель для быстрой сегментации: «мёртвая» или «живая без ответственного». Пример ответа модели: Инженерная обвязка здесь простая, но обязательная: лимит на количество запросов в минуту (чтобы не упереться в rate limit при массовой выгрузке в сотни строк), лог каждого ответа модели с deal_id — иначе при сбое непонятно, какие сделки уже обработаны, и fallback-правило «если API недоступен или confidence ниже 0,4 — сделка уходит в очередь на ручной разбор, а не отправляется автоматом». Без этого правила один сбойный ответ модели может улететь клиенту как есть. Скрытые критерии убивают доверие к системе Если вы одновременно вводите скоринг звонков или сортировку сделок и не объясняете менеджерам, по каким именно критериям их теперь оценивают, — получаете не улучшение процесса, а сопротивление. В одной компании система оценивала вторичные звонки по требованиям, о которых сами менеджеры не знали: они продолжали звонить «как звонили всегда», а отчёт показывал провал. Правильный порядок обратный: сначала показать менеджерам, как оценки модели соотносятся с реальными звонками, добиться согласия, что критерии справедливы, и только потом вводить их как норму. Здесь я обязан сказать про себя, а не про абстрактную компанию. Тот случай со скрытыми критериями — моя ошибка. Систему ставил я, критерии держал в голове я, а до менеджеров их не донёс: решил, что цифры в отчёте объяснят себя сами. Не объяснили — получил месяц глухого сопротивления и отчёт, которому в отделе никто не верил. Так что если ваша первая попытка навести порядок в заявках упрётся в «да мы и так всё делаем» — это нормальный этап, я сам через него прошёл. Это не признак того, что команда плохая. Экономика: цена одного процента конверсии Посчитайте на своих цифрах — умножьте свой средний чек на количество заявок за месяц и на один процент. Обычно получается сумма, ради которой стоит потратить неделю на наведение порядка. Отдельно стоит разобрать шестизначную сумму в евро, которая обычно всплывает как аргумент «просто дожмите старую базу». В одной компании подняли базу лидов, которые отказали менеджерам семь лет назад — по трём причинам: не готовы платить, не готовы разговаривать, заявку в итоге не оставили. В марте те же контакты вернулись и купили на шестизначную сумму в евро. Важная деталь: все они когда-то реально брали трубку и общались — просто тогда с ними работали менеджеры низкой квалификации, и заявка терялась не из-за плохого лида, а из-за плохой обработки. Это чистый результат ручной реактивации: обзвон, повторный контакт, живой разговор. Автоматический ИИ-инструмент, о котором шла речь выше, на момент этой реактивации ещё не применялся — компания только готовит его, чтобы повторить эффект без ручного перебора каждой карточки. Вклад ИИ в этот результат — нулевой, и приписывать ему чужой результат было бы нечестно. Его роль — не заменить то, что сделали руками, а масштабировать сортировку, когда база вырастет с десятков до сотен карточек и руками её уже не разобрать. Чтобы прикинуть свой риск, а не чужой, считайте по формуле: количество сделок в активной воронке × доля зависших дольше норматива × консервативная доля тех, что без вмешательства так и не закроются × средний чек. Все три доли — это оценка, а не факт, поэтому берите её с запасом в свою пользу, а не в пользу красивой цифры. Параметр Значение Менеджеров в отделе 6 Сделок в активной воронке на менеджера (оценка) ~15 Всего сделок в работе 90 Доля зависших дольше норматива 10% Зависших сделок 9 Доля теряемых без вмешательства (консервативная оценка) 50% Теряемых сделок (округлено, оценка) ≈4 Средний чек 250 000 ₽ Риск в месяц (оценка) ≈ 1 000 000 ₽ То есть отдел из 6 менеджеров при обороте около 6 млн ₽ в месяц и всего 10% зависших сделок рискует терять около 1 млн ₽ выручки в месяц просто потому, что часть заявок никто не подхватил вовремя (оценка, не факт — но повод посчитать свою воронку по той же схеме, прежде чем списывать провал плана на «слабый месяц»). Второй слой затрат — не выручка, а время руководителя на ручной разбор. Если РОП тратит на каждую зависшую сделку в среднем 15 минут — найти карточку, вспомнить историю, решить, что делать — 9 сделок в неделю дают около 2,25 часа, то есть порядка 9 часов в месяц. При ставке руководителя примерно 1 500 ₽/час это около 13 500 ₽ в месяц только на ручную разборку (оценка) — статья расходов, которая исчезает, если дашборд с датой последнего касания и цветовой меткой уже показывает, где смотреть, а не заставляет искать вручную. Что делать вам в первую очередь Порядок действий на вашу неделю — каждый пункт можно закрыть за один подход, и первые два не требуют ни техники, ни бюджета. Если внедрять всё сразу — не начнёте ничего. Порядок действий на ближайшую неделю такой: Выгрузить из CRM все сделки без движения дольше нормативного срока по своей же стадии — это делается за один экспорт, без интеграций. Разделить список на две группы: «мёртвые» (нет ответа больше 2-3 месяцев, нет смысла держать в активной статистике) и «живые без ответственного» (клиент отвечал, но никто не назначен вести дальше). По каждой «живой» сделке назначить конкретного человека с именем и сроком следующего касания — не отделу, а сотруднику. «Мёртвые» сделки вынести в отдельную воронку реактивации, чтобы они перестали искажать общую конверсию отдела. Проверить риск на увольнение и ротацию: у каждого активного клиента должен быть второй контакт, зафиксированный в CRM, а не только в голове одного менеджера. Если база зависших сделок исчисляется сотнями — протестировать автоматическую сортировку промптом выше только на «паузниках», не на активных сделках, и только после того, как критерии оценки объяснены команде. Ничего из этого не требует бюджета на разработку. Первые четыре пункта — это час работы с выгрузкой CRM и здравым смыслом. Автоматизация подключается позже, когда ручной разбор перестаёт помещаться в рабочий день руководителя, а не раньше. Правило простое: сначала находите разрыв руками на одной неделе данных, и только когда он подтверждается системно — из недели в неделю, из месяца в месяц — переводите его в дашборд и промпт, а не наоборот. И назовём вещи именем. Умение удержать заявку на стыке — это управленческий навык, а не черта характера дружной команды. Руководитель, который открывает воронку и за минуту говорит, какие сделки стоят дольше норматива и кто по каждой отвечает, стоит дороже руководителя, который умеет только спросить на планёрке «ну как там продажи». Этому нигде не учили. Осваивать придётся на своей же выгрузке, и лучше сейчас, пока это стоит 9 сделок в месяц, а не годовой воронки. Сделайте это на этой неделе: возьмите все заявки за последние семь дней и найдите те, где нет ни одного контакта с клиентом. Каждая такая строка — оплаченный вами и выброшенный шанс. Как закрыть разрыв так, чтобы он не открывался снова, и поставить автоматический контроль без напоминалок, — механика в бесплатном курсе . Что я понял на своей истории Мы нашли у себя заявки, которые лежали без ответа по три дня, — и это при том, что у нас был регламент «отвечать в течение часа». Регламент был, ответственность размазана: заявка падала в общий пул, каждый думал, что её взял кто-то другой. Починилось не ужесточением, а простой вещью: у каждой заявки с первой секунды есть имя ответственного. Не отдел, не «менеджеры», а конкретный человек, который видит её в своём списке. После этого потери упали до единиц, и никого не пришлось наказывать. Если у вас заявки падают в общий котёл — начните с этого, до всякой автоматизации. Вам это не будет стоить ничего, кроме одного решения.