Почему портал самообслуживания не работает — и при чём тут когнитивная нагрузка

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

Команда SimpleOne ITSM размышляет о том, почему так происходит и как быть — чтобы и пользователям хорошо, и агентам поддержки.

Парадокс и фундаментальная ошибка

Каждый Service Desk последние 15 лет хочет добиться успеха в Shift-Left — это концепция операционной эффективности: решать задачи на самых ранних этапах поддержки, чтобы большинство обращений закрывалось на первой линии или через самообслуживание, без эскалации на вторую и третью линии, где работают дорогие узкопрофильные специалисты.

Но даже если компания придерживается этой концепции, тратит месяцы на создание идеальных моделей типовых запросов, пользователи всё равно могут пройти мимо и написать сразу в Service Desk. 

Shift-Left не работает, потому что портал слишком сложен для конечного пользователя.

Возьмём конкретную ситуацию. Сотруднику отдела продаж нужен доступ к корпоративной системе отчётности. Он заходит на портал, видит 200 карточек с услугами и начинает читать названия:

• Выдача прав для пользователей

• Предоставление доступа к информационным ресурсам

• Управление учётными записями

Все три звучат похоже. Через 15 минут он закрывает портал и пишет в Service Desk:

• Не могу открыть отчёт по продажам, помогите

Портал здесь ни при чём — он работает именно так, как был спроектирован. Проблема в том, что он спроектирован под логику ИТ-отдела, а пользователь мыслит иначе. Это хорошо описывает фреймворк Cynefin, который делит ситуации по степени предсказуемости: от простых и очевидных (Clear) до запутанных (Complex), где причинно-следственные связи неясны.

Например, типовой запрос на выдачу доступа — это Clear для системного администратора: есть форма, есть поля, есть регламент.

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

Портал молча перекладывает на пользователя работу по переводу своей задачи из Complex в Clear. Пользователь этого не делает, и поступает правильно, потому что это не его работа.

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

Большинство диалогов заканчивалось одинаково:

• Соедините меня с оператором

Когнитивная нагрузка никуда не делась, просто поменяла форму.

ИИ спешит на помощь

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

В основе работы лежит технология RAG — Retrieval-Augmented Generation. 

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

Если сложнее, то есть два шага:

1. Сначала специализированная модель (embeddings model) преобразует весь корпоративный контент в векторные представления — числовые описания смысла каждого фрагмента текста. Когда пользователь пишет запрос, система ищет в этом векторном пространстве семантически близкие фрагменты — не по ключевым словам, а по смыслу. «Не могу открыть отчёт» и «проблема с доступом к системе отчётности» дадут одинаковый результат поиска. 

2. Затем языковая модель получает найденные фрагменты, проверяет их релевантность и формирует финальный ответ на естественном языке.

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

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

Сценарий 1: Самообслуживание через базу знаний

Запрос пользователя:

• Не работает почта

Что делает ИИ-помощник:

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

2. Задаёт уточняющие вопросы: «Не открывается веб-интерфейс или не синхронизируется почтовый клиент?».

В результате проблема решается без создания обращения, пользователь получает ответ за 1–2 минуты, а не ждёт ответа первой линии.

Сценарий 2: Типовой запрос с предзаполнением формы

Запрос пользователя:

• Мне нужен доступ к отчётам по продажам

Что делает ИИ-помощник:

1. Определяет, что это типовой запрос на выдачу доступа.

2. Находит правильную форму в каталоге услуг (даже если она называется «Предоставление прав доступа к информационным ресурсам категории B»).

3. На основе ответов предзаполняет все обязательные поля формы.

4. Показывает пользователю готовую форму для проверки и отправки.

Запрос сразу попадает в профильное подразделение (администраторам системы), минуя первую линию, с полной информацией для немедленного выполнения. Не нужен статус «Требуется информация», не нужны итерации уточнений.

Сценарий 3: Инцидент с полным контекстом

Запрос пользователя:

• Не открывается отчёт по продажам за месяц. Проверил всё, что вы написали в статьях — не помогло. Мне срочно нужен этот отчёт для встречи с клиентом через час

Что делает ИИ-помощник:

1. Определяет, что это инцидент — неожиданная проблема, требующая срочного решения.

2. Классифицирует срочность на основе контекста («встреча через час» → высокая срочность).

3. Создаёт форму инцидента с предзаполненными полями (срочность, контекст).

4. Генерирует ссылку на готовую форму.

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

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

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

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

Почему это работает

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

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

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

Выводы

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

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

Сталкивались с этой проблемой? Интересно услышать в комментариях, что пробовали и как решали — или почему решили не решать.