Лучшие практики для деревьев категорий службы поддержки / тикетов

Мой бесполезный ответ - попытаться удержать теги или сильно полагаться на поиск.

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

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

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

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

Поскольку у нас есть сотрудники, которые перемещаются между предприятиями, мы фактически используем категорию уровня 1 для названия компании и уровень 2 для области поддержки. например:

• Альфа
  • Проблемы O/S
  • Приложение 1
  • A / V оборудование
• Браво
  • Проблемы O/S
  • Приложение 1
  • A / V оборудование
• Чарли
  • Проблемы O/S
  • Приложение 1
  • A / V оборудование

Эта схема все еще довольно новая, поэтому мы не столкнулись с какими-либо проблемами (пока)

Две вещи торчат мне; перечитайте ваш вопрос.

1. Это правильный трекер для вас? кажется, что отсутствует функциональность, которую вы хотите. Возможно, пришло время найти другой инструмент для этой конкретной работы?
2. Общее правило при категоризации элементов: чем выше иерархия дерева, тем шире область действия элемента. Направление должно быть от самого широкого определения до самого узкого.

Вы ищете класс, категорию, тип и элемент таксономии. Вы застряли, потому что не хватает какой-то базы данных конфигурации (это поможет со списком ITEM). Другая проблема заключается в том, что вам следует использовать программное обеспечение службы поддержки, чтобы определить, какие службы подвержены влиянию той или иной проблемы, а не какие серверы имели наибольшее время простоя. Если вы выбираете модель, основанную на услугах, определение классов, категорий, типа и элемента становится намного проще. Я рекомендую думать об этом как о группе (класс), приложении (категории), услуге (типе), о том, что на самом деле не работает (элемент). Кроме того, поскольку вы можете использовать отношения времени и тикета, чтобы показать влияние проблемы в вашей среде. Вот пример:

Пользователь звонит, потому что его команда не может получить доступ к своей электронной почте (CCTI может быть Windows, exchange, email,client), парень по обмену смотрит на обмен, и обмен отчетами работает отлично для всех остальных и прослеживает его до сетевой проблемы. Его билет должен быть закрыт, и он должен открыть новый билет, чтобы заставить сетевую группу посмотреть на инфраструктуру. тикет обмена должен быть связан с новым (CCTI, сеть, внутренняя сеть, подключение, настольный компьютер), поскольку оказывается, что коммутатор вышел из строя, поэтому тикет закрывается с этим разрешением. Теперь, когда вы запускаете отчет о доступности по электронной почте, вы должны увидеть сбой и то, что он был связан с проблемой сети.

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

Другой пример: Launchpad предлагает "также влияет" и объединяет комментарии в один поток. Примерно так может подписаться как нью-йоркский техник, так и серверный техник, и задокументировать взаимодействие, которое происходит (или нет).