директор и машина · продажи · запись № 030 · 5 августа 2026 · Давид Герштейн

Контроль работы менеджера в CRM — дашборд вместо штрафов и пустых карточек

Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные.

Если ваши менеджеры не ведут CRM — не спешите вводить штрафы. Сначала ответьте себе на неудобный вопрос: а что менеджер получает от того, что заполнил карточку?

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

За одну неделю условный отдел производственной компании недосчитался 200 000 ₽ выручки — план по деньгам выполнили лишь на четыре пятых. При плановой недельной выручке в 1 000 000 ₽ факт составил 800 000 ₽. Закрыли 7 сделок из 16 запланированных. Причина не в том, что менеджеры плохо разговаривали — во встречу конвертировалось 55% лидов (49 встреч), это нормальный показатель. Провал случился на следующем шаге: из встречи в договор дошло только 22% — притом что для выхода на плановую конверсию лид → продажа в 23% нужна была совсем другая цифра на этом шаге. При этом средний чек по факту оказался выше плана — 13,5% против плановых 10% — то есть часть провала по количеству сделок частично компенсировалась более крупными контрактами, но разрыв в выручке это не закрыло. Корень проблемы окажется банальным: менеджеры не вносят данные в CRM вовремя, и часть воронки просто исчезает из поля зрения.

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

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

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

Почему менеджеры не вносят данные в CRM

Три причины, и ни одна из них не про лень ваших людей.

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

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

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

Зависшие сделки: где в мёртвых карточках ваши деньги

Посмотрите свои карточки без движения за месяц — обычно там лежит выручка размером с неплохую неделю.

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

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

Ещё нагляднее — история с реанимацией старых отказников. Компания подняла базу клиентов, отказавших менеджерам семь лет назад: не готовы платить, не готовы разговаривать, заявку так и не оставили. Все они когда-то брали трубку — просто работали с менеджерами низкой квалификации. В марте эти же люди вернулись и купили на 500 000 ₽ — это ощутимая часть месячного оборота условного отдела в 4 000 000 ₽. Зависшая сделка — не всегда мёртвый груз. Иногда это отложенные деньги, которые CRM не помогает найти, потому что никто не открывает старые статусы.

Прежде чем гоняться за виновными в незаполненной CRM, стоит проверить саму систему на честность: я разбирал отдельно, как Битрикс24 может физически сдвигать даты и путать статусы. Метод сверки по ID оттуда применим и здесь — часть «зависших» сделок при ближайшем разборе оказывается ошибкой синхронизации, а не бездействием менеджера.

Контроль работы менеджера: что реально показывает ваша воронка

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

Возвращаясь к неделе с провалом плана на 200 000 ₽: цифры сами показали, где именно течёт воронка. Дело не в команде в целом — дело в одном конкретном шаге: встречи назначаются нормально (55%), но до договора доходит только 22%. На диаграмме — конверсия по каждому шагу воронки в сравнении с плановой конверсией лид → продажа. Руководитель отдела не скрывал тревоги: «конверсия очень низкая в продажу... мне становится страшно, я начинаю переживать конкретно». Честная реакция на цифры полезнее общих слов про эффективность.

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

Дашборд вместо репрессий

Ваша цель — сделать так, чтобы менеджеру было выгодно вести карточку, а не страшно её не вести. Разница в результате огромная.

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

В нескольких компаниях, где я наблюдал эту задачу, решение выглядело похоже. Один дашборд отслеживал pipeline по каждому менеджеру, конверсию договоров в оплату, дату последнего контакта с клиентом и источник сделки — с детализацией по месяцам, чтобы видеть заброшенные сделки без единого касания. Второй пошёл дальше: динамический отчёт по воронке, обновляемый ежечасно, с индикатором-светофором на каждой сделке — зелёный, жёлтый, красный — на основе нормативных сроков по стадиям. Не «сколько дней клиент висит вообще», а «сколько дней он висит сверх нормы для этой стадии конкретно».

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

Логика всех решений одна, и один из руководителей сформулировал её коротко: «чем мне создавать два отчёта? Мне проще создать один». Разрозненные таблицы плодят пустые поля в CRM, потому что менеджеру физически неудобно вносить одно и то же в три места. Единый портал с данными по источникам, пайплайну и оплатам снимает барьер механически — не мотивацией, а конструкцией системы.

ИИ-связка: подсветка причины зависания

Здесь вы получаете то, чего не даст ни один отчёт: не факт «сделка стоит», а причину — что было последним касанием, чего ждёт клиент, писал ли ему кто-нибудь вообще.

Ручной светофор по срокам решает половину задачи — он показывает, ЧТО зависло. Не показывает, ПОЧЕМУ. На потоке в несколько сотен активных сделок в месяц у РОПа физически нет времени открывать каждую просроченную карточку и читать историю переписки. Здесь встраивается модель — не вместо человека, а как первый фильтр, который сортирует зависшие сделки по вероятной причине, прежде чем к ним прикоснётся менеджер.

Схема конвейера: Bitrix24 (событие ONCRMDEALUPDATE при смене стадии) → облачная функция вычисляет «дней в стадии» и сверяет с нормативом из таблицы Google Sheets → если превышение — тело сделки уходит в дешёвую модель на классификацию → ответ модели записывается обратно в кастомные поля сделки через REST API → РОП видит готовую метку в дашборде, а не сырую историю переписки.

Модель здесь нужна дешёвая (уровня GPT-4o-mini или аналог), не топовая: задача — классификация по короткому списку причин плюс черновик из 2–3 предложений, объём — сотни сделок в месяц. Дорогая модель на этом шаге — переплата без прироста качества: разница в точности классификации причины паузы для топовой и лёгкой модели на таком объёме текста практически не ощущается.

Пример входных данных, которые уходят в модель (структура из Bitrix24-вебхука):

Ты — ассистент отдела продаж. На входе — данные по сделке CRM в JSON.
Определи вероятную причину остановки сделки строго из списка:
["не готов платить", "ждёт внутреннего решения", "потерял интерес",
"менеджер не дожал", "техническая пауза / не по вине клиента"].

Входные данные:
{
  "deal_id": 48213,
  "stage": "Переговоры",
  "days_in_stage": 47,
  "norm_days_for_stage": 10,
  "last_contact_date": "2026-03-02",
  "comments_tail": "Клиент попросил паузу для внутреннего решения. Ждём подтверждение бюджета."
}

Оцени уверенность (0–1). Предложи тон следующего касания
(деловой / тёплый / нейтральный) и короткий черновик сообщения
на 2–3 предложения без давления и без прямого "купите".
Ответ верни строго в JSON с полями:
reason, confidence, tone, recommended_action, message_draft.
Если не можешь определить причину с уверенностью выше 0.4 —
верни reason: "не определено" и confidence как есть, без домыслов.

Пример ответа модели:

{
  "reason": "ждёт внутреннего решения",
  "confidence": 0.78,
  "tone": "нейтральный, без давления",
  "recommended_action": "напомнить через 5 дней, не звонить раньше",
  "message_draft": "Понимаю, что решение требует времени внутри вашей команды. Если появятся вопросы по цифрам — пришлю их отдельно, чтобы не тратить ваше время на звонок."
}

Инженерная обвязка: функция крутится на облачном сервере по расписанию раз в час плюс по вебхуку при смене стадии. Нормативы сроков хранятся в отдельной 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 — просто по другим причинам.

Применительно к нашей задаче: автоматическая классификация причины зависания снимает часть ручной работы с РОПа, но кто-то обязан раз в неделю проверять, что модель классифицирует верно. Иначе зависшая сделка получит автоматическую метку «ждёт решения» вместо реального «менеджер забыл позвонить» — и станет ещё незаметнее, чем была без всякой автоматизации.

И вот что здесь стоит назвать вслух. Умение построить контур, в котором данные появляются сами — норматив по стадии, светофор, пятнадцатиминутный разбор только красных сделок, — это отдельный управленческий навык, а не работа айтишника. Руководитель, который умеет собрать такой контур, стоит дороже руководителя, который умеет только требовать заполнять карточки. Я сам шёл к этому годами: сначала делал красивые отчёты, которые никто не открывал, и злился на людей вместо того, чтобы чинить конструкцию.

Чек-лист: с чего начать в понедельник

Если на всё остальное нет времени — сделайте сегодня три вещи:

1. Выгрузить из CRM список сделок без движения дольше 14 дней без комментария — это временный норматив, пока нет своего.
2. Разослать менеджерам письменный список критериев, по которым оцениваются их звонки и сделки, — до включения любого автоматического контроля.
3. Договориться с РОПом о еженедельном 15-минутном разборе только красных (просроченных) сделок — не всей воронки целиком.

Остальное — по мере появления времени в течение недели:

• Добавить в таблицу или дашборд две колонки: «дней в текущей стадии» и «дата последнего контакта» — это можно сделать за один день в Google Таблице, не дожидаясь интеграции.
• Вручную проверить 5–10 «зависших» сделок: клиент правда неактивен или это ошибка внесения данных, как в разборе про CRM, которая врёт.
• Если планируете тестировать ИИ-классификацию причин, начните с сегмента «холодных» или паузных сделок, где риск минимален, прежде чем выкатывать на всю базу.
• Считать порог для вызова интегратора по конкретным цифрам, а не «на глазок»: если зависших сделок сверх нормы больше 10% пайплайна, если ручной разбор воронки у РОПа занимает больше 5 часов в неделю, или если поток сделок превышает 100 в месяц — это тот объём, где Google-таблица с ручным обновлением перестаёт справляться и нужен вебхук.
• Если своими силами за 2–3 недели не удалось: настроить вебхук на смену стадии в CRM, договориться с РОПом о нормативах по каждой стадии воронки, или найти в CRM поле, где физически хранится дата последнего контакта, — это сигнал звать интегратора или вендора CRM. Самодельная Google-таблица с ручным обновлением решает диагностику, но не автоматизацию; для конвейера с вебхуком и записью результата обратно в кастомные поля сделки нужен человек, который хотя бы раз настраивал такую интеграцию. Найти его дешевле, чем полгода терпеть пустые карточки CRM и объяснять на планёрках, куда делась выручка.

Что сделать вам на этой неделе: спросите двух менеджеров, что им даёт заполненная карточка. Ответ определит, с чего начинать — с правил, с обучения или с того, чтобы убрать из CRM половину полей, которые никому не нужны.

Как выстроить это так, чтобы данные появлялись сами, а не «по требованию», — в бесплатном курсе.

Частые вопросы

CRM не ведётся, что делать в первую очередь?

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

Как найти зависшие сделки в CRM?

Строить отчёт с колонкой «дней в статусе сверх нормы» и светофором по нормативным срокам стадии — застрявший клиент виден сразу, без ручного разбора воронки.

Помогает ли увеличение штата менеджеров при плохом контроле?

Нет. В одном случае расширение отдела в два с лишним раза без контроля дало снижение качества работы с лидами; конверсия выросла только после внедрения контроля, и то на 1 п.п. в месяц.

Что делать, если ИИ-классификация причины зависания выдаёт не тот формат ответа?

Строить проверку JSON-схемы на приёме и retry с более жёстким промптом; если после двух попыток схема не сходится — сделке присваивается метка «требует ручного разбора», а не пустое поле, а сам факт повторного сбоя уходит в эскалацию, а не тихо копится в логе.

#ошибки и провалы #аналитика и отчётность #ии и нейросети