Request Fulfillment: как автоматизировать обработку сервисных запросов

Что такое Service Request

Service Request — это запрос на стандартную, заранее одобренную услугу. Ключевое слово — стандартная. Если процедура описана и одобрена менеджментом, запрос становится «продуктом» в каталоге: пользователь его запрашивает, не объясняя каждый раз, зачем.

Примеры:

• Доступ к сетевой папке / SharePoint / Wiki
• Установка ПО из утверждённого каталога (Office, Photoshop, IDE)
• Заказ периферии (мышка, наушники, монитор)
• Создание учётки в системе
• Восстановление файла из бэкапа
• Запрос на учебный курс / сертификацию

В отличие от инцидента (что-то сломалось), Service Request не требует диагностики — нужно выполнить процедуру. Это меняет всю логику обработки.

Сервисный каталог как основа

Каталог — это структурированный список доступных запросов с шаблонами форм, SLA, исполнителями и согласующими. Без каталога каждая заявка обрабатывается ad hoc: пользователь пишет в свободной форме, оператор уточняет детали, ищет ответственного. С каталогом — за 2 клика и одну форму.

Структура карточки в каталоге:

• Название и иконка — для портала
• Описание — для каких ситуаций
• Форма — обязательные поля (например, для запроса на доступ: к какому ресурсу, на какой срок, обоснование)
• SLA — сколько обещаем выполнять
• Согласующие — кто должен одобрить (если нужно)
• Исполнитель — кто закрывает (автоназначение)
• Условия видимости — кому доступен запрос (по отделу, должности)

В TIQQET каждый шаблон в Request Types может содержать customFields с типами text / dropdown / date / checkbox / file. Это полностью покрывает 95% типовых форм.

Авто-аппрув: когда согласование не нужно

Не каждый запрос требует ручного согласования. Если правила прописаны — система может одобрять сама. Примеры:

• Доступ к публичной Wiki — нужен всем сотрудникам, согласовывать нечего.
• Стандартное ПО из white-list — Adobe Reader, Notepad++, лицензионный VLC. Согласование занимает 0 человеко-минут, но в очереди сидит.
• Сброс пароля для собственного аккаунта — самосервис через email/SMS.
• Запрос на типовое оборудование при онбординге нового сотрудника — список «стандартный комплект новичка» утверждён HR, автоматически уходит на склад.

Правила для авто-аппрува: если запрос соответствует критериям → переход сразу на исполнителя. Согласующий получает уведомление «согласовано автоматически, можно отменить в течение 24 часов».

Это убирает «узкое горлышко в виде менеджера» для рутины. Менеджеры согласуют только нестандартное: VIP-оборудование, лицензии вне каталога, доступ к чувствительным системам.

Интеграция с HR и закупками

Самые «дорогие» Service Request — это онбординг и offboарding сотрудника. В типовой компании:

• Нанимается человек → IT нужно создать учётки, выдать ноутбук, дать доступы. 5-15 заявок.
• Увольняется → блокировать всё, передать данные. 8-20 заявок.

Если HRM и helpdesk не интегрированы — это переписка в почте «Иванов выходит 1 марта», ручное создание заявок, забытые доступы. Сценарий, где integration выручает:

1. HR в кадровой системе ставит статус «onboarding initiated» с датой выхода.
2. Через webhook в helpdesk автоматически создаётся pack заявок: «AD-учётка», «корпоративная почта», «доступ к Confluence», «комплект оборудования по должности».
3. Заявки идут параллельно по разным исполнителям с дедлайном «к дате выхода».
4. В день выхода — все доступы готовы. HR-менеджер видит зелёный статус и подтверждает.

То же зеркально для offboарding: статус «termination» в HRM → автоблокировка во всех системах + передача данных по чек-листу.

Технически это webhook от HRM в API ServiceDesk + правило в Automation Rules «при создании заявки типа onboarding → создать связанные заявки по списку».

Метрики Request Fulfillment

Главное отличие от метрик инцидентов: Service Requests не должны иметь высокую вариативность. Если процесс описан — он должен исполняться предсказуемо.

• SLA compliance per request type — каждый тип запроса в каталоге имеет свой SLA. Цель: 95-98%. Если упало ниже — либо SLA нереалистичный, либо процесс сломан.
• Volume per type — какие типы запросов самые частые. Топ-5 — кандидаты на shift-left и автоматизацию.
• Auto-approval rate — процент запросов, прошедших без ручного согласования. Высокий показатель = меньше overhead на менеджеров.
• Lead time vs touch time — общее время выполнения vs реальное время, которое исполнитель потратил. Если lead time = 4 дня, а touch time = 30 минут — заявки висят в очереди, не работают над ними.

Отдельно стоит замерять request volume per FTE — сколько запросов в месяц обрабатывает один FTE поддержки. Здоровое значение: 80-150 для L1, 30-60 для L2. Выше — перегрузка, ниже — недозагрузка или процессные неэффективности.