В нормальной схеме агент не заменяет инженера, а ускоряет triage. Он принимает обращение из helpdesk, Slack, Teams, email или формы, определяет тип: incident, service request, access request, question или problem, уточняет недостающие данные и предлагает следующий шаг.
Главные объекты процесса: ticket, requester, asset, service, category, priority, SLA, knowledge article, approval, assignment group, incident timeline, resolution note и audit log. Без этих полей агент будет отвечать красиво, но поддержка не сможет управлять очередью.
Агент полезен в простых сценариях: найти статью базы знаний, подготовить черновик ответа, попросить скриншот, проверить статус сервиса, заполнить summary тикета, предложить категорию и приоритет, найти похожие обращения и собрать release или incident report.
Рискованные действия требуют approval: выдача доступа, сброс MFA, изменение прав, блокировка учетной записи, изменение инфраструктуры, запуск скрипта, закрытие инцидента и сообщение пользователю о причинах сбоя без подтвержденных данных.
Для production важны ACL, role-based permissions, handoff rules, SLA escalation, runbook, knowledge base freshness, incident severity policy, approval_queue, action_allowlist, audit_log и метрики: first response time, resolution time, reopen rate, deflection rate и SLA breach.
Примеры
- Сотрудник пишет: "Не работает VPN". Агент уточняет ОС, сеть, ошибку, проверяет базу знаний и готовит черновик ответа с инструкцией.
- Поступил запрос на доступ к CRM. Агент классифицирует его как access request, проверяет владельца системы и отправляет заявку на approval руководителю.
- В течение часа пришло 20 похожих тикетов про недоступность почты. Агент группирует их как возможный incident, повышает priority и уведомляет дежурную группу.
- Тикет близок к нарушению SLA. Агент подсвечивает риск, предлагает эскалацию и пишет summary для второй линии поддержки.
- Пользователь просит сбросить MFA. Агент не выполняет действие сам, а проверяет policy, собирает данные для верификации и передает инженеру.
Где используется
- triage внутренних IT-заявок
- классификация тикетов и приоритета
- поиск решения в базе знаний
- подготовка черновиков ответов
- SLA monitoring и эскалации
- обработка access requests
- сводка инцидента для второй линии
- поиск похожих тикетов
- создание bug или task для инженерной команды
- weekly service desk report
Связанные термины
Частые вопросы
Что делает ИИ-агент для IT Service Desk?
Он помогает принимать и классифицировать IT-заявки, искать ответы в базе знаний, уточнять данные, готовить черновики ответов, следить за SLA и передавать сложные случаи инженерам.
Можно ли доверить агенту выдачу доступов?
Нет, не напрямую. Агент может подготовить заявку, проверить policy и отправить запрос на approval, но выдача доступа, сброс MFA и изменение прав должны подтверждаться человеком или строгим backend-процессом.
Какие данные нужны для запуска?
Нужны helpdesk или ITSM-система, категории тикетов, SLA-правила, база знаний, список сервисов, группы поддержки, матрица доступов, approval workflow и audit log.
Чем IT Service Desk агент отличается от агента клиентской поддержки?
Он работает с внутренними IT-сервисами, доступами, устройствами, инцидентами и SLA для сотрудников. Риски чаще связаны с безопасностью, правами доступа и инфраструктурой.
Какая первая автоматизация самая полезная?
Начните с triage тикетов и поиска ответов по базе знаний: агент ставит категорию, priority, предлагает статью, готовит summary и передает сложные или рискованные заявки второй линии.
