Вот проблема:
Я отвечаю за горячую линию поддержки пользователей для нового серверного приложения в большой компании. Приложение не очень хорошее, и мы получаем много звонков и писем от наших пользователей. Пока мы используем инструмент отслеживания проблем (Jira), поэтому управляйте всеми запросами наших пользователей.
Наша служба поддержки в первую очередь обрабатывает заявки с наивысшим приоритетом. У нас постоянно около 50 открытых билетов. Таким образом, может пройти несколько дней, прежде чем мы проанализируем и решим проблему с низким приоритетом. Поэтому необходима хорошая классификация билетов.
Мы постоянно улучшаем приложение и документацию, но это требует времени.
Ограничения
Перед подробным техническим анализом мы должны определить приоритетность. Парень у телефона не глубокий технический специалист. Каждый пользователь утверждает, что его проблема - это опасное для жизни средство от шоу. Наши пользователи должны понимать, почему определенный тикет имеет определенный приоритет. Поэтому опубликую критерии в нашей документации.
Вопросы к вам:
Как нам определиться с приоритетом билетов? Кто-нибудь знает набор проверенных критериев для этой проблемы?
Начните с попытки определить такие вещи, как:
Сделайте матрицу с этими двумя измерениями, и пересечение будет приоритетом. Если Impact = max (затронуты все) и Severity = max (приложение не работает), это приоритет 1. Все остальное будет иметь более низкий приоритет. Насколько подробным вы хотите добиться этого, - это бизнес-решение.
/ Edit - в стороне, было бы полезно прочитать SLA, SLO и все другие условия, которые связаны с этим. ITIL может быть хорошим фоном. Я получил сертификат ITIL v2 Foundation, который является хорошим описательным обзором того, как предоставлять и поддерживать ИТ-услуги. Не читайте его как предписания - относитесь к нему как к знаниям, которые вы можете использовать в своей ситуации. ITIL v3, я не так много знаю, за исключением того, что он, кажется, стал более сложным.
/ Другое редактирование - убедитесь, что ваши команды разработчиков и / или инженеров умеют общаться с парнями на передовой. Если передовики получают информацию о том, как решаются открытые проблемы, они должны иметь возможность сказать новому абоненту: «Да, эта ошибка - известная проблема, и мы ожидаем исправления на следующей неделе, когда она проходит QA »и др.
Я не знаю таких проверенных критериев.
Тем не менее, я знаю, с чем сталкиваюсь со службами поддержки поставщиков ИТ, которые действительно дают намек на то, как может выглядеть хороший набор критериев. Один из таких рейтингов приоритета выглядит примерно так:
Ясно, что это шкала, определяемая тем, сколько работы будет выполнено. Для старой средней службы поддержки большинство проблем будут Низкими / Умеренными, а здоровая закваска - Важными.
Я знаю некоторые службы поддержки, которые определяют приоритетность в соответствии с ожидаемым временем решения. Эта единственная ошибка в MS-Office, которую обнаружил пользователь, ожидает от Microsoft исправления, поэтому она получает более низкий приоритет. Сообщение о проблеме с драйвером принтера, сделанное одним пользователем, также должно повлиять на группу других людей, которые еще не заметили, поэтому эта проблема получает более высокий приоритет. Такие вещи.
Боковой узел:
Эти «информационные» вопросы могут иметь изрядную долю доброй воли. Кто-то обращается в службу поддержки за советом специалиста, и вы можете найти друзей, своевременно ответив на него. Если на него можно ответить быстро, обязательно сделайте это.
Это мое мнение, основанное на наблюдениях нашей службы поддержки (которой я не занимаюсь):
Критическая серьезность / высокий приоритет - пользователь / компания не работает: любая проблема, которая не позволяет пользователям использовать ваше приложение каким-либо образом, формой или формой. Это означает, что они, по-видимому, не могут выполнять свою работу ни в каком смысле (если их работа зависит от использования вашего приложения).
Средняя серьезность / нормальный приоритет: пользователи, которые могут использовать ваше приложение с ограниченным уровнем функциональности или производительности: эти проблемы создают неудобства для пользователей, но не мешают им использовать приложение и необходимые для этого функции. их работы.
Низкая серьезность / низкий приоритет: это проблемы, которые не мешают пользователю использовать ваше приложение и необходимые функции. Примером может быть пользователь, которому необходимо знать, как установить конкретный параметр или параметр в приложении.
Каждый пользователь должен получить телефонный звонок или электронное письмо в течение указанного вами временного окна SLA, чтобы сообщить им, что их сообщение / проблема была зарегистрирована и что они получат ответ от вас в течение указанного временного окна SLA. Целью звонка / электронного письма является не решение проблемы, а облегчение общения между вами и клиентом. Нет ничего хуже, чем заставить клиента ждать звонка / электронного письма, подтверждающего, что его проблема получена и решается.
Постарайтесь не сходить с ума, реализуя различные уровни воздействия, масштабов, серьезности и т. Д., Потому что вы в конечном итоге потратите больше времени на «управление» системой / процедурами, чем на решение проблем. Сначала делайте это просто и при необходимости вносите коррективы. Наша служба поддержки использует 3 уровня серьезности в сочетании с 3 уровнями приоритета: критический / высокий, средний / нормальный и низкий / низкий.
По моему опыту работы в службе поддержки, у нас было ДВА критерии: приоритет и строгость.