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

Сделка на 5,6 млн сорвалась за сутки: что не так со сделками в CRM

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

Крупный контракт на 5,6 млн ₽ — клиенты по рукам ударили в пятницу, обе стороны довольны, координатор уже готовит договор. В понедельник оба клиента звонят и просят паузу «для стратегического решения» и просят не давить. Всё. Сделка стоит в CRM в статусе «переговоры» ещё две недели, потому что никто не поставил задачу на перезвон, а менеджер решил, что «раз просили не давить — подожду сам». Итог: минус 5,6 млн из недельного плана, который и так не выполнялся, — классическая ошибка сделки в CRM, которую никто не заметил вовремя.

У отдела из 8 менеджеров с оборотом около 12 млн ₽ в месяц одна такая сделка — это почти половина месячного оборота, замороженная в статусе, за которым никто не следил. И это не единичный сбой. Это симптом того, что воронка в CRM показывает не текущее состояние сделки, а последнее, что кто-то туда вписал.

Саша не поверил: «Моя таблица меня ни разу не подводила»

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

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

Но потом мы вместе прогнали дашборд по всей активной воронке — не по избранным сделкам, а по всем 120 с лишним записям в pipeline отдела. И нашли сделку, которую Саша лично считал живой и перспективной и был уверен, что держит её на контроле: клиент, статус «в работе», без движения 1,5 года. На деле последний реальный контакт был полтора года назад, а сделка всё это время портила статистику по срокам закрытия и создавала иллюзию активного pipeline.

Саша замолчал. Потом сказал: «Ладно, эту переношу в отдельную воронку». С этого момента спор перешёл в эксперимент.

Что мы изменили: шаги, а не лозунги

1. Развели воронки по типам сделок. Долгоживущие нестандартные случаи (вроде найденной зависшей сделки) вынесли в отдельную воронку с другими нормативами сроков. Иначе они искажают среднюю длительность цикла и путают аналитику по остальным сделкам.
2. Определили нормативы дней на каждую стадию. Взяли фактические сроки успешных сделок за полгода и посчитали медиану по каждой стадии: заявка, встреча, коммерческое, договор, оплата. Это стало базой для светофора.
3. Настроили динамический отчёт, обновляемый ежечасно. Для каждого менеджера: клиент, статус, дата создания сделки, число дней в текущем статусе, светофор (зелёный/жёлтый/красный) по нормативу стадии.
4. Отдельно завели логику для сделок «на паузе». Пауза — это не то же самое, что забытая сделка. Для паузников запустили отдельного ИИ-бота, который анализирует историю переписки и решает, когда и как аккуратно вернуться к клиенту — без давления, с учётом причины паузы.
5. Протестировали бота сначала на паузниках, а не на активных клиентах. Логика простая: если бот ошибётся в тоне или времени касания с клиентом, который и так «спит», риск минимален. На активной сделке цена ошибки выше.

ИИ-конвейер: кто считает дни, а кто пишет клиенту

Здесь два разных ИИ-шага, и намеренно на разных моделях — дорогая модель для генерации текста клиенту не нужна там, где достаточно классификации.

Шаг 1 — дешёвая модель классифицирует причину паузы и тон. Это массовая, простая задача: прочитать историю переписки и выдать структурированный вердикт. Для неё достаточно недорогой модели уровня GPT-4o-mini — она справляется с классификацией на коротких диалогах почти так же хорошо, как дорогая, но кратно дешевле при потоке в сотни сделок в месяц.

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

Верни строго JSON:
{
  "deal_id": "строка из входных данных",
  "pause_reason": "одно из: нужно_время_на_решение | финансовый_вопрос | конкурирующее_предложение | потеря_интереса | внешние_обстоятельства | неясно",
  "client_tone": "одно из: доброжелательный | нейтральный | раздражённый | тревожный",
  "days_since_last_contact": число,
  "recommended_next_touch_days": число,
  "recommended_channel": "звонок | сообщение | email",
  "risk_of_loss": "низкий | средний | высокий"
}

Входные данные:
{{deal_id}}, {{дата_последнего_контакта}}, {{история_переписки_последние_10_сообщений}}

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

{
  "deal_id": "CRM-4821",
  "pause_reason": "нужно_время_на_решение",
  "client_tone": "доброжелательный",
  "days_since_last_contact": 6,
  "recommended_next_touch_days": 3,
  "recommended_channel": "сообщение",
  "risk_of_loss": "средний"
}

Шаг 2 — дорогая модель пишет само сообщение реактивации. Здесь цена ошибки выше: неудачная формулировка может окончательно спугнуть клиента, который и так на паузе. Берём модель уровня GPT-4o и отдаём ей результат шага 1 плюс контекст сделки.

Ты — менеджер по работе с клиентами. Напиши короткое сообщение клиенту, который взял паузу
по причине "{{pause_reason}}", тон клиента "{{client_tone}}".
Правила: без давления, без "напоминаю о сделке", без сроков и дедлайнов.
Цель — мягко возобновить контакт, дать пользу (новость, вопрос, факт по теме сделки),
не просить решения. Максимум 3 предложения.

Контекст сделки: {{краткое_описание_услуги}}, {{имя_клиента}}

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

{
  "message": "Иван, добрый день. Пока вы думаете, нашёл информацию, которая может быть полезна
  для вашего решения — пришлю её отдельно, без привязки к срокам. Как удобнее: сюда или на почту?",
  "channel": "сообщение",
  "requires_manager_review": true
}

Где это крутится: обвязка без магии

Конвейер простой и без самописной инфраструктуры: изменение статуса сделки в Bitrix24 триггерит вебхук → облачная функция забирает историю переписки и метаданные сделки → отправляет запрос на шаг 1 (классификация) → если риск потери «средний» или «высокий», запускает шаг 2 (генерация сообщения) → результат пишется обратно в комментарий к сделке в CRM, а сообщение уходит менеджеру на согласование, не клиенту напрямую.

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

Ошибки сделок в CRM на цифрах: что показал дашборд

Неделя, в которую сорвалась крупная сделка, была показательной сама по себе — без всякого ИИ. План на неделю (в пересчёте на легенду компании) — 3 млн ₽, факт — 2,4 млн ₽, минус 0,6 млн. Закрыто 7 сделок из 16 запланированных.

Пример того, как выглядит дашборд по зависшим сделкам (данные по менеджерам вымышленные, структура рабочая):

Красная строка Игоря — это и есть та самая логика, которая полтора года назад пропустила «мёртвую» сделку Саши. Разница в том, что теперь статус не просто есть в CRM — он сравнивается с нормативом автоматически и подсвечивается без участия человека.

Эксперимент: чем кончился спор с Сашей

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

На диаграмме — доля сделок без движения дольше норматива стадии, до и после месяца работы дашборда и бота реактивации.

Доля сделок без движения дольше норматива стадии от общего pipeline отдела, до и после запуска дашборда и бота реактивации.

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

Экономика: что это стоит и что даёт

Внедрение: вебхук на Bitrix24, облачная функция, две модели, интеграция с CRM — на разовую настройку ушло около 18 часов работы (оценка), это разовые затраты, не абонемент.

Эксплуатация: запросы к дешёвой модели на классификацию идут пачкой по паузникам раз в день, к дорогой — только когда риск потери «средний» или «высокий». По объёму сделок среднего отдела продаж это укладывается в 3-5 тыс. ₽ в месяц на токены (оценка, зависит от объёма переписок).

Эффект от возврата зависших сделок. Отдел из 8 менеджеров, средний чек ~200 тыс. ₽, в pipeline одновременно около 120 сделок. Если 10% из них зависают без движения дольше норматива стадии — это 12 сделок (120 × 10%). По практике, часть из них можно вернуть простым своевременным касанием, часть — нет. Консервативно берём долю возврата 25%: 12 × 25% ≈ 3 сделки в месяц, которые иначе были бы потеряны. Формула: 3 сделки × средний чек 200 тыс. ₽ = 600 тыс. ₽/мес (оценка) — это и есть цифра из шапки статьи.

Эффект от освобождения времени РОПа. Если раньше на ручную сверку таблиц уходило 1,5 часа в день, а в месяце ~20 рабочих дней, формула такая: 1,5 часа × 20 дней = 30 часов в месяц, которые дашборд освобождает. При типовой ставке времени РОПа ~1000 ₽/час (оценка) это даёт 30 часов × 1000 ₽ = 30 тыс. ₽/мес в пересчёте на время (оценка). Это отдельная, более мелкая часть эффекта — она не складывается напрямую с 600 тыс. ₽ выше, а идёт параллельно, потому что первая цифра — про выручку, вторая — про высвобожденное рабочее время.

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

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

• Выгрузите из CRM все активные сделки с датой последнего изменения статуса — посчитайте долю тех, кто без движения дольше 14 дней.
• Найдите вручную минимум одну «мёртвую» сделку, которую ваш РОП или менеджер считает живой, — как правило, она есть.
• Посчитайте медианный срок каждой стадии по успешным сделкам за полгода — это база для нормативов светофора, а не оценка «на глаз».
• Разведите нестандартные долгоживущие случаи в отдельную воронку, чтобы они не портили статистику по остальным.
• Начните тест ИИ-классификации причины паузы на сделках со статусом «пауза», а не на активных — риск ошибки там ниже.
• Настройте алерт (хотя бы в мессенджер) на сделки, ушедшие в «красный» дольше 2 дней подряд — без этого дашборд превращается в ещё один отчёт, который никто не открывает.

Смежная тема, если у вас в принципе не доверяют датам в CRM: разбирал отдельно, откуда берётся сдвиг дат, в статье про то, как Битрикс24 врёт с датами.

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

Почему сделки в CRM не отражают реальное положение дел?

Потому что статус в CRM показывает, где клиент был в момент последнего касания, а не где он сейчас. Без норматива дней на стадию и автоматической подсветки просрочки воронка врёт молча.

С чего начать проверку, если кажется, что сделки в CRM «зависают»?

Выгрузите все сделки без движения дольше 14 дней и посчитайте их долю от общего pipeline. Если больше 8-10% — у вас системная проблема, не единичный случай.

Какие ошибки сделок в CRM встречаются чаще всего?

Три типа: сделка без даты последнего касания, сделка не в той воронке (искажает статистику сроков), и сделка на паузе без зафиксированной причины паузы — именно на ней ИИ-бот реактивации даёт наибольший эффект.

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