Портал №1 по управлению цифровыми
и информационными технологиями

Насколько детальным должно быть меню регистрации запросов пользователей?

В редакцию портала поступил вопрос:

Добрый день. Вопрос наверное не новый и проблема общая.

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

Вопрос в следующем, насколько глубоко меню регистрации запроса должно быть категоризировано. Грубо говоря первая крайность  — меню совсем без полей выбора привязки к сервису, к типу и т.д., пользователь просто описывает проблему своими словами, а далее все привязки делает специалист СТП при регистрации запроса. Вторая крайность -  меню содержит кучу зависимых полей выбора (Сервис — Вид обращения — Тип запроса и т.д.), в которых пользователь обычно путается и регистрирует запрос неверно.

Хотелось бы знать, есть ли какая то методология по определению дружелюбности меню (интерфейса) регистрации запроса со стороны пользователя? Ну или у кого-то есть опыт в решении данной проблемы. Заранее спасибо.

«VAP: Управление поддержкой ИТ-услуг»
Концентрация знаний и опыта без натаскивания на экзамен

Комментариев: 6

  • Владимир Невский

    Добрый день. Тоже хотел бы узнать мнение коллег по этому поводу... ИМХО — если пользователь редко обращается в тех. Поддержку, то, конечно, изучать процедуру самостоятельного оформления тикета с заполнением всех полей он не будет. Для массового пользователя нужно попытаться найти золотую середину, например, не работает печать/проблема или вопрос с конкретным ПО/нужна бумага/справка НДФЛ/вызвать такси — первый шаг, думаю, каждый пользователь может сделать безошибочно сам. Также в информационных системах можно разместить кнопку типа «сообщить об ошибке», по нажатию которой можно относительно предметно формировать тикет. + Есть достаточно большая группа пользователей-предметников, например, бухгалтера, которые безошибочно и быстрее любого диспетчера на 1-й линии могут определить всю подноготную обращения, которое можно сразу без участия 1-й линии маршрутизировать на группу исполнителей (был такой опыт, когда для оформления тикета повышенного приоритета нужно было из справочника выбрать помимо услуги ещё вид запроса/событие, которое произошло). В общем: универсальной таблетки не существует, нужно учитывать нюансы и интересы различных групп заказчиков.

  • Антон Боганов

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

  • ВяЧЕСлав

    Поддерживаю идею комбинированных входящих:

    1. телефон для «все пропало»

    2. почта с гибким шаблоном на 5 полей

    3. портал с хард каталогом для ТОП-проблематики

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

    Для себя ставлю целью — 10%-30%-60%

  • Sergey

    Доброго дня, поделюсь своим.

    Если услуг много то их лучше группировать (Пользовательское оборудование, Пользовательское ПО, Инфраструктура, Приложения (критичные и нет), Услуги АХО и т.д.).

    Когда пользователь выбирает услугу дальше ему неконструктивно подсовывать стандартный набор (выберите что хотите Инцидент, ЗнО или ЗнИ) т.к. если с инцидентом пользователь ещё разберётся то разницу между ЗнО\ЗнИ это уже тяжело.

    Лучше после выбора сервиса предложить понятные формы запросов, например:

    После выбора сервиса МФУ — Установить\Забрать, Переместить, Консультация, Не работает, Застряла бумага, Заменить картридж, Регламентные работы (для своих), Подключить и т.д...

    Желательно оставить «неопределенное» — если пользователь не нашёл или не уверен что выбрать. Тип заявки уже привязать к «пользовательскому» запросу например Консультация = ЗнО. Таким образом вы не «грузите» пользователя спецификой ITIL\ITSM.

    А анализируя «неопределенные» запросы легко выявлять каких категорий ещё не хватает или они неудобны.

  • Сергей Харитонов

    Приветствую!

    Нас спасает многоуровневая классификация.

    На самом верхнем уровне — подразделение, услуги которого пользователь собирается получить (ИТ, Бухгалтерия, Кадры, АХО, управляющая компания).

    Далее — пользователь выбирает сервис — один или 2 уровня классификации — (Программа 1С -> Бухгалтерия, Персональное оборудование -> телефон, Оборудование рабочего места -> Компьютер).

    И в последнем уровне классификации — действие/услуга (Проблема со входом, не включается, купить новый, ошибка программы).

    Помимо набора услуг в каждом подразделении есть категория «Не нашёл необходимого сервиса». Это категория-триггер, что либо не хватает услуги, либо пользователь не смог разобраться в каталоге, либо пользователь просит услугу, которую подразделение не предоставляет. На данную категорию обращает пристальное внимание ITSM-спец и руководитель подразделения.

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

    Эволюция каталога услуг возложена на первую линию (диспетчеров). Они видят либо повторяющиеся ошибки пользователей при классификации, либо большое количество заявок в категории «Не нашёл необходимого сервиса». В любом случае в интересах первой линии выровнять каталог услуг, чтобы было меньше работы в диспетчеризации. Shift-left он и в Африке shift-left

  • Артем

    То есть все опытным путем ? Просто думал есть какая то методология, чтобы велосипед не изобретать...


Добавить комментарий

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

  • Рубрики

  •  
  • Авторы

  •  
  • Самое свежее

    • 3 стратегии, которые помогут вашей команде принять метрику потока
      Вам необходимо эффективно управлять рабочими процессами, чтобы иметь возможность постоянно предоставлять ценность своим клиентам. Именно здесь в игру вступают метрики потока. Метрики потока являются основной движущей силой оптимизации процессов.
    • Новая модель предоставления ИТ-услуг: почему вам нужно ориентироваться на продукт
      Традиционно ИТ-организации делят все предоставляемые ими услуги на три уровня: инфраструктура (инфраструктура как услуга), платформа (платформа как услуга) и приложения
    • Как DevOps-командам следует использовать метрики DORA
      С момента выхода в 2018 году книги «Accelerate: Наука о бережливом программном обеспечении и DevOps», показатели DORA, которые она представила, стали популярным
    • Лучше делать хоть что-то, чем не делать ничего
      На конференциях по всяким Agile и DevOps мы часто слышим слово «unlearn» — забудьте то, что вы знали ранее! Измените свои представления о мире! Всё устроено
    • VI форум «Управление данными — 2021»: наведите порядок в данных!
      23 сентября 2021 года издательство «Открытые системы» в шестой раз проведет в Москве масштабный форум «Управление данными — 2021», объединяющий всех, кто определяет стратегию работы с данными, воплощает ее в жизнь и управляет предприятием на основе объективных достоверных данных. Участники форума обсудят не только инновационные стратегии и бизнес-модели работы с корпоративными данными, но и конкретные архитектурные и технологические решения.
    • Простые уловки, как ускорить процесс разработки программного обеспечения
      С некоторыми вещами люди из бизнеса вынуждены соглашаться, и одна из них заключается в том, что никто не хочет сердить свою команду разработчиков. Часто они являются краеугольным
    • Почему каждая инициатива DevOps должна начинаться с оценки возможностей
      Внедрение практики DevOps идет полным ходом. Организации сосредоточены на том, как внедрить возможности DevOps в командах и как масштабировать DevOps в масштабах предприятия. Но важным аспектом любого пути масштабной трансформации является оценка возможностей команды или организации на этом пути.
    • Что такое процесс и что такое практика в ITIL®4
      Продолжаем публиковать короткие видеоролики, посвященные актуальным вопросам управления ИТ. Сегодня поговорим о том, что такое процесс и что такое практика в ITIL4. Это не переименование процессов в практики, это два отдельных понятия. Рассказывает Игорь Фадеев, ITIL 4 Managing Professional и ITIL 4 Strategic Leader, аккредитованный тренер по ITIL4.
    • Аудит. Что может быть скучнее?!
      На прошедшей неделе участвовал в аудите (в качестве объекта аудита). Большинство людей, проходивших аудит, подозреваю, разделяет это ощущение: «Бюрократия, формальности и т.п.»
    • Как технический долг вредит вашей команде программистов — и вашей безопасности приложений
      Техническая долг может серьезно повлиять на здоровье организации - и на психическое здоровье ваших разработчиков. Более половины из 200+ членов инженерных команд, опрошенных в рамках отчета Stepsize "Состояние технического долга в 2021 году", считают, что технический долг негативно влияет на моральное состояние их команд.
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT