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

Клиентский портал для среднего бизнеса: когда он нужен, а когда — нет

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

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

Зачем клиенту личный кабинет

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

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

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

Портал без порядка в CRM — это красивый фасад

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

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

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

Подробнее о том, как CRM врёт данными и почему сверку нужно вести по ID, а не по датам — в статье про сдвиг дат в Bitrix24.

Обработка заявок: автоматизация, которая не роняет данные

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

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

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

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

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

Решение получилось из четырёх частей:

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

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

MVP вместо релиза: зачем тянуть полгода

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

Та же логика с порталом для документов: вместо запуска на всей базе клиентов собрали 92 типовых примера, обучили стажёра проверять результат вручную, и только потом написали спецификации под каждый тип документа с описанием нюансов распознавания. Маленькая выборка с ручной проверкой дешевле, чем автоматизация на 100% данных, которая потом требует переделки.

Про то, как ИИ-система теряет точность на нестандартных документах и что с этим делать, — в статье про рост распознавания с 59% до 85%.

Когда портал не нужен вообще

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

Портал имеет смысл, когда:

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

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

Кстати, любая автоматизация вокруг портала требует постоянного присмотра — она не работает сама по себе после запуска. Об этом подробнее в статье про автоматизацию, которая становится второй работой.

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

Зачем клиенту личный кабинет, если есть менеджер?

Личный кабинет снимает с менеджера рутинные вопросы «на каком я этапе» и «какие документы нужны» — это статус и чек-лист, а не замена общения.

Как автоматизировать обработку заявок без потери данных?

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

Нужен ли портал малому бизнесу?

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