Случай: «давайте сделаем AI для Service Desk»
Elena Varga руководит ENGAGE Service Desk в Aldervane Advisory LLP. За прошлый год её команда приняла 18 400 тикетов. Каждый тикет дежурный агент читает и отправляет в одну из 14 групп поддержки. Почти каждый четвёртый тикет потом перекидывают в другую группу, и каждая такая переброска добавляет часы к решению. На квартальном ревью David Okonkwo сказал: «Давайте сделаем AI для Service Desk».
Это не постановка задачи. Это пожелание. Непонятно, какое решение должно стать лучше, кто его принимает, по каким данным и во что обходится ошибка. Группа Digital & IT, в которой вы работаете, должна превратить пожелание в задачу — или честно сказать, что AI здесь не нужен. Этот юнит учит делать именно это. Весь курс дальше будет возвращаться к этому случаю: он станет Triage PoC.
Три разных класса решений
Автоматизация по правилам. Поведение полностью описывается логикой, которую можно записать заранее. «Если в форме выбрано Сброс пароля — отправить в Identity». Правило дешёвое, проверяемое и объяснимое. Если задача так решается, AI не нужен.
Аналитика отвечает на вопросы о прошлом: сколько P1 было за квартал, какая группа чаще всего перебрасывает тикеты, как менялось время первой реакции. Результат — отчёт, по которому решает человек.
AI/ML нужен, когда правило трудно выписать руками, но есть примеры правильных ответов или нужно работать со смыслом текста:
- предсказать вероятность нарушения SLA;
- по свободному тексту тикета предложить группу;
- найти похожие прошлые инциденты;
- подготовить черновик ответа клиенту.
Внутри AI курс различает классический ML (u05–u10) и generative AI (u11–u14). Это тоже не синонимы.
Description
Дерево из четырёх вопросов. Первый: можно ли записать решение правилом заранее? Если да — правило или автоматизация, AI не нужен. Если нет, второй вопрос: нужен ли ответ о прошлом — сколько, где, как менялось? Если да — аналитика и отчёт. Если нет, третий вопрос: есть ли исторические примеры правильных решений? Если да — классический ML, юниты u05–u10. Если нет, четвёртый вопрос: нужно ли найти или написать текст по смыслу? Если да — GenAI, RAG или агенты, юниты u11–u14. Если нет — задачу надо переформулировать или сначала собрать данные. Порядок вопросов — от дешёвого решения к дорогому: каждый следующий подход сложнее и дороже в сопровождении.
Порядок вопросов не случаен: от дешёвого к дорогому. В реальном use case подходы часто комбинируются. Для Triage PoC: правила для очевидных форм, ML для свободного текста, аналитика — чтобы измерить эффект.
Пять вопросов до выбора технологии
- Какое решение или действие мы хотим улучшить? Не «Service Desk», а «первичную маршрутизацию тикета в группу поддержки».
- Кто принимает это решение сейчас и за сколько? Дежурный агент, в среднем 3 минуты на тикет.
- Какие данные доступны в момент решения? Тема, текст, сервис, отправитель. Не «итоговая группа, в которой тикет закрыли»: её в момент маршрутизации ещё нет. К этой ловушке мы вернёмся в u05.
- Как выглядит правильный результат и как мы это узнаем? Тикет не перебросили и не нарушили SLA.
- Сколько стоит ошибка — в каждую сторону? P1, отправленный не туда, стоит часов простоя клиентского проекта. Лишний тикет у сильной группы стоит минут.
«Использовать LLM для ServiceNow» — слабая постановка. «Сократить долю перебросок с 23 % до 12 %: предлагать агенту группу по тексту тикета, а финальное решение оставить агенту» — уже инженерная задача. У неё есть метрика, базовая линия и граница ответственности.
Где возникает ценность — и как её посчитать
Для IT в professional-services типичны:
- triage обращений;
- поиск по внутренним знаниям;
- анализ документов;
- прогноз нагрузки;
- anomaly detection;
- summarization;
- помощь разработчикам и тестировщикам.
Ценность считают в единицах бизнеса, а не в accuracy. Грубая оценка для Triage PoC: 18 400 тикетов в год. Если подсказка сэкономит агенту одну минуту на 70 % тикетов, это 18 400 × 0,7 × 1 / 60 ≈ 215 часов в год. Это примерно шесть рабочих недель одного агента. Много или мало — зависит от цены решения, и этим займётся u15.
Но основная ценность здесь, скорее всего, не в минутах агента, а в переброшенных тикетах. Каждая переброска P1 — это часы, которые клиент ждёт. Хорошая постановка называет, какую из ценностей мы покупаем.
Human-in-the-loop
Description
Изометрический рисунок стойки Service Desk. На стойке высокая куча одинаковых конвертов — это тикеты. За стойкой стена открытых ячеек — группы поддержки. Слева на стойке стоит простая серая сортировочная машина с одним механическим рычагом; сверху у неё лежит зелёная карточка-подсказка. Сотрудница держит такую же зелёную карточку и читает её; рядом на стойке лежит серый штемпель. Справа мужчина несёт к куче новую стопку конвертов. Зелёные карточки — единственный цветной предмет. Метафора: машина предлагает, куда отправить тикет, а решение и штемпель остаются у человека. Рисунок не показывает, что происходит, когда машина не уверена: такие тикеты в хорошем дизайне идут человеку без подсказки.
Во многих enterprise-сценариях AI не заменяет решение человека, а снижает стоимость его принятия: предлагает категорию, выделяет риск, готовит черновик, показывает evidence. Есть три типичных распределения ролей:
- AI предлагает, человек решает. Подходит для старта и для дорогих ошибок.
- AI решает сам, если уверен; остальное отдаёт человеку. Это экономит больше, но требует измеренной уверенности (u03, u09).
- AI решает, человек выборочно проверяет. Подходит только для дешёвых и обратимых ошибок.
Чем выше цена ошибки и чем труднее её отменить, тем ближе к первой схеме. Human-in-the-loop — не бесплатная страховка. Если агент подтверждает 300 подсказок в смену, он перестаёт их читать, и контроль остаётся только на бумаге (u14).
Цена
Даже самый простой AI use case стоит больше, чем подписка на модель:
- Данные. Выгрузка, чистка, разметка. Для Triage PoC это недели Rahul Mehta, data engineer.
- Evaluation. Базовая линия «как сейчас» и честное измерение «как стало».
- Изменение процесса. Агентов учат работать с подсказкой, меняются инструкции и SLA.
- Сопровождение. Модель стареет вместе с данными: появились новые сервисы, переименовали группы.
- Риски. Конфиденциальность текстов тикетов, ошибки на редких, но дорогих случаях.
Иногда честный итог первого юнита — «здесь хватит трёх правил в форме тикета». Это тоже результат.
Первый принцип курса
Не спрашивайте «где применить AI?». Спрашивайте: какое решение мы хотим улучшить, почему текущий процесс недостаточен, какой уровень ошибки допустим и во что обойдётся решение? Только после этого выбирается технология.