# Директор и машина — Производственный цикл: полные тексты (часть 1 из 2)

Направление: Производственный цикл — документы и заявки · клиентский портал · сроки и статусы
Хаб направления: https://davidgerstein.pro/proizvodstvo/
Материалов в файле: 8 из 10 по направлению.
Автор: Давид Герштейн. Цитирование свободное при указании источника.
Суммы пересчитаны на условную компанию: пропорции, механика и выводы реальные, абсолютные величины изменены. «оценка» = расчёт, а не замер.
Оглавление всех частей: https://davidgerstein.pro/llms.txt
Все направления одним файлом: https://davidgerstein.pro/llms-full.txt
Цифры и словарь понятий: https://davidgerstein.pro/cifry/ · машинная копия: https://davidgerstein.pro/cifry.json
Другие части этого направления: https://davidgerstein.pro/llms-proizvodstvo-2.txt

## Личный кабинет на 400 тысячах вопросов: красивый интерфейс без работающей логики
URL: https://davidgerstein.pro/blog/lichnyy-kabinet-klienta/
Дата: 2026-08-29
Направление: Производственный цикл
Цифры: 92 примера на OCR, 27 клиентов в просрочке, 30–40% экономии токенов
Коротко: Личный кабинет клиента ломается не на дизайне, а на стыках данных: документ отмечен «в наличии», но не загружен; проверка провалена, но статус не откатился; портал не пишет в CRM. В клиентском портале компании на 40 человек пять таких разрывов держали 27 клиентов в просрочке одновременно; чинится это сверкой данных, а не переделкой дизайна.

Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Если у вас есть личный кабинет, а клиенты всё равно звонят менеджерам с теми же вопросами — вы платите дважды: за интерфейс и за людей, которых он должен был разгрузить. И дело почти никогда не в дизайне. У нас на столе лежал готовый личный кабинет клиента. База — 400 тысяч вопросов из публичного источника, красивый интерфейс, чат, форма загрузки документов. Разработчик передавал его техническому лиду несколько дней подряд. Система не собиралась. Технический лид сказал фразу, которую я записал дословно: «Получается красивый дом, но дверей нету, как зайти непонятно». Дело было не в коде. Личный кабинет клиента — это стык трёх систем: формы, куда клиент вводит данные, модели, которая их разбирает, и CRM, где живёт сделка. Если стык не проверен, кабинет выглядит рабочим и не работает ни дня. В нашем случае разрыв на одном только этапе «документы запрошены» держал 26–27 клиентов в просрочке одновременно — притом что менеджеры отчитывались, что документы получены. Почему личный кабинет клиента не работает при красивом интерфейсе Потому что интерфейс и логика — разные слои, и проверяют их по-разному. Экран показывают на демонстрации, а данные под ним не сверяет никто. В клиентском портале компании на 40 человек за готовым фасадом лежали пять разрывов логики: документ отмечен «в наличии», но файл не загружен; проверка провалена, но статус не откатился; портал считает рекомендации, но не пишет их в CRM. Эти пять разрывов держали 27 клиентов в просрочке одновременно — притом что менеджеры отчитывались, что всё получено. Первый шаг починки не дизайнерский: выгрузить список документов, отмеченных «в наличии», и сверить с файлами, физически лежащими на сервере. Процент разрыва и есть размер проблемы. До: экран, на который не стыдно позвать инвестора Показать такой кабинет никому не стыдно. Клиент заходит, видит статус заказа, форму загрузки, чат с ответами на частые вопросы — база в тысячи записей закрывала почти любой типовой вопрос без участия менеджера. Сверху — план: обучить алгоритм на 40 живых кейсах, отдать менеджерам на проверку, при подтверждении корректности протестировать на сегменте в 5 000 клиентов и через полгода иметь достаточный массив данных для MVP. План выглядел разумным. Проблема была не в плане, а в том, что данные, которые должны были обучать модель, оказались недостоверными ещё до того, как до модели дошли. Пять поломок логики за красивым фасадом Прежде чем чинить логику, стоит ответить на вопрос, нужен ли вам вообще клиентский портал — там три условия, при которых он окупается. Сверьте со своим кабинетом — эти ошибки повторяются почти в каждом, который я разбирал. Когда мы стали разбирать кабинет по частям, а не смотреть на него целиком, вскрылись пять конкретных разрывов. Первое. Менеджеры отмечали документ «в наличии» в системе, но не загружали файл на сервер. Для клиента и для отчёта менеджера всё выглядело завершённым. Для модели обучения это означало одно: она начинала считать, что проверку можно пройти без документа вообще. Обучающая выборка врала сама себе. Второе. Рекомендации, которые формировал портал после анализа документов, не долетали до CRM автоматически. Собственник обнаружил это случайно, когда сопоставил массив данных портала со списком клиентов, прошедших проверку с первого раза, — и увидел, что связи между двумя базами попросту нет. Третье. Если клиент не проходил внешнюю проверку, система это не фиксировала. Менеджер вручную откатывал сделку назад и должен был удалить дату уже назначенной проверки — и часто забывал это сделать. В CRM оставалась сделка с датой в прошлом и статусом «ожидание», которую никто не видел как проблемную. Четвёртое. OCR-распознавание документов работало отлично внутри самого сервиса модели и разваливалось при вызове через API — повёрнутые документы система не распознавала корректно. Технически это два разных пути обработки одного и того же файла, и никто не тестировал их отдельно. Пятое. Знания о том, как вообще работает кабинет, существовали только в голове разработчика. Ни таблиц, ни регламентов — «падают под запись, под диктофон, и всё». При передаче проекта техническому лиду не оказалось ни одного документа, по которому можно было бы собрать систему заново. Если вы сейчас узнали свой кабинет — выдохните. Я сам собирал его ровно в этом порядке: сначала экран, потом логика, данные в последнюю очередь. Это нормальная последовательность для того, кто делает такое впервые, и на ней спотыкаются все, включая меня. Дорого стоит не то, что вы в неё попали, а то, сколько месяцев вы в ней просидели, не проверив данные. Где ломается. Личный кабинет клиента почти всегда собирают в обратном порядке: сначала интерфейс, потом логика, в последнюю очередь — данные. Красивый экран проходит демонстрацию инвестору и собственнику. Данные, которые он якобы собирает, проверяют только тогда, когда модель начинает откровенно врать. К этому моменту в базе уже месяцы искажённых записей, и их придётся вычищать вручную. Как мы перебирали кабинет по частям Ваш путь будет короче, если начнёте с проверки данных, а не с дизайна. Мы не стали переписывать интерфейс — он был готов. Пересобирали логику по стыкам, в порядке, в котором они ломались чаще всего. Аудит фактических данных. Выгрузили список документов, отмеченных «в наличии», и сверили с файлами, физически лежащими на сервере. Разрыв — процент документов без файла — стал главной метрикой первой недели. Обязательное поле причины отказа. При провале внешней проверки система теперь требует выбрать причину из закрытого списка (недостаток документов, несоответствие данных, иное) и отдельное поле даты неуспешной проверки — отдельное от даты запланированной. Без заполнения сделка не двигается дальше. Автозадача на день проверки. В день назначенной проверки менеджеру автоматически ставится задача с двумя вариантами ответа: пройдена / не пройдена. Если задача не закрыта в срок, уведомление уходит контролю качества, а не остаётся в личных напоминаниях менеджера. Централизация загрузки документов. Вместо разброса по облачным дискам и локальным компьютерам — единая точка загрузки в портале с автоматической сегментацией по типу документа. Многоступенчатый анализ вместо одной модели на всё. Сначала определяется тип документа, затем применяется спецификация под этот тип, при необходимости подключается более мощная модель, финальную проверку всегда делает менеджер. Вебхук из портала в CRM. Рекомендации и статус документа сразу пишутся в карточку клиента — без ручной сверки раз в неделю. На этапе аудита OCR мы не стали гонять всю базу документов через новую логику сразу. Собрали 92 типовых примера, отдали стажёру на ручную проверку результатов и по итогам составили отдельную спецификацию под каждый тип документа — с описанием, что именно сбивает распознавание (чаще всего — вертикальная загрузка и разворот страницы). Похожий путь — от процента ошибок к спецификации по типам — подробно разобран в статье о том, как точность распознавания документов подняли с 59% до 85% . ИИ-связка: конвейер распознавания и рекомендаций Конвейер обработки одного документа выглядит так: загрузка в портал → определение типа документа дешёвой моделью → применение спецификации и OCR → при сложном случае — эскалация на более мощную модель → проверка менеджером → запись в CRM. На диаграмме ниже — относительное время каждого этапа: видно, что три автоматических шага занимают секунды, а «бутылочное горлышко» конвейера — ручная проверка менеджером. Определение типа документа ~2 сек OCR + спецификация по типу ~5 сек Эскалация на мощную модель ~10 сек Проверка менеджером ~3 мин Первый промпт — классификация типа документа и подготовка к OCR. Он должен быть дешёвым: запускается на каждый файл без исключения, поэтому дорогая модель здесь — деньги на ветер. Отправляется через вебхук из Bitrix24 при создании новой записи в разделе документов. Пример ответа модели: Дешёвая модель (условно — Claude Haiku или аналог) достаточно точна для типизации и оценки ориентации. Она не должна принимать решение по существу документа — только маршрутизировать. Второй промпт, для сложных случаев, работает уже на более мощной модели и формирует структурированное описание кейса. Пример ответа модели: Инженерная обвязка. Портал крутится на облачном хранилище с единой точкой загрузки — вместо трёх разрозненных дисков. Все действия конвейера (успешно обработано / ошибка / требует ручной проверки) логируются через прокси-сервис в отдельную таблицу Google Sheets — это дало руководителю видимость того, что раньше видел только разработчик через личный кабинет провайдера модели. Обновление карточки клиента идёт через вебхук в CRM. Для доступа ИИ-инструментов к данным CRM напрямую поднят MCP-сервер поверх базы. Он снижает расход токенов на 30–40% и меньше галлюцинирует — модель получает точный контекст вместо пересказа через промежуточный слой. Подробный разбор счетов за ИИ-инфраструктуру — в статье о реальных расходах на ИИ . После: каким стал личный кабинет клиента Ориентир для вашего кабинета: клиент должен понять статус за секунду и без вопросов к менеджеру. Таблица ниже — сравнение состояния личного кабинета клиента по ключевым узлам логики, до пересборки и после. Узел логики До После Отметка документа «в наличии» Ставится вручную, без проверки файла Невозможна без загруженного файла Фиксация неуспешной проверки Ручной откат, дата часто не удаляется Обязательное поле причины + отдельная дата Уведомление о просрочке Не формируется Автоматически, контролю качества Хранение документов Облачный диск + личный компьютер + мессенджер Единая точка загрузки в портале Связь портал → CRM Отсутствует, сверка вручную раз в неделю Вебхук, обновление в реальном времени OCR повёрнутых документов Не распознаёт Автоматический разворот + спецификация по типу Ниже — то же самое в цифрах: сколько клиентов держало в просрочке узкое место «документы запрошены» до пересборки и сколько остаётся при консервативном сценарии после. 27 в просрочке ≈19 после Оценка, консервативный сценарий: снижение на ~30% за счёт обязательного поля причины отказа, отдельной даты неуспешной проверки и автоматического уведомления контролю качества. Отдельно подчеркну: снижение просрочки в этом узле дало не только исправление личного кабинета. Параллельно в договор внесли срок действия услуги — раньше клиенту говорили «можно начать когда угодно», и он расслаблялся. Это отдельная мера, и её вклад я не смешиваю с пересборкой кабинета: договорный срок сокращает поток новых зависаний, а логика кабинета — снимает потери на уже зависших случаях. Экономика: что стоит пересборка Ваши затраты зависят от того, насколько в порядке данные. Если бардак — считайте вдвое. Возьмём условную сервисную компанию из легенды: отдел из 8 менеджеров, оборот 9 млн ₽ в месяц, средний чек 180 тыс. ₽ — это около 50 сделок в активной работе одновременно (оценка, с учётом цикла сделки ~6 недель). Формула для своего кейса. Риск задержки выручки = доля зависших на этапе документов сделок × количество сделок в работе × средний чек. Потери часов = количество зависших случаев × время ручной обработки одного случая × ставка сотрудника. посчитайте на своих цифрах сделок в активной работе % зависших на этапе документов средний чек, ₽ риск задержки выручки ≈ {X} ₽ в месяц формула: сделки × доля зависших ÷ 100 × средний чек; это оценка риска задержки цикла, а не списанные деньги Если на этапе документов зависает 10% сделок — консервативная оценка по нашей практике — это 5 сделок, «замороженных» без движения: 10% × 50 = 5. В деньгах это риск задержки выручки на уровне 5 × 180 000 ₽ = 900 000 ₽ в месяц (оценка, не потеря — именно риск задержки цикла, а не списанные деньги). Ручная обработка каждого такого зависшего случая — поиск причины, откат сделки, повторный запрос документов — занимает у менеджера примерно 1,5 часа (оценка). При 5 случаях это 5 × 1,5 = 7,5 часа в месяц. По ставке 1 000 ₽/час (оценка, линейная ставка менеджера) — 7,5 × 1 000 = 7 500 ₽/мес прямых часов, которые автоматический откат и обязательное поле причины отказа возвращают менеджерам на продажи. Стоимость внедрения: доработка полей CRM, автозадач и вебхука — это разовые часы разработчика, по нашей оценке 40–60 часов. По ставке разработчика 2 000 ₽/час (оценка) — 80 000–120 000 ₽ разово. Настройка спецификаций OCR под 92 примера документов — ещё 15–20 часов стажёра и разработчика совместно. Если считать окупаемость только по возврату часов менеджеров, разовые ~100 000 ₽ (среднее по вилке) окупаются за 100 000 ₽ ÷ 7 500 ₽/мес ≈ 13,3 месяца (оценка) — и это без учёта риска задержки выручки. На деле экономика доработки держится не на часах, а именно на разморозке зависших сделок: если логика снимает даже треть зависаний (5 → 3, оценка), это 2 сделки × 180 000 ₽ = 360 000 ₽ оборота, разблокированного за один месяц — тогда доработка окупается практически сразу, в пределах одного цикла сделки (~6 недель). Разница между двумя оценками — это разница между «часы менеджеров» и «скорость движения денег», и на своём кейсе стоит считать оба слоя отдельно, не складывая их в одну цифру. Эксплуатация: расход на модели в конвейере распознавания и MCP-сервер — это регулярная статья, которую стоит считать отдельно от разовой доработки; ориентиры по счетам за ИИ — в статье про реальные расходы, ссылка выше. Риск, о котором забывают: история вне портала Проверьте у себя: если клиент написал в мессенджер, а не в кабинет, эта переписка попадёт в его историю? Обычно нет — и вы теряете половину контекста. Второй риск. Пока личный кабинет не был единственной точкой хранения документов, у нас был сотрудник, который вёл клиентов через переписки и локальные папки, не имея доступа в CRM. При передаче его дел выяснилось, что часть истории работы попросту не восстановить — она существовала только в его почте. Централизованный портал решает это только если доступ в него обязателен для всех, кто касается клиента, без исключений «пока разберёмся». Ваш чек-лист на понедельник Прежде чем к нему перейти — про то, чему здесь придётся научиться. Умение сказать «покажите мне данные, а не экран» — это отдельный управленческий навык, такой же базовый, как чтение отчёта о прибыли. Руководитель, который принимает работу по демонстрации, всегда узнаёт правду последним. Руководитель, который умеет проверить систему по её же данным, стоит дороже — и я считаю, что этот навык придётся освоить каждому, кто заводит у себя ИИ. Дальше — пять пунктов, начиная с проверки данных. Выгрузить список документов, отмеченных «в наличии», и сверить с файлами на сервере — процент разрыва даст реальную картину, а не отчёт менеджеров. Добавить обязательное поле причины отказа и отдельную дату неуспешной проверки — без этих двух полей сделка не может закрыться как «отказ». Поставить автозадачу менеджеру на день проверки с бинарным выбором «пройдена / не пройдена» и уведомлением контролю качества при просрочке. Прогнать 5–10 живых кейсов через новую логику вручную, прежде чем включать автоматизацию на всю базу — это дешевле, чем чистить обучающую выборку постфактум. Проверить, есть ли у каждого сотрудника, работающего с клиентом, доступ в общую систему — переписки и локальные папки не восстанавливаются при передаче дел. Свести чек-лист по интеграции портал → CRM в документ, а не диктовать его на планёрке — при передаче проекта устные договорённости теряются первыми. Похожий разрыв между красивым фасадом и рабочей логикой я разбирал на примере CRM — там причиной было не отсутствие данных, а их искажение задним числом, см. разбор про сдвиг дат в Битрикс24 . А если вы только решаете, нужен ли вашей компании личный кабинет вообще, у меня есть отдельный разбор — когда клиентский портал оправдан, а когда нет . Что сделать вам: соберите за неделю список вопросов, с которыми клиенты обращаются к вашим менеджерам. Кабинет должен закрывать первые пять из них — всё остальное вторично, каким бы красивым оно ни было. Как выстроить логику вокруг реальных вопросов клиентов — в бесплатном курсе для руководителей . Чего мне стоил красивый фасад Кабинет, которым я гордился на демо, оказался бесполезным в работе: логика была построена от того, что удобно показать, а не от того, что нужно клиенту. Переделка заняла больше времени, чем первая сборка. Ваш способ этого избежать: до первой строчки кода соберите реальные вопросы клиентов за месяц и стройте от них. Скучно, зато не придётся переделывать.

## Согласование договоров: сколько стоит автоматизация — смета на 32 000 ₽
URL: https://davidgerstein.pro/blog/soglasovanie-dogovorov-stoimost/
Дата: 2026-08-29
Направление: Производственный цикл
Цифры: 27 зависших клиентов, 32 000 ₽ на доработку (оценка), 3 неответа = отказ
Коротко: Стоимость автоматизации согласования договоров для среднего отдела продаж — это в первую очередь стоимость доработки регламента и условной логики в CRM, а не покупка новой системы: в разобранном случае это около 32 тысяч рублей разовых работ (оценка). Окупаемость считается не в деньгах напрямую, а в скорости, с которой сделки перестают зависать без причины.

Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Если вы не можете назвать цену автоматизации ни одного своего процесса — ни точную, ни хотя бы порядок, — вы эту автоматизацию не покупаете, вы её опасаетесь. А пока вы опасаетесь, подрядчик называет любую цифру, и вам нечем её проверить. Наш счёт за автоматизацию согласования договоров — 32 000 ₽. Вместе со всеми переделками. Это меньше пятой части одной сделки при среднем чеке 180 000 ₽. И в полтораста раз меньше оборота, который в тот момент стоял у нас без движения из-за пустой строки в шаблоне договора. Раскладку я показываю не ради дешевизны. А чтобы вы видели, из чего цена складывается и в каких местах вас будут пробовать развести на порядок дороже. Откуда взялась цифра Планёрка по средам, отчёт по воронке. Координатор — он держит сроки заказов в голове и в трёх табличках — смотрит на столбец «документы запрошены» и молчит дольше обычного. Потом говорит: «У меня тут 27 клиентов, которые не двигаются вообще. Не неделю, не две. Просто стоят». Первая реакция — «менеджеры не дожимают», почти рефлекс. Стали смотреть по факту: клиенты не отвечают, но просроченными их система не считает. Формально всё в порядке. Причина оказалась смешной в своей глупости: в договоре нет срока действия услуги. Ни строчки. Клиент подписал документ, где не сказано, до какого числа он обязан прислать документы или ответить менеджеру. Юридически — тишина. Системно — тоже: если в договоре нет даты, CRM неоткуда взять точку отсчёта для просрочки. Условная компания из легенды: сервисная, 8 менеджеров в продажах, около 40 человек всего, оборот около 9 млн рублей в месяц, средний чек 180 тысяч, цикл сделки около 6 недель. При таком цикле в работе одновременно держится примерно 75 сделок. 27 зависших — больше трети воронки. По деньгам это не потеря, а заморозка: 27 × 180 000 ₽ ≈ 4,86 млн рублей оборота стоят без движения (часть из них всё равно доедет до финала, просто позже). Сколько стоит автоматизация согласования договоров: смета целиком Решение оказалось скучным до неприличия: вписать в регламент требование указывать срок действия договора для типовых работ, а для нестандартных проектов оставить исключение — не насиловать то, что в шаблон объективно не укладывается. Дальше две статьи расходов, и обе внутренние. Строка сметы Часы Ставка Сумма Юрист: правка шаблонов, архив старых версий, простановка дат в активных сделках 8 1 500 ₽/ч 12 000 ₽ Разработчик: условная логика — срок подставляется в договор по пакету услуг 10 2 000 ₽/ч 20 000 ₽ Новая CRM или платформа — — 0 ₽ Подписка за автоматизацию, ежемесячно — — 0 ₽ Итого разово 18 — 32 000 ₽ (оценка) Смотрите на эту таблицу не по итогу, а по структуре. Десять часов из восемнадцати — программирование, восемь — юрист и регламент. То есть почти половина сметы уходит на то, чтобы решить, что вообще должно быть написано в договоре, и только вторая половина — на то, чтобы машина это подставляла сама. Сначала мы и внедрили руками: юрист правил активные шаблоны, менеджеры проставляли даты в существующих сделках. Разработчик подключился вторым шагом — чтобы срок приезжал в договор из формы, в зависимости от пакета услуг, а не ждал, пока кто-то вспомнит. Дорожает такая смета предсказуемо. Дороже всего — когда вместо доработки регламента вам продают новую систему: к сумме добавляется лицензия, миграция и полгода, пока отдел привыкает. Дальше идут исключения: каждый нестандартный случай, для которого нельзя назвать срок, превращается в отдельную ветку логики и в лишние часы разработчика. И тише всего бюджет съедают согласования — юрист несёт формулировку руководителю продаж, тот собственнику, и восемь часов юриста незаметно становятся двадцатью. Скажу про свою ошибку, раз уж разговор про деньги. Я сам долго смотрел на такие сметы с другой стороны: видел итоговую сумму и торговался по ней, а не по строкам. Я не понимал простой вещи — платят здесь не за код, а за решение, которое кто-то должен принять и подписать. Пока решение не принято, любая сумма выглядит завышенной, потому что непонятно, за что именно. На этом ошибаются почти все, кто заказывает автоматизацию впервые, и я в том числе. Почему в договоре важно прописывать срок действия Дальше стали разматывать, откуда взялась пустая строка. Дело оказалось не только в юристах, которые когда-то делали шаблон. Менеджеры на закрытии сделки сами говорили клиентам: «Не переживайте, можно начать когда угодно, спешить некуда». Это снимает возражение о нагрузке и помогает продать. Но клиент слышит буквально и потом действительно не спешит. А система не подсветит проблему, потому что формально сделка не просрочена: срока-то нет. Срок в договоре — не юридическая формальность, а точка отсчёта для машины. Без неё любой автоматический контроль бессмыслен: нечего сравнивать с сегодняшним числом. Заодно вписали второе условие: три подтверждённых неответа клиента считаются отказом от услуг. Одна строка, а закрывает риск бесконечного зависания без вины компании. Координатор оценил сразу: «Наконец-то будет что показывать в отчёте, а не гадать, жив клиент или просто забыл». Тот же класс сбоя — просрочка, которую система не видит, потому что не от чего считать, — разобран подробнее в тексте про контроль дебиторки, который не зависит от памяти людей . А как согласование ломается уже на финальной проверке — в соседнем разборе . Чем кончится — пока не знаем Честно: финальных цифр по возврату сделок в срок у меня ещё нет. Прошло меньше месяца, а цикл сделки здесь около 6 недель — раньше конца квартала выводы делать рано. По предварительным снимкам статусов зависших уже не 27, но динамику будем смотреть на горизонте квартала. Что можно сказать сейчас: замороженный оборот стал видимым. Раньше система не умела показать, что 4,86 млн рублей стоят без движения. Теперь это строка в отчёте, а не ощущение менеджера, что «что-то как-то не очень». Что мы в эффект не записываем: часы юриста и разработчика — разовая работа, а не освободившееся время, которое можно пересчитывать в деньги каждый месяц. И сокращение числа зависших сделок — не заслуга одной строки: параллельно поменялся скрипт менеджеров на закрытии, и выделить вклад условия про срок из общей связки честно нельзя. Будут цифры за квартал — опубликую, включая неудобные. Читать смету автоматизации по строкам, а не по итогу — это отдельный управленческий навык, и его придётся освоить. Руководитель, который умеет спросить «сколько тут часов того, кто принимает решение, сколько — того, кто закрепляет его в системе, и что мы покупаем в каждой строке», платит за один и тот же результат в разы меньше, чем тот, кто торгуется по конечной сумме. Проверяется навык за один разговор с подрядчиком. Возьмите на этой неделе один процесс, который у вас буксует, и попробуйте назвать его смету в двух строках — часы решения и часы закрепления. Не сойдётся — значит, вы пока не знаете, что покупаете, и торговаться вам нечем. Когда назовут сумму на порядок выше нашей раскладки, просите разложить по пунктам: нормальный подрядчик объяснит, ненормальный заговорит про уникальность вашего бизнеса. Как считать такие проекты и что в них правда дорого — разбираю в бесплатном курсе для руководителей .

## Распознавание документов: как мы снизили ошибки с 20% до 7% на 92 эталонных документах
URL: https://davidgerstein.pro/blog/ii-raspoznavanie-dokumentov/
Дата: 2026-08-28
Направление: Производственный цикл
Цифры: 92 эталонных документа · ошибки 20% → 7% · токены −30–40%
Коротко: Распознавание документов запустили сразу на реальном потоке — модель путала имена и фамилии, не читала повёрнутые сканы, а доля сбойных комплектов доходила до 20%. Помогло не «лучшая модель», а эталонная выборка из 92 документов, спецификации по типам и каскад из дешёвой и дорогой модели, снизившие ошибки до 7%.

Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Дневник внедрения: как мы запускали распознавание документов на реальном потоке и что из этого вышло. Я вёл эту задачу и полтора месяца был уверен, что она чисто техническая. Если вы собираетесь делать то же самое — читайте про грабли, они здесь подробнее, чем успехи: мои обойдутся вам дешевле, чем ваши собственные. Какую точность даёт распознавание документов На старте доля сбойных комплектов доходила до 20% : модель путала имена с фамилиями и не читала повёрнутые сканы. После доработки на 92 эталонных документах ошибки снизились до 7% . Точность растёт не от смены модели, а от эталонного набора и правил разбора: тот же путь на другом наборе дал переход с 59% до 85% без замены нейросети. Мы сразу запустили распознавание документов — и получили путаницу в именах клиентов Разберём на примере: сервисная компания, отдел продаж из 8 менеджеров, оборот около 9 млн ₽ в месяц, средний чек услуги — 180 000 ₽. Это примерно 50 сделок в месяц на отдел — то есть на каждого менеджера приходится около 6 сделок в месяц, чуть больше одной новой сделки в неделю (цикл сделки — около 6 недель, у каждого менеджера обычно несколько сделок одновременно в работе). Всего в компании около 40 человек. Каждая сделка — это комплект из нескольких документов: удостоверение личности, справка, договор, иногда рукописная форма. Именно на этом потоке мы и включили распознавание документов — с этого стартовал весь разбор ниже. Мы решили не тратить полгода на пилот и запустили распознавание документов сразу на живом потоке. Логика была простая: в интерфейсе Клода мы прогнали десяток сканов — модель прекрасно читала имена, даты, номера документов. Значит, думали мы, через API будет так же. Не было. Через API модель путала имя и фамилию местами, пропускала отчество, а часть сканов, загруженных вертикально (люди фотографируют документы телефоном как придётся), распознавала как случайный набор символов. Координатор производственного цикла получал карточки клиентов, где в поле «фамилия» стояло имя, и разбирался вручную — почему у клиента вдруг «сменилось» отчество между двумя проверками. «Задним числом никто ничего не менял, — говорил он, — просто модель второй раз прочитала документ иначе». Ошибка в имени клиента — это не мелочь. Это переделка карточки, повторная проверка менеджером и, в худшем случае, конфликт с клиентом, который увидел свои данные с ошибкой в личном кабинете. При потоке около 50 комплектов в месяц каждый пятый в первые недели — то есть около 10 комплектов — требовал ручной пересборки: дополнительные 30–40 минут работы менеджера сверх обычных 10–15 минут на проверку (оценка). Скрытая нагрузка на отдел, которую никто не считал при запуске. Почему в чате работало, а через API — нет Ловушка, в которую попадёте и вы, если будете тестировать в чате, а запускать через API: это разные условия, и результат отличается. Я сам в неё зашёл первым: показал руководству прогон в чате, получил «отлично, запускаем» — и потом месяц объяснял, почему на живом потоке всё иначе. Мне это стоило доверия к проекту на старте, вам не обязательно повторять. Разработчик, который вёл эту задачу, сформулировал причину точно: «Получается красивый дом, но дверей нету, как зайти — непонятно». В чат-интерфейсе модель получает не просто картинку, а картинку, уже прошедшую предобработку интерфейса: разворот, обрезку, иногда улучшение контраста. Через API вы отдаёте модели то, что реально загрузили — а грузили документы кто в лежачей ориентации, кто в портретной, кто со смартфона под углом. Вторая причина глубже: одна универсальная инструкция «распознай документ и извлеки данные» работает плохо на разнородном потоке. Паспорт, справка о доходах и рукописная форма читаются моделью совершенно по-разному — разное расположение полей, разный шрифт, разная логика, где искать фамилию. Один промпт «на всё» — это и есть тот самый провал: модель либо перегружена универсальностью, либо теряет точность на нетиповых случаях. Третья причина — организационная, а не техническая: часть менеджеров отмечала документы как «в наличии» в CRM, но не загружала сами файлы на сервер. Модель, которую предполагалось дообучать на этих данных, начинала считать, что клиент прошёл проверку вообще без документов. Это ломало не текущую сессию, а будущее обучение — самую дорогую часть проекта, потому что ошибку в разметке находишь не сразу, а через месяц, когда пробуешь анализировать накопленный массив. Как мы переделали: механика по шагам Ваш путь будет короче, если сразу заложите то, к чему мы пришли через месяц проб. Я закладывал на переделку неделю — ушло больше месяца, и почти всё это время съела не техника, а описание типов документов. Вместо того чтобы чинить универсальный промпт, мы откатились назад и собрали процесс заново, на маленьком контролируемом объёме. Собрали эталонную выборку. 92 реальных документа разных типов — не случайных, а специально подобранных так, чтобы в них были все проблемные варианты: повёрнутые сканы, рукописные вставки, документы с низким контрастом. Разметили вручную. Стажёр прошёл все 92 документа и зафиксировал, что модель распознала правильно, а что — нет, с указанием конкретной причины ошибки (ориентация, почерк, качество скана). Написали спецификации по типам документов. Для каждого типа — отдельная инструкция: где искать нужные поля, какие нюансы у этого типа (например, в рукописных формах отчество часто пишут через запятую после имени, а не отдельным полем). Добавили автоматический разворот. Перед вызовом модели изображение проверяется и разворачивается в правильную ориентацию — это убрало большую часть ошибок с вертикальными сканами. Построили каскад из двух моделей. Дешёвая модель сначала определяет тип документа, затем к нему применяется своя спецификация, и только на этом этапе подключается более мощная модель для извлечения данных. Добавили проверку человеком на выборке, а не на всём потоке. Менеджер смотрит не каждый документ, а случайную часть — если ошибок нет, доля проверки снижается. Перепроверили промпты на разных моделях. На наборе из 10–15 полных первичных консультаций прогнали одну и ту же задачу через несколько моделей разного уровня — сравнили, где точнее и где дешевле. Логика по модели разработки была такая: сначала пишем промпт под самую мощную модель, добиваемся, чтобы правила распознавания были выстроены безупречно, и только потом адаптируем этот же промпт под более простую и дешёвую модель, у которой уже есть готовая логика — ей не нужно «изобретать» правила, только следовать им. Где ломается. Если менеджер отмечает документ как «загружен», а файла на сервере нет — модель никогда не увидит эту ошибку сама. Мы столкнулись с этим напрямую: часть карточек в CRM выглядела «полной», а по факту обучающий массив содержал дыры. Без обязательной проверки «есть файл физически, а не просто галочка» любое дальнейшее дообучение будет тренироваться на пустоте. ИИ-связка целиком Возьмите схему за основу и подставьте свои типы документов и свои критичные поля. Конвейер выглядит так: клиент или менеджер загружает документ в общую папку → скрипт по расписанию проверяет новые файлы → дешёвая модель классифицирует тип документа → к нему применяется соответствующая спецификация → мощная модель извлекает данные → результат уходит в CRM через вебхук → менеджер видит статус и, если нужно, проверяет вручную. Шаг 1. Классификация типа документа. Модель: дешёвая (лёгкий уровень) — задача простая, вариантов ответа мало, переплачивать за мощную модель здесь бессмысленно. Пример ответа модели: Шаг 2. Извлечение данных по спецификации. Модель: мощная — здесь цена ошибки высокая, экономить нельзя. Инструкция берётся под конкретный тип документа, определённый на шаге 1. Пример ответа модели: Инженерная обвязка. Скрипт крутится на облачном триггере, который раз в час проверяет папку с документами: появился новый файл — робот подхватил его в очередь. Все вызовы моделей логируются в отдельную таблицу: тип документа, использованная модель, уверенность ответа, флаги. Если модель вернула низкую уверенность или флаг «требует проверки», в CRM через вебхук ставится задача на менеджера, а не автоматически заполняется карточка. Если сам скрипт падает (нет ответа от API, таймаут) — в таблицу пишется строка с ошибкой и статусом «не обработано», и раз в день кто-то один просматривает эту колонку целиком, а не каждый сбой в моменте. Отдельно: модель получает данные напрямую из CRM через отдельный слой между ИИ и базой данных компании, а не через ручную выгрузку файлов — это снижает расход токенов на 30–40%, потому что запрос не тащит за собой лишний контекст. Например: если типовой запрос на извлечение данных с ручной выгрузкой и склейкой файлов обходился условно в 1500 токенов на документ, то через прямой слой к CRM — ориентировочно 900–1050 токенов на тот же документ при том же качестве ответа (оценка, цифры иллюстративные). Заодно это снижает долю галлюцинаций модели — она не додумывает то, чего нет в обрезанном контексте. Тема отдельная и подробно разобрана в статье о реальных счетах за ИИ — Сколько на самом деле стоит ИИ в месяц . Так может выглядеть карточка очереди документов в CRM — с реальными числами из нашей выборки: Очередь документов — CRM 92 эталонных документа в выборке 7% доля ошибок после каскада 30–40% меньше токенов со связкой CRM Клиент Тип документа Уверенность Статус Соколова М. В. рукописная_форма 0.74 проверка Иванов П. С. удостоверение_личности 0.96 готово Что показало сравнение моделей Задача была не найти «самую точную вообще», а разложить конвейер так, чтобы дорогая модель работала только там, где без неё точность реально падает. Шаг конвейера Модель Почему именно она Классификация типа документа Дешёвая (лёгкий уровень) Задача с ограниченным набором ответов, ошибка здесь дешёво чинится на следующем шаге Извлечение данных по типовой спецификации Мощная Ошибка в имени или дате напрямую попадает в карточку клиента Документы с рукописным текстом Мощная, с проверкой человеком Даже сильная модель на почерке ошибается чаще — проверка обязательна Повторная проверка при низкой уверенности Мощная, другой промпт Второй проход с уточняющим промптом иногда исправляет то, что не увидел первый Часы, которые уходили у менеджеров на ручное исправление ошибок распознавания, до и после внедрения спецификаций и автоповорота — на диаграмме ниже: поток около 50 комплектов в месяц, ставка менеджера ~1000 ₽/час. 7ч было 2ч стало ≈7 часов/мес на исправления до внедрения спецификаций и автоповорота против ≈2 часов/мес после — оценка на основе потока около 50 комплектов в месяц. Экономика: что стоил провал и что даёт починка Настройка каскада заняла ~30 часов работы разработчика (≈60 000 ₽ по ставке 2000 ₽/час), а даёт снижение потерь на ручной пересборке документов с ≈7 000 до ≈2 000 ₽/мес — то есть эффект около 5 000 ₽/мес (оценка). Формула для потерь простая и её легко пересчитать под свой поток: число комплектов в месяц × доля ошибок × лишние минуты на пересборку ÷ 60 = дополнительные часы менеджеров в месяц . У нас: 50 комплектов × 20% ошибок в первые недели × 40 минут (верхняя граница диапазона 30–40 минут) ÷ 60 ≈ 7 часов в месяц. При ставке менеджера 1000 ₽/час это около 7 000 ₽/мес прямых потерь на ручную пересборку. посчитайте на своих цифрах комплектов в месяц доля ошибок, % минут на пересборку ставка менеджера, ₽/час потери ≈ {X} ₽ в месяц формула: комплекты × доля ошибок × минуты на пересборку × ставка ÷ 6000 (перевод процентов и минут в рубли); расчёт по верхней границе диапазона минут Вторая часть стоимости провала не считается в часах — это риск, что клиент увидит ошибку в своих данных в личном кабинете и потеряет доверие к сервису ещё до того, как получит результат. Стоимость починки — это не покупка новой лицензии, а время разработчика: сбор и разметка эталонной выборки (92 документа, разметка стажёром — примерно 3–4 часа), написание спецификаций по 4–5 типам документов (примерно 2–3 часа на тип, итого 10–12 часов разработчика) и настройка каскада моделей с обвязкой — промпты, вебхуки, логирование (примерно 15–20 часов разработчика). Итого около 30 часов разработчика. При условной ставке разработчика 2000 ₽/час это порядка 60 000 ₽ разовых затрат. После починки доля сбойных комплектов снизилась примерно до 7%: 50 × 7% × 40 минут ÷ 60 ≈ 2 часа в месяц — именно эта цифра стоит на диаграмме выше. Экономия на ручной работе: (7 − 2) часов × 1000 ₽/час = 5 000 ₽/мес. При разовых затратах на починку около 60 000 ₽ и экономии 5 000 ₽/мес окупаемость — около 12 месяцев, и это без учёта снижения репутационного риска от ошибок в карточках клиентов, который в часах не считается вовсе. Что мы не считаем эффектом: снижение репутационного риска не переводим в рубли — честно оценить вероятность потери клиента из-за ошибки в личном кабинете нельзя, поэтому в расчёт выше эта часть не входит. Освободившиеся часы менеджеров тоже не автоматически превращаются в новые продажи — это высвобожденное время для другой работы, а не гарантированная выручка. Цифра в 5 000 ₽/мес скромная в абсолютах, а окупаемость почти год — не быстрый результат. Но именно эта связка переводит распознавание документов из источника ручной работы в фоновый процесс, за которым не нужно следить каждый день, и при росте потока (например, при расширении отдела продаж) окупаемость только ускорится. Похожий по духу, но количественно другой результат — рост точности распознавания с 59% до 85% на другом наборе документов и с другими вводными — разобран отдельно в статье Распознавание документов: как мы подняли точность с 59% до 85% ; не путайте эти два кейса. Показатель До каскада После каскада Эффект Доля комплектов с ошибкой ~20% ~7% снижение примерно в 3 раза Доп.часы менеджеров в месяц ~7 ч ~2 ч −5 ч/мес Доп.расходы на ручную пересборку ~7 000 ₽/мес ~2 000 ₽/мес экономия ~5 000 ₽/мес Токены на один запрос через связку с CRM ~1500 (иллюстративно) ~900–1050 −30–40% токенов Разовые затраты на починку — ~60 000 ₽ окупаемость ~12 мес Все числа в таблице привязаны к потоку ~50 комплектов в месяц — это оценка для примера, проценты ошибок и экономия токенов взяты из фактических результатов эксперимента. Где ещё ломается. Если тип документа не описан ни в одной спецификации, каскад по умолчанию отправляет его на самую дорогую модель «на всякий случай» — и если доля таких нетиповых документов растёт, счёт за API растёт вместе с ней незаметно для того, кто не смотрит лог по типам. Раз в месяц стоит смотреть, какие типы документов система относит к «другое», и добавлять для них спецификации, а не оставлять на откуп дорогой модели навсегда. Что дальше: от 92 документов к пилоту на тысячи клиентов Механика выше — это не финал, а промежуточный, контролируемый шаг. Дальше по плану — прогнать систему ещё на 40 живых клиентских кейсах и отдать менеджерам на прямое подтверждение точности: совпадает ли распознанное с тем, что видит человек. Только если менеджеры подтверждают результат на этом объёме, имеет смысл переходить на сегмент около 5000 клиентов — тестировать не столько точность (она уже проверена на меньшем масштабе), сколько отклик и накопление достаточного массива данных для полноценного дообучения модели. Именно так — от эталонных 92 документов, через 40 живых кейсов, к тысячам — а не сразу на всю базу, как в первой, неудачной попытке. Чего я не понимал, когда начинал распознавание документов Я два месяца искал, какая модель «лучше читает документы», и всё это время ответ лежал в другом месте. Распознавание документов — задача не про модель, а про описание собственного потока: пока никто в компании не может назвать, какие типы документов у нас ходят и какие поля в них критичны, любая модель будет угадывать. Мой вывод из этого проекта простой: умение описать свой процесс до того, как покупать под него инструмент, — базовый навык руководителя, и окупается он не в этом внедрении, а во всех следующих. Проверьте это на себе прямо сейчас, не откладывая: перечислите типы документов, которые проходят через вашу компанию за неделю, и для каждого назовите два-три поля, ошибка в которых дорого вам обойдётся. Если список даётся тяжело — начинать надо с него, а не с выбора модели: ваш подрядчик или ваш разработчик всё равно спросят у вас то же самое, только через месяц и за ваши деньги. Чек-лист на понедельник Не запускайте распознавание сразу на всём потоке — соберите 50–100 эталонных документов и разметьте вручную, где модель ошибается. Проверьте, действительно ли документы, отмеченные в CRM как «загружены», физически лежат на сервере — расхождение здесь ломает любое будущее обучение. Разбейте документы на типы и напишите отдельную короткую инструкцию для каждого, а не одну универсальную «распознай документ». Добавьте автоматический разворот изображения перед вызовом модели — если работаете через API, а не через чат-интерфейс, это не опция, а обязательный шаг. Постройте каскад: дешёвая модель на классификацию, дорогая — на извлечение данных, человек — на выборочную проверку, а не на весь поток. Прикиньте свою экономику по той же формуле: поток комплектов × доля ошибок × лишние минуты на пересборку ÷ 60 = ваши часы потерь в месяц — и сравните с разовыми затратами на починку, чтобы понять свою окупаемость. Перед тем как отправлять документы клиентов в любую модель, свежим взглядом перечитайте, что вообще можно передавать наружу — коротко об этом в статье Персональные данные и нейросети . Что забрать вам из этого дневника: запускайтесь на реальном потоке, а не на чистых сканах; считайте точность по критичным полям, а не по документам; и заложите время на описание типов — это ваша основная работа, а не настройка модели. Полная механика — в разборе про точность и в бесплатном курсе . Чек-лист для вашего запуска Проверьте перед стартом: у вас есть эталонная выборка реальных документов; вы знаете, какие поля критичны; вы решили, что делать с неуверенными случаями; и у вас есть человек, который принимает результат. Без любого из четырёх пунктов вы получите наш первый результат — путаницу и потерянное время.

## Разработка личного кабинета: как один скрипт превратил 12 страниц в проблему
URL: https://davidgerstein.pro/blog/klientskiy-portal-oshibki/
Дата: 2026-08-28
Направление: Производственный цикл
Цифры: 12 страниц одним скриптом · 0 интеграций с CRM · 30–40% меньше токенов на MCP
Коротко: Разработка личного кабинета чаще всего срывается не из-за дизайна, а из-за трёх дыр: 12 страниц собраны без контроля качества, данные не долетают до CRM, а сотрудники обходят обязательные поля. На одном реальном экране показываем, как это чинится по шагам — эталон вместо генерации, привязка статуса к файлу, ИИ-проверка документов, — и что это даёт в цифрах: пересборка 12 страниц заняла 30–50 часов, а MCP-сервер срезал 30–40% токенов на запросах к CRM.

Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Если вы заказали кабинет подрядчику, приняли работу по демонстрации и ни разу не открывали его глазами клиента — у вас там сейчас лежит минимум одна из трёх поломок, о которых ниже, и вы про неё пока не знаете. Я эти грабли собрал своими ногами: разбор ниже — про наш собственный кабинет, а не про чужие кейсы. У нас сервисная компания: отдел продаж 8 менеджеров, оборот около 9 млн ₽ в месяц, средний чек по сделке — 180 тысяч ₽. Это значит примерно 50 сделок в месяц проходят через один и тот же экран — клиентский портал, личный кабинет, куда контрагент грузит документы для оформления заявки. Когда этот экран собран криво, теряются не абстрактные «удобство» и «имидж», а конкретные сделки: если из 50 сделок в месяц застревает на этапе документов хотя бы 10% — это 5 сделок по 180 тысяч, то есть 900 тысяч ₽ отложенной выручки в месяц (оценка). Формула для своего случая: число сделок в месяц × доля зависших на этапе документов (%) × средний чек = сумма отложенной выручки в месяц — подставьте свои цифры и получите свою оценку. Отдельный случай, когда интерфейс уже есть, а логики под ним нет, — личный кабинет клиента . посчитайте на своих цифрах сделок в месяц средний чек, ₽ % зависших на документах риск ≈ {X} ₽ отложенной выручки в месяц формула: сделки в месяц × средний чек × доля зависших на этапе документов; результат — верхняя граница риска Я расскажу, как один и тот же экран портала прошёл путь от «страшно показать клиенту» до рабочего инструмента с ИИ-проверкой документов. По дороге вскрылись три отдельные поломки: скрипт, который генерировал страницы, кривая интеграция с CRM и сотрудники, которые обходили систему честнее, чем она это предполагала. Разработка личного кабинета: где чаще всего ошибаются? Ошибок три, и они повторяются почти у всех: страницы генерируют одним скриптом без построчной сверки с брендбуком, данные из кабинета не долетают до CRM автоматически, а статус «документ получен» ставится без прикреплённого файла. В клиентском портале компании на 40 человек это вылилось в пересборку 12 типов страниц — 30–50 часов дизайнера и разработчика. Порядок важнее скорости: сначала данные и валидация, потом логика и только в конце интерфейс. Я делал наоборот и потерял на этом месяц. Зачем вообще затевают разработку личного кабинета Ваша логика при заказе портала обычно такая же: клиенты сами всё увидят, менеджеры разгрузятся. Дальше — что этому мешает. Идея была простая: клиент заходит в личный кабинет, грузит документы — карточку организации, доверенность, спецификацию — и видит статус: одобрено, нужен доп. документ, лимит согласован. Менеджер освобождается от рутинной переписки «а вы прислали скан?». Под капотом — нейросеть, которая анализирует загруженные документы и формирует рекомендацию. Чтобы не тратить месяцы на полноценный продукт, решили запустить обучение алгоритма на реальных кейсах прямо сейчас: взять 40 живых случаев, прогнать через систему, отдать менеджерам на проверку. Если менеджеры подтвердят корректность — протестировать на сегменте из 5 тысяч клиентов и оценить отклик. Логика: за полгода набрать адекватный массив данных, чтобы к концу года запустить полноценный MVP. Разумный план. Экран подвёл раньше, чем модель. Как выглядело «до» Если у вас портал делал подрядчик и вы не смотрели внутрь — там может быть примерно то же самое. Под личный кабинет разработали 12 типов страниц: главная с дашбордом статуса, загрузка документов, история заявок, договор и тарифы, поддержка, база знаний, уведомления, счета, аналитика по заказам и ещё несколько служебных экранов. Чтобы не собирать каждую вручную, поручили одному скрипту сгенерировать все сразу по гайдлайнам бренда. Результат открыли и не узнали компанию. Скрипт формально «следовал» брендбуку, но на разных страницах — разные отступы, не тот акцентный цвет на кнопках, заголовки набраны шрифтом, которого в гайдлайне нет вовсе. На одной странице карточка документа выглядела как в брендбуке, на соседней — как шаблон конструктора сайтов десятилетней давности. Клиенту, который до этого получал аккуратные счета и договоры, показывать такой кабинет было стыдно. Мой первый инстинкт был именно такой — доводить каждую из 12 страниц до идеала вручную, страница за страницей. Это тупик: 12 страниц, у каждой десяток мелких расхождений — на полную вычитку и правку уйдут недели, а сзади уже стоит вторая проблема, куда более серьёзная. Что вскрылось при аудите Проверьте свой портал так же: возьмите пять реальных клиентов и сверьте то, что они видят, с тем, что в системе. Расхождения найдутся. Пока разбирались с вёрсткой, собственник обнаружил вторую поломку: документы клиентов загружаются в портал, там же формируются рекомендации нейросети — но эти данные не долетают до CRM автоматически. Менеджер видит статус в портале, а в карточке сделки — пусто. Чтобы обучить модель, нужно было вручную выгрузить весь массив данных портала и сопоставить его с клиентами, которые прошли проверку с первого раза. Без этого сопоставления модель не понимает, какие признаки в документе реально коррелируют с успешным исходом. Третья поломка была самой тихой и самой опасной. Менеджеры отмечали в CRM статус «документ в наличии» — но физически файл на сервер не грузили: экономили время, ставили галочку по памяти. Для человека разницы нет: документ где-то есть, все в курсе. Для модели, которая обучается на этих статусах, разница катастрофическая — она начинает считать, что клиент может пройти проверку без документа вообще. Обучающая выборка тихо портится, и никто этого не видит, пока не начинают сыпаться рекомендации по реальным сделкам. Где ломается: если в системе можно поставить статус «готово» без прикреплённого файла — рано или поздно кто-то так и сделает, не по злому умыслу, а чтобы не тормозить работу. Любая ИИ-модель, обученная на таких статусах, унаследует эту дыру и начнёт занижать требования к комплекту документов. Проверяйте не «отмечено ли», а «прикреплён ли файл» — это разные вещи. Пересборка личного кабинета: механика по шагам Ваш порядок: сначала данные, потом логика, и только в конце интерфейс. Мы делали наоборот и потеряли на этом месяц. Я принял решение не доводить каждую из 12 страниц до идеала перед тестированием, а изменить сам процесс сборки. Эталон вместо генерации. Взяли единственный утверждённый прототип главной страницы — тот, что прошёл дизайн-ревью без замечаний — и сделали его образцом для всех остальных 12 типов. Комплексный аудит вместо точечных правок. Собрали все 12 типов страниц в одну таблицу (Google Sheets: тип страницы → элемент брендбука → статус «совпадает / не совпадает» → кто чинит) и прогнали разом с привлечением дизайнера и разработчика, а не по одной странице за раз. Обязательная привязка статуса к файлу. На уровне формы и API запретили менять статус документа на «в наличии», пока файл физически не загружен на сервер. Это убрало третью поломку сразу — модель больше не видит «пустых успехов». Выгрузка и сопоставление данных. Массив документов и рекомендаций портала выгрузили и сопоставили с клиентами, прошедшими проверку с первого раза — так появился первый размеченный датасет для обучения. Точечное обучение OCR вместо запуска на всей базе. Вместо прогона через всю накопленную базу собрали 92 типовых документа, обучили стажёра проверять результат вручную и по каждому типу документа написали отдельную спецификацию — с описанием нюансов распознавания (развороты, качество скана, положение печати). Многоступенчатый анализ. Сначала система определяет тип документа, затем применяет нужную спецификацию, при затруднении эскалирует на более мощную модель, и только после этого документ уходит на подтверждение менеджеру. Координатор, который в других процессах компании держит статусы в трёх табличках, на этой пересборке сформулировал главное требование к системе одной фразой: «Статус меняется один раз и в одну сторону. Если менеджер откатывает дату проверки назад — я должен это видеть, а не гадать, что случилось на самом деле». Требование вошло в техзадание почти дословно. ИИ-связка целиком Возьмите эту схему за основу — она не зависит от того, на чём сделан ваш портал. Конвейер обработки документа выглядит так: клиент грузит файл на портал → вебхук уходит в обработчик → OCR извлекает текст → лёгкая модель определяет тип документа и полноту пакета → при низкой уверенности передаёт сложный случай на более мощную модель → результат пишется в карточку сделки в CRM → менеджер подтверждает или отклоняет. Загрузка файла на портал ~1 мин OCR + определение типа ~2 мин Анализ по спецификации ~3 мин Эскалация на сильную модель ~1,5 мин Проверка менеджером ~1 мин На шаге определения типа и полноты пакета работает дешёвая модель: задача формальная (классификация + извлечение полей), ошибка стоит немного, а объём документов большой. На шаге эскалации, когда документ повёрнут, скан плохого качества или тип нестандартный, — подключаем более дорогую модель с расширенным контекстом. Разница в стоимости запроса ощутима при потоке в сотни документов в месяц, поэтому маршрутизация «дешёвая → дорогая только по необходимости» — не экономия ради экономии, а единственный способ не сжечь бюджет на рутине. Пример ответа модели: Инженерная обвязка. Обработчик крутится на отдельном сервере, принимает вебхук из Bitrix24 при появлении нового файла в карточке сделки (входные данные: ID сделки, ссылка на файл, тип документа из формы). Результат анализа пишется обратно в кастомное поле сделки через API. Каждый шаг конвейера логируется в отдельную Google-таблицу: время, ID документа, модель, результат, ошибка — по образцу того, как в другом процессе компании настроили логирование обработки резюме, чтобы руководитель видел не только успешные случаи, но и зависшие. При сбое обработчик переставляет задачу в очередь на повтор и, если попытка проваливается трижды, кидает сообщение в общий чат команды, а не молчит. Отдельно для доступа ИИ-инструментов к данным CRM без раздувания промпта настроили MCP-сервер поверх базы CRM. Это снижает расход токенов на 30–40% и уменьшает долю галлюцинаций, потому что модель обращается к структурированным данным напрямую, а не получает их вставленными текстом в каждый запрос. Условный пример: запрос без MCP — это вставка текстового дампа карточки сделки в промпт, порядка 3000 токенов (оценка); тот же запрос через MCP обращается к структурированным полям и укладывается в 1800–2100 токенов — те самые 30–40% экономии на каждом вызове. При потоке в несколько сотен вызовов в месяц разница заметна на счёте за токены, но точную сумму в рублях считайте по своему тарифу у провайдера модели — универсальной цифры тут нет. Экран «после»: что показал аудит Ориентир для вашей проверки: данные на экране должны сходиться с системой на всех пяти проверенных клиентах, а не на одном показательном. Тип страницы портала Проблема на аудите Часов на исправление Личный кабинет / дашборд статуса Не тот акцентный цвет, шрифт заголовков не по брендбуку 3–4 Загрузка документов Статус менялся без привязки к файлу 6–8 (включая правку API) История заявок Расхождение в стилистике карточек 2–3 Договор и тарифы Вёрстка не соответствовала эталону 3–4 Остальные 8 типов страниц Точечные расхождения того же рода 2–4 на каждую, то есть 16–32 суммарно Итого по 12 страницам — 30–51, консервативно берём 30–50 (оценка) 0 из 12 было 12 из 12 стало До пересборки ни одна из 12 страниц не проходила аудит без замечаний по брендбуку; после сборки по единому эталону — все 12 страниц прошли аудит комплексно, за один цикл. Дело не в самих правках — их можно было сделать и раньше. Дело в порядке действий: раньше страницу доводили до идеала и только потом показывали; теперь берут эталон, собирают по нему всё сразу и лишь затем аудируют комплексно. Разница — недели точечной доводки против одного цикла аудита с понятным списком правок. Экономика: что это стоило и что дало Прикиньте свою: сколько времени ваши менеджеры тратят на ответы про статусы и сколько стоит переделка портала, если данные под ним неверны. Настройка ИИ-конвейера и MCP-сервера (вебхук, OCR, маршрутизация «дешёвая → дорогая модель», подключение к CRM) заняла ориентировочно 20–30 часов разработчика, эксплуатация моделей — около 3 000–5 000 ₽/мес, а эффект — сокращение затрат на ручную проверку документов примерно на 6 500–11 000 ₽/мес (оценка). Дальше — раскладка по инициативам: пересборку экрана и ИИ-модуль считаю раздельно, потому что это разные инициативы с разной окупаемостью и их нельзя складывать в один эффект. Пересборка вёрстки по эталону. По таблице выше сумма нижних оценок часов — 30, верхних — 51; берём консервативный диапазон 30–50 часов дизайнера и разработчика на аудит и доводку 12 типов страниц. При ставке около 1500 ₽/час это 45 000–75 000 ₽ разовых расходов — не эксплуатационных, а разового цикла пересборки. Обязательная привязка статуса к файлу. Стоимость внедрения — около 3–4 часов на изменение формы и валидации API, то есть на порядок дешевле, чем пересборка вёрстки. Эффект не в часах, а в риске: без этой правки модель обучается на искажённых данных, и любые рекомендации от неё становятся ненадёжными — а это уже не часы, а качество всего проекта. ИИ-конвейер анализа документов. При потоке около 50 сделок в месяц и в среднем 3–4 документах на сделку это 150–200 документов ежемесячно. Формула для своего случая: количество документов в месяц × время ручной проверки одного документа (мин) / 60 × ставка часа сотрудника = затраты на ручную проверку. Подставляем: ручная проверка каждого документа менеджером занимает 5–7 минут — 150×5/60 ≈ 12,5 и 200×7/60 ≈ 23,3, то есть 12–23 часа в месяц на весь отдел, или 12 500–23 000 ₽ по ставке 1000 ₽/час менеджера. Автоматическая маршрутизация «дешёвая модель → эскалация только сложных случаев» оставляет менеджеру только проверку результата — консервативно это сокращает время проверки вдвое (точная доля зависит от того, сколько документов ушло на эскалацию), то есть высвобождает 6 500–11 000 ₽/мес в пересчёте на часы менеджеров. Расходы на сами модели при таком потоке — условно 3 000–5 000 ₽/мес, то есть в разы меньше, чем экономия на времени менеджеров; подробный разбор счетов за ИИ есть в материале про реальные расходы на ИИ . Показатель До автоматизации После автоматизации Документов в месяц 150–200 150–200 Время проверки менеджером 5–7 мин/документ ~2,5–3,5 мин/документ (в среднем вдвое меньше) Часы отдела в месяц 12–23 6–12 Стоимость времени менеджеров (1000 ₽/час) 12 500–23 000 ₽ 6 000–12 000 ₽ Расходы на модели — 3 000–5 000 ₽/мес Риск зависших сделок. Если 10% из 50 месячных сделок зависает на этапе документов — это 5 сделок по 180 тысяч ₽, то есть 900 тысяч ₽ отложенной выручки в месяц (формула — в начале статьи). Пересборка экрана и обязательная привязка статуса к файлу не гарантируют, что этот риск исчезнет полностью, но убирают одну из его причин — искажённые статусы, из-за которых сделка стоит на месте, пока никто не замечает, что документа фактически нет. Что мы не считаем эффектом: устранение этой причины — это снижение вероятности зависания, а не гарантированная экономия; складывать эту цифру с экономией на ИИ-конвейере напрямую нельзя — это разные механизмы эффекта, один снижает трудозатраты, другой снижает вероятность потери сделки. Где ломается: качество OCR через API и через веб-интерфейс модели — разные вещи. Мы тестировали распознавание в самом сервисе — работало отлично. При запуске через API повёрнутые документы переставали распознаваться корректно. Если тестируете модель только в интерфейсе, а в продакшне работаете через API — закладывайте отдельный цикл тестирования именно на API-вызовах, желательно на 90–100 типовых документах с разными углами поворота и качеством скана. С чего начать вам в понедельник Четыре шага, и первый — не про интерфейс. Выгрузить список всех типов страниц/форм портала и построчно сверить с брендбуком — не выборочно, а полностью. Найти один утверждённый экран и объявить его эталоном для всех остальных, вместо доводки каждого по отдельности. Проверить в CRM: можно ли поставить статус «документ получен» без прикреплённого файла. Если можно — закрыть это в первую очередь. Собрать 50–100 типовых документов из потока, прогнать через OCR именно через тот канал, который будет в проде (API, а не веб-интерфейс), дать проверить человеку. Настроить логирование каждого шага обработки документа в отдельную таблицу — сколько успешно, сколько зависло, сколько с ошибкой. Назначить одного ответственного за актуализацию спецификаций и шаблонов — без владельца документация устаревает за первый же квартал. Про то, когда клиентский портал вообще нужен компании, а когда это лишние деньги на пустом месте, — отдельный разбор в материале о клиентских порталах для среднего бизнеса . Как поднять точность распознавания документов с 59% до 85% на конкретном кейсе — в разборе по OCR . Главный вывод для вас: портал нужен не тогда, когда его хочется, а когда клиенты уже спрашивают одно и то же, и вашим людям это надоело отвечать вручную. До этого момента вы строите красивую витрину, которой никто не пользуется. Как понять, дозрели ли вы до портала, — в отдельном разборе , а механика внедрения — в бесплатном курсе . Мой вывод из этой пересборки Я потратил месяц на красивый интерфейс, прежде чем понял, что проблема была в данных. Клиенты видели статусы, которые не соответствовали реальности, — и портал не экономил время менеджеров, а добавлял им работы по объяснению расхождений. Если вы делаете свой портал — начните с проверки данных. Это скучно и это единственное, что определит, будет он работать или нет. И назову вещь, которую раньше не считал работой руководителя. Это отдельный управленческий навык: читать не экран, а данные под ним. Руководитель, который умеет спросить «что физически лежит в системе за этим статусом» и получить ответ цифрой, стоит дороже руководителя, который принимает решения по красивой картинке. Мне этот навык обошёлся в месяц работы команды — вам он может достаться за один вечер проверки. И назову вещь, которую раньше не считал работой руководителя. Это отдельный управленческий навык: читать не экран, а данные под ним. Руководитель, который умеет спросить «что физически лежит в системе за этим статусом» и получить ответ цифрой, стоит дороже руководителя, который принимает решения по красивой картинке. Мне этот навык обошёлся в месяц работы команды — вам он может достаться за один вечер проверки. Проверьте свой портал на этой неделе так же, как проверили мы: пять реальных клиентов, сверка того, что видят они, с тем, что в системе.

## Почему согласование договоров стопорится на финальной проверке — и как перестать терять клиентов
URL: https://davidgerstein.pro/blog/soglasovanie-dogovorov-oshibki/
Дата: 2026-08-28
Направление: Производственный цикл
Цифры: 900 000 ₽ риска в месяц, 12 зависших сделок, 35→3 мин на случай отказа (обе оценки)
Коротко: Согласование договоров чаще всего ломается не на подписании, а на этапе финальной проверки: сделка зависает, статус не откатывается, а причина отказа нигде не фиксируется. По расчёту, из-за этого под риском оказывается около 900 000 ₽ выручки в месяц. Дыру закрывают обязательное поле причины отказа, автоматический откат и контроль качества по срокам — время на разбор случая отказа падает с 35 до 3 минут.

Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Если вы не можете за десять секунд назвать, сколько договоров прямо сейчас висит на согласовании и у кого именно, — у вас уже идут потери, вы их просто не видите. Клиенты уходят на том этапе, где они вам уже сказали «да». Это самая обидная точка потерь в бизнесе. Не «дорого», не «подумаем», не конкурент увёл. Клиент готов подписать — и ждёт, пока договор проходит круг по вашей компании. Иногда неделю. Иногда до тех пор, пока ему не надоест. Ниже — месяц перестройки этого процесса по неделям: что сломалось, что сработало и сколько это стоило. Я специально оставил в хронике собственные грабли: они полезнее гладкой истории успеха. У нас отдел из 15 менеджеров, оборот около 18 млн ₽ в месяц, средний чек по сопровождению сделки — 150 тысяч ₽. Это значит, что через воронку каждый месяц проходит примерно 120 сделок, и каждая из них проходит через процесс согласования договоров перед подписанием. Часть сделок дополнительно обязана пройти финальную проверку — комплаенс-проверку контрагента на стороне заказчика или банка. Пока эта проверка идёт, сделка живёт своей жизнью в CRM. И вот тут начинается дыра. Если проверка провалена, менеджер должен откатить сделку назад, зафиксировать причину и запустить повторную подготовку. На практике он делал это руками — и часто забывал снять дату уже прошедшей проверки. Сделка зависала: система считала, что проверка ещё впереди, хотя она уже провалена. По грубой оценке, на этом держится риск в 900 000 ₽ выручки в месяц — я покажу расчёт ниже. Дальше — хроника, как мы это чинили, по неделям, с тем, что сломалось на каждом шаге. Почему согласование договора зависает и как это чинится Согласование ломается не на подписании, а на финальной проверке: её отрицательный результат никто не заносит в систему, сделка остаётся в статусе «на проверке» и выпадает из работы. При обороте 18 млн ₽ в месяц и среднем чеке 150 тыс. ₽ это держит под риском около 900 000 ₽ выручки ежемесячно — шесть сорванных сделок из ста двадцати. Дисциплиной это не лечится, лечится архитектурой: результат проверки становится обязательным полем с закрытым списком причин, откат сделки — автоматическим действием CRM, а просроченный статус уходит не менеджеру, а контролю качества. После этого один случай отказа стал занимать 3 минуты вместо 35 . Что решили на старте: как перестроить процесс подписания Поводом стал не абстрактный аудит, а обычная планёрка по воронке. Собственник посмотрел на отчёт и не увидел ни одной сделки со статусом «проверка провалена» — только «на проверке» и «подписан». Провалы были, менеджеры о них рассказывали устно, но в системе они не существовали. Решили втроём с руководителем продаж и разработчиком: систему нужно заставить фиксировать отказ так же строго, как она фиксирует оплату. Задача на старте звучала так: убрать зависимость от памяти менеджера в трёх точках — фиксация даты неуспешной проверки, причина отказа, откат сделки на этап повторной подготовки. Четвёртым пунктом добавили контроль: если сделка не перемещена в установленный срок, об этом должен узнать не только менеджер, но и контроль качества. Неделя 1: диагностика — сколько дел уже потеряно из виду С этого начнёте и вы: не с внедрения, а с честного замера. Вам понадобится список всех договоров в работе с датами — и готовность увидеть неприятную картину. Прежде чем чинить, подняли карточки сделок за три месяца. Картина оказалась хуже, чем думали. У части сделок дата плановой проверки стояла в прошлом, а сама сделка всё ещё висела на этапе «ожидание проверки» — то есть либо проверка не проводилась, либо результат никто не внёс. Это тот же класс сбоя, что мы разбирали в материале про то, как Битрикс24 сам сдвигает даты сделок : система не спорит с пользователем, если её об этом не попросили. Причина отказа, если её вообще писали, лежала свободным текстом в общем поле комментария — что-то вроде «не прошло, документов не хватило» вперемешку с другими заметками по сделке. Отдельно нашли соседнюю проблему на более раннем этапе цикла — «ожидание документов от клиента»: там скопилось 26–27 просроченных дел одновременно. Причина оказалась не техническая, а человеческая: менеджеры на продаже говорили клиентам, что спешить не нужно, можно прислать документы когда удобно. Это тот же класс проблемы — процесс не давит на дедлайн, пока кто-то не заставит систему это делать. Мы решили не чинить это отдельно, а сразу закладывать дедлайны и жёсткую фиксацию статуса во весь цикл согласования, а не только в точку финальной проверки. Этап цикла Что нашли (факт) Кто должен был заметить Ожидание документов 26–27 просроченных дел одновременно Менеджер — не заметил, срок не был зафиксирован в договоре Ожидание проверки Дата в прошлом, сделка не сдвинута Никто — система не фиксировала провал После отказа Причина в свободном тексте или отсутствует Менеджер — писал по памяти, если вспоминал Повторная подготовка Запускалась вручную, с задержкой 1–3 дня Контроль качества — не видел провалов вообще Неделя 2: первое решение — и что сразу сломалось Обратите внимание на этот этап: у вас будет так же. Я обжёгся здесь ровно тем же способом — первое решение ломается о привычки людей, а не о технику, и это нормальная часть пути, а не признак того, что вы что-то делаете не так. Добавили в CRM три вещи: отдельное поле «дата неуспешной проверки» (не путать с датой плановой), обязательное поле «причина отказа» с фиксированным списком из четырёх вариантов — критическое несоответствие данных, риски по контрагенту, недостаток документов, другое — и автоматическую задачу менеджеру на день проверки с двумя кнопками: «пройдена» и «не пройдена». На бумаге это закрывало всю дыру. На практике за первую неделю сломалось две вещи. Первое: менеджеры по привычке продолжали писать причину в старое общее поле комментария — новое обязательное поле физически существовало, но не было частью их рабочего маршрута, они его просто не видели. Мы уже сталкивались с похожей инерцией, когда разбирали, почему менеджеры не вносят данные в CRM , и решили не повторять ошибку уговоров, а сразу менять архитектуру полей. Второе: даже когда кто-то нажимал «не пройдена», сделка не откатывалась сама — это по-прежнему было ручным действием. То есть мы автоматизировали фиксацию факта, но не автоматизировали следствие. Менеджер видел на экране «не пройдена», разводил руками и всё равно тратил 20–30 минут (оценка) на ручной перенос сделки и повторную настройку задач — то есть время почти не сократилось по сравнению с полностью ручным процессом (≈35 минут на случай, оценка, — из расчёта в разделе про экономику ниже). Где ломается. Если новое обязательное поле не встроено в тот же экран, где менеджер и так работает — он его не заметит, сколько бы раз вы ни объясняли на планёрке. У нас поле стояло на вкладке «Дополнительно», а не на основной карточке сделки. Перенесли на первый экран — заполняемость выросла сразу, без единого разговора с отделом продаж. Скажу честно: я сам годами держал такие статусы в голове. Раз в неделю пробегал глазами по списку сделок, помнил, у кого что застряло, и был уверен, что процесс под контролем. Здесь ошибаются все, включая меня: пока провал не обязан появиться в системе, его в системе и не будет. Это не разгильдяйство менеджеров — это дыра в процессе, которую спроектировал руководитель. Неделя 3: ИИ-связка — автоматический откат и разбор причины Раз ручной откат не работает, решили убрать его из процесса вовсе. Как только менеджер выбирает «не пройдена», Bitrix24-вебхук должен сам: снять сделку с этапа проверки, поставить причину отказа, создать задачу на повторную подготовку и — отдельно — разобрать текстовый комментарий менеджера (если он есть) на структурированную категорию для аналитики, потому что «другое» без расшифровки бесполезно для отчётности. Схема конвейера: смена поля «Результат проверки» в сделке → триггер вебхука → сценарий в n8n на нашем сервере → вызов дешёвой модели для классификации комментария → запись категории обратно в сделку через REST API Bitrix24 → если сделка не сдвинута автоматом за час — сообщение в Telegram ответственному разработчику. Для классификации причины отказа модель не нужна дорогая — задача короткая, закрытый список вариантов, риск ошибки невысокий, а объём — до 12 сделок в месяц с отказом. Взяли модель уровня Haiku / GPT-4o-mini. Пример ответа модели: Второй промпт — сложнее и запускается реже: сверка комплекта договора с условной логикой пакета. У нас в договорах зашита подстановка: пакет «базовый» тянет за собой облегчённую услугу (инструкция по самостоятельной подготовке), пакет «расширенный» — полное сопровождение. Шаблон лежит в общем облачном хранилище, за его актуализацию отвечает юрист: старые версии архивируются, новая версия размещается под тем же названием файла. Проблема в том, что скрипт подстановки иногда путает пакеты, если менеджер поменял тип услуги в форме уже после того, как договор сформирован. Здесь нужна модель, которая понимает контекст текста договора, а не просто ищет ключевые слова — взяли уровень Sonnet. Из чего собирается сам шаблон и какие пункты в нём страхуют от суда — разобрал отдельно . Инженерная обвязка: все вызовы модели логируются в отдельную Google-таблицу — какая сделка, какой промпт, какой ответ, сколько токенов — по той же схеме, что мы уже обкатали на другой задаче с логированием обработки резюме через прокси-сервис. Отдельно подняли MCP-сервер поверх базы CRM: он даёт модели прямой безопасный доступ к нужным полям сделки без выгрузки лишнего контекста, это снижает расход токенов на 30–40% и уменьшает долю галлюцинаций на классификации. Ошибки — в Telegram-бот на ответственного разработчика, retry — три попытки с очередью, если сервис модели недоступен. Неделя 4: контроль качества и статусы без напоминалок Здесь ваша задача как руководителя — не дать процессу вернуться к ручным напоминаниям. Если статус приходится спрашивать голосом, система не работает, как бы красиво она ни выглядела на схеме. Отдельно добавили правило: если сделка с результатом «не пройдена» не переместилась на нужный этап автоматически в течение установленного срока — уведомление уходит не менеджеру, а контролю качества. Это страховка на случай, если сам вебхук упал или модель вернула низкую уверенность и пометила needs_manual_review. Тот же принцип контроля, не зависящего от памяти сотрудников, мы применяли для контроля дебиторки — работает он одинаково хорошо на любых зависающих статусах, не только на договорах. На этой же неделе всплыла идея с соседнего фронта — от координатора производственного цикла Димы, который держит статусы заказов в трёх табличках и каждую неделю делает «снимок» — фиксирует состояние на конкретный момент, чтобы через месяц видеть, где реально стояло дело, а не где его задним числом подвинули. «Если статус не менялся — ставь прочерк, не заставляй меня гадать, кто забыл нажать кнопку», — сказал он на общей планёрке, когда обсуждали именно эту проблему с забытыми откатами. Взяли этот принцип буквально: теперь каждую среду вечером система автоматически фиксирует текущий статус каждой сделки в отдельный столбец таблицы контроля. Новые столбцы добавляются слева от предыдущих — руководитель видит последние изменения без прокрутки. Если статус не изменился — прочерк, а не пустая ячейка, потому что пустая ячейка неотличима от «забыли посчитать». Таблица контроля — срез по средам Сделка 28.08 21.08 14.08 #48213 не пройдена — на проверке #48219 подписан на проверке — #48225 — не пройдена на проверке На диаграмме ниже — во сколько раз сократилось время на один случай отказа после того, как откат и классификация стали автоматическими. 35 мин было 3 мин стало Среднее время на один случай отказа: ручной откат и поиск зависшей сделки — против автоматического отката с классификацией причины (обе цифры — оценка). Что осталось нерешённым Дальше — честная часть, которую я в кейсах подрядчиков ни разу не встречал. У нас тоже не всё закрылось, и вам стоит знать, где будет сопротивляться ваш процесс. Три вещи мы сознательно не стали закрывать в этом же спринте. Первое — шаблоны договоров по-прежнему актуализирует юрист вручную в облачном хранилище, автоматической проверки версии (не устарел ли шаблон, из которого собран конкретный договор) пока нет. Это уже аукнулось на смежном участке: часть клиентов получила документы по старому шаблону, не соответствующему новым требованиям к комплекту, и застряла на этапе финальной проверки. По месяцам это выглядело неровно: например, около 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 ₽/мес прямой экономии времени. Чтобы прикинуть свой случай: возьмите долю сделок, которые у вас реально зависают на этапах согласования, умножьте на число сделок в воронке за месяц — получите число зависших; из них оцените долю тех, что срываются именно из-за забытого статуса, а не по объективным причинам, и умножьте на средний чек — получите сумму риска. Отдельно: возьмите разницу в минутах между ручной и автоматической обработкой одного случая отказа, умножьте на число таких случаев в месяц, переведите в часы и умножьте на часовую ставку сотрудника, который этим занимается, — получите экономию времени в деньгах. посчитайте на своих цифрах сделок в воронке / мес % зависших сделок % из них — из-за статуса средний чек, ₽ риск ≈ {X} ₽ в месяц формула: сделки × доля зависших × доля потерянных из-за статуса × чек (проценты приведены к долям); оценка сверху Сама по себе цифра экономии времени скромная. Я считаю главным эффектом не сэкономленные минуты, а в том, что 900 000 ₽ выручки, которые раньше утекали через забытый статус, теперь остаются в воронке — потому что зависшую сделку больше не нужно случайно заметить, система сама не даёт ей провисеть незамеченной. Эти два эффекта — снятый риск выручки и экономия времени — считаются раздельно и не складываются в одну сумму: первое про то, что не потеряно, второе — про то, что не потрачено. Показатель Значение Оборот в месяц 18 млн ₽ Средний чек сделки 150 тыс ₽ Сделок в воронке / мес 120 (18 000 000 ÷ 150 000) Доля зависших сделок (оценка) 10% → 12 сделок Из них теряется из-за забытого статуса (оценка 50%) 6 сделок Риск выручки 6 × 150 000 ₽ = 900 000 ₽ (оценка) Время на случай отказа до автоматизации ≈35 мин (оценка) Время на случай отказа после автоматизации ≈3 мин (оценка) Случаев отказа в месяц до 12 Экономия времени в месяц 32 мин × 12 = 6,4 часа Экономия времени в деньгах (ставка 1000 ₽/час, оценка) ≈6 400 ₽/мес Умение вынести собственную память в поле, которое система обязана заполнить, — такой же базовый навык руководителя, как чтение отчёта о деньгах. Я понял это поздно: пока причина отказа живёт в голове менеджера и в устном рассказе на планёрке, управления процессом нет — есть ощущение управления. Руководитель, который умеет заставить систему фиксировать плохие новости, стоит дороже того, кто узнаёт о них последним. Что сделать на этой неделе: попросите показать вам все договоры, которые сейчас на согласовании, с датой отправки. Не отчёт — реальный список. Обычно после этого разговор о необходимости менять процесс заканчивается сам собой: цифры убеждают лучше меня. Как собрать такой контроль так, чтобы он работал без вашего участия и напоминаний, — механика в бесплатном курсе : там же готовые постановки для разбора договоров машиной.

## Клиентский портал для бизнеса: когда нужен, а когда только кажется
URL: https://davidgerstein.pro/blog/klientskiy-portal-zachem/
Дата: 2026-08-12
Направление: Производственный цикл
Цифры: несколько десятков кейсов на пилот · 3000→80 мс отклик формы · ~88 ч/мес экономии (оценка)
Коротко: Клиентский портал даёт пользу, только если под ним уже есть чистые данные в CRM и понятный процесс обработки заявок: в разобранном кейсе один личный кабинет со статусами экономил отделу менеджеров около 88 часов рабочего времени в месяц (оценка). Если документы разбросаны по личным папкам и трём облакам, портал станет красивой витриной без содержания — время и бюджет уйдут в интерфейс, а не в снятую нагрузку с менеджеров.

Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Если вы уже обсуждаете с подрядчиком макеты личного кабинета, а на вопрос «где физически лежат документы клиентов» в вашей компании нет одного короткого ответа — вы покупаете не портал, а витрину над бардаком. Узнаете об этом через полгода, когда переделка будет стоить дороже, чем стройка с нуля. Клиентский портал — из тех вещей, которые все хотят и мало кому нужны. Разберу честно: когда он окупается, а когда становится дорогой игрушкой. Мы сейчас строим такой портал у себя — самообслуживание с нейросетью для анализа документов клиентов. Логика понятная: клиент сам загружает бумаги, система их проверяет, статус обновляется без звонка менеджеру. Я настоял на том, чтобы не запускать продукт целиком: сначала прогнать несколько десятков живых кейсов через алгоритм и отдать на проверку менеджерам. Только если результат подтвердится — тест на 20% клиентской базы. MVP запланирован к концу года, но уже сейчас понятно: месяцы уйдут не на код, а на то, чтобы данные вообще стали пригодны для обучения модели. Так происходит почти в любом подобном проекте: все хотят красивый личный кабинет, а упираются в то, что данные под ним не готовы. Менеджер тратит 5–10 минут на каждый ответ «на каком я этапе», при 30 активных клиентах на менеджера это набегает в часы каждую неделю. Расскажу, где портал реально экономит эти часы, а где он просто дублирует бардак, только с красивым интерфейсом. Нужен ли вам клиентский портал: проверка по 4 признакам Если на вопрос «где физически лежат документы клиентов» у вас нет одного короткого ответа — клиентский портал вам пока не нужен, каким бы хорошим ни был макет. Портал — это витрина поверх CRM: клиент сам видит статус заказа, документы и историю обращений, не звоня менеджеру, но данные берутся оттуда, где они уже лежат. Четыре признака, что портал пока не нужен: документы клиентов лежат больше чем в одном месте; однотипные вопросы отнимают у менеджеров меньше рабочего дня в неделю; статус клиента нельзя показать без пояснения менеджера; после запуска портал некому вести. Ни один признак не совпал — считайте экономику: в разобранном примере кабинет со статусами снимал с отдела из 15 менеджеров около 88 часов в месяц (оценка). Что такое клиентский портал и когда он нужен Клиентский портал — это раздел, где ваш клиент сам видит статус своего заказа, документы и историю обращений, не звоня менеджеру. Технически это витрина поверх вашей CRM: данные те же, доступ другой. Нужен он не тогда, когда «у конкурентов есть», а когда к вам не относится ни один из четырёх признаков: документы клиентов лежат больше чем в одном месте; однотипные вопросы съедают у ваших людей меньше рабочего дня в неделю; статус клиента нельзя показать без пояснения менеджера; после запуска портал некому вести. Совпал хотя бы один — вы строите красивый фасад, которым никто не пользуется. Ниже разбираю каждый признак по отдельности. Что показывать клиенту в кабинете Правило простое: показывайте то, ради чего вам звонят. Всё остальное можно не делать. Личный кабинет решает одну конкретную задачу — снимает с менеджера повторяющиеся вопросы. «На каком я этапе», «что ещё нужно прислать», «когда будет готово». Если поток клиентов идёт волнами, а вопросы предсказуемы, портал со статусами окупается быстро. Если вопросы каждый раз уникальные — портал не поможет, там нужен живой человек. В одной компании не стали ждать портал и завели двухуровневую систему статусов прямо в CRM. Каждую среду вечером система фиксирует актуальный статус клиента в отдельный столбец. Новые столбцы добавляются слева от старых — руководитель видит последние изменения сразу, без прокрутки. Если статус не поменялся — ставится прочерк, а не повторяется старое значение. Это не портал в классическом смысле, но принцип тот же: понятный, регулярно обновляемый статус вместо «спросите у менеджера». Для клиента полезная версия портала — не витрина с анимацией, а простой список: что загружено, что проверено, что ждём. Отдельная сложность — статусы, которые критичны, но неудобны для прямого показа. Пример: система долго не фиксировала случаи, когда клиент не прошёл внешнюю проверку. Менеджер вручную откатывал сделку назад и должен был удалить дату проверки — но часто забывал. В CRM месяцами висела дата «пройдено» у клиента, который проверку не прошёл. Решение мы собрали из четырёх частей: отдельное поле для даты неуспешной проверки — не путать с датой плановой проверки; обязательное поле с причиной отказа: фиксированный список вариантов, а не свободный текст; автоматическая задача менеджеру на день проверки с бинарным выбором «пройдена / не пройдена»; уведомление контролю качества, если сделка не перемещена в срок. Для клиентского портала вывод простой: статус «отказ» нельзя показывать как есть — нужна причина и понятный следующий шаг. Иначе клиент видит слово «отказано» и звонит в панике, а у менеджера нет готового ответа, потому что причину никто не зафиксировал в структурированном виде. Портал без порядка в CRM — красивый фасад Если у вас в CRM бардак, портал покажет клиенту ваш бардак — только быстрее и круглосуточно. Здесь вылезает главная проблема. В одной компании документы клиентов загружались в портал, там же формировались рекомендации — но данные не попадали в CRM автоматически. Получилась параллельная система: клиент видит один статус в портале, менеджер работает с другим в CRM. Пришлось вручную выгружать массив портала и сопоставлять с данными о клиентах, прошедших проверку с первого раза, чтобы вообще накопить материал для обучения модели. Похожая история с документами: менеджеры отмечали документы клиента как «в наличии», но не загружали сами файлы на сервер. Система при обучении начинала считать, что клиент может пройти проверку без документов — потому что видела только галочку, а не файл. Пришлось либо ретроспективно грузить все документы заново, либо жёстко обязывать менеджеров загружать файлы вперёд, до того как ставить галочку. Третий пример вообще не про портал, но про ту же болезнь. Новый сотрудник не работал в CRM: все документы клиентов хранились на его личном компьютере. Когда встал вопрос передачи дел, оказалось, что проанализировать кейсы и передать их другому менеджеру невозможно — данные существовали в единственном экземпляре на одном ноутбуке. Портал в такой ситуации бесполезен: показывать клиенту нечего, источника данных нет. Здесь ошибаются все, включая меня. Я долго смотрел в отчёт, где напротив клиентов стояли галочки «документы в наличии», и был уверен, что база готова к обучению модели. Файлов за галочками не было. Моя недоработка: я не проверил, что именно ложится в CRM, — принял отметку менеджера за факт и построил на ней план. Если у вас сейчас так же — это не приговор и не повод закрывать проект. Чинится одним правилом: файл сначала, галочка потом. Где ломается №1 Не начинайте разработку портала, пока не проверили, куда физически падают документы клиентов. Личный компьютер, Google Drive, NextCloud, локальные папки — если хотя бы часть данных живёт вне CRM, портал будет показывать неполную или устаревшую картину. Сначала наводите порядок в источнике, потом стройте витрину поверх него. Подробнее о том, как CRM врёт данными и почему сверку нужно вести по ID, а не по датам — в статье про сдвиг дат в Bitrix24 . Разработка клиентского портала: сколько стоит и с чего начинать Вопрос про деньги обычно звучит первым, поэтому отвечу прямо: разработка клиентского портала стоит ровно столько, сколько стоит порядок в данных под ним. Сам интерфейс — самая дешёвая часть проекта. Порядок расходов на нашем опыте: собрать рабочий экран со статусами и загрузкой документов — недели, а не месяцы, если данные уже лежат в одном месте. Если не лежат — сначала считайте наведение порядка в учёте, и это основная статья. Портал поверх кривых данных обойдётся дороже вдвое: сперва заплатите за разработку, потом за переделку. С чего начинать. Не с дизайна и не с выбора подрядчика, а с одного вопроса: какие три вещи клиент спрашивает у менеджера чаще всего? Обычно это статус заказа, какие документы ещё нужны и когда будет результат. Портал, который отвечает на эти три вопроса без человека, уже окупается — всё остальное можно добавлять потом. Что бывает, когда портал собирают наоборот — от интерфейса, — показал на 12 страницах одного скрипта . Обработка заявок: автоматизация, которая не роняет данные Если портал принимает заявки от клиентов напрямую — форму обратной связи, загрузку документов, запрос статуса — узкое место чаще не в интерфейсе, а в приёмнике данных. В одном проекте разработали плагин для формы, который снизил время отклика с 3 секунд до 80 миллисекунд (на диаграмме — до и после), и добавили буферизацию заявок на случай сбоя приёмщика. Раньше при падении системы заявка терялась молча. Теперь она встаёт в очередь и обрабатывается, как только сервис поднимается. Решение признали достаточно надёжным, чтобы раскатать на всю группу компаний. 3000 мс было 80 мс стало Отклик формы обратной связи снизился благодаря новому плагину и буферизации заявок на случай сбоя приёмщика. Второй пример из той же области — обработка заявок через API: данные шли из портала в облачную систему анализа, потом записывались в таблицу. Проблема была в том, что разработчик не видел баланс своей учётной записи и не мог отследить, где заявка потерялась. Решили логировать каждое действие процесса в общую таблицу через прокси-сервис — теперь видно три категории: успешно обработано, не обработано, ошибка. Похожий отчёт получается на выходе — примерный вид такой таблицы ниже. Без такого лога любая автоматизация заявок превращается в чёрный ящик: заявки вроде идут, но проверить это можно только руками, перебирая переписки. Лог обработки заявок — прокси-сервис 3 категории статуса Заявка Статус doc_00918 успешно обработано doc_00919 не обработано doc_00920 ошибка Логика простая: любая точка входа заявок с портала должна иметь буфер и лог. Иначе одна ночь падения сервиса — и вы теряете клиентов, даже не зная, сколько именно. ИИ-связка: конвейер анализа документов и промпт Конвейер, который реально работает в разобранных кейсах, выглядит так: Клиент загружает документ в портал → OCR распознаёт текст → дешёвая модель определяет тип документа → к типу применяется своя спецификация → при необходимости включается более мощная модель для сложного случая → результат уходит менеджеру на проверку → подтверждённые данные попадают в CRM как обучающий пример. Два момента здесь стоили нам нескольких недель работы. Первый: распознавание внутри самого сервиса модели работало отлично, а при запуске через API повёрнутые документы переставали распознаваться корректно. Решение — не гнать всю базу разом. Собрали компактную выборку типовых примеров, обучили стажёра проверять результат вручную и написали отдельные спецификации под каждый тип документа: как модель путает имена и фамилии, пропускает отчества, сбивается на вертикально загруженных сканах. Второй момент: OCR внутри системы и OCR при передаче документов по API давали разное качество — потребовался отдельный протокол выбора модели под тип документа и почерк. Ниже — рабочий промпт для этапа «определение типа документа + первичная оценка кейса». Это дешёвая модель (например, класс Haiku/GPT-4o-mini) — задача простая, классификационная, дорогая модель здесь избыточна и увеличивает счёт без пользы. Пример ответа модели на такой запрос: Если need_strong_model = true — документ уходит на второй проход к более мощной модели с расширенным промптом, который уже включает спецификацию под конкретный тип и просит выделить уязвимости кейса (недостающие поля, нечитаемые фрагменты, признаки старого шаблона документа). Это тот самый многоступенчатый анализ: дешёвая модель фильтрует основной поток, дорогая разбирает только спорные 20–30% случаев. Инженерная обвязка. Всё крутится вокруг трёх узлов: облачное хранилище документов (единая точка вместо трёх), прокси-сервис, который логирует каждый вызов модели в таблицу (успех / ошибка / нет ответа), и вебхук в CRM, который обновляет карточку клиента только после подтверждения менеджером. Один рабочий MCP-server поверх базы CRM даёт ИИ-инструментам прямой доступ к данным компании без ручного экспорта — по нашему опыту это снижает расход токенов на 30–40% и уменьшает долю галлюцинаций модели, потому что она не пытается угадывать контекст, а получает его напрямую. Перезапуск — по крону раз в час: проверяются документы со статусом «в очереди» дольше часа, они переотправляются автоматически. Об ошибке система сообщает записью в лог-таблицу с кодом ошибки и document_id, а не молчанием — это правило родилось из той самой истории с потерянным балансом, о которой я писал выше. MVP вместо релиза Ваш первый портал должен закрывать один вопрос клиента, а не тридцать. Дальше вы будете достраивать по обратной связи, а не по фантазии. Соблазн — запустить портал сразу целиком, с красивым дизайном и всеми функциями. Одна команда так и сделала со страницами сайта: собрали больше десятка типов страниц одним скриптом, который должен был соблюдать брендбук. Результат не соответствовал ни стилю, ни гайдлайнам. Руководитель не стал доводить каждую страницу до идеала — взял утверждённый прототип главной как эталон и пересобрал все типы заново с участием команды, через полноценный аудит. В итоге ушло больше времени, чем если бы сразу заложили ревью на старте вместо попытки автоматизировать всё скриптом. Другой случай — тот же урок, но с чужим конструктором распознавания документов: разработчик собрал систему на основе крупного массива вопросов из публичного источника, а при передаче техническому лиду она не собралась. «Получается красивый дом, но дверей нету, как зайти — непонятно». Это ровно тот риск, который снимает поэтапный пилот вместо разового релиза. Этап Что делали Зачем 1. Пилот на живых кейсах Несколько десятков реальных случаев прогнали через алгоритм, отдали менеджерам на проверку Проверить корректность без риска на всей базе 2. Тест на сегменте 20% клиентской базы, оценка отклика рынка Понять, нужен ли портал клиентам вообще, до вложений в MVP 3. Сбор данных полгода Накопление массива для обучения модели Без объёма данных нейросеть в портале не заработает 4. MVP к концу года Запуск ограниченной версии Только после проверки качества на двух предыдущих этапах На диаграмме ниже — примерная длительность каждого этапа: от короткого пилота до MVP в конце года. Пилот: живые кейсы ~2 недели Тест: сегмент клиентов ~2 месяца Сбор данных до объёма ~6 месяцев MVP запуск конец года Та же логика повторилась и с документами — той самой компактной выборкой и стажёром, о которых я писал выше: сначала маленькая выборка с ручной проверкой, потом спецификации под каждый тип. Дешевле, чем гнать автоматизацию сразу на всей базе данных и потом переделывать модель с нуля. Про то, как ИИ-система теряет точность на нестандартных документах и что с этим делать пошагово, — в статье про рост распознавания с 59% до 85% . Экономика: что портал стоит и что даёт Считаю раздельно три эффекта — их нельзя складывать в одну цифру, потому что это разные инициативы с разной механикой. Возьмём для примера условную компанию: производство на заказ, отдел из 15 менеджеров, оборот ~18 млн ₽/мес, средний чек около 120 000 ₽ — то есть примерно 150 сделок в месяц на весь отдел. Формула для каждого эффекта — часы × поток клиентов × доля повторяющихся вопросов, чтобы вы могли подставить свои цифры вместо примерных. Эффект статусов (снятые вопросы «на каком я этапе»). Оценка: отдел из 15 менеджеров, у каждого в работе около 12 клиентов на этапе ожидания документов. По грубой оценке 30% из них раз в день пишут с вопросом статуса (около 4 вопросов), на ответ уходит примерно 5 минут. Это около 20 минут в день на менеджера, или около 6 часов в месяц (оценка, 22 рабочих дня). На весь отдел — около 88 часов рабочего времени в месяц (оценка). Это эффект именно личного кабинета со статусами, отдельно от MVP с нейросетью — статусы можно и нужно внедрить до всякого ИИ. Эффект буферизации заявок. Отдельная мера, отдельный эффект. Если форма без буфера падает в сумме на условные 2 часа в месяц (оценка) при потоке около 30 заявок в день, то за это время теряется молча несколько заявок. При исторической конверсии обращения в сделку ≈20% (оценка) это означает риск потери около одной оплаченной сделки в месяц — то есть каждая пятая из молча потерянных заявок могла бы стать клиентом. При среднем чеке 120 000 ₽ это риск около 120 000 ₽/мес (оценка). Это тот риск, который снимает не портал целиком, а конкретно буфер и лог на приёмнике формы — недорогая доработка с ощутимой отдачей. Стоимость пилота с нейросетью. Проверка живых кейсов менеджерами — оценочно 15 минут на кейс, итого около 10 часов работы менеджеров на первый круг проверки. При ставке ~1 000 ₽/час (оценка) это около 10 000 ₽ разовых затрат — на порядок дешевле, чем сразу запускать MVP на всей базе клиентов и потом переделывать модель, которую обучили на «галочках без файлов». Эффект Оценка Что конкретно даёт Статусы в личном кабинете ~88 ч/мес (оценка) Снимает вопросы «на каком я этапе» с отдела менеджеров Буферизация заявок ~1 сделка/мес риска, ~120 000 ₽/мес (оценка) Не теряет молча несколько заявок при сбое формы Пилот ИИ-анализа (разово) ~10 ч, ~10 000 ₽ (оценка) Проверка живых кейсов менеджерами перед тестом на сегменте Итог: личный кабинет со статусами и буферизация заявок окупаются почти сразу и не требуют нейросети вообще. ИИ-часть портала (анализ документов) — самая дорогая и самая долгая по времени составляющая, её эффект проявится не раньше, чем накопится обучающий массив, то есть не раньше MVP к концу года. Чтобы прикинуть свой случай: возьмите число менеджеров, среднее число активных клиентов на менеджера, долю вопросов о статусе в день и свою историческую конверсию — и посчитайте по той же формуле. Когда клиентский портал для бизнеса не нужен вообще Если у вас пять пересекающихся процессов внутри одного проекта — сбор документов, исследование, редактура, вёрстка, производство — и вы ещё не свели их в одну воронку внутри CRM, портал только добавит путаницы. В одном таком проекте решили не делать пять отдельных воронок, а собрать одну главную с проект-менеджером как фасадом и вложенными смарт-процессами внутри, чтобы руководитель видел итоговый процент готовности без погружения в десятки деталей. Это заняло меньше ресурсов, чем разработка внешнего портала, и решило ту же задачу — прозрачность для того, кто принимает решения. Проверка занимает пять минут: четыре признака, каждый из которых означает «портал вам пока не нужен». Хватает одного совпадения, чтобы отложить разработку и заняться тем, что под ней. Признак 1. Документы клиентов лежат больше чем в одном месте. Личные компьютеры, пара облаков и CRM — портал покажет клиенту не всю картину, а ту часть, которая случайно попала в систему. Сначала одно хранилище, потом витрина над ним. Признак 2. Однотипные вопросы отнимают у менеджеров меньше рабочего дня в неделю. Экономить нечего: отвечать руками дешевле, чем строить и потом поддерживать интерфейс. Признак 3. Статус клиента нельзя показать без пояснения менеджера. Пока нет фиксированного списка причин и следующего шага, слово «отказано» в кабинете читается как приговор — телефон зазвонит чаще, а не реже. Признак 4. После запуска портал некому вести. Нет владельца и нет записанной инструкции по интеграции — через полгода никто не вспомнит, какие поля куда уходят, и любая правка встанет. Обратите внимание: три признака из четырёх — про данные и процесс, и ни один не про дизайн. Портал не чинит то, что сломано под ним. Где ломается признак 4 Портал легко превращается в проект без документации. У нас были случаи, когда знания о настройке интеграции передавались только устно, «под диктофон», а таблиц и регламентов не оставалось вообще. Если человек, который настраивал вебхук между порталом и CRM, уходит — новый сотрудник тратит дни на то, чтобы понять идентификаторы полей, которые нигде не записаны. Пишите инструкцию сразу, а не «когда будет время». Если хотя бы один признак про вас — сначала чинить его, а потом думать про интерфейс. Иначе получится история про «красивый дом без дверей»: интерфейс готов, а зайти в него системно нельзя, потому что данные под капотом рассинхронизированы. Чек-лист: с чего начать в понедельник Проверьте, где физически хранятся документы клиентов сейчас — сколько источников (личные компьютеры, облака, CRM) участвуют в одном процессе. Посчитайте, сколько раз в день менеджеры отвечают на вопрос «на каком я этапе» — это и есть будущая экономия от статусов, а не от всего портала целиком. Добавьте буфер и лог на любую точку приёма заявок с сайта или портала — это дешевле и быстрее, чем весь остальной проект. Заведите фиксированный список причин отказа/статусов вместо свободного текста — без этого показывать статус клиенту нечестно. Если планируете ИИ-анализ документов — начните с небольшой выборки живых кейсов и ручной проверки, а не с запуска на всей базе. Запишите инструкцию по интеграции (вебхук, идентификаторы полей) в документ, а не оставляйте знание в голове одного разработчика. Если у вас автоматизация уже работает, но требует, чтобы кто-то за ней постоянно следил — это отдельная и очень частая проблема, разобрана в статье про автоматизацию, которая становится второй работой . Проверьте себя тремя вопросами: сколько однотипных запросов приходит вашим менеджерам за неделю, сколько времени уходит на ответы и жалуются ли клиенты на непрозрачность. Если по всем трём цифры высокие — портал вам нужен. Если нет — займитесь тем, что болит. Как считать окупаемость таких проектов — в бесплатном курсе . Как решать вам Мой критерий после нескольких таких проектов: портал оправдан, когда однотипные вопросы клиентов съедают у ваших людей больше рабочего дня в неделю. Меньше — дешевле отвечать руками и вложиться во что-то другое. И не стройте сразу большой: наш первый рабочий вариант закрывал ровно один вопрос — «на каком этапе мой заказ». Этого хватило, чтобы снять половину звонков. И то, что я вынес из этих проектов главным. Умение посмотреть на свой процесс и сказать «вот здесь машина справится, а вот здесь под ней нет данных» — это отдельный управленческий навык, и его придётся освоить. Раньше руководителя мерили тем, как он раздаёт задачи людям. Сегодня дороже стоит тот, кто умеет масштабировать процесс через машину и до старта видит, где витрину ставить не на чем. Портал этот навык проверяет быстро и без пощады: либо вы посчитали часы и источники данных заранее, либо оплатили красивый фасад. Посчитайте свои однотипные вопросы за неделю — эта цифра и ответит вам, нужен ли портал сейчас или ещё рано.

## Контроль сроков выполнения заказов: как перестать узнавать о срыве от клиента
URL: https://davidgerstein.pro/blog/sroki-vypolneniya-zakazov/
Дата: 2026-08-10
Направление: Производственный цикл
Цифры: 8 из 75 сделок зависает на одном этапе (~10%) · около 20 случаев в месяц требуют ручного разбора причины · 3 неответа клиента = отказ по договору
Коротко: Контроль сроков выполнения работает, если срок прописан в договоре, статус фиксируется автоматически без участия менеджера, а причина просрочки — обязательное поле, а не свободный текст. В отделе из 8 менеджеров при 75 сделках в работе одновременно без такой системы зависает до 8 сделок на одном этапе (около 10%) — и директор узнаёт об этом последним, от самого клиента.

Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные. Если вы не можете прямо сейчас, за минуту, назвать три заказа, которые стоят дольше норматива, — у вас нет контроля сроков. У вас есть система оповещения через скандал: вы узнаёте о срыве от клиента, а не до него. И узнаёте последним — раньше вас об этом знали менеджер, клиент и, скорее всего, ваш конкурент, которому клиент уже позвонил. Разбираю, как мы это чинили: без новых систем и без найма, одной перестройкой того, что уже было. Что такое контроль сроков выполнения Контроль сроков выполнения — это когда норматив на каждый этап заказа зафиксирован как обязательство, система сама считает дни в статусе и при превышении норматива пишет ответственному, а не ждёт, пока кто-то откроет отчёт. Он держится на трёх опорах: срок прописан в договоре, статус фиксируется автоматически без участия менеджера, причина просрочки — обязательное поле со списком значений, а не свободный текст. Без этих трёх опор в отделе из 8 менеджеров при 75 сделках в работе зависает до 8 сделок на одном этапе — около 10% активного портфеля, — и руководитель узнаёт о срыве последним, от самого клиента. В отделе из 8 менеджеров при обороте около 9 млн ₽/мес и среднем чеке 180 тыс. ₽ одновременно в работе держится порядка 75 сделок — так диктует цикл сделки около 6 недель. В какой-то момент 8 из этих 75, то есть каждая девятая, зависли на этапе «документы запрошены». Не на день, не на неделю — достаточно долго, чтобы это стало заметно в отчёте. Разбор показал причину: продавцы на этапе продажи говорили клиентам «спешить не нужно, можно начать когда угодно». Клиент расслаблялся. Документы не присылал. Формально сделка жила, фактически — стояла. Контроль сроков выполнения заказов в этой компании до того момента держался на памяти менеджера и на том, вспомнит ли он позвонить клиенту через месяц. Похожая история, только с другим механизмом сбоя. В феврале из-за несинхронизированного изменения требований к пакету документов зависло 9 сделок, в апреле — всего 1, а за первую неделю мая снова 6. Требования изменились, а процесс не подхватил изменение вовремя. И есть отдельный риск: если ошибка повторится с крупным клиентом, под удар попадёт не только конкретная сделка, но и репутация компании при следующем тендере. Оба случая — не про недобросовестных сотрудников. Про то, что срок выполнения заказа нигде не был зафиксирован как обязательство, а отклонение от него нигде не всплывало само. Если у вас в CRM статус сделки — это то, что менеджер поменял вручную, когда вспомнил, — вы уже в этой ситуации, просто ещё не увидели цифру. Почему вы узнаёте о срыве от клиента У нас так было полгода: я узнавал о просрочках из претензий, а мои руководители — от меня. И первое, что я сделал, было ошибкой: я собрал людей и потребовал «внимательнее вести CRM». Полтора месяца стало чуть лучше, потом всё вернулось. Это моя недоработка, не их: я требовал дисциплины там, где не было ни зафиксированного срока, ни сигнала о его нарушении. Если вы сейчас на этой стадии — это нормально, здесь спотыкаются все, включая меня. Три причины, и ни одна не про безответственность ваших людей. Классическая цепочка: клиент звонит недовольный, менеджер оправдывается, директор лезет в CRM и видит, что сделка «висит» уже два месяца без движения. При этом статус в системе формально корректный — просто никто не смотрел, сколько дней он не менялся. Дело не в CRM. Статус там — это то, что менеджер отметил в последний раз, а не сигнал о том, что дело зависло. Разбор с этапом внешней проверки показал то же самое: система вообще не фиксировала случаи неуспешного прохождения. Менеджер вручную откатывал сделку назад и должен был удалить дату проверки — и часто забывал это делать. Тогда в отчётах числилась проверка, которой не было, а реальный срок молчаливо съезжал. Где теряется история Ручной откат сделки назад — это точка, где теряется вся история просрочки. Если человек вручную возвращает статус, он с высокой вероятностью забудет зафиксировать причину. Автоматизировать нужно не «красивый дашборд», а именно момент отката. Что добавили под этап проверки Решение получилось не про интерфейс, а про обязательные поля и таймер: отдельное поле даты неуспешной проверки — не путается с датой планируемой; обязательная причина отказа с выбором из списка (документы, оплата, согласование, другое) — без свободного текста, который никто потом не читает; автоматическая задача менеджеру ровно в день проверки с двумя вариантами ответа: пройдена / не пройдена; уведомление контролю качества, если сделка не перемещена на новый этап в установленный срок. Последний пункт — самый важный. Не начальнику менеджера, а именно контролю качества, отдельному от продаж человеку. Это разрывает зависимость контроля от того, кто заинтересован в красивой отчётности. Статусы для клиентов: снимок, а не текущее значение Если статусы вы планируете показывать клиенту сами — смотрите разбор про клиентский портал : что выводить, а что оставить внутри. Тонкость, которая спасёт вас от споров: клиент должен видеть, что было обещано изначально, а не только то, что стало после сдвигов. Отдельная ловушка — когда статус в CRM это один и тот же столбец, который менеджер просто меняет по ходу дела. Тогда невозможно понять, сколько дней клиент провёл на каждом этапе и когда именно случился затор. Рабочее решение — двухуровневая фиксация. Раз в неделю, в фиксированный день (в разобранном случае — среда вечером), система автоматически записывает актуальный статус каждого клиента в отдельный столбец. Новый столбец добавляется слева от предыдущих — так руководитель видит последние изменения без прокрутки таблицы вправо. Если статус не поменялся, ставится прочерк — это тоже сигнал, причём часто более тревожный, чем смена статуса. CRM · Срез статусов · среда, 18:00 8 из 75 сделок на этапе «документы запрошены» Клиент 29.05 22.05 15.05 Иванов А. — Документы запрошены Документы запрошены Петрова М. Проверка назначена Документы запрошены — Сидоров К. — — Документы запрошены По такому снимку видно не только «где клиент сейчас», но и «сколько недель он там стоит» — это и есть данные для поиска системных заторов вроде описанной выше группы из 8 сделок на «документах запрошены». Февраль 9 сделок Апрель 1 случай Май, 1-я неделя 6 сделок На диаграмме — сделки, зависшие из-за устаревшего шаблона документов, по месяцам. Провал в апреле — не решение проблемы, а просто меньше сделок в этом месяце в целом: сама причина (несинхронизированное изменение требований) устранена не была, поэтому в мае объём снова вырос. Про то, как CRM вообще может искажать даты и вводить в заблуждение при построении отчётов, у меня был отдельный разбор — CRM врёт. Как я поймал Битрикс24 на сдвиге дат . Если статусы «сами меняются» без видимой причины, начинать нужно оттуда. Автоматические алерты: что это и как их ставить Автоматический алерт — это сообщение, которое система отправляет сама при нарушении срока, без участия менеджера. Разница с отчётом принципиальная: отчёт надо открыть и прочитать, алерт приходит к тому, кто должен действовать, в момент, когда действовать ещё не поздно. Рабочая настройка выглядит так. У каждого этапа есть норматив в днях. Система считает дни в статусе и при превышении отправляет сообщение ответственному — в мессенджер, а не в журнал. Если через сутки статус не изменился, второе сообщение уходит его руководителю. Ключевое, что делает алерты рабочими, а не фоновым шумом: сообщение должно требовать действия, а не сообщать факт . «Заказ №142 стоит в сборке 6 дней при нормативе 3 — что делаем?» работает. «Просрочено заказов: 7» не работает, потому что непонятно, чьё это и что с этим делать. Договор: первая линия контроля сроков выполнения Посмотрите свой типовой договор: там вообще указан срок и что происходит при его сдвиге? У половины компаний это формулировка ни о чём. Самая дешёвая мера сработала лучше остальных. В договорах с клиентами не был прописан срок действия контракта. Для аналитики это было критично: без даты «когда услуга должна быть выполнена» нельзя посчитать просрочку в принципе — не с чем сравнивать. Решение простое на бумаге: внести в регламент требование прописывать сроки для стандартных работ. Для специальных, нетиповых видов работ срок сознательно опускается — не нужно натягивать обязательство там, где реальная зависимость от третьей стороны (например, ожидание документа от внешнего ведомства или партнёра — до пяти месяцев) делает жёсткий срок бессмысленным и даже опасным для компании. Второй пункт в договор — условие про отказ клиента от контакта. Если клиент не отвечает три зафиксированных раза, это считается отказом от услуги. Формулировка защищает компанию от ситуации, когда сделка формально «активна», а по факту клиент пропал на полгода, и именно на это время растягивается статистика просрочек, за которую отвечает менеджер. Правило Если срок не зафиксирован в договоре, любая система статусов будет показывать красиво оформленную неопределённость. Автоматизация фиксации не заменяет обязательство — она делает видимым его отсутствие. Что происходит, когда данные живут в головах Ваш риск здесь не в потере файлов, а в том, что статус заказа знает только один человек — и он в отпуске. Ещё один источник просрочек — не процесс, а место, где хранятся данные. В одном случае новый сотрудник вообще не работал в CRM: все документы клиентов лежали на личном компьютере. Проанализировать кейсы или передать дела другому менеджеру было физически невозможно — данные просто не существовали для системы. При уходе менеджера в отпуск в другой компании нашли рабочий обходной путь: документооборот вели через общую таблицу со всеми контрактами. Назначенный сотрудник сверял поступление документов по фамилиям и отмечал в таблице, руководитель подтверждал и уведомлял клиентов. Это не идеальное решение — но оно централизованное, и любой человек может подхватить процесс без раскопок в личных папках. Похожая картина была с сотрудником, который собирал документы по клиентам для дальнейшей передачи подрядчикам: у него не было доступа в CRM, вся координация шла через переписки и локальные папки. При передаче проекта выяснилось, что клиентская информация рассредоточена и недоступна команде — историю работы пришлось восстанавливать заново, потому что фиксировалось всё «под запись, под диктофон» — ни таблиц, ни регламентов. Про то, почему менеджеры вообще избегают вносить данные в общую систему, я разбирал отдельно в статье Менеджеры не вносят данные в CRM — это не про лень, а часто про неудобный интерфейс и отсутствие обратной связи от системы. ИИ-связка: классификация причин просрочки Мы завели её после того, как я устал слышать «так вышло»: машина раскладывает причины по типам, и становится видно, что половина срывов — не вина исполнителей. Здесь вы получаете не факт «сорвали», а причину — и по ней уже видно, чинить процесс или разговаривать с конкретным исполнителем. Обязательное поле «причина отказа» решает проблему только наполовину: менеджер может выбрать «другое» и написать в комментарии два слова. Дальше это невозможно агрегировать — приходится читать вручную десятки карточек. Здесь и появляется задача для модели: не принимать решение вместо менеджера, а привести его текст к структуре, по которой уже можно строить отчёт. Конвейер выглядит так: Bitrix24: смена стадии сделки → вебхук уходит во внешний обработчик. Облачная функция передаёт комментарий менеджера в дешёвую модель для классификации. Модель возвращает категорию и дату повтора — функция записывает их обратно через REST API. Каждый шаг логируется; при сбое — алерт в Google Sheets и чат контроля качества. Шаг 1: в Bitrix24 настраивается автоматизация — при переводе сделки на стадию «проверка не пройдена» вебхук отправляет во внешний обработчик JSON с данными сделки и комментарием менеджера. Пример того, что летит на вход: Шаг 2: этот JSON вместе с промптом уходит в дешёвую модель (обобщённо — модель класса GPT-4o-mini или Claude Haiku: задача простая, классификация короткого текста по фиксированному списку, дорогая модель здесь избыточна и просто дороже на объёме в пару десятков кейсов в месяц). Промпт: Пример ответа модели на вход выше: Шаг 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 и текстом ошибки, карточка помечается на ручную обработку. Никакой сделки, которая должна получить статус, нельзя оставлять «зависшей» без сигнала о том, что автоматика не сработала — иначе получаем ту же тишину, из-за которой директор узнаёт о срыве от клиента. Где ломается автоматика Модель на входе видит только комментарий менеджера — если он пишет «клиент не смог» без деталей, категория уйдёт в «другое» с низким confidence, и карточку всё равно придётся разбирать вручную. Классификатор снимает рутину с однозначных случаев, но не заменяет обязанность менеджера писать по существу. Экономика: сколько стоит и когда окупается Считайте от ваших потерь: сорванный срок — это не только штраф, но и клиент, который в следующий раз пойдёт к другому. Настройка обязательных полей, автозадачи и вебхука с классификатором занимает около 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 ₽/мес — счёт идёт на рубли, а не на тысячи, если не гонять через неё документы целиком. Показатель Значение (оценка на условном примере) Активных сделок в работе одновременно 75 (отдел из 8 менеджеров) Зависших дел без движения в месяц 8 (~10% портфеля) Риск срыва/потери дела в месяц 2 сделки × 180 тыс. ₽ = 360 000 ₽ Ручной разбор без автоматизации ~5 часов/мес (≈5 000 ₽) Разовое внедрение (поля + автозадача + классификатор) 18-25 часов специалиста (18 000-25 000 ₽) Окупаемость по экономии времени 4-5 месяцев Эксплуатация классификатора в месяц 100-300 ₽ Так эти цифры будут выглядеть на экране отчёта, который стоит собрать перед внедрением: Отчёт: экономика контроля сроков 8/75 сделок зависло без движения 360 000 ₽ риск потерь в месяц 18-25 ч разовое внедрение 4-5 мес окупаемость по времени Чтобы прикинуть свой случай: возьмите число активных сделок в работе, оцените долю зависших без движения по своему отчёту (не по этой статье), умножьте на средний чек и на реальную долю срывов из своей практики — цифры в этом разделе служат ориентиром для расчёта, а не готовым ответом. Чек-лист: с чего начать в понедельник Выгрузить из CRM все сделки, которые не меняли статус дольше двух недель, и посчитать долю от общего активного портфеля — это ваша реальная цифра вместо оценки из этой статьи. Проверить 10 случайных договоров за последний месяц на предмет прописанного срока выполнения для стандартных работ. Если срока нет — это первая правка в регламент, дешевле любой автоматизации. Сделать причину отказа/просрочки обязательным полем с фиксированным списком значений вместо свободного текста — хотя бы вручную, без интеграции с моделью. Настроить один автоматический снимок статуса раз в неделю в отдельный столбец (можно начать с Google Sheets и ручного экспорта, не обязательно сразу вебхук). Назначить, кто получает уведомление о просрочке этапа — не непосредственный руководитель менеджера, а независимый контроль качества. Если решите автоматизировать классификацию причин — начните с 10-15 реальных кейсов и дешёвой модели, проверяя результат вручную, прежде чем доверять полю в CRM. Похожий принцип — не чинить симптом, а искать место, где система молчит вместо того чтобы сигналить, — разбирал и в материале про автоматизацию, которая требует надзора . Контроль сроков без такого надзора рано или поздно превращается в ещё одну красивую таблицу, за которой всё равно нужно ходить и проверять руками. Начните с замера на этой неделе: возьмите десять последних заказов и посмотрите, сколько из них сдано в обещанный срок. Цифра обычно ниже, чем ощущение, — и именно она даёт основание что-то менять. Как поставить контроль сроков, который предупреждает заранее, — механика в бесплатном курсе для руководителей . Что я понял про сроки Мы годами считали срывы виной исполнителей и разбирали каждый случай отдельно. Когда собрали статистику причин, картина изменилась: больше половины просрочек начиналось не у исполнителя, а на входе — заказ приняли без реального срока, согласовали устно, никто не зафиксировал. И ещё одно, чего я не понимал раньше. Умение построить так, чтобы о просрочке мне сообщала машина, а не клиент, — это не «настройка CRM». Это отдельный управленческий навык, и его придётся освоить так же, как когда-то осваивали бюджетирование. Руководитель, который держит сроки системой, стоит дороже руководителя, который держит их своей памятью и обзвоном по пятницам. Память кончается на тридцатой сделке. Система — нет. Ваш вывод из этого простой: прежде чем спрашивать с людей, проверьте, есть ли у них шанс уложиться. Часто выясняется, что срок им никто и не называл.

## Распознавание первичных документов и своего потока: точность с 59% до 85% без смены модели
URL: https://davidgerstein.pro/blog/raspoznavanie-dokumentov-59-85/
Дата: 2026-07-18
Направление: Производственный цикл
Цифры: 79 типов · точность 59% → 85% · полтора часа на комплект → минуты
Коротко: Первый запуск распознавания первичных документов и собственного потока бумаг почти у всех даёт около 59% — и на этом большинство закрывает тему, решив, что «модель не тянет». Путь до 85% проходится без смены и дообучения модели: работает не она, а организация вокруг неё — спецификация на каждый из 79 типов документов, режимы доверия (авто / с проверкой / только руками) вместо тотальной автоматизации и дорогая модель только там, где она нужна. Побочный результат: полтора часа разбора комплекта превратились в минуты, а качество перестало зависеть от того, как привык раскладывать документы конкретный менеджер.

Суммы и объёмы в разборе пересчитаны на условную компанию — механика и выводы реальные. Если вы пробовали распознавание первичных документов — счетов, актов, накладных, а следом и собственного потока справок и договоров — и бросили, почти наверняка вы остановились на 59%. Не буквально на этой цифре, но в этом районе: система вроде работает, но перепроверять приходится всё, менеджеры плюются, и через месяц все возвращаются к ручному вводу с чувством «ну я же говорил». Мы стояли ровно там же. Разница только в том, что не бросили — и выяснили вещь, которая переворачивает подход: эти 59% не имеют отношения к качеству модели. Мы подняли точность до 85%, не обучая и не меняя модель вообще. Всё, что дало прирост, — организация вокруг неё. Ниже — что именно делать, по слоям, с честными цифрами и с местом, где ломаются почти все готовые решения. Распознавание первичных документов: почему первый прогон даёт около 59% Речь о рабочем потоке компании — счета, акты, накладные, справки, договоры с приложениями, а не о том, как вытащить текст из одной фотографии. Первый прогон проваливается потому, что модель работает без эталонного набора и без правил разбора спорных случаев. 59% — типовой результат первого прогона, и на нём большинство закрывает тему, решив, что технология не тянет. Ту же связку удалось довести до 85% на 79 типах документов , не меняя модель: собрали эталоны, описали правила для спорных полей, прогнали циклы сверки. Время на комплект упало с полутора часов до минут. Откуда берутся 59% Сначала про цифру, потому что её обычно считают нечестно. Стартовую точность мы считали по ключевым полям — фамилии, имена, даты, номера, то, из-за чего документ вообще обрабатывают. На реальном потоке, сверкой с человеком. Не «доля распознанных документов», а доля полей, которые можно не перепроверять . Разница принципиальная: вендор покажет вам первое, работать вы будете со вторым. И ещё одно, из-за чего цифры вендоров и ваши никогда не сойдутся: они считают на своей тестовой выборке, вы живёте на своём потоке. Пока не прогнали свои документы — любая обещанная точность к вам отношения не имеет. 59% — это типичный результат схемы «модель как есть плюс универсальный промпт». И вот где на самом деле лежат потери: система не знает, что за документ перед ней; не знает, какие поля в нём критичны; и пытается обрабатывать всё одним способом. Три дыры, и ни одна не чинится сменой модели. Хоть флагманскую поставьте. Модель «как есть» + общий промпт 59% После трёх слоёв организации 85% Слой 1: спецификация на каждый тип документа Вместо универсальной инструкции — библиотека: на каждый из 79 типов своя спецификация. Что это за документ, какие поля извлекать, какие из них критичны, какие типичные ловушки — где путается серия с номером, как выглядят старые бланки. Выглядит спецификация буднично — вот сокращённый пример того, что мы пишем на каждый тип: Обратите внимание на последнюю строку. «Пустое поле лучше выдуманного» — правило, которое я бы вешал на стену: без него машина заполнит пропуск правдоподобной ерундой, и вы найдёте её через месяц в договоре. Звучит трудоёмко. Это и есть трудоёмко: неделя работы человека, который знает эти документы. Но именно здесь основной прирост точности, и работа делается один раз, а окупается на каждом документе потока. Если вам не хочется её делать — это честный сигнал, что внедрение вы не потянете: дальше будет не легче. Слой 2: режимы доверия вместо «всё автоматом» Второй слой — признать, что стопроцентная автоматизация не нужна и вредна. Поток делится на три режима, и решение принимается расчётом по фактическим признакам (тип шрифта, согласие двух моделей между собой, число критичных полей), а не на глаз. Режим Что попадает Роль человека Авто Печатный текст, высокое согласие моделей, мало критичных полей Не участвует Авто с проверкой Средние случаи Видит поля рядом с документом и подтверждает Только руками Рукопись, плохой скан, высокая цена ошибки Делает целиком Почему это главное решение Первая же ошибка автоматики на важном документе убивает доверие ко всей системе. Люди начинают перепроверять всё подряд — и эффект обнуляется, при том что деньги за обработку продолжают тратиться. Честное «этот тип мы пока проверяем руками» сохраняет доверие к тем девяноста процентам потока, где автоматика реально работает. Система с режимами доверия живёт. Система «всё автоматом» умирает от первого скандала — и забирает с собой вашу репутацию внутри компании. Слой 3: дорогая модель — только там, где нужна Третий слой — экономика, и здесь директору стоит вмешаться лично. Флагманская модель на каждом документе — это дорого и бессмысленно: на печатном тексте дешёвая даёт то же качество. Дорогая работает на сложных случаях и критичных полях. Это не экономия ради экономии. Разница в счёте между «гоняем всё через флагман» и «маршрутизируем по сложности» — кратная, и она решает, доживёт ли проект до второго квартала. Подробнее про эту арифметику — в разборе реальных расходов на ИИ . Сколько это стоит и когда окупается Считаем на условной компании: поток 400 комплектов в месяц, разбор одного руками — полтора часа, ставка менеджера 700 ₽/час. Это порядка 420 тысяч рублей в месяц управляемой работы (оценка) — при том, что менеджер нанимался не за этим. Стоимость машинной обработки складывается из трёх частей: сами вызовы модели (центы за документ при разумной маршрутизации), недели работы на спецификации — разовые, и время человека на приёмку в режимах «с проверкой» и «руками». Последняя часть не исчезает никогда, и её надо честно закладывать: у нас это порядка четверти прежнего времени. посчитайте свою ручную обработку комплектов документов в месяц часов на один комплект ставка сотрудника, ₽/час ручной разбор ≈ {X} ₽ в месяц формула: комплекты × часы × ставка. Сравнивайте не с нулём, а с четвертью этой суммы — столько останется на приёмку Если ваша цифра в калькуляторе меньше сотни тысяч в месяц — честно скажу: не начинайте, вам это пока не окупится, займитесь чем-то более денежным. Если больше — вы каждый месяц платите эту сумму за работу, которую половина рынка уже не делает руками. Случай, о котором молчат вендоры Теперь то, ради чего стоит дочитать до конца, если вы выбираете готовое решение. В реальном хранилище документы не лежат «один файл — один документ». Справка приходит тремя фотографиями. Договор — сканом по страницам. А иногда в одном PDF лежат два разных документа, потому что менеджер отсканировал стопку не глядя. Требование «склейте всё в один файл» не работает. Так документы физически не приходят, и заставлять клиентов и сотрудников пересобирать файлы — значит убить внедрение об удобство. Нам пришлось учить систему собирать документ из нескольких файлов и резать файл на несколько документов. Если вы выбираете подрядчика или коробку — тестируйте именно на этом. Не на чистом скане паспорта, который вам покажут на демо. Дайте три фотографии одной справки под углом и PDF с двумя документами внутри. Здесь ломаются почти все, и лучше узнать об этом до оплаты, а не после. Чего я не понимал в начале Признаюсь в двух вещах, на которых потерял время. Первое: я месяц искал «модель получше». Сравнивал, читал бенчмарки, гонял тесты. Прирост от смены модели оказался в пределах статистической погрешности — а прирост от описания типов документов дал двадцать шесть процентных пунктов. Я искал не там, где потерял, а там, где светлее. Второе: мы сначала строили «всё автоматом», потому что режимы доверия казались признанием поражения. Это была ошибка ровно наоборот: система без режимов доверия проработала до первой громкой ошибки, после которой ей перестали верить целиком. Пришлось откатываться и вводить их задним числом — вместе с потерянным доверием команды, которое восстанавливается дольше, чем настраивается любая техника. Распознавание первичных документов в 1С: где проходит граница Раз уж речь зашла о выборе, разведу два вопроса, которые постоянно смешивают: распознавание первичных документов и распознавание вашего потока — это не одно и то же, и решаются они разными инструментами. Первичка — счета, акты, накладные, УПД. Структура устойчивая, поля стоят на своих местах, форма предсказуема. Здесь встроенные средства учётной системы справляются, и городить рядом свой контур незачем: цены подписочные, результат сразу в проводке. Ваш собственный поток — всё остальное. Клиентские справки, договоры с приложениями, рукописные формы, сканы под углом. Именно на этом наборе первый прогон и даёт те самые 59% , потому что каждый тип требует своей спецификации, а «одна модель на всё» разваливается. Первый заход на другом наборе — 92 эталонных документа, ошибки с 20% до 7% — описан здесь . Практический вывод: если у вас болит первичка — начинайте с возможностей учётной системы, это дешевле и быстрее. Свой контур нужен там, где документы нестандартные, а объём такой, что ручной ввод стал отдельной работой. У нас именно этот путь и довёл точность до 85% на 79 типах , а время на комплект — с полутора часов до минут. Как выбирать между коробкой, подрядчиком и своими руками Раз уж вы дочитали до сюда, вам скоро придётся принимать это решение. Коротко, как я его вижу. И сразу отвечу на вопрос, который задают чаще всего: «а в 1С же есть распознавание документов, зачем что-то ещё?» Есть, и для бухгалтерии оно работает: 1С и подобные программы отлично забирают счета и накладные в учёт, цены там понятные и подписочные. Но их распознавание заточено под бухгалтерский первичный документ — стандартную форму с предсказуемой структурой. Как только поток становится вашим — клиентские справки, договоры с приложениями, сканы под углом, редкие типы, — оптическое распознавание по шаблону упирается в потолок, и начинается ровно то, о чём эта статья. Готовая коробка хороша, если ваши документы — стандартные и массовые: счета, накладные, паспорта. Дёшево, быстро, но спецификации под ваши редкие типы вы туда не занесёте, и на «трёх фотографиях справки» она, скорее всего, споткнётся. Тест перед покупкой описан выше — не поленитесь. Подрядчик нужен, когда типов много и они ваши. Но требуйте, чтобы спецификации писались вместе с вашим человеком, который эти документы знает, — и чтобы они остались у вас в читаемом виде. Спецификации, а не код, — главный актив этого проекта. Если подрядчик уходит, а описания типов остались у вас, вы восстановите систему за недели. Если наоборот — начнёте с нуля. Своими руками реально, если в компании есть человек, готовый разбираться. Инструменты доступны, вход — десятки долларов, механика описана в разборе про агентов . Именно так это начиналось у нас, и оглядываясь — это был правильный выбор: мы поняли свои документы лучше, чем понял бы любой внешний исполнитель. Что это дало людям До: менеджер разбирает комплект документов клиента полтора часа. Скачивает, переименовывает, раскладывает по разделам, вносит данные в карточку. После: загружает всё одним окном, система определяет типы, раскладывает и извлекает данные, менеджер проверяет результат. Полтора часа превратились в минуты — и я специально не пишу «в ноль», потому что проверка осталась. Но выигрыш даже не в этом. Исчезла зависимость от того, «как привык раскладывать конкретный человек» — а значит, ушёл целый класс проблем: потерянные комплекты, разный порядок папок у разных менеджеров, невозможность быстро передать клиента другому сотруднику. Где остановиться 85% — не потолок и не магия. Это уровень, на котором система стала выгоднее ручного труда с запасом, а дальнейший прирост стоит дороже, чем проверка оставшихся случаев человеком. Практический признак, что пора остановиться: вы неделю бьётесь за пару процентных пунктов, а очередь на приёмке от этого не уменьшается. Значит, оставшиеся случаи по своей природе требуют человека, и правильное решение — не улучшать модель, а нормально организовать проверку. Знать, где остановиться, — управленческий навык, и в распознавании документов он экономит больше денег, чем любая смена модели. Ему нигде не учат, и именно на нём чаще всего сыплются внедрения. Гонка за сотней процентов съедает бюджеты, которые нужно было потратить на второй процесс. О том, где такие проекты ломаются целиком, — разбор ошибок внедрения . С чего начать вам Не с выбора подрядчика и не с изучения рынка программ. С трёх действий, на которые уйдёт неделя и ни рубля. Первое. Посчитайте, сколько времени ваши люди тратят на разбор документов. Не «примерно», а замером: попросите двух менеджеров неделю фиксировать. Цифра вас удивит — она всегда больше ожидаемой. Второе. Выпишите типы документов, которые к вам приходят. Не все 79 — топ-10 по частоте. Это и будет черновик первых спецификаций. Третье. Возьмите десять реальных комплектов — грязных, с фотографиями и перевёрнутыми сканами — и прогоните через любой доступный инструмент. Получите свои 59% и увидите, где именно теряется точность. Это ваша стартовая точка, и она всегда честнее презентации вендора. Дальше — три слоя из этой статьи. А если хотите пройти путь по порядку, с практикой на своих документах, — у меня есть бесплатный курс для руководителей : работа с документами там разобрана отдельно, вместе с экономикой и режимами доверия. И последнее. Разница между компаниями, у которых это работает, и теми, у кого «не пошло», — почти никогда не в бюджете и не в подрядчике. Она в том, нашёлся ли человек, готовый неделю описывать типы документов вместо того, чтобы ждать волшебную коробку. Волшебных коробок не будет ни в этом году, ни в следующем — будут инструменты, которые окупаются в руках того, кто разобрался.