Что получится
ИИ-агент для IT Service Desk помогает внутренней поддержке быстрее разбирать заявки сотрудников: классифицирует обращения, ищет решение в базе знаний, уточняет недостающие данные, готовит черновик ответа, следит за SLA и эскалирует сложные случаи специалисту.
Важно: агент не должен самостоятельно выдавать доступы, менять права, сбрасывать пароли, закрывать инциденты или трогать критичную инфраструктуру без подтверждения. Внутренний service desk часто работает с доступами и персональными данными, поэтому безопасность здесь не декоративная галочка.
Где агент полезен
- Первичная классификация заявок.
- Ответы на типовые вопросы сотрудников.
- Подбор статьи из базы знаний.
- Сбор недостающих данных.
- Маршрутизация в нужную группу.
- Контроль SLA.
- Черновики ответов инженерам.
- Обнаружение массовых инцидентов.
- Связка заявки с активом или сотрудником.
- Подготовка отчета по нагрузке service desk.
Шаг 1. Выберите первый сценарий
Не начинайте с агента, который "решает все IT-заявки". Для MVP выберите безопасный поток.
Хорошие варианты:
- агент классифицирует входящие заявки;
- агент предлагает статью из базы знаний;
- агент задает уточняющие вопросы;
- агент готовит черновик ответа;
- агент следит за SLA и риском просрочки;
- агент формирует ежедневный отчет по очереди.
Лучший старт - read-only помощник оператора: он читает заявку, предлагает категорию, приоритет, статью и черновик ответа, но ничего не применяет без человека.
Шаг 2. Соберите каталог заявок
Агент должен понимать типы обращений.
Примеры категорий:
- доступы;
- оборудование;
- программное обеспечение;
- сеть;
- почта;
- VPN;
- учетная запись;
- инцидент;
- сервисный запрос;
- консультация;
- закупка;
- увольнение или onboarding.
Для каждой категории задайте:
- какие данные нужны;
- кто владелец;
- какой SLA;
- какие действия разрешены;
- какие действия запрещены;
- какие статьи базы знаний подходят;
- когда нужна эскалация.
Шаг 3. Подключите service desk систему
Чаще всего агент работает рядом с ITSM или ticketing-системой.
Типовая связка:
- Jira Service Management для service desks, requests, customers, organizations и queues.
- Zendesk API для tickets, users, groups, organizations и ticket workflow.
- Freshservice API для tickets, requesters, service requests, assets и ITSM-процессов.
Для старта не нужно подключать все системы. Подключите ту, где реально живут внутренние заявки.
Шаг 4. Настройте минимальные права
На первом этапе агенту нужны только безопасные действия.
Разрешите:
- читать заявки;
- читать комментарии;
- читать статус;
- читать приоритет;
- читать SLA;
- читать базу знаний;
- читать активы без лишних персональных данных;
- создавать черновик ответа;
- предлагать категорию.
Через approval:
- поменять статус;
- назначить группу;
- назначить исполнителя;
- изменить приоритет;
- добавить публичный ответ;
- закрыть заявку;
- запустить автоматизацию;
- выдать доступ.
Запретите без отдельного процесса: удаление заявок, массовое изменение, сброс пароля, изменение прав доступа и действия с production-инфраструктурой.
Шаг 5. Сделайте нормализацию заявки
Разные системы хранят заявки по-разному. Агенту нужна единая структура.
{
"ticket_id": "IT-1245",
"subject": "Не работает VPN",
"requester": "employee_42",
"category": "vpn",
"priority": "medium",
"status": "open",
"sla_due_at": "2026-05-22T17:00:00+05:00",
"asset_id": "laptop_774",
"missing_fields": ["os_version"]
}Такая модель помогает агенту одинаково работать с Jira Service Management, Zendesk, Freshservice и другими системами.
Шаг 6. Подключите базу знаний
Без базы знаний service desk агент начнет импровизировать. Это опасно.
В базе должны быть:
- инструкции для сотрудников;
- инструкции для операторов;
- типовые решения;
- правила выдачи доступов;
- регламенты SLA;
- список сервисов;
- список ответственных;
- шаблоны ответов;
- запрещенные действия;
- сценарии эскалации.
Агент должен ссылаться на статью или регламент, по которому предлагает ответ.
Шаг 7. Настройте уточняющие вопросы
Часто заявка неполная. Агент должен не угадывать, а спрашивать.
Примеры:
- какая операционная система;
- когда началась проблема;
- появляется ли ошибка;
- затронут один пользователь или группа;
- какой сервис недоступен;
- есть ли скриншот;
- какой номер устройства;
- нужен ли временный или постоянный доступ;
- кто согласует доступ.
Для каждой категории заведите список обязательных полей. Если поле отсутствует, агент предлагает уточнение.
Шаг 8. Разделите инциденты и запросы
Инцидент - что-то сломалось. Service request - сотрудник просит стандартную услугу.
Примеры инцидентов:
- не работает VPN;
- почта не отправляется;
- сервис недоступен;
- ноутбук не включается;
- ошибка в системе.
Примеры service requests:
- выдать доступ;
- установить ПО;
- подготовить ноутбук;
- создать учетную запись;
- заказать оборудование.
Для инцидентов важны влияние и срочность. Для запросов - согласование, права и стандартная процедура.
Шаг 9. Следите за SLA
SLA нельзя отслеживать на глаз.
Агент должен видеть:
- время создания;
- время первого ответа;
- срок решения;
- текущий статус;
- группу исполнителя;
- приоритет;
- сколько осталось до просрочки;
- кто должен отреагировать.
Полезные сигналы:
- заявка скоро нарушит SLA;
- нет первого ответа;
- заявка долго висит в ожидании;
- исполнитель не назначен;
- похожих заявок стало много.
Шаг 10. Обнаруживайте массовые проблемы
Если за 20 минут пришло 15 заявок про VPN, это может быть инцидент.
Агент может группировать заявки по:
- сервису;
- тексту ошибки;
- времени;
- отделу;
- локации;
- устройству;
- версии ПО;
- сети.
При подозрении на массовую проблему агент не должен отвечать каждому по отдельности как на частный случай. Он должен предложить создать incident, уведомить ответственных и подготовить единый статус.
Шаг 11. Готовьте черновики ответов
Черновик ответа должен быть коротким и полезным.
Структура:
- признать обращение;
- уточнить недостающие данные или дать шаги;
- сослаться на инструкцию;
- сказать, что будет дальше;
- указать срок или следующий статус.
Для чувствительных тем агент не должен обещать доступ или решение. Формулировка должна быть аккуратной: "передал запрос на согласование", а не "доступ будет выдан".
Шаг 12. Проверьте агента перед запуском
Соберите тестовый набор:
- 20 типовых заявок;
- 10 неполных заявок;
- 10 заявок на доступ;
- 10 инцидентов;
- 5 массовых проблем;
- 5 конфликтных обращений;
- 5 заявок с персональными данными;
- 5 заявок, где агент должен отказать.
Проверяйте:
- агент правильно классифицирует заявку;
- не выдает доступ без approval;
- не закрывает заявку без решения;
- задает уточняющие вопросы;
- ссылается на базу знаний;
- видит риск SLA;
- отделяет массовый инцидент от одиночной проблемы;
- не раскрывает лишние данные.
Минимальная архитектура
- Ticketing-система хранит заявки, статусы, SLA и комментарии.
- База знаний хранит регламенты, инструкции и шаблоны.
- Каталог услуг описывает категории, владельцев и обязательные поля.
- Агент классифицирует заявку, ищет решение и готовит черновик.
- SLA-монитор отслеживает просрочки и риски.
- Approval-слой подтверждает действия с доступами, статусами и ответами.
- Audit log фиксирует все предложения и подтверждения.
Частые вопросы
Может ли агент сам закрывать заявки?
На старте лучше нет. Он может предложить закрытие, если есть подтверждение пользователя или выполненное решение, но финальное действие должен сделать оператор или автоматизация с четкими правилами.
Чем IT Service Desk агент отличается от агента поддержки клиентов?
Клиентская поддержка работает с внешними пользователями и продуктом. IT Service Desk работает с внутренними сотрудниками, доступами, оборудованием, сервисами, SLA и ITSM-процессами. Риски по правам доступа обычно выше.
Какие заявки можно автоматизировать первыми?
Типовые информационные запросы, подбор статей базы знаний, уточнение недостающих данных, классификация, маршрутизация и SLA-напоминания. Доступы, пароли и инфраструктурные действия лучше подключать позже.
Что делать с заявками на доступ?
Агент может проверить обязательные поля и подготовить запрос на согласование. Выдача доступа должна идти через утвержденный процесс, владельца системы и audit log.
Как понять, что агент полезен?
Смотрите на время первого ответа, долю правильно классифицированных заявок, снижение просрочек SLA, меньше ручной маршрутизации, больше заявок с полными данными и меньше повторных вопросов сотрудникам.
