Короткий ответ
AI-функция нужна пользователю не тогда, когда бизнесу хочется добавить AI в продукт, а когда у пользователя есть повторяющаяся задача, понятный контекст, проверяемый результат и причина доверять помощи системы.
Если AI не сокращает путь пользователя, не снижает ошибку, не помогает принять решение или не убирает рутинную операцию, он быстро становится декоративной функцией.
Начинать нужно не с технологии
Типовая ошибка - формулировать задачу так: “добавить AI в личный кабинет”, “сделать чатбота”, “прикрутить ассистента”. Это описание решения, а не проблемы пользователя.
Правильный первый вопрос звучит иначе:
В какой момент пользователь застревает, тратит лишнее время, ошибается или вынужден обращаться к сотруднику?
Пока этот момент не описан, нельзя выбрать правильный AI-сценарий. Может оказаться, что пользователю нужен не AI, а нормальная навигация, понятный статус заявки, фильтр, шаблон документа, подсказка в интерфейсе или исправление интеграции.
Проверка пользовательской боли
AI-функцию стоит рассматривать, если задача повторяется и имеет измеримую цену.
Проверьте:
- как часто пользователь сталкивается с этой ситуацией;
- что он делает сейчас вместо AI-функции;
- сколько шагов занимает текущий путь;
- где появляются ошибки или обращения в поддержку;
- что пользователь считает хорошим результатом;
- можно ли проверить ответ или действие AI;
- есть ли данные, на которые AI может опереться.
Если пользовательская боль существует только в презентации, AI-пилот будет выглядеть убедительно на демо, но не приживётся в реальной работе.
Хорошие признаки AI-сценария
AI может быть полезен, когда задача имеет контекст и допускает помощь, а не бесконтрольное решение.
Хорошие признаки:
- пользователь ищет информацию в большом массиве документов;
- сотрудник вручную классифицирует похожие обращения;
- оператор готовит типовые ответы, но должен учитывать контекст;
- менеджер сверяет данные из нескольких источников;
- пользователь не понимает, где в портале найти нужное действие;
- эксперт тратит время на повторяющиеся черновики;
- результат можно проверить до отправки клиенту или запуска процесса.
В таких сценариях AI помогает ускорить работу, но не заменяет ответственность. Это хороший формат для первого AI-пилота.
Плохие признаки AI-сценария
Есть ситуации, где AI добавляет больше риска, чем пользы.
Плохие признаки:
- бизнес не может назвать конкретного пользователя функции;
- сценарий описан как “пусть AI помогает во всём”;
- данные противоречат друг другу или быстро устаревают;
- ошибка AI может создать финансовый, юридический или репутационный риск;
- нет человека, который будет проверять качество;
- результат нельзя измерить;
- пользователи уже не доверяют текущему порталу или данным.
Если несколько пунктов совпадают, сначала нужен AI-аудит, а не разработка интерфейса.
Как отличить пользовательскую пользу от бизнес-желания
Бизнес может хотеть AI по понятным причинам: снизить нагрузку на поддержку, ускорить обработку заявок, показать технологичность продукта, сократить ручные операции. Но пользователь оценивает функцию иначе.
Для пользователя важны другие вопросы:
- стало ли быстрее получить результат;
- стало ли понятнее, что делать дальше;
- можно ли доверять ответу;
- видно ли, откуда взята информация;
- можно ли исправить ошибку;
- не стало ли больше лишних шагов;
- не заставляют ли его проверять то, что раньше работало проще.
AI-функция полезна только тогда, когда эти два взгляда совпадают: бизнес получает управляемую эффективность, а пользователь получает более понятный и надёжный путь.
Мини-тест перед запуском
Перед тем как ставить задачу разработке, полезно провести короткую проверку.
1. Описать один сценарий
Не “AI-ассистент для портала”, а конкретно: “помогает пользователю найти нужный регламент”, “классифицирует входящее обращение”, “готовит черновик ответа оператору”.
2. Найти пользователя
У сценария должен быть конкретный пользователь: клиент, менеджер, оператор, администратор, сотрудник поддержки, партнёр или руководитель.
3. Понять текущий путь
Нужно описать, как пользователь решает задачу сейчас. Если текущий путь не понятен, AI будет автоматизировать догадку.
4. Проверить данные
AI должен опираться на актуальные документы, базу знаний, CRM, портал, 1С или другой источник истины. Если источники не готовы, сначала нужна AI-ready архитектура.
5. Определить риск ошибки
Чем выше риск ошибки, тем осторожнее должен быть сценарий: подсказка, черновик, рекомендация, поиск по источникам, ручное подтверждение.
6. Задать метрику пользы
Метрика должна показывать не активность AI, а пользу процесса: меньше обращений, быстрее поиск, меньше ручных ошибок, выше доля решённых задач, понятнее качество ответа.
Какие метрики использовать
Для пользовательской ценности подходят практичные метрики:
- время до результата;
- доля задач, решённых без обращения к сотруднику;
- количество повторных обращений;
- точность классификации;
- доля ответов, принятых без правки;
- количество ошибок после запуска;
- оценка полезности пользователями;
- число отказов AI от ответа в рискованных ситуациях.
Эти метрики стоит определить до пилота. Подробнее про качество можно читать в статье метрики качества AI-ассистента.
Когда нужен RAG, а когда нет
Если пользовательская задача связана с поиском ответа по документам, инструкциям, регламентам или технической базе знаний, может подойти RAG-ассистент. Его ценность в том, что ответ можно привязать к источникам.
Но если проблема в плохой структуре интерфейса, непонятных статусах, неработающих интеграциях или устаревших данных, RAG не решит причину. Он только покажет пользователю хаос быстрее.
Поэтому до RAG нужно проверить качество базы знаний, права доступа и владельца обновлений.
Как оформить решение для пилота
После проверки сценарий можно описать коротким брифом:
- пользователь и его задача;
- текущий путь без AI;
- источник данных;
- что AI делает и чего не делает;
- где нужен ручной контроль;
- какие ошибки недопустимы;
- как измеряется польза;
- кто владеет сценарием после запуска.
Если этот бриф не получается заполнить, пилот ещё не готов. Именно поэтому многие AI-пилоты не внедряются: они проверяют технологию, но не проверяют пользовательский процесс.
Практический вывод
AI-функция должна начинаться с пользовательской задачи, а не с желания добавить AI в продукт. Хороший сценарий имеет конкретного пользователя, понятную боль, готовые данные, ограниченный риск и метрику пользы.
Если сценарий нельзя объяснить простым языком без технических терминов, его рано отдавать в разработку. Начните с проверки пользовательского пути, данных и ограничений, а для первичной самодиагностики используйте AI-ready чек-лист.
