Автоматизация техподдержки: что, когда и как автоматизировать

Что стоит автоматизировать в первую очередь

Универсальный принцип — автоматизируйте то, что повторяется. Не уникальные задачи, а рутину. Топ-5 кандидатов:

1. Маршрутизация входящих заявок. Email от support@ → парсинг темы и отправителя → создание заявки с правильным типом, услугой, командой-исполнителем. Экономия: 30–60 секунд на каждую входящую заявку.
2. Эскалация по SLA. За 20% времени до дедлайна — напоминание исполнителю; за 10% — уведомление руководителю; при просрочке — переназначение. Экономит время дежурного диспетчера.
3. Шаблонные сервисные запросы. «Сброс пароля», «Выдача VPN», «Установка MS Office» — должны обрабатываться по готовому скрипту с минимумом ручных действий.
4. Уведомления пользователям. Автоматические при смене статуса, назначении, закрытии. Снимает с оператора рутину "написать пользователю".
5. Автозакрытие неактивных заявок. Заявка в статусе «Ожидает пользователя» > 7 дней без ответа — автоматическое напоминание, ещё 3 дня — автозакрытие с возможностью переоткрыть.

Rules Engine: правила IF-THEN

Большая часть автоматизации — это правила вида «если условие — то действие». Это реализуется через rules engine в ITSM-системе.

Триггеры: что запускает правило

• Создание заявки — по email, через портал, через API, из мониторинга
• Смена статуса — новая → в работе, в работе → решена
• Истечение времени — таймер SLA, таймаут ожидания пользователя
• Изменение поля — смена приоритета, перевод в другую команду
• Внешнее событие — алерт из системы мониторинга, webhook

Условия: когда правило применяется

Условия могут комбинироваться через AND/OR:

• Тип заявки = Инцидент
• Приоритет = Критичный
• Услуга IN (Электронная почта, VPN)
• Отправитель в группе «VIP»
• Текст темы содержит «пароль»
• Время создания вне рабочего окна

Примеры рабочих правил

Несколько реальных правил, которые стоит внедрить в первую очередь:

1. Парсинг темы на пароли: IF тема содержит "пароль" OR "password" THEN создать запрос с шаблоном "Сброс пароля", назначить L1-очереди.
2. Критичные эскалации: IF приоритет = Критичный AND статус = Новая > 15 мин THEN уведомить дежурного SMS + телефоном.
3. SLA-алерт: IF до дедлайна осталось ≤ 20% THEN повысить приоритет, уведомить руководителя команды.
4. Авто-маршрутизация по услуге: IF услуга = "1С" AND тип = Инцидент THEN назначить команде 1С-администраторов.
5. VIP-обработка: IF отправитель в группе «Руководство» THEN приоритет = Высокий, назначить senior L2.
6. Тикет вне рабочего времени: IF создано в 20:00–08:00 AND приоритет ≠ Критичный THEN автоответ "Мы ответим с 9 утра", SLA стартует в 9:00.

Самообслуживание как форма автоматизации

Лучшая заявка — которой не было. Пользователь сам нашёл ответ в базе знаний и не стал отвлекать команду. Это и есть самообслуживание — частный случай автоматизации.

Что должно быть в self-service-портале:

• Поисковая строка — в первую очередь показывать статьи БЗ
• Каталог услуг — с формами заказа типовых услуг
• Статус «моих» заявок — пользователь не звонит "а что там с моим?"
• FAQ по самым частым вопросам
• Кнопка "Создать заявку" — если ничего не подошло

При правильной настройке 20–40% потенциальных заявок закрываются без участия оператора. Подробно о БЗ — в статье о базе знаний.

Автоматическая маршрутизация

Классический сценарий: письмо приходит в IT, его читает диспетчер, определяет тип, назначает команду. На 50 заявок в день это ~1 час работы. Автоматизация устраняет этот шаг.

Маршрутизация строится на нескольких признаках:

• По ключевым словам в теме — "1С" → команда 1С, "VPN" → сеть, "почта" → Exchange.
• По услуге — если пользователь выбрал услугу в каталоге.
• По отправителю — из AD известна локация пользователя, маршрутизируем на команду этого офиса.
• По времени — ночные заявки идут на дежурную смену, а не на выходных сотрудников.
• По загрузке — внутри команды равномерно распределять между операторами (round-robin или по доступности).

Интеграция с мониторингом

Одна из самых полезных автоматизаций — автоматическое создание заявок из алертов мониторинга:

• Prometheus / Zabbix засёк падение сервиса → webhook в ServiceDesk
• Создаётся инцидент с приоритетом по severity алерта
• Назначается команде-владельцу сервиса
• Если алерт резолвится через N минут сам — заявка закрывается автоматически

Подробнее об интеграциях — в отдельной статье.

AI и чат-боты: где реальная польза, а где хайп

За последние годы тема "AI в поддержке" превратилась в поток обещаний. Прагматичная оценка:

Где AI реально помогает

• Классификация обращений — ML-модель определяет тип, услугу, приоритет по тексту с точностью 80–90%. Экономит время диспетчера.
• Подсказка статей БЗ — при открытии заявки система ищет похожие решённые и показывает операторам.
• Анализ тональности — вычисление "горячих" недовольных клиентов по тексту для проактивной эскалации.
• Саммаризация тикетов — когда заявка велась долго, модель собирает короткое резюме.

Где часто переоценивают

• Чат-боты для первой линии — работают для очень узких сценариев (сброс пароля), на остальное фрустрируют пользователей.
• "AI сам решит любую заявку" — нет. Сложные технические проблемы требуют доступа к системам и логам.
• Полная замена L1 — миф. AI разгружает L1, но не заменяет.

Расчёт ROI автоматизации

Как посчитать, окупится ли конкретное правило автоматизации:

1. Частота применения — сколько раз в месяц сработает? (например, 200 раз)
2. Экономия времени на одно срабатывание — сколько минут сэкономит? (например, 2 мин)
3. Стоимость минуты оператора — зарплата + накладные / 10 000 рабочих минут в месяц.
4. Итоговая экономия в месяц = 200 × 2 × стоимость минуты.
5. Стоимость настройки — часы на внедрение и тестирование × стоимость часа.
6. Срок окупаемости = стоимость настройки / месячная экономия.

Правило с окупаемостью > 12 месяцев — скорее всего не стоит внедрять. 3–6 месяцев — хороший показатель. 1–3 — внедрять немедленно.

Типовые ошибки автоматизации

1. Автоматизация хаоса. Процессы не описаны, автоматизируется "как сейчас работает" (то есть никак). Автоматизированный хаос — это быстрый хаос. Сначала описываем процесс, потом автоматизируем.
2. Слишком много правил. 200+ правил, никто уже не помнит, что каждое делает. Конфликты, дубликаты, невозможно поддерживать. Решение: ежеквартальный аудит правил, отключение неиспользуемых.
3. Авто-ответы без человеческой помощи. Пользователь пишет о горящей проблеме — получает автоответ "ваш запрос принят" и тишина. Решение: авто-уведомления дополняют, но не заменяют реальную работу команды.
4. Нет отслеживания эффекта. Внедрили правило, забыли. Не знаем, работает ли. Решение: метрики до/после внедрения по каждому правилу.
5. Жёсткие правила без гибкости. "В 18:00 все незакрытые заявки эскалируются" — ломает ситуации, когда это неуместно. Решение: исключения, пороги, возможность оператору отключить правило для конкретной заявки.

С чего начать

Приоритетный список для внедрения:

1. Неделя 1: авто-создание заявок из email с базовым парсингом темы.
2. Неделя 2: маршрутизация по услугам (по ключевым словам в теме и услуге из формы).
3. Неделя 3: автоматические уведомления (смена статуса, назначение, закрытие).
4. Неделя 4: SLA-таймер с эскалацией за 20% до дедлайна.
5. Месяц 2: шаблоны для топ-5 сервисных запросов (сброс пароля, выдача ПО, VPN и т.д.).
6. Месяц 3: интеграция с мониторингом для автоматического создания инцидентов.

Вывод

Автоматизация — это бесконечный процесс улучшений, а не разовый проект. Начните с простых правил, измеряйте эффект, добавляйте новые по мере необходимости.

Хорошая ITSM-система даёт rules engine из коробки: создание и редактирование правил через интерфейс, без программирования. В TIQQET это встроенный модуль с типовыми шаблонами правил, которые можно адаптировать под свои процессы.