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

Личный кабинет на 400 тысячах вопросов: красивый интерфейс без работающей логики

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

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

Дело было не в коде. Личный кабинет клиента — это стык трёх систем: формы, куда клиент вводит данные, модели, которая их разбирает, и CRM, где живёт сделка. Если стык не проверен, кабинет выглядит рабочим и не работает ни дня. В нашем случае разрыв на одном только этапе «документы запрошены» держал 26–27 клиентов в просрочке одновременно — притом что менеджеры отчитывались, что документы получены.

До: экран, на который не стыдно позвать инвестора

Показать такой кабинет никому не стыдно. Клиент заходит, видит статус дела, форму загрузки, чат с ответами на частые вопросы — база в 400 тысяч записей закрывала почти любой типовой вопрос без участия менеджера. Сверху — план: обучить алгоритм на 40 живых кейсах, отдать менеджерам на проверку, при подтверждении корректности протестировать на сегменте в 5 000 клиентов и через полгода иметь достаточный массив данных для MVP.

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

Что за фасадом: пять поломок логики в личном кабинете клиента

Когда мы стали разбирать кабинет по частям, а не смотреть на него целиком, вскрылись пять конкретных разрывов.

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

Второе. Рекомендации, которые формировал портал после анализа документов, не долетали до CRM автоматически. Собственник обнаружил это случайно, когда сопоставил массив данных портала со списком клиентов, прошедших проверку с первого раза, — и увидел, что связи между двумя базами попросту нет.

Третье. Если клиент не проходил внешнюю проверку, система это не фиксировала. Менеджер вручную откатывал сделку назад и должен был удалить дату уже назначенной проверки — и часто забывал это сделать. В CRM оставалась сделка с датой в прошлом и статусом «ожидание», которую никто не видел как проблемную.

Четвёртое. OCR-распознавание документов работало отлично внутри самого сервиса модели и разваливалось при вызове через API — повёрнутые документы система не распознавала корректно. Технически это два разных пути обработки одного и того же файла, и никто не тестировал их отдельно.

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

Пересборка: как мы перебрали кабинет по частям

Мы не стали переписывать интерфейс — он был готов. Пересобирали логику по стыкам, в порядке, в котором они ломались чаще всего.

1. Аудит фактических данных. Выгрузили список документов, отмеченных «в наличии», и сверили с файлами, физически лежащими на сервере. Разрыв — процент документов без файла — стал главной метрикой первой недели.
2. Обязательное поле причины отказа. При провале внешней проверки система теперь требует выбрать причину из закрытого списка (недостаток документов, несоответствие данных, иное) и отдельное поле даты неуспешной проверки — отдельное от даты запланированной. Без заполнения сделка не двигается дальше.
3. Автозадача на день проверки. В день назначенной проверки менеджеру автоматически ставится задача с двумя вариантами ответа: пройдена / не пройдена. Если задача не закрыта в срок, уведомление уходит контролю качества, а не остаётся в личных напоминаниях менеджера.
4. Централизация загрузки документов. Вместо разброса по облачным дискам и локальным компьютерам — единая точка загрузки в портале с автоматической сегментацией по типу документа.
5. Многоступенчатый анализ вместо одной модели на всё. Сначала определяется тип документа, затем применяется спецификация под этот тип, при необходимости подключается более мощная модель, финальную проверку всегда делает менеджер.
6. Вебхук из портала в CRM. Рекомендации и статус документа сразу пишутся в карточку клиента — без ручной сверки раз в неделю.

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

ИИ-связка: конвейер распознавания и рекомендаций

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

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

Ты — классификатор входящих документов клиента.
На входе: файл (base64 или ссылка на облачное хранилище) и метаданные.

Верни строго JSON без пояснений:
{
  "doc_type": "тип документа из списка: паспорт / справка / договор / анкета / иное",
  "orientation": "normal / rotated_90 / rotated_180 / rotated_270",
  "needs_rotation_fix": true/false,
  "confidence": 0.0-1.0,
  "escalate_to_stronger_model": true/false,
  "reason": "краткая причина эскалации или null"
}

Правила эскалации:
- confidence < 0.75 → escalate_to_stronger_model: true
- рукописный текст или низкое качество скана → escalate_to_stronger_model: true
- стандартный печатный документ, confidence >= 0.9 → escalate_to_stronger_model: false

Входные данные:
{
  "doc_id": "{{doc_id}}",
  "client_id": "{{client_id}}",
  "file_url": "{{file_url}}",
  "mime_type": "{{mime_type}}"
}

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

{
  "doc_type": "справка",
  "orientation": "rotated_90",
  "needs_rotation_fix": true,
  "confidence": 0.62,
  "escalate_to_stronger_model": true,
  "reason": "низкое качество скана после разворота"
}

Дешёвая модель (условно — Claude Haiku или аналог) достаточно точна для типизации и оценки ориентации. Она не должна принимать решение по существу документа — только маршрутизировать. Второй промпт, для сложных случаев, работает уже на более мощной модели и формирует структурированное описание кейса.

Ты — аналитик документов клиента. Модель: мощная (используется только
для эскалированных случаев с confidence < 0.75 на предыдущем шаге).

На входе: распознанный текст документа + спецификация по его типу.

Верни JSON:
{
  "doc_type": "тип документа",
  "extracted_fields": { "поле": "значение" },
  "missing_fields": ["список отсутствующих обязательных полей"],
  "case_strength": "low / medium / high",
  "risk_flags": ["конкретные риски, если есть"],
  "manager_review_required": true
}

Спецификация по типу документа:
{{spec_for_doc_type}}

Текст документа:
{{ocr_text}}

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

{
  "doc_type": "справка",
  "extracted_fields": {"фио": "распознано частично", "дата": "12.03.2025"},
  "missing_fields": ["номер документа"],
  "case_strength": "medium",
  "risk_flags": ["отсутствует обязательный реквизит"],
  "manager_review_required": true
}

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

После: что показывает экран теперь

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

Ниже — то же самое в цифрах: сколько клиентов держало в просрочке узкое место «документы запрошены» до пересборки и сколько остаётся при консервативном сценарии после.

Оценка, консервативный сценарий: снижение на ~30% за счёт обязательного поля причины отказа, отдельной даты неуспешной проверки и автоматического уведомления контролю качества.

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

Экономика: что стоит пересборка и что она даёт

Возьмём условную сервисную компанию из легенды: отдел из 8 менеджеров, оборот 9 млн ₽ в месяц, средний чек 180 тыс. ₽ — это около 50 сделок в активной работе одновременно (оценка, с учётом цикла сделки ~6 недель).

Формула для своего кейса. Риск задержки выручки = доля зависших на этапе документов сделок × количество сделок в работе × средний чек. Потери часов = количество зависших случаев × время ручной обработки одного случая × ставка сотрудника.

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

Ещё один риск: доступ вне портала и потерянная история клиента

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

• Выгрузить список документов, отмеченных «в наличии», и сверить с файлами на сервере — процент разрыва даст реальную картину, а не отчёт менеджеров.
• Добавить обязательное поле причины отказа и отдельную дату неуспешной проверки — без этих двух полей сделка не может закрыться как «отказ».
• Поставить автозадачу менеджеру на день проверки с бинарным выбором «пройдена / не пройдена» и уведомлением контролю качества при просрочке.
• Прогнать 5–10 живых кейсов через новую логику вручную, прежде чем включать автоматизацию на всю базу — это дешевле, чем чистить обучающую выборку постфактум.
• Проверить, есть ли у каждого сотрудника, работающего с клиентом, доступ в общую систему — переписки и локальные папки не восстанавливаются при передаче дел.
• Свести чек-лист по интеграции портал → CRM в документ, а не диктовать его на планёрке — при передаче проекта устные договорённости теряются первыми.

Похожий разрыв между красивым фасадом и рабочей логикой я разбирал на примере CRM — там причиной было не отсутствие данных, а их искажение задним числом, см. разбор про сдвиг дат в Битрикс24. А если вы только решаете, нужен ли вашей компании личный кабинет вообще, у меня есть отдельный разбор — когда клиентский портал оправдан, а когда нет.

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

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

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

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

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

С чего начать, если личный кабинет клиента уже запущен, но не работает?

Не переписывать интерфейс. Сначала выгрузить реальные данные: сколько документов отмечено против того, сколько файлов физически лежит на сервере. Разрыв покажет, где логика сломана.

#автоматизация #ии и нейросети #ошибки и провалы