Большинство крупных компаний потратили годы на внедрение порталов самообслуживания — проектировали каталоги услуг, писали инструкции, проводили обучения. Портал есть, каталог есть, база знаний в наличии. А пользователи всё равно звонят на первую линию.
Команда 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.
Если упрощённо: система не генерирует ответы из собственных знаний, а ищет релевантную информацию в корпоративных источниках и на её основе формирует ответ. Источниками служат база знаний, каталог услуг с описаниями типовых запросов, объявления о плановых работах — всё, что уже есть в системе.
Если сложнее, то есть два шага:
Сначала специализированная модель (embeddings model) преобразует весь корпоративный контент в векторные представления — числовые описания смысла каждого фрагмента текста. Когда пользователь пишет запрос, система ищет в этом векторном пространстве семантически близкие фрагменты — не по ключевым словам, а по смыслу. «Не могу открыть отчёт» и «проблема с доступом к системе отчётности» дадут одинаковый результат поиска.
Затем языковая модель получает найденные фрагменты, проверяет их релевантность и формирует финальный ответ на естественном языке.
Корпоративный контекст задаётся через промпты — инструкции, которые объясняют модели специфику компании: что считать инцидентом, как определять срочность, какие поля обязательны для разных типов запросов, как отличить типовой запрос от нестандартной ситуации. Новые данные в системе подхватываются автоматически с заданным интервалом — администратору не нужно каждый раз перенастраивать модель вручную.
Принципиальное отличие от скриптового бота: система не ведёт пользователя по заранее прописанному дереву вопросов. Она понимает контекст диалога и адаптируется — если пользователь добавляет детали, уточняет или меняет формулировку, модель учитывает это в следующем ответе.
Сценарий 1: Самообслуживание через базу знаний
Запрос пользователя:
Не работает почта
Что делает ИИ-помощник:
Проверяет актуальные объявления — возможно, идут плановые работы на почтовом сервере, — и ищет в базе знаний статьи по этой проблеме. Предлагает пользователю статьи с решением, дополнительно поясняя основные шаги.
Задаёт уточняющие вопросы: «Не открывается веб-интерфейс или не синхронизируется почтовый клиент?».
В результате проблема решается без создания обращения, пользователь получает ответ за 1–2 минуты, а не ждёт ответа первой линии.
Сценарий 2: Типовой запрос с предзаполнением формы
Запрос пользователя:
Мне нужен доступ к отчётам по продажам
Что делает ИИ-помощник:
Определяет, что это типовой запрос на выдачу доступа.
Находит правильную форму в каталоге услуг (даже если она называется «Предоставление прав доступа к информационным ресурсам категории B»).
На основе ответов предзаполняет все обязательные поля формы.
Показывает пользователю готовую форму для проверки и отправки.
Запрос сразу попадает в профильное подразделение (администраторам системы), минуя первую линию, с полной информацией для немедленного выполнения. Не нужен статус «Требуется информация», не нужны итерации уточнений.
Сценарий 3: Инцидент с полным контекстом
Запрос пользователя:
Не открывается отчёт по продажам за месяц. Проверил всё, что вы написали в статьях — не помогло. Мне срочно нужен этот отчёт для встречи с клиентом через час
Что делает ИИ-помощник:
Определяет, что это инцидент — неожиданная проблема, требующая срочного решения.
Классифицирует срочность на основе контекста («встреча через час» → высокая срочность).
Создаёт форму инцидента с предзаполненными полями (срочность, контекст).
Генерирует ссылку на готовую форму.
Что происходит дальше: пользователь видит готовую форму, может при необходимости дополнить информацию и отправляет обращение одним кликом. Агент Service Desk получает инцидент с полным контекстом и может сразу начать работу — не нужно уточнять детали, всё уже описано. При этом помощник на основе искусственного интеллекта может ускорить решение задачи, определив степень её критичности, которую сам пользователь не всегда может осознать. Как в примере выше — если ИИ понимает из контекста диалога, что встреча с клиентом через час, система может обозначить задачу как срочную, даже если пользователь так её не воспринимает.
Но у подхода есть и слабое место — честно про него. ИИ-помощник хорош ровно настолько, насколько хороша база знаний, из которой он берёт ответы. Если статьи в ней устарели или противоречат друг другу, помощник всё равно ответит — уверенно и складно, только неправильно. И это опаснее, чем когда обычный бот говорит «не понял»: пользователь видит гладкий ответ и верит ему.
Отсюда главное: ИИ не отменяет работу по наполнению и обновлению базы знаний, а делает её ещё важнее. Плохие данные на входе — это уверенные, но плохие ответы на выходе.
И ещё: часть запросов помощник всё равно передаст человеку. Это нормально — он не «сдаётся», а осознанно отправляет сложный случай специалисту. Но если ждать, что ИИ возьмёт на себя вообще все обращения, разочарование неизбежно.
Почему это работает
Главное отличие от обычного портала самообслуживания — помощник на основе искусственного интеллекта избавляет пользователя от необходимости понимать структуру каталога услуг, разбираться в терминологии ИТ-отдела, искать нужную форму среди сотен вариантов, вручную заполнять поля, которые не всегда понятны.
Вместо этого пользователь общается на естественном языке, как с коллегой, а система сама делает всю работу по категоризации, поиску нужной формы и структурированию информации.
Помощник берёт на себя роль интеллектуального диспетчера — он правильно маршрутизирует и структурирует запрос ещё до его создания. Фактическое выполнение (выдача доступа, решение технической проблемы) остаётся за специалистами профильных подразделений. То есть не нужно расширять штат первой линии — искусственный интеллект делает ту работу, которую раньше выполняли люди вручную.
Выводы
Портал самообслуживания как концепция — работает, а проблема была и есть в точке входа. Каталог услуг, типовые запросы, база знаний, маршрутизация — всё это в системе остаётся и продолжает работать. Меняется только то, как пользователь до этого добирается: он описывает задачу своими словами, а когнитивную работу по переводу из Complex в Clear должна делать система.
Скриптовые боты не справились, потому что воспроизводили ту же логику портала. Генеративный ИИ справляется, потому что работает в обратную сторону: подстраивается под пользователя, а не требует от него подстраиваться под структуру системы.
Сталкивались с этой проблемой? Интересно услышать в комментариях, что пробовали и как решали — или почему решили не решать.