Именно так у нас и реализовано, см. статью :-)
Пользователь не может ставить приоритет, но может выставлять критичность, исходя из которой ставится приоритет уже на нашей стороне.
Ну в таком случае потеряется основная идея, когда мы хотим, что бы пользователь рассказал нам как у него болит, а исходя уже из этого и сопоставив в болями других мы выставляем приоритет. Я просто уверен, что пользователи, видя что им нужно поставить что бы получить приоритет повыше, особенно если табличка наглядно показывающая корреляцию будет прямо рядом с выпадающим окном, выберут значение пострашней, что бы получить приоритет повыше. Не думаете?
О, спасибо за замечание, самое главное-то я и упустил. А точнее забыл написать, когда описывал нашу форму. По факту, после того как пользователь выставляет характер воздействия той проблемы с которой он к нам пришел, система, руководствуясь настроенной нами логики, выставляет приоритет обращению. Апдейтил в статье.
Самое плачевное, что «динамический градусник» нарисован и находится в открытом доступе в правилах оказания техподдержки, но тут, как и писал в статье сталкиваемся с тем, что условия далеко не все читают…
А что вы имеете ввиду под горизонтальной шкалой? Срочность проблемы по которой обращается пользователь?
Под вертикальной соответственно влияние проблемы на работу?
Что касается юзкейсов, обобщенно можно написать так:
Есть риск снижения эффективности СЭД: Наблюдаются отдельные проявления нештатного поведения системы, пока не снижающие общей эффективности СЭД для предприятия, но доставляющие неудобство пользователям. В случае развития этой тенденции эффективность СЭД может снизиться, что отразится на работе предприятия. Например, отдельные небольшие замедления или легко преодолимые сбои.
Снижена эффективность СЭД — Наблюдаются затруднения в работе пользователей, в целом позволяющие выполнить требуемые функции, но снижающие эффективность СЭД для предприятия. Например, повторяющиеся замедления или сбои в работе большинства пользователей, а также аналогичные проявления в работе отдельных ключевых пользователей СЭД.
Дополню, что по пункту 1 "Максимально вежливая и обученная, но полностью непробиваемая 1 линия, которая самостоятельно способна выставить приоритет" — к сожалению не всегда возможно объективно оценить на сколько то или иное поведения, описанное в запросе влияет на работу конечных пользователей. Почему? Потому что наш продукт может использоваться в различных процессах работы и если в одной компании определенный неработающий процесс будет критичен для работы в целом, то в другой этот же процесс не будет носить критичный характер и созданный запрос в отдел техподдержки будет иметь более низкий приоритет чем по сравнению с первым вариантом. Так вот, этими специфическими знаниями о критичности воздействия сбоя, описанного в запросе конкретно для каждой компании 1 линия не обладает и не сможет обладать, ввиду большого количества компаний, которые обращаются а также специфичности использования нашего продукта у них.
Хм, соль в том, что мы не даем прямой возможности выбора приоритета пользователям, а как раз наоборот предлагаем им выбрать характер воздействия проблемы, с которой он пришел к нам и уже исходя из того, что он выбрал, выставляем приоритет.
Или я не так понял комментарий?
Идея хорошая, также дошел до нее и пытаюсь сейчас реализовать подобное. Здесь правда есть опасение, что КП будут заинтересованы завышать приоритеты, что бы запросы от их компании решались побыстрее, что на общем фоне оказания техподдержки ряду компаний будет проблемой для техподдержки. С подобным не столкнулись?
Да и до момента возникновения необходимости повысить приоритет и включения в процесс КП, запрос будет висеть и обрабатываться не в том приоритете, в котором должен был бы быть с самого момента создания.
Пользователь не может ставить приоритет, но может выставлять критичность, исходя из которой ставится приоритет уже на нашей стороне.
Самое плачевное, что «динамический градусник» нарисован и находится в открытом доступе в правилах оказания техподдержки, но тут, как и писал в статье сталкиваемся с тем, что условия далеко не все читают…
Под вертикальной соответственно влияние проблемы на работу?
Что касается юзкейсов, обобщенно можно написать так:
Есть риск снижения эффективности СЭД: Наблюдаются отдельные проявления нештатного поведения системы, пока не снижающие общей эффективности СЭД для предприятия, но доставляющие неудобство пользователям. В случае развития этой тенденции эффективность СЭД может снизиться, что отразится на работе предприятия. Например, отдельные небольшие замедления или легко преодолимые сбои.
Снижена эффективность СЭД — Наблюдаются затруднения в работе пользователей, в целом позволяющие выполнить требуемые функции, но снижающие эффективность СЭД для предприятия. Например, повторяющиеся замедления или сбои в работе большинства пользователей, а также аналогичные проявления в работе отдельных ключевых пользователей СЭД.
Дополню, что по пункту 1 "Максимально вежливая и обученная, но полностью непробиваемая 1 линия, которая самостоятельно способна выставить приоритет" — к сожалению не всегда возможно объективно оценить на сколько то или иное поведения, описанное в запросе влияет на работу конечных пользователей. Почему? Потому что наш продукт может использоваться в различных процессах работы и если в одной компании определенный неработающий процесс будет критичен для работы в целом, то в другой этот же процесс не будет носить критичный характер и созданный запрос в отдел техподдержки будет иметь более низкий приоритет чем по сравнению с первым вариантом. Так вот, этими специфическими знаниями о критичности воздействия сбоя, описанного в запросе конкретно для каждой компании 1 линия не обладает и не сможет обладать, ввиду большого количества компаний, которые обращаются а также специфичности использования нашего продукта у них.
Или я не так понял комментарий?
Да и до момента возникновения необходимости повысить приоритет и включения в процесс КП, запрос будет висеть и обрабатываться не в том приоритете, в котором должен был бы быть с самого момента создания.