А на самом деле Василий не сказал, что перезапуск службы сервера приложений приводит к ошибкам при обновлении пользовательских онлайн отчетов у всех работников компании. Другими словами, ни один пользователь не может посмотреть актуальные онлайн отчеты по существующим документам, что равносильно остановке документооборота в компании в принципе. Получается, Василий не дал необходимой информации для того, чтобы его обращению присвоили правильный приоритет – и это несмотря на то, что у него была такая возможность. И, если реальный приоритет ниже заявленного — это не так страшно, то в противоположном случае это может иметь опасные последствия. В связи с чем встает закономерной вопрос: как узнать, что хотел донести пользователь, но по какой-то причине застеснялся и в последний момент сообщил совсем другое?
Вопрос приоритета
В силу специфики вендорской бизнес–модели нашей компании, за техподдержкой к нам может обратиться как представитель бизнеса, который оказывает свою собственную поддержку конечным пользователям (то есть компания-интегратор платформы), так и конечный пользователь Docsvision напрямую. Мы работаем с сотнями компаний (это тысячи пользователей), и я как руководитель службы технической поддержки остро ощущаю проблему невозможности заранее оговорить со всеми правила подачи заявок. Краеугольным камнем этой статьи стал такой важный аспект как приоритезация инцидентов.
Конечно, служба техподдержки формулирует эти правила в форме открытой оферты, но кто её читает? Любой сотрудник технической поддержки наверняка сталкивался с ситуацией, когда пользователь имел в виду совсем не то, что сообщил при обращении. С неправильной приоритезацией инцидентов пользователями я встречаюсь на практике настолько часто, что вижу основания выделить это в качестве проблемы. На моей практике примерно в каждом 3 инциденте выясняется, что приоритет должен был быть другим.
Наше решение: форма подачи заявки
Наша система подачи тикетов предусматривает возможность полностью описать инцидент и его важность для пользователя. Мы разрабатывали её на основе информации из обработанных тикетов, если говорить конкретнее, того, что пользователи писали о важности и срочности тикета по ходу его решения. Система выглядит как мастер-форма, предлагающая пользователю последовательно выбирать варианты ответов на вопросы. Вариант каждого следующего вопроса зависит от ответа на предыдущий. При постановке вопросов пользователю, помимо вариантов ответа предлагаются подсказки, для выбора ответа, наиболее подходящего для его конкретной проблемы. После ответов на все предложенные вопросы, система выставляет приоритет инциденту на основе предоставленной им информации и руководствуясь нами настроенной логикой. Пример того, как выглядит выбор характера воздействия проблемы при создании тикета:
После введения данной формы в эксплуатацию, в созданных инцидентах пользователи начали предоставлять существенно больше информации чем раньше. А иногда даже прикладывали необходимые логи для анализа проблемного поведения, что несомненно большой плюс! Но, что нас, все еще не удовлетворяет в найденном нами решении, так это то, что немалое количество пользователей ставят признаки неправильно, вследствие чего получают некорректный приоритет в инциденте. Что само по себе заложенная бомба эскалации с темой (цитирую) «У меня все горит, а техподдержка решает мой инцидент медленно!!!111».
Почему происходит так, что пользователи ставят неправильно признаки, напрямую влияющие на проставление приоритета? После анализа ряда инцидентов стало понятно, что люди не всегда понимают взаимосвязь информации, которую они дают, и приоритета, который после проставляется в инциденте. И что с этим делать?
Панацея?
Есть ли панацея, которая могла бы помочь в таких случаях? Какие есть еще варианты избежать подобного недопонимания?
- Нанять 100500 специалистов 1 линии, которые вместе с пользователем будут создавать каждый инцидент, задавая ему правильные наводящие вопросы, интерпретировать ответы, проставлять правильные признаки для определения приоритета – эффективно, но невыгодно.
- Обязать компании, пользователи которой обращаются к вам за техподдержкой, обучать своих коллег премудростям сообщения в инцидентах необходимой информации, которая напрямую влияет на выставление приоритета. Вариант, как мне кажется, неплохой в теории. На практике нам пока такого реализовать не удалось.
- Задать лимит на создание инцидентов с возможностью самостоятельно проставлять высокий приоритет. При этом каждое последующее обращение, созданное сверх лимита, идет по дополнительной стоимости. С одной стороны, это вынудит коллег более внимательно относиться к предоставляемой информации о критичности и срочности влияния инцидентов на работу, с другой стороны, это может побудить вопросы вроде «А почему мы должны платить деньги за баги в вашем продукте?». Стоит добавить, что такая практика — не выдумка, я сам с ней встречался, правда, в зарубежных компаниях.
Мы пока не нашли панацею, которая позволила бы нам избежать этого влияния «человеческого фактора» и вытекающей из него неоптимальной траты ресурсов – как наших, так и пользовательских.
Интересно, сталкиваются ли с проблемой выставления корректного приоритета другие компании и какие решения вы встречали?
Комментарии (19)
AntiHelper
27.10.2016 14:30Вы сделали вертикальную шкалу, которая описывает приоритет. Соответственно остановка работы или затруднение в осуществления его работы для одного пользователя, согласно его ЧСВ является проблемой мирового масштаба.
Нужно попробовать сделать горизонтальную систему(к сожалению не знаю продукт Вашей компании и не могу предложить полноценные рабочие варианты):
1) Нет доступа к чему-либо
2) Не создаётся(не обрабатывается документ)
3) Не работает маршрутизация документа
4) Наблюдаются проблемы с производительностью (долго обрабатывается/регистрируется/проходит маршрут)
5) Проблемы с работой интерфейса(не работают кнопочки, не активно поле и пр..)
6) Прочие проблемы(тут нужно обязать заполнить самостоятельно и через некоторое время из этих заголовков сформируете новые пункты для выбора)AntiHelper
27.10.2016 14:37А вы можете тут написать юзкейс по пунктам «Есть риск снижения эффективности СЭД» и «Снижена эффективность СЭД»???
KanFD
27.10.2016 18:18А что вы имеете ввиду под горизонтальной шкалой? Срочность проблемы по которой обращается пользователь?
Под вертикальной соответственно влияние проблемы на работу?
Что касается юзкейсов, обобщенно можно написать так:
Есть риск снижения эффективности СЭД: Наблюдаются отдельные проявления нештатного поведения системы, пока не снижающие общей эффективности СЭД для предприятия, но доставляющие неудобство пользователям. В случае развития этой тенденции эффективность СЭД может снизиться, что отразится на работе предприятия. Например, отдельные небольшие замедления или легко преодолимые сбои.
Снижена эффективность СЭД — Наблюдаются затруднения в работе пользователей, в целом позволяющие выполнить требуемые функции, но снижающие эффективность СЭД для предприятия. Например, повторяющиеся замедления или сбои в работе большинства пользователей, а также аналогичные проявления в работе отдельных ключевых пользователей СЭД.AntiHelper
27.10.2016 19:27А что вы имеете ввиду под горизонтальной шкалой? Срочность проблемы по которой обращается пользователь?
У Вас есть шкала субъективной оценки работоспособности СЭД. Эта шкала разбивает приоритет решения проблем от «Назкий» до «Сверхсрочно! Всё пропало!». Этой шкалой Вы позволяете пользователю злоупотреблять, потому что человек по натуре склонен преувеличивать/преуменьшать в свою пользу. На примере провайдеров связи выявлено, что среди абонентов тарифов за 300руб. огромное ко-во людей у которых срываются контракты на миллионы долларов из-за простоев в работе провайдера. Это реалии любой техподдержки, но в случае провайдера это понятней выглядит, т.к. там контингент самый разнообразный.
Я предлагаю делить обращения не от «рядовых» до «срочных», а по типу обращения. Грубо говоря: 1) Технический вопрос 2) Программный вопрос 3) Вопрос по эксплуатации 4) Прочие вопросы. Это позволит пользователям не злоупотреблять приоритетом.
devpreview
27.10.2016 15:06Всегда немного озадачивала возможность дать инциденту приоритет. По-моему это актуально только для «жесткого аутсорсинга», когда менеджеры одной компании управляют сотрудниками другой. Необходимость в таком аутсорсинге сильно специфична.
По своей сути приоритет диктует внутренние условия работы специалистов внешним клиентом. А вот выбор отдела или тип инцидента (с обязательной возможностью выбора «Другое») как-то более понятен.KanFD
27.10.2016 15:19Хм, соль в том, что мы не даем прямой возможности выбора приоритета пользователям, а как раз наоборот предлагаем им выбрать характер воздействия проблемы, с которой он пришел к нам и уже исходя из того, что он выбрал, выставляем приоритет.
Или я не так понял комментарий?devpreview
27.10.2016 15:29Это просто мои размышления/наблюдения по теме и к ДоксВижин не имеют отношения.
А если говорить именно о системе, где пользователь выбирает воздействие инцидента (как у вас в статье описано), то вы сами в первом абзаце привели пример почему это не всегда работает. С другой стороны, у меня нет предложений как это исправить.
Лично я (как участник тех поддержки, а не клиент) работал только по двум моделям:
1. Максимально вежливая и обученная, но полностью непробиваемая 1 линия, которая самостоятельно способна выставить приоритет;
2. Все тикеты валятся в кучу, а специально обученный человек (или сами инженеры) их разгребает. Т.е. примерно так: посмотрел все необработанные заявки -> принял наиболее важную -> решил -> посмотрел все необработанные заявки. Но это для маленькой компании, разумеется.KanFD
27.10.2016 16:30Я вас понял, спасибо за мнение.
Дополню, что по пункту 1 "Максимально вежливая и обученная, но полностью непробиваемая 1 линия, которая самостоятельно способна выставить приоритет" — к сожалению не всегда возможно объективно оценить на сколько то или иное поведения, описанное в запросе влияет на работу конечных пользователей. Почему? Потому что наш продукт может использоваться в различных процессах работы и если в одной компании определенный неработающий процесс будет критичен для работы в целом, то в другой этот же процесс не будет носить критичный характер и созданный запрос в отдел техподдержки будет иметь более низкий приоритет чем по сравнению с первым вариантом. Так вот, этими специфическими знаниями о критичности воздействия сбоя, описанного в запросе конкретно для каждой компании 1 линия не обладает и не сможет обладать, ввиду большого количества компаний, которые обращаются а также специфичности использования нашего продукта у них.
PFight77
27.10.2016 16:58Имхо, нужно задать больше вопросов, каждый из которых будет в общем об одном и том же, но сформулированы они по разному. Один вертикальный, другой горизонтальный, третий еще какой-нибудь. Из нескольких ответов больше вероятность интерполировать адекватный приоритет.
Еще идея — сделать поле "важность". Если пользователь ставит высокую важность, то запускается какой-то процесс, для выяснения действительной важности вопроса. Например, по варианту 1 — специалист ТП связывается с пользователем, и приоритет. Ведь, главная проблема в том, что важные вопросы могут простаивать.
AntiHelper
27.10.2016 19:29Насколько я понял, тут как-раз проблема в том, что важностью злоупотребляют.
esambou
28.10.2016 10:10Я может невнимательно читал, но есть же понятия «критичность» и «приоритет». Критичность выставляется клиентом, а приоритет — диспетчером или начальником ТП.
У клиента из примера сбой мог возникнуть на тестовой среде, либо еще где-то, о чем он действительно не написал. И если он сам выставит низкую «критичность», то это его право. А вы уже сами выставите нужный приоритет.
Но если говорить про развитие вашего подхода и вы хотите, чтобы клиент видел, как его выбор на что-то влияет, то нарисуйте динамический градусник, который показывает текущее значение приоритета. А если на него завязана стоимость, то еще и её. Как у провайдеров интернет-услуг: зависимость цены от услуги.KanFD
28.10.2016 10:22О, спасибо за замечание, самое главное-то я и упустил. А точнее забыл написать, когда описывал нашу форму. По факту, после того как пользователь выставляет характер воздействия той проблемы с которой он к нам пришел, система, руководствуясь настроенной нами логики, выставляет приоритет обращению. Апдейтил в статье.
Самое плачевное, что «динамический градусник» нарисован и находится в открытом доступе в правилах оказания техподдержки, но тут, как и писал в статье сталкиваемся с тем, что условия далеко не все читают…esambou
28.10.2016 11:18Я имел в виду, что его надо разместить на форму создания инцидента.
KanFD
28.10.2016 17:09Ну в таком случае потеряется основная идея, когда мы хотим, что бы пользователь рассказал нам как у него болит, а исходя уже из этого и сопоставив в болями других мы выставляем приоритет. Я просто уверен, что пользователи, видя что им нужно поставить что бы получить приоритет повыше, особенно если табличка наглядно показывающая корреляцию будет прямо рядом с выпадающим окном, выберут значение пострашней, что бы получить приоритет повыше. Не думаете?
esambou
28.10.2016 21:45Если вы даёте им выбирать приоритет, конечно, выберут. Я же выше написал, что клиент должен указывать не приоритет, а критичность. Но это в моей вселенной. Если бы я выстраивал работу ТП, я бы сделал так.
KanFD
31.10.2016 10:58Именно так у нас и реализовано, см. статью :-)
Пользователь не может ставить приоритет, но может выставлять критичность, исходя из которой ставится приоритет уже на нашей стороне.
fidelich
Проблема действительно имеет место быть. Работаю в техподдержке «системного интегратора», обслуживающего множество компаний.
У нас вопрос «повышения приоритета» решается добавлением в схему взаимодействия «Пользовать — Поддержка»
«ключевого пользователя (КП)» (по факту сотрудника ИТ-службы компании-клиента).
В вашем случае думаю это тоже может помочь в корректной приоритезации.
Т. е.
1. Пользователь оформляет запрос.
2. В зависимости от выставленного приоритета оповещается КП (вариант — оповещение о обращениях с высоким приоритетом).
3. КП уже «с высоты своего понимания бизнес-процессов» утверждает, либо корректирует приоритет запроса.
KanFD
Идея хорошая, также дошел до нее и пытаюсь сейчас реализовать подобное. Здесь правда есть опасение, что КП будут заинтересованы завышать приоритеты, что бы запросы от их компании решались побыстрее, что на общем фоне оказания техподдержки ряду компаний будет проблемой для техподдержки. С подобным не столкнулись?
Да и до момента возникновения необходимости повысить приоритет и включения в процесс КП, запрос будет висеть и обрабатываться не в том приоритете, в котором должен был бы быть с самого момента создания.
fidelich
Злоупотребеление высоким приоритетом «купируется» финансово. Т. е. у Заказчика есть некий лимит на количество обращений с высоким приоритетом.
Всё что свыше лимита — «любой каприз за ваши деньги» (с).
Это мотивирует КП не злоупотреблять повышением приоритета.
Отдельно стоит оговаривать ситуацию с инцидентами которые «отлавливаются» системой мониторинга — они «не в зачёт»