Если внедрять и поддерживать ITSM-систему, обязательно столкнешься с заявками по ошибочно выбранным услугам и прочими неприятностями. 

Привет, Хабр! Я — Ксения Попова, младший бизнес-аналитик в ITSM 365. Сейчас расскажу, как мы минимизируем проблемы в предоставлении сервисов.

В статье:

• почему пользователи выбирают не те услуги и как это исправить;

• как построить идеальный процесс обслуживания — от ввода услуги до создания заявки;

• как упростить жизнь поддержки при помощи автоматизации;

• как улучшить опыт пользователей и снизить количество «мусорных» заявок.

Что может пойти не так при выборе услуги

Что может быть проще, чем выбрать нужную услугу в сервис деск системе. В нашей практике мы часто наблюдаем ситуации, которые опровергают это представление. 

Например, пользователь создает заявку в категории «Получить доступ к ИТ-системам» с текстом: «Недоступно такое-то приложение, не могу работать, помогите ааа».

Вот что происходит дальше: специалист поддержки тратит время на выяснение деталей → оказывается, что проблема в зависшей программе, а не в правах доступа → из-за запуска некорректного процесса приходится переоткрывать заявку, сроки срываются, все ворчат.

Мы выделяем несколько основных причин, почему пользователь выбирает услугу неверно:

• не понятно из названия и описания, что входит в услугу, а что — нет;

• сбивают с толку технические термины, незнакомые простому смертному;

• нет времени погружаться в информацию, нужно быстро завести заявку;

• не удалось найти подходящий вариант, поэтому выбрана рандомная услуга.

В итоге получаем рост нагрузки на поддержку, замедление решения заявок и снижение удовлетворенности пользователей. Таких проблем может быть значительно меньше, если создавать и предоставлять услуги по определенным правилам.

Как выстроить процесс ввода новых услуг

При создании услуг мы в ITSM 365 рекомендуем придерживаться следующей последовательности этапов:

• Идентификация потребностей

• Определение структуры услуги

• Проектирование процессов 

• Формирование каталога услуг

• Тестирование на пользователях

• Запуск в работу

1. Идентификация потребностей

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

Для создания услуги необходимо понять:

• кто будет использовать услугу; 

• какие проблемы она решает;

• что хотят получить пользователи;

• как оценивать оказание услуги.

Пример: услуга по заказу оборудования

• Кто будет использовать — сотрудники, которым нужно оборудование для работы + отдел закупок + руководители, согласующие закупки.

• Какие проблемы решает — «не понимаю, что с моим запросом», «заказали не ту модель», «начальник долго согласует закупку».

• Что хотят получить пользователи — понимание текущего статуса запроса, сохранение корректных данных по заказу, получение согласия на замену модели у пользователя, фиксированные сроки согласования закупки.

• Как измерять и оценивать — оценка качества услуги потребителями, оценка соблюдения SLA, продолжительность решения заявки.

2. Определение структуры услуги

Мы выявили, чего хотят пользователи, теперь нужно перевести это на язык ITSM-подхода. Это поможет сократить уточнения по заявкам и экономить время исполнителей.

Рекомендуем учитывать следующие параметры:

• название — понятное обычному пользователю;

• описание — что входит в услугу;

• категория/привязка — в рамках какого договора предоставляется услуга и кто имеет возможность по ней обращаться;

• тип запроса — инцидент, запрос на обслуживание, запрос на изменение;

• вложенность — задается при необходимости, можно указывать вложенные и вышестоящие услуги для более детальной проработки сервисов;

• SLA — нужен для установления сроков и расстановки приоритетов в обработке заявок.

Опционально устанавливаются:

• куратор услуги — ответственный за процесс и качество сервиса по конкретной услуге;

• шаблон заявки — предзаполненная форма заявки с темой и описанием;

• рекомендуемые статьи базы знаний — связанные с услугой материалы, ссылки на них отображаются в форме подачи заявки.

                        Пример хорошо структурированной услуги в ITSM 365

3. Проектирование процессов по услуге

Проектирование процессов для IT-услуг должно решать проблемы пользователей, выявленные на первом этапе, и поддерживать баланс между эффективностью, контролем и удобством. Разберем ключевые моменты и принципы.

• Критерии выбора действий — необходимо установить факторы влияния и учесть их в процессах по услуге.

Важна срочность → варьируем сроки по SLA и автоматической эскалации.

Нужно снизить риски → вводим обязательные согласования, например, при замене одной модели оборудования на другую.

Очень много запросов по услуге → автоматизируем действия по заявке и используем шаблоны.

• Автоматизация рутины — проводим первоочередную оптимизацию процессов 

Упрощаем сбор информации → настраиваем форму подачи заявки и предзаполнение полей по шаблонам.

Настраиваем маршрутизацию заявок → устанавливаем правила назначения заявок на нужных ответственных и при необходимости добавляем согласования.

Настраиваем оповещения → добавляем уведомления о создании, смене статуса, добавлении комментария, завершении заявки, а также уведомления и напоминания об эскалации по SLA.

4. Формирование каталога услуг

Этот этап проиллюстрируем сравнением удачно собранного каталога и каталога, который стоит доработать.

Проблемы плохого каталога

• Технический язык 

Пример: «Инцидент в AD» → обычный пользователь может не знать, что это Active Directory.

• Нет контекста и примеров

Пример: «Запрос доступа» → к чему именно? К CRM, к папке, к серверу? Также не понятно, что именно указывать в описании заявки.

• Дублирование услуг 

Пример: «Проблема с Outlook» и «Ошибка SAP GUI» → эти услуги могут быть объединены в один инцидент «Не открывается программа».

• Слишком обширная услуга

Пример: «Выдача и ремонт оборудования» → необходимо разделить, как минимум, на две услуги.

Плюсы хорошего каталога

• Естественный язык

Пример: вместо «Активы» → категории «Программное обеспечение» и «Офисная техника». 

• Конкретные примеры

Пример: «Настроить удаленный доступ к компьютеру» → если важна причина, нужен образец описания заявки «Попытаюсь поработать из дома с 5 по 10 августа».

• Группировка по потребностям

Пример: услуги определяются не по категориям «Инцидент» или «Запрос», а по жизненным ситуациям → «Проблемы с техникой», «Доступ к системам».

Правильно сформированный каталог поможет сократить количество некорректных обращений. Главное — смотреть на него глазами заявителя!

5. Тестирование на пользователях

У нас в ходу есть несколько простых приемов для проверки «понятности» созданных услуг.

• Тест «5 секунд»

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

• Квест «Бухгалтерия»

Тут желательно найти добровольца, незнакомого с системой. Сможет ли человек не из ИТ-среды понять, как ему создать заявку по определенной услуге? Так получится выявить недостатки не только в формулировках, но и представлении каталога.

• Мониторинг ошибочных заявок

Смотрим на количество ошибочно созданных заявок от общего числа заявок по услуге. Если условные 20% запросов «Не работает Excel» попадают в «Доступ к системам», требуется корректировка.

Как упростить работу саппорта

Теперь рассмотрим работу конвейера по оказанию услуг с точки зрения службы поддержки. Чтобы у сотрудников было меньше стресса и проблем, на этапе проектирования услуг закладывают использование инструментов автоматизации. 

1. LLM-модуль

AI-модели анализируют текст заявки и устанавливают категории на основе описания, указанного заявителем. Используя LLM-модуль, специалисты больше не тратят время на переклассификацию заявок, система делает это за них. Это особенно удобно, если в службу поддержки поступает много обращений.

Пример:

Пользователь оставил заявку по услуге «Предложения по работе компании» с текстом: «Хочу подать жалобу на директора» → ML анализирует текст: ключевые слова «директор», «жалоба» → ML определяет договор «HR» и услугу «Подать заявление об увольнении» → заявка переклассифицируется по нужному сервису.

2. Правила автоматизации

С использованием правил можно назначить ответственный отдел или конкретного сотрудника, классифицировать заявку без участия специалиста, добавить автоматический комментарий при оказании определенной услуги

Пример:

После настройки правила пользователь создает заявку по услуге «Интернет» → автоматически проставляется нужный ответственный → добавляется автокомментарий для быстрого закрытия типовых вопросов.

                                      Карточка правила автоматизации в ITSM 365

3. Оповещения и эскалации

Чтобы предотвращать «зависание» заявок, соблюдать SLA и реагировать на срочные запросы вовремя, рекомендуем использовать механизм оповещений и эскалаций.

Пример:

• Уведомление о создании заявки → всем участникам процесса

• Установлен SLA → 2 часа на реакцию, 8 часов на ответ

• Через 6 часов → первое напоминание ответственному

• Через 7 часов → уведомление руководителю

Важно, чтобы оповещения по услугам приходили в удобные для исполнителей каналы, так информация не потеряется.

Пример:

❌ Оповещение о приближении срока по заявке на почту, которую руководитель проверяет нерегулярно.

✅  Оповещение о приближении срока по заявке через push-уведомление в мобильном приложении и в Telegram-боте. Зависимость от смартфона нам на руку!

4. Дашборды

Дашборд — это интерактивная панель с ключевыми метриками, которая собирает данные из системы и показывает их в виде графиков, диаграмм и таблиц. 

Что дают дашборды специалистам и лидерам команд:

• наглядность нагрузки → кто продуктивный молодец, а кому нужно подкинуть работы;

• ранжирование услуг по количеству запросов → сразу видно, где сосредоточены основные усилия специалистов и требуется дополнительная автоматизация;

• отслеживание SLA → помогает держать под контролем горящие заявки на команде и в личной ответственности, а также отслеживать, кто и по каким услугам чаще всего срывает сроки. 

Пример дашборда с аналитикой по заявкам можно посмотреть в материале Обзор service desk ITSM 365. 

5. База знаний

«Живая», качественная база знаний способна значительно облегчить жизнь сотрудников поддержки. 

• Улучшение обработки заявок → вся информация по работе под рукой, специалисты быстрее и качественнее решают заявки с помощью инструкций и шаблонов решений.

• Внедрение самообслуживания → заявители изучают статьи из внешнего раздела базы знаний и закрывают часть своих вопросов без помощи специалиста.

• Снижение нагрузки на поддержку → вылавливаем заявки на подлете: при выборе услуги всплывают подсказки со ссылками на статьи для самостоятельного решения проблемы.

Как улучшить опыт пользователей 

— А вы оказываете услуги или показываете?

— И оказываем и показываем!

— Мм, красивое

                             Так выглядит витрина услуг в ITSM 365, точнее ее часть

Как мы выяснили выше, слишком сложный каталог услуг с техническими названиями — основная проблема при подаче заявки.

По нашим наблюдениям, это может приводить к таким последствиям:

• 30-40% заявок создают в неправильной категории

• Пользователи дублируют запросы

• Растет срок решения заявки

• Снижается удовлетворенность поддержкой

Чтобы этого избежать, рекомендуем показывать пользователям каталог услуг в виде витрины, где они выбирают нужный сервис в удобном интерфейсе — как товар в интернет-магазине.

Ключевые элементы корректной витрины

• Категории 

Основной плюс витрины — возможность последовательного выбора категории и услуги согласно вложенности. Путь к нужному сервису показан в «хлебных крошках». Если такая цепочка кликабельна, то можно вернуться к предыдущим шагам, чтобы скорректировать выбор.

Услуги группируют по бизнес-процессам и на основе жизненных ситуаций, а не по IT-системам — так пользователям проще найти нужную услугу. Популярные услуги выносят в отдельную категорию для удобного доступа.

• Названия, описания, иконки

Простые и понятные названия услуг, емкие описания с примерами, информативные иконки — базовые элементы для быстрого и безошибочного выбора услуги. Они дополняются интерактивными возможностями витрины.

Краткие описания услуг можно полностью прочитать при клике или наведении на плашку услуги. Название и описание услуг будут видны сразу целиком, если переключиться с плиточного формата отображения на построчный. Также нужные услуги удобно находить через строку поиска.

• Форма подачи заявки

При подаче заявки с витрины все ключевые данные в форме добавления заявки уже предзаполнены, от пользователя потребуется внести минимум информации — указать тему и добавить описание. 

Для описания заявки также можно настроить автоматическое предзаполнение. Например, добавлять список требуемых данных или еще раз акцентировать внимание на том, что не входит в услугу. Тогда заявка точно будет заполнена правильно и сотрудникам не придется все переделывать.

                            Пример предзаполненной формы подачи заявки в ITSM 365

Вывод: как быстро наладить сервисный конвейер?

В первую очередь советуем:

• перевести услуги на «человеческий» язык;

• автоматизировать рутинные задачи поддержки;

• запустить витрину услуг для сотрудников или клиентов

Если привести в порядок эти три ключевых элемента, конвейер цифровых сервисов начнет выдавать результаты, которые понравятся всем участникам процесса обслуживания.