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

Сроки выполнения заказов: как перестать узнавать о срыве от клиента

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

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

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

Почему директор узнаёт о срыве от клиента, а не от системы

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

Дело не в CRM. Статус там — это то, что менеджер отметил в последний раз, а не сигнал о том, что дело зависло. Разбор с консульскими проверками показал то же самое: система вообще не фиксировала случаи неуспешной проверки. Менеджер вручную откатывал сделку назад и должен был удалить дату проверки — и часто забывал это делать. Тогда в отчётах числилась проверка, которой не было, а реальный срок молчаливо съезжал.

Что добавили под консульские проверки

Решение получилось не про интерфейс, а про обязательные поля и таймер:

• отдельное поле даты неуспешной проверки — не путается с датой планируемой;
• обязательная причина отказа с выбором из списка (документы, судимость, другое) — без свободного текста, который никто потом не читает;
• автоматическая задача менеджеру ровно в день проверки с двумя вариантами ответа: пройдена / не пройдена;
• уведомление контролю качества, если сделка не перемещена на новый этап в установленный срок.

Последний пункт — самый важный. Не начальнику менеджера, а именно контролю качества, отдельному от продаж человеку. Это разрывает зависимость контроля от того, кто заинтересован в красивой отчётности.

Статусы заказов для клиентов: зачем нужен снимок, а не текущее значение

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

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

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

На диаграмме — клиенты, получившие документы по устаревшему шаблону, по месяцам. Провал в апреле — не решение проблемы, а просто меньше поданных дел в этом месяце: сама причина (несинхронизированное изменение требований) устранена не была, поэтому в мае объём снова вырос.

Про то, как CRM вообще может искажать даты и вводить в заблуждение при построении отчётов, у меня был отдельный разбор — CRM врёт. Как я поймал Битрикс24 на сдвиге дат. Если статусы «сами меняются» без видимой причины, начинать нужно оттуда.

Договор — первая линия контроля сроков выполнения заказов

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

Решение простое на бумаге: внести в регламент требование прописывать сроки для стандартных работ. Для специальных, нетиповых видов работ срок сознательно опускается — не нужно натягивать обязательство там, где реальная зависимость от третьей стороны (например, ожидание внешнего документа около пяти месяцев) делает жёсткий срок бессмысленным и даже опасным для компании.

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

Что происходит без централизованного хранилища данных

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

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

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

ИИ-связка: как автоматически классифицировать причину просрочки

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

Конвейер выглядит так:

1. Bitrix24: смена стадии сделки → вебхук уходит во внешний обработчик.
2. Облачная функция передаёт комментарий менеджера в дешёвую модель для классификации.
3. Модель возвращает категорию и дату повтора — функция записывает их обратно через REST API.
4. Каждый шаг логируется; при сбое — алерт в Google Sheets и чат контроля качества.

Шаг 1: в Bitrix24 настраивается автоматизация — при переводе сделки на стадию «проверка не пройдена» вебхук отправляет во внешний обработчик JSON с данными сделки и комментарием менеджера. Пример того, что летит на вход:

{
  "deal_id": 48213,
  "stage_from": "Проверка назначена",
  "stage_to": "Проверка не пройдена",
  "manager_comment": "Клиент не смог, сказали не хватает одной бумаги про судимость, принесёт через месяц",
  "planned_check_date": "2026-07-14"
}

Шаг 2: этот JSON вместе с промптом уходит в дешёвую модель (GPT-4o-mini или Claude Haiku — задача простая: классификация короткого текста по фиксированному списку, дорогая модель здесь избыточна и просто дороже на объёме в сотню кейсов в месяц). Промпт:

Ты — классификатор причин отказа в проверке для CRM отдела контроля качества.

На входе — комментарий менеджера о причине непрохождения проверки клиентом.
Классифицируй причину строго по одной из категорий:
- "документы" — не хватает документа, ошибка в документе, документ просрочен
- "судимость" — судимость или родственные основания для отказа
- "днк" — вопросы по ДНК-экспертизе или родству
- "другое" — причина не попадает в перечисленные категории

Также извлеки предполагаемую дату повторной попытки, если она упомянута
в тексте (в формате YYYY-MM-DD). Если дата не указана — верни null.

Комментарий менеджера: "{{manager_comment}}"
Плановая дата проверки: {{planned_check_date}}

Ответь строго в формате JSON без пояснений:
{
  "category": "...",
  "retry_date": "YYYY-MM-DD или null",
  "confidence": 0.0-1.0
}

Пример ответа модели на вход выше:

{
  "category": "документы",
  "retry_date": "2026-08-14",
  "confidence": 0.86
}

Шаг 3: облачная функция берёт этот JSON и через метод crm.deal.update REST API Bitrix24 записывает категорию в обязательное поле причины отказа, а дату повторной попытки — в отдельное поле для следующей автозадачи менеджеру. Если confidence ниже 0.6 — категория не проставляется автоматически, а карточка помечается флагом «проверить вручную»: дешёвая модель не должна тихо ошибаться там, где сомневается сама.

Инженерная обвязка

Логика крутится не «где-то в облаке абстрактно», а на конкретном стеке: вебхук Bitrix24 → серверлес-функция (можно на n8n или Google Cloud Functions) → вызов API модели → запись обратно через REST API CRM. Всё, что происходит на каждом шаге, дублируется строкой в общую Google-таблицу: время вызова, deal_id, что отправили, что получили, статус (успех/ошибка/низкая уверенность). Это тот же принцип, что уже отрабатывали на похожей задаче с обработкой резюме через API — тогда разработчик не видел баланс своей учётной записи и не мог поймать ошибку, пока не появился общий лог всех вызовов. Здесь ошибка та же по природе: без построчного лога руководитель не узнает, что классификатор неделю падал по таймауту, пока кто-то не заметит пустые поля причины отказа у полусотни карточек.

Перезапуск — простой ретрай с экспоненциальной задержкой на 2-3 попытки; если все три упали — в чат контролю качества уходит уведомление с deal_id и текстом ошибки, карточка помечается на ручную обработку. Никакой сделки, которая должна получить статус, нельзя оставлять «зависшей» без сигнала о том, что автоматика не сработала — иначе получаем ту же тишину, из-за которой директор узнаёт о срыве от клиента.

Экономика контроля сроков: сколько стоит внедрение и когда окупается

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

Не каждое зависшее дело теряется — часть просто задерживается. Но по опыту с похожими просрочками часть таких дел (условно 25-30%, оценка) действительно уходит в отказ или требует полного пересбора документов заново: это несколько дел в месяц под риском срыва. При среднем чеке одного комплексного дела, заметном для месячного оборота отдела (цифра из фактуры), риск сопоставим с потерей нескольких полноценных сделок ежемесячно (оценка, верхняя граница потенциальных потерь на условном примере — реальная доля срывов может быть ниже, если часть дел просто задерживается, а не теряется безвозвратно).

Теперь стоимость ручной альтернативы — того, что менеджер и контроль качества делают руками вместо автоматики. На поток сотня-полторы кейсов в месяц, если на каждый уходит около 15 минут ручного разбора причины и уточнения статуса (оценка), это несколько десятков часов в месяц — примерно 3-5 рабочих дней одного сотрудника, которые высвобождаются при внедрении автоклассификации и автозадач.

Стоимость внедрения: настройка обязательных полей, автозадачи по проверке и вебхука с классификатором — в среднем 15-20 часов работы разработчика или интегратора (оценка) на разовую настройку, то есть 2-3 рабочих дня одного специалиста. Плюс тестовый прогон на десятке-полутора полных кейсов для проверки промпта — так же делали при сверке нескольких моделей на одном наборе консультаций — это ещё несколько часов, меньше рабочего дня. Итого разовое внедрение — порядка 18-25 часов работы специалиста (оценка), то есть чуть больше половины рабочей недели.

При экономии в несколько десятков часов в месяц на ручном разборе (3-5 рабочих дней специалиста) внедрение, требующее 18-25 часов разовой настройки, окупается уже в первый-второй месяц эксплуатации (оценка, без учёта риска срыва сделок, который посчитан отдельно выше как верхняя граница потерь, а не гарантированная экономия). Эксплуатация дешёвой модели на объём сотня-полторы классификаций в месяц с короткими текстами (комментарий менеджера на 1-2 предложения плюс промпт на пару абзацев — это порядка 100-300 токенов на один вызов) при тарифах GPT-4o-mini или Claude Haiku обходится в скромную сумму в месяц (оценка) — счёт идёт на рубли, а не на тысячи, если не гонять через неё документы целиком. Общую картину по счетам за ИИ-инструменты в масштабе всей компании, а не одного процесса, я разбирал отдельно в статье Сколько на самом деле стоит ИИ в месяц.

Так эти цифры будут выглядеть на экране отчёта, который стоит собрать перед внедрением:

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

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

• Выгрузить из CRM все сделки, которые не меняли статус дольше двух недель, и посчитать долю от общего активного портфеля — это ваша реальная цифра вместо оценки из этой статьи.
• Проверить 10 случайных договоров за последний месяц на предмет прописанного срока выполнения для стандартных работ. Если срока нет — это первая правка в регламент, дешевле любой автоматизации.
• Сделать причину отказа/просрочки обязательным полем с фиксированным списком значений вместо свободного текста — хотя бы вручную, без интеграции с моделью.
• Настроить один автоматический снимок статуса раз в неделю в отдельный столбец (можно начать с Google Sheets и ручного экспорта, не обязательно сразу вебхук).
• Назначить, кто получает уведомление о просрочке этапа — не непосредственный руководитель менеджера, а независимый контроль качества.
• Если решите автоматизировать классификацию причин — начните с 10-15 реальных кейсов и дешёвой модели, проверяя результат вручную, прежде чем доверять полю в CRM.

FAQ по контролю сроков заказов

Как вести статусы заказов для клиентов, чтобы директор не звонил каждому менеджеру?
Фиксировать статус автоматически по расписанию — например, раз в неделю — в отдельный столбец CRM, без ручного ввода менеджером. Тогда картина не зависит от того, вспомнил он или нет.

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

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

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

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

Как вести статусы заказов для клиентов, чтобы директор не звонил каждому менеджеру?

Фиксировать статус автоматически по расписанию — например, раз в неделю — в отдельный столбец CRM, без ручного ввода менеджером. Тогда картина не зависит от того, вспомнил он или нет.

Что делать с просроченными заказами, если их накопилось много?

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

Нужен ли срок в каждом договоре?

Для стандартных работ — да, обязательно, иначе не с чем сравнивать при расчёте просрочки. Для нетиповых работ или зависящих от третьей стороны срок стоит явно исключать из ответственности компании, а не молчать о нём.

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