директор и машина · производственный цикл · запись № 055 · 28 августа 2026 · Давид Герштейн

Почему согласование договоров стопорится на финальной проверке — и как перестать терять клиентов

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

У нас отдел из 15 менеджеров, оборот около 18 млн ₽ в месяц, средний чек по сопровождению сделки — 150 тысяч ₽. Это значит, что через воронку каждый месяц проходит примерно 120 сделок, и каждая из них проходит через процесс согласования договоров перед подписанием. Часть сделок дополнительно обязана пройти финальную проверку — комплаенс-проверку контрагента на стороне заказчика или банка. Пока эта проверка идёт, сделка живёт своей жизнью в CRM. И вот тут начинается дыра.

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

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

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

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

Неделя 1: диагностика — сколько дел уже потеряно из виду

Прежде чем чинить, подняли карточки сделок за три месяца. Картина оказалась хуже, чем думали. У части сделок дата плановой проверки стояла в прошлом, а сама сделка всё ещё висела на этапе «ожидание проверки» — то есть либо проверка не проводилась, либо результат никто не внёс. Это тот же класс сбоя, что мы разбирали в материале про то, как Битрикс24 сам сдвигает даты сделок: система не спорит с пользователем, если её об этом не попросили. Причина отказа, если её вообще писали, лежала свободным текстом в общем поле комментария — что-то вроде «не прошло, документов не хватило» вперемешку с другими заметками по сделке.

Отдельно нашли соседнюю проблему на более раннем этапе цикла — «ожидание документов от клиента»: там скопилось 26–27 просроченных дел одновременно. Причина оказалась не техническая, а человеческая: менеджеры на продаже говорили клиентам, что спешить не нужно, можно прислать документы когда удобно. Это тот же класс проблемы — процесс не давит на дедлайн, пока кто-то не заставит систему это делать. Мы решили не чинить это отдельно, а сразу закладывать дедлайны и жёсткую фиксацию статуса во весь цикл согласования, а не только в точку финальной проверки.

Неделя 2: первое решение — и что сразу сломалось

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

На бумаге это закрывало всю дыру. На практике за первую неделю сломалось две вещи. Первое: менеджеры по привычке продолжали писать причину в старое общее поле комментария — новое обязательное поле физически существовало, но не было частью их рабочего маршрута, они его просто не видели. Мы уже сталкивались с похожей инерцией, когда разбирали, почему менеджеры не вносят данные в CRM, и решили не повторять ошибку уговоров, а сразу менять архитектуру полей. Второе: даже когда кто-то нажимал «не пройдена», сделка не откатывалась сама — это по-прежнему было ручным действием. То есть мы автоматизировали фиксацию факта, но не автоматизировали следствие. Менеджер видел на экране «не пройдена», разводил руками и всё равно тратил 20–30 минут (оценка) на ручной перенос сделки и повторную настройку задач — то есть время почти не сократилось по сравнению с полностью ручным процессом (≈35 минут на случай, оценка, — из расчёта в разделе про экономику ниже).

Неделя 3: ИИ-связка — автоматический откат и разбор причины

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

Схема конвейера: смена поля «Результат проверки» в сделке → триггер вебхука → сценарий в n8n на нашем сервере → вызов дешёвой модели для классификации комментария → запись категории обратно в сделку через REST API Bitrix24 → если сделка не сдвинута автоматом за час — сообщение в Telegram ответственному разработчику.

Для классификации причины отказа модель не нужна дорогая — задача короткая, закрытый список вариантов, риск ошибки невысокий, а объём — до 12 сделок в месяц с отказом. Взяли модель уровня Haiku / GPT-4o-mini.

Ты — классификатор причин отказа в комплаенс-проверке контрагента.
На входе — комментарий менеджера о результате проверки.
Определи одну категорию из списка:
- nedostatok_dokumentov
- risk_po_kontragentu
- nesootvetstvie_dannyh
- drugoe

Если категория не ясна из текста — ставь drugoe и needs_manual_review = true.

Входные данные (JSON):
{
  "deal_id": "48213",
  "stage_before": "proverka",
  "comment": "клиент не донёс справку из банка, комплект неполный, ждём ещё документ"
}

Верни строго JSON без пояснений:
{
  "deal_id": "...",
  "reason_category": "...",
  "confidence": 0.0-1.0,
  "needs_manual_review": true/false,
  "suggested_next_stage": "povtornaya_podgotovka" | "otkaz_klienta"
}

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

{
  "deal_id": "48213",
  "reason_category": "nedostatok_dokumentov",
  "confidence": 0.91,
  "needs_manual_review": false,
  "suggested_next_stage": "povtornaya_podgotovka"
}

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

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

Правило: economy → "инструктаж по подготовке пакета документов";
premium → "полное сопровождение подготовки пакета документов".

Входные данные (JSON):
{
  "deal_id": "48219",
  "package": "economy",
  "contract_text_excerpt": "...Исполнитель осуществляет полное сопровождение подготовки пакета документов Заказчика..."
}

Верни JSON:
{
  "deal_id": "...",
  "package": "...",
  "mismatch_found": true/false,
  "expected_clause": "...",
  "found_clause": "..."
}

{
  "deal_id": "48219",
  "package": "economy",
  "mismatch_found": true,
  "expected_clause": "инструктаж по подготовке пакета документов",
  "found_clause": "полное сопровождение подготовки пакета документов"
}

Инженерная обвязка: все вызовы модели логируются в отдельную Google-таблицу — какая сделка, какой промпт, какой ответ, сколько токенов — по той же схеме, что мы уже обкатали на другой задаче с логированием обработки резюме через прокси-сервис. Отдельно подняли MCP-сервер поверх базы CRM: он даёт модели прямой безопасный доступ к нужным полям сделки без выгрузки лишнего контекста, это снижает расход токенов на 30–40% и уменьшает долю галлюцинаций на классификации. Ошибки — в Telegram-бот на ответственного разработчика, retry — три попытки с очередью, если сервис модели недоступен.

Неделя 4: контроль качества и статусы без напоминалок

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

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

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

На диаграмме ниже — во сколько раз сократилось время на один случай отказа после того, как откат и классификация стали автоматическими.

Среднее время на один случай отказа: ручной откат и поиск зависшей сделки — против автоматического отката с классификацией причины (обе цифры — оценка).

Что осталось нерешённым

Три вещи мы сознательно не стали закрывать в этом же спринте. Первое — шаблоны договоров по-прежнему актуализирует юрист вручную в облачном хранилище, автоматической проверки версии (не устарел ли шаблон, из которого собран конкретный договор) пока нет. Это уже аукнулось на смежном участке: часть клиентов получила документы по старому шаблону, не соответствующему новым требованиям к комплекту, и застряла на этапе финальной проверки. По месяцам это выглядело неровно: например, около 76 случаев в одном месяце, 8 в следующем и 47 — за одну только первую неделю ещё одного месяца, но на пике масштаб доходил до 100–150 дел в месяц. Чинили точечно, руками, ответственный сотрудник лично отслеживал версии шаблонов.

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

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

При обороте 18 млн ₽/мес и среднем чеке 150 тыс. ₽ через воронку проходит около 120 сделок в месяц (18 000 000 ₽ ÷ 150 000 ₽ = 120). По нашей оценке, порядка 10% сделок в моменте виснут без движения дольше нормы на любом из этапов согласования — это 120 × 0,10 = 12 сделок в месяц. Из них до автоматизации примерно половина (оценка) реально срывалась из-за забытого статуса или потерянного контакта с клиентом, а не из-за объективного отказа — то есть 12 × 0,5 = 6 сделок в месяц, или 6 × 150 000 ₽ = 900 000 ₽ выручки под риском (оценка).

Экономия времени отдельно от снятого риска: до автоматизации ручной откат и поиск зависших дел занимал у менеджера и контролёра качества суммарно около 35 минут на каждый случай отказа; после — около 3 минут (проверка, что вебхук отработал корректно, и в редких случаях — разбор карточек с needs_manual_review). Разница — 32 минуты на случай. При 12 случаях отказа в месяц: 32 мин × 12 = 384 минуты = 6,4 часа работы отдела в месяц. По ставке 1000 ₽/час (оценка, усреднённая для менеджера и контролёра качества) это 6,4 × 1000 ≈ 6 400 ₽/мес прямой экономии времени.

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

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

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

Почему согласование договоров тормозит именно на финальной проверке?

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

Что делать, если менеджеры забывают откатывать сделку после отказа?

Убрать ручной откат из процесса вообще: сделать выбор «пройдена / не пройдена» обязательным полем задачи, а откат сделки — автоматическим действием CRM, а не памятью человека.

Какая модель ИИ нужна для классификации причин отказа в договорах?

Для короткой классификации по 4 категориям хватает дешёвой модели уровня Haiku или GPT-4o-mini; для сверки текста договора с условной логикой пакета лучше брать модель уровня Sonnet.

#автоматизация #контроль и надёжность #деньги