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

Портал для клиентов: как один скрипт превратил 12 страниц в проблему

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

У нас сервисная компания: отдел продаж 8 менеджеров, оборот около 9 млн ₽ в месяц, средний чек по сделке — 180 тысяч ₽. Это значит примерно 50 сделок в месяц проходят через один и тот же экран — клиентский портал, личный кабинет, куда контрагент грузит документы для оформления заявки. Когда этот экран собран криво, теряются не абстрактные «удобство» и «имидж», а конкретные сделки: если из 50 сделок в месяц застревает на этапе документов хотя бы 10% — это 5 сделок по 180 тысяч, то есть 900 тысяч ₽ отложенной выручки в месяц (оценка). Формула для своего случая: число сделок в месяц × доля зависших на этапе документов (%) × средний чек = сумма отложенной выручки в месяц — подставьте свои цифры и получите свою оценку.

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

Клиентский портал: экран, который должен был сэкономить время

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

Чтобы не тратить месяцы на полноценный продукт, решили запустить обучение алгоритма на реальных кейсах прямо сейчас: взять 40 живых случаев, прогнать через систему, отдать менеджерам на проверку. Если менеджеры подтвердят корректность — протестировать на сегменте из 5 тысяч клиентов и оценить отклик. Логика: за полгода набрать адекватный массив данных, чтобы к концу года запустить полноценный MVP. Разумный план. Экран подвёл раньше, чем модель.

Как выглядело «до»: 12 страниц одним скриптом

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

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

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

Что вскрылось при аудите: экран красивый, а данные — нет

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

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

Пересборка: механика по шагам

Руководитель принял решение не доводить каждую из 12 страниц до идеала перед тестированием, а изменить сам процесс сборки.

1. Эталон вместо генерации. Взяли единственный утверждённый прототип главной страницы — тот, что прошёл дизайн-ревью без замечаний — и сделали его образцом для всех остальных 12 типов.
2. Комплексный аудит вместо точечных правок. Собрали все 12 типов страниц в одну таблицу (Google Sheets: тип страницы → элемент брендбука → статус «совпадает / не совпадает» → кто чинит) и прогнали разом с привлечением дизайнера и разработчика, а не по одной странице за раз.
3. Обязательная привязка статуса к файлу. На уровне формы и API запретили менять статус документа на «в наличии», пока файл физически не загружен на сервер. Это убрало третью поломку сразу — модель больше не видит «пустых успехов».
4. Выгрузка и сопоставление данных. Массив документов и рекомендаций портала выгрузили и сопоставили с клиентами, прошедшими проверку с первого раза — так появился первый размеченный датасет для обучения.
5. Точечное обучение OCR вместо запуска на всей базе. Вместо прогона через всю накопленную базу собрали 92 типовых документа, обучили стажёра проверять результат вручную и по каждому типу документа написали отдельную спецификацию — с описанием нюансов распознавания (развороты, качество скана, положение печати).
6. Многоступенчатый анализ. Сначала система определяет тип документа, затем применяет нужную спецификацию, при затруднении эскалирует на более мощную модель, и только после этого документ уходит на подтверждение менеджеру.

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

ИИ-связка целиком: промпт, модель, обвязка

Конвейер обработки документа выглядит так: клиент грузит файл на портал → вебхук уходит в обработчик → OCR извлекает текст → лёгкая модель определяет тип документа и полноту пакета → при низкой уверенности передаёт сложный случай на более мощную модель → результат пишется в карточку сделки в CRM → менеджер подтверждает или отклоняет.

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

Ты — ассистент проверки комплекта документов клиента B2B-портала.
На вход: распознанный текст документа (OCR) + тип документа, заявленный при загрузке.

Проверь и верни строго JSON:
1. document_type — фактический тип документа (карточка организации / доверенность / спецификация / другое)
2. matches_declared — совпадает ли фактический тип с заявленным (true/false)
3. required_fields_found — список найденных обязательных полей (ИНН, ОГРН, срок действия доверенности, подпись)
4. missing_fields — список отсутствующих обязательных полей
5. confidence — уверенность распознавания от 0 до 1
6. escalate — true, если confidence ниже 0.75 ИЛИ документ повёрнут/плохого качества
7. comment — одна короткая фраза для менеджера, что проверить руками

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

Текст документа: {{ocr_text}}
Заявленный тип: {{declared_type}}

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

{
  "document_type": "доверенность",
  "matches_declared": true,
  "required_fields_found": ["ИНН", "срок действия", "подпись"],
  "missing_fields": ["печать"],
  "confidence": 0.62,
  "escalate": true,
  "comment": "Проверить наличие печати вручную, скан частично обрезан"
}

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

Отдельно для доступа ИИ-инструментов к данным CRM без раздувания промпта настроили MCP-сервер поверх базы CRM. Это снижает расход токенов на 30–40% и уменьшает долю галлюцинаций, потому что модель обращается к структурированным данным напрямую, а не получает их вставленными текстом в каждый запрос. Условный пример: запрос без MCP — это вставка текстового дампа карточки сделки в промпт, порядка 3000 токенов (оценка); тот же запрос через MCP обращается к структурированным полям и укладывается в 1800–2100 токенов — те самые 30–40% экономии на каждом вызове. При потоке в несколько сотен вызовов в месяц разница заметна на счёте за токены, но точную сумму в рублях считайте по своему тарифу у провайдера модели — универсальной цифры тут нет.

Экран «после»: что показал аудит

До пересборки ни одна из 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 ₽/мес, то есть в разы меньше, чем экономия на времени менеджеров; подробный разбор счетов за ИИ есть в материале про реальные расходы на ИИ.

Риск зависших сделок. Если 10% из 50 месячных сделок зависает на этапе документов — это 5 сделок по 180 тысяч ₽, то есть 900 тысяч ₽ отложенной выручки в месяц (формула — в начале статьи). Пересборка экрана и обязательная привязка статуса к файлу не гарантируют, что этот риск исчезнет полностью, но убирают одну из его причин — искажённые статусы, из-за которых сделка стоит на месте, пока никто не замечает, что документа фактически нет. Что мы не считаем эффектом: устранение этой причины — это снижение вероятности зависания, а не гарантированная экономия; складывать эту цифру с экономией на ИИ-конвейере напрямую нельзя — это разные механизмы эффекта, один снижает трудозатраты, другой снижает вероятность потери сделки.

С чего начать в понедельник

• Выгрузить список всех типов страниц/форм портала и построчно сверить с брендбуком — не выборочно, а полностью.
• Найти один утверждённый экран и объявить его эталоном для всех остальных, вместо доводки каждого по отдельности.
• Проверить в CRM: можно ли поставить статус «документ получен» без прикреплённого файла. Если можно — закрыть это в первую очередь.
• Собрать 50–100 типовых документов из потока, прогнать через OCR именно через тот канал, который будет в проде (API, а не веб-интерфейс), дать проверить человеку.
• Настроить логирование каждого шага обработки документа в отдельную таблицу — сколько успешно, сколько зависло, сколько с ошибкой.
• Назначить одного ответственного за актуализацию спецификаций и шаблонов — без владельца документация устаревает за первый же квартал.

Про то, когда клиентский портал вообще нужен компании, а когда это лишние деньги на пустом месте, — отдельный разбор в материале о клиентских порталах для среднего бизнеса. Как поднять точность распознавания документов с 59% до 85% на конкретном кейсе — в разборе по OCR.

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

Почему клиентский портал не работает после запуска?

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

Какие типичные ошибки клиентского портала встречаются при разработке?

Автогенерация страниц одним скриптом без построчного аудита на соответствие брендбуку, отсутствие обязательной привязки статуса к загруженному файлу, и разное качество OCR при работе через API по сравнению с интерфейсом самого сервиса.

Как понять, что портал сломан именно из-за ИИ-модуля, а не интерфейса?

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

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