Комментарии 19
Проблема действительно имеет место быть. Работаю в техподдержке «системного интегратора», обслуживающего множество компаний.
У нас вопрос «повышения приоритета» решается добавлением в схему взаимодействия «Пользовать — Поддержка»
«ключевого пользователя (КП)» (по факту сотрудника ИТ-службы компании-клиента).
В вашем случае думаю это тоже может помочь в корректной приоритезации.
Т. е.
1. Пользователь оформляет запрос.
2. В зависимости от выставленного приоритета оповещается КП (вариант — оповещение о обращениях с высоким приоритетом).
3. КП уже «с высоты своего понимания бизнес-процессов» утверждает, либо корректирует приоритет запроса.
У нас вопрос «повышения приоритета» решается добавлением в схему взаимодействия «Пользовать — Поддержка»
«ключевого пользователя (КП)» (по факту сотрудника ИТ-службы компании-клиента).
В вашем случае думаю это тоже может помочь в корректной приоритезации.
Т. е.
1. Пользователь оформляет запрос.
2. В зависимости от выставленного приоритета оповещается КП (вариант — оповещение о обращениях с высоким приоритетом).
3. КП уже «с высоты своего понимания бизнес-процессов» утверждает, либо корректирует приоритет запроса.
Идея хорошая, также дошел до нее и пытаюсь сейчас реализовать подобное. Здесь правда есть опасение, что КП будут заинтересованы завышать приоритеты, что бы запросы от их компании решались побыстрее, что на общем фоне оказания техподдержки ряду компаний будет проблемой для техподдержки. С подобным не столкнулись?
Да и до момента возникновения необходимости повысить приоритет и включения в процесс КП, запрос будет висеть и обрабатываться не в том приоритете, в котором должен был бы быть с самого момента создания.
Да и до момента возникновения необходимости повысить приоритет и включения в процесс КП, запрос будет висеть и обрабатываться не в том приоритете, в котором должен был бы быть с самого момента создания.
Злоупотребеление высоким приоритетом «купируется» финансово. Т. е. у Заказчика есть некий лимит на количество обращений с высоким приоритетом.
Всё что свыше лимита — «любой каприз за ваши деньги» (с).
Это мотивирует КП не злоупотреблять повышением приоритета.
Отдельно стоит оговаривать ситуацию с инцидентами которые «отлавливаются» системой мониторинга — они «не в зачёт»
Всё что свыше лимита — «любой каприз за ваши деньги» (с).
Это мотивирует КП не злоупотреблять повышением приоритета.
Отдельно стоит оговаривать ситуацию с инцидентами которые «отлавливаются» системой мониторинга — они «не в зачёт»
Вы сделали вертикальную шкалу, которая описывает приоритет. Соответственно остановка работы или затруднение в осуществления его работы для одного пользователя, согласно его ЧСВ является проблемой мирового масштаба.
Нужно попробовать сделать горизонтальную систему(к сожалению не знаю продукт Вашей компании и не могу предложить полноценные рабочие варианты):
1) Нет доступа к чему-либо
2) Не создаётся(не обрабатывается документ)
3) Не работает маршрутизация документа
4) Наблюдаются проблемы с производительностью (долго обрабатывается/регистрируется/проходит маршрут)
5) Проблемы с работой интерфейса(не работают кнопочки, не активно поле и пр..)
6) Прочие проблемы(тут нужно обязать заполнить самостоятельно и через некоторое время из этих заголовков сформируете новые пункты для выбора)
Нужно попробовать сделать горизонтальную систему(к сожалению не знаю продукт Вашей компании и не могу предложить полноценные рабочие варианты):
1) Нет доступа к чему-либо
2) Не создаётся(не обрабатывается документ)
3) Не работает маршрутизация документа
4) Наблюдаются проблемы с производительностью (долго обрабатывается/регистрируется/проходит маршрут)
5) Проблемы с работой интерфейса(не работают кнопочки, не активно поле и пр..)
6) Прочие проблемы(тут нужно обязать заполнить самостоятельно и через некоторое время из этих заголовков сформируете новые пункты для выбора)
А вы можете тут написать юзкейс по пунктам «Есть риск снижения эффективности СЭД» и «Снижена эффективность СЭД»???
А что вы имеете ввиду под горизонтальной шкалой? Срочность проблемы по которой обращается пользователь?
Под вертикальной соответственно влияние проблемы на работу?
Что касается юзкейсов, обобщенно можно написать так:
Есть риск снижения эффективности СЭД: Наблюдаются отдельные проявления нештатного поведения системы, пока не снижающие общей эффективности СЭД для предприятия, но доставляющие неудобство пользователям. В случае развития этой тенденции эффективность СЭД может снизиться, что отразится на работе предприятия. Например, отдельные небольшие замедления или легко преодолимые сбои.
Снижена эффективность СЭД — Наблюдаются затруднения в работе пользователей, в целом позволяющие выполнить требуемые функции, но снижающие эффективность СЭД для предприятия. Например, повторяющиеся замедления или сбои в работе большинства пользователей, а также аналогичные проявления в работе отдельных ключевых пользователей СЭД.
Под вертикальной соответственно влияние проблемы на работу?
Что касается юзкейсов, обобщенно можно написать так:
Есть риск снижения эффективности СЭД: Наблюдаются отдельные проявления нештатного поведения системы, пока не снижающие общей эффективности СЭД для предприятия, но доставляющие неудобство пользователям. В случае развития этой тенденции эффективность СЭД может снизиться, что отразится на работе предприятия. Например, отдельные небольшие замедления или легко преодолимые сбои.
Снижена эффективность СЭД — Наблюдаются затруднения в работе пользователей, в целом позволяющие выполнить требуемые функции, но снижающие эффективность СЭД для предприятия. Например, повторяющиеся замедления или сбои в работе большинства пользователей, а также аналогичные проявления в работе отдельных ключевых пользователей СЭД.
А что вы имеете ввиду под горизонтальной шкалой? Срочность проблемы по которой обращается пользователь?
У Вас есть шкала субъективной оценки работоспособности СЭД. Эта шкала разбивает приоритет решения проблем от «Назкий» до «Сверхсрочно! Всё пропало!». Этой шкалой Вы позволяете пользователю злоупотреблять, потому что человек по натуре склонен преувеличивать/преуменьшать в свою пользу. На примере провайдеров связи выявлено, что среди абонентов тарифов за 300руб. огромное ко-во людей у которых срываются контракты на миллионы долларов из-за простоев в работе провайдера. Это реалии любой техподдержки, но в случае провайдера это понятней выглядит, т.к. там контингент самый разнообразный.
Я предлагаю делить обращения не от «рядовых» до «срочных», а по типу обращения. Грубо говоря: 1) Технический вопрос 2) Программный вопрос 3) Вопрос по эксплуатации 4) Прочие вопросы. Это позволит пользователям не злоупотреблять приоритетом.
Всегда немного озадачивала возможность дать инциденту приоритет. По-моему это актуально только для «жесткого аутсорсинга», когда менеджеры одной компании управляют сотрудниками другой. Необходимость в таком аутсорсинге сильно специфична.
По своей сути приоритет диктует внутренние условия работы специалистов внешним клиентом. А вот выбор отдела или тип инцидента (с обязательной возможностью выбора «Другое») как-то более понятен.
По своей сути приоритет диктует внутренние условия работы специалистов внешним клиентом. А вот выбор отдела или тип инцидента (с обязательной возможностью выбора «Другое») как-то более понятен.
Хм, соль в том, что мы не даем прямой возможности выбора приоритета пользователям, а как раз наоборот предлагаем им выбрать характер воздействия проблемы, с которой он пришел к нам и уже исходя из того, что он выбрал, выставляем приоритет.
Или я не так понял комментарий?
Или я не так понял комментарий?
Это просто мои размышления/наблюдения по теме и к ДоксВижин не имеют отношения.
А если говорить именно о системе, где пользователь выбирает воздействие инцидента (как у вас в статье описано), то вы сами в первом абзаце привели пример почему это не всегда работает. С другой стороны, у меня нет предложений как это исправить.
Лично я (как участник тех поддержки, а не клиент) работал только по двум моделям:
1. Максимально вежливая и обученная, но полностью непробиваемая 1 линия, которая самостоятельно способна выставить приоритет;
2. Все тикеты валятся в кучу, а специально обученный человек (или сами инженеры) их разгребает. Т.е. примерно так: посмотрел все необработанные заявки -> принял наиболее важную -> решил -> посмотрел все необработанные заявки. Но это для маленькой компании, разумеется.
А если говорить именно о системе, где пользователь выбирает воздействие инцидента (как у вас в статье описано), то вы сами в первом абзаце привели пример почему это не всегда работает. С другой стороны, у меня нет предложений как это исправить.
Лично я (как участник тех поддержки, а не клиент) работал только по двум моделям:
1. Максимально вежливая и обученная, но полностью непробиваемая 1 линия, которая самостоятельно способна выставить приоритет;
2. Все тикеты валятся в кучу, а специально обученный человек (или сами инженеры) их разгребает. Т.е. примерно так: посмотрел все необработанные заявки -> принял наиболее важную -> решил -> посмотрел все необработанные заявки. Но это для маленькой компании, разумеется.
Я вас понял, спасибо за мнение.
Дополню, что по пункту 1 "Максимально вежливая и обученная, но полностью непробиваемая 1 линия, которая самостоятельно способна выставить приоритет" — к сожалению не всегда возможно объективно оценить на сколько то или иное поведения, описанное в запросе влияет на работу конечных пользователей. Почему? Потому что наш продукт может использоваться в различных процессах работы и если в одной компании определенный неработающий процесс будет критичен для работы в целом, то в другой этот же процесс не будет носить критичный характер и созданный запрос в отдел техподдержки будет иметь более низкий приоритет чем по сравнению с первым вариантом. Так вот, этими специфическими знаниями о критичности воздействия сбоя, описанного в запросе конкретно для каждой компании 1 линия не обладает и не сможет обладать, ввиду большого количества компаний, которые обращаются а также специфичности использования нашего продукта у них.
Дополню, что по пункту 1 "Максимально вежливая и обученная, но полностью непробиваемая 1 линия, которая самостоятельно способна выставить приоритет" — к сожалению не всегда возможно объективно оценить на сколько то или иное поведения, описанное в запросе влияет на работу конечных пользователей. Почему? Потому что наш продукт может использоваться в различных процессах работы и если в одной компании определенный неработающий процесс будет критичен для работы в целом, то в другой этот же процесс не будет носить критичный характер и созданный запрос в отдел техподдержки будет иметь более низкий приоритет чем по сравнению с первым вариантом. Так вот, этими специфическими знаниями о критичности воздействия сбоя, описанного в запросе конкретно для каждой компании 1 линия не обладает и не сможет обладать, ввиду большого количества компаний, которые обращаются а также специфичности использования нашего продукта у них.
Имхо, нужно задать больше вопросов, каждый из которых будет в общем об одном и том же, но сформулированы они по разному. Один вертикальный, другой горизонтальный, третий еще какой-нибудь. Из нескольких ответов больше вероятность интерполировать адекватный приоритет.
Еще идея — сделать поле "важность". Если пользователь ставит высокую важность, то запускается какой-то процесс, для выяснения действительной важности вопроса. Например, по варианту 1 — специалист ТП связывается с пользователем, и приоритет. Ведь, главная проблема в том, что важные вопросы могут простаивать.
Я может невнимательно читал, но есть же понятия «критичность» и «приоритет». Критичность выставляется клиентом, а приоритет — диспетчером или начальником ТП.
У клиента из примера сбой мог возникнуть на тестовой среде, либо еще где-то, о чем он действительно не написал. И если он сам выставит низкую «критичность», то это его право. А вы уже сами выставите нужный приоритет.
Но если говорить про развитие вашего подхода и вы хотите, чтобы клиент видел, как его выбор на что-то влияет, то нарисуйте динамический градусник, который показывает текущее значение приоритета. А если на него завязана стоимость, то еще и её. Как у провайдеров интернет-услуг: зависимость цены от услуги.
У клиента из примера сбой мог возникнуть на тестовой среде, либо еще где-то, о чем он действительно не написал. И если он сам выставит низкую «критичность», то это его право. А вы уже сами выставите нужный приоритет.
Но если говорить про развитие вашего подхода и вы хотите, чтобы клиент видел, как его выбор на что-то влияет, то нарисуйте динамический градусник, который показывает текущее значение приоритета. А если на него завязана стоимость, то еще и её. Как у провайдеров интернет-услуг: зависимость цены от услуги.
О, спасибо за замечание, самое главное-то я и упустил. А точнее забыл написать, когда описывал нашу форму. По факту, после того как пользователь выставляет характер воздействия той проблемы с которой он к нам пришел, система, руководствуясь настроенной нами логики, выставляет приоритет обращению. Апдейтил в статье.
Самое плачевное, что «динамический градусник» нарисован и находится в открытом доступе в правилах оказания техподдержки, но тут, как и писал в статье сталкиваемся с тем, что условия далеко не все читают…
Самое плачевное, что «динамический градусник» нарисован и находится в открытом доступе в правилах оказания техподдержки, но тут, как и писал в статье сталкиваемся с тем, что условия далеко не все читают…
Я имел в виду, что его надо разместить на форму создания инцидента.
Ну в таком случае потеряется основная идея, когда мы хотим, что бы пользователь рассказал нам как у него болит, а исходя уже из этого и сопоставив в болями других мы выставляем приоритет. Я просто уверен, что пользователи, видя что им нужно поставить что бы получить приоритет повыше, особенно если табличка наглядно показывающая корреляцию будет прямо рядом с выпадающим окном, выберут значение пострашней, что бы получить приоритет повыше. Не думаете?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Битва экстрасенсов в технической поддержке, или как помочь пользователю правильно проставить приоритет инцидента