Что показал документированный кейс

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

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

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

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

Где именно терялось время

Самым тяжёлым участком оказался промежуток между подписанным письмом о сотрудничестве и готовностью к стартовой встрече. Там концентрировались повторные запросы документов, ручная проверка комплектности, перенос реквизитов и вопросы партнёров «на каком этапе клиент».

Карта процесса выявила типичные для профессиональных услуг проблемы:

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

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

Три класса работы вместо одного «AI-агента»

Практичная архитектура начинается с классификации задач.

1. Детерминированная оркестрация

Это события с однозначным входом и выходом:

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

Здесь модель только повышает стоимость и непредсказуемость. Нужны API, очереди, повторные попытки, журнал событий и обработка исключений.

2. ИИ с обязательной проверкой

Модель полезна для работы с вариативным содержанием:

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

Выход модели не должен напрямую менять мастер-данные. Он попадает в очередь проверки с исходным документом, уровнем уверенности и видимым сравнением полей.

3. Решения человека

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

Минимальная целевая архитектура

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

Вокруг неё работают пять контуров:

1. Портал или защищённая форма получает сведения и файлы от клиента.
2. Оркестратор связывает CRM, электронную подпись, календарь, систему задач и хранилище.
3. Сервис документов проверяет формат, запускает OCR и предлагает классификацию.
4. LLM или локальная модель готовит только черновики и ответы из утверждённой базы знаний.
5. Очередь проверки показывает человеку исходник, предложенные поля, историю и необходимые действия.

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

Локальная модель уместна, если документы нельзя передавать во внешний контур или требуется контроль хранения промптов и результатов. Но локальность не заменяет разграничение доступа, журналирование и удаление данных по сроку. Внешний API может быть рациональнее при небольшом объёме, если договор, регион обработки и запрет обучения на данных соответствуют требованиям компании.

Данные и безопасность

До пилота нужно составить таблицу полей: источник истины, владелец, чувствительность, срок хранения, кто видит и кто может изменять. Паспортные, финансовые и контактные сведения не должны попадать в общий чат сотрудников или публичный ИИ-сервис.

Российское исследование, опубликованное CNews, сообщало, что около 60% изученных организаций не имели формализованных правил работы с ИИ, а объём данных, отправляемых в публичные нейросети, резко вырос. Эти цифры относятся к выборке поставщика безопасности и не описывают весь рынок, но хорошо показывают риск «теневого ИИ»: сотрудник ускоряет работу, копируя клиентский документ туда, где компания перестаёт контролировать его обработку.

Минимальные меры для онбординга:

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

Модельная экономика без выдуманного ROI

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

При полной стоимости часа 1 500 рублей ресурсный эффект равен 60 000 рублей. Допустим, сопровождение сервисов и интеграций стоит 15 000 рублей в месяц, а настройка — 300 000 рублей. Тогда чистый ежемесячный эффект без учёта роста выручки составляет 45 000 рублей, а простая окупаемость — около 6,7 месяца.

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

Как провести пилот за восемь недель

Недели 1–2: выберите один тип клиента, опишите фактические этапы и измерьте базовую длительность, повторный ввод, число напоминаний и возвраты документов.

Недели 3–4: создайте единый список документов, статусы, владельцев и шаблоны. Подключите детерминированные переходы без LLM.

Недели 5–6: добавьте один ИИ-сценарий — например, классификацию документа с ручным подтверждением. Проверьте обезличивание, ошибки и время исправления.

Недели 7–8: проведите параллельный прогон на ограниченной группе, разберите исключения и сравните полный цикл с базовой линией.

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

Что взять руководителю

Не покупайте «агента для онбординга» как единую чёрную коробку. Сначала разделите процесс: правила выполняет оркестратор, неструктурированные данные разбирает ИИ под контролем, а риск и профессиональный вывод остаются за человеком. Именно такое разделение превращает автоматизацию из красивой демонстрации в управляемый производственный процесс.