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

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

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

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

Разбираю, как мы это чинили: без новых систем и без найма, одной перестройкой того, что уже было.

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

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

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

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

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

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

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

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

Что добавили под этап проверки

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

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

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

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

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

Тонкость, которая спасёт вас от споров: клиент должен видеть, что было обещано изначально, а не только то, что стало после сдвигов.

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

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

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

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

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

Автоматические алерты: что это и как их ставить

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

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

Ключевое, что делает алерты рабочими, а не фоновым шумом: сообщение должно требовать действия, а не сообщать факт. «Заказ №142 стоит в сборке 6 дней при нормативе 3 — что делаем?» работает. «Просрочено заказов: 7» не работает, потому что непонятно, чьё это и что с этим делать.

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

Посмотрите свой типовой договор: там вообще указан срок и что происходит при его сдвиге? У половины компаний это формулировка ни о чём.

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

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

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

Что происходит, когда данные живут в головах

Ваш риск здесь не в потере файлов, а в том, что статус заказа знает только один человек — и он в отпуске.

Ещё один источник просрочек — не процесс, а место, где хранятся данные. В одном случае новый сотрудник вообще не работал в 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 и текстом ошибки, карточка помечается на ручную обработку. Никакой сделки, которая должна получить статус, нельзя оставлять «зависшей» без сигнала о том, что автоматика не сработала — иначе получаем ту же тишину, из-за которой директор узнаёт о срыве от клиента.

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

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

Настройка обязательных полей, автозадачи и вебхука с классификатором занимает около 18-25 часов работы специалиста (18 000-25 000 ₽ по ставке ~1 000 ₽/час), а снимает с менеджеров и контроля качества около 5 часов ручного разбора в месяц (≈5 000 ₽/мес) — при этом остаётся частью защиты от риска потери сделок, который оценивается в 360 000 ₽/мес (оценка, верхняя граница).

Разложим на цифрах. Отдел из 8 менеджеров держит одновременно около 75 сделок в работе (чек 180 тыс. ₽, цикл 6 недель). Без автоматической фиксации на одном этапе без движения зависает около 10% портфеля — это 8 сделок. Не каждая зависшая сделка теряется: часть просто задерживается. Но по опыту похожих ситуаций около четверти из зависших (2 сделки из 8, консервативно) реально уходит в отказ или требует полного пересбора документов. При чеке 180 тыс. ₽ это риск на уровне 360 000 ₽/мес (оценка, верхняя граница — реальные потери могут быть ниже, если часть дел просто задерживается, а не теряется безвозвратно).

Теперь стоимость ручной альтернативы. Через стадию «проверка/согласование не пройдено» в месяц проходит порядка 20 сделок (около 40% от 50 закрываемых в месяц — нормальная доля для услуг с проверками на входе). Если на разбор причины и уточнение статуса у каждой уходит около 15 минут (оценка), это 5 часов в месяц, или 5 000 ₽ по ставке 1 000 ₽/час менеджера. Именно эти 5 часов автоматика снимает напрямую — это единственный по-настоящему денежный поток-эффект классификатора.

При затратах на внедрение 18 000-25 000 ₽ и экономии 5 000 ₽/мес окупаемость по времени разбора — 4-5 месяцев. Это честная цифра для отдела такого масштаба, а не мгновенная отбивка. Риск в 360 000 ₽/мес снижает не классификатор сам по себе, а вся связка целиком — договор со сроком, обязательное поле, автозадача и контроль качества; вклад именно ИИ-классификатора в этом риске отдельно от прочих мер выделить нельзя. Что не считаем эффектом: если высвобожденные 5 часов менеджера и контроля качества не сокращают штат и не увеличивают продажи, а просто перетекают на другую рутину — это не денежный эффект, а перераспределение нагрузки на бумаге.

Эксплуатация классификатора на объём около 20 вызовов в месяц с короткими текстами (комментарий менеджера на 1-2 предложения плюс промпт на пару абзацев — порядка 200-300 токенов на вызов) при тарифах дешёвых моделей обходится в 100-300 ₽/мес — счёт идёт на рубли, а не на тысячи, если не гонять через неё документы целиком.

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

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

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

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

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

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

Как поставить контроль сроков, который предупреждает заранее, — механика в бесплатном курсе для руководителей.

Что я понял про сроки

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

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

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

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

Что такое контроль сроков с автоматическими алертами?

Это когда система сама считает дни на каждом этапе и при превышении норматива отправляет сообщение ответственному, а не ждёт, пока кто-то откроет отчёт. Алерт должен требовать действия: «заказ стоит 6 дней при нормативе 3 — что делаем?», а не сообщать факт.

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

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

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

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

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

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

Контроль сроков выполнения — это то же самое, что контроль сроков годности или сроки проведения проверок?

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

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