А на самом деле Василий не сказал, что перезапуск службы сервера приложений приводит к ошибкам при обновлении пользовательских онлайн отчетов у всех работников компании. Другими словами, ни один пользователь не может посмотреть актуальные онлайн отчеты по существующим документам, что равносильно остановке документооборота в компании в принципе. Получается, Василий не дал необходимой информации для того, чтобы его обращению присвоили правильный приоритет – и это несмотря на то, что у него была такая возможность. И, если реальный приоритет ниже заявленного — это не так страшно, то в противоположном случае это может иметь опасные последствия. В связи с чем встает закономерной вопрос: как узнать, что хотел донести пользователь, но по какой-то причине застеснялся и в последний момент сообщил совсем другое?
Вопрос приоритета
В силу специфики вендорской бизнес–модели нашей компании, за техподдержкой к нам может обратиться как представитель бизнеса, который оказывает свою собственную поддержку конечным пользователям (то есть компания-интегратор платформы), так и конечный пользователь Docsvision напрямую. Мы работаем с сотнями компаний (это тысячи пользователей), и я как руководитель службы технической поддержки остро ощущаю проблему невозможности заранее оговорить со всеми правила подачи заявок. Краеугольным камнем этой статьи стал такой важный аспект как приоритезация инцидентов.
Конечно, служба техподдержки формулирует эти правила в форме открытой оферты, но кто её читает?.. Любой сотрудник технической поддержки наверняка сталкивался с ситуацией, когда пользователь имел в виду совсем не то, что сообщил при обращении. С неправильной приоритезацией инцидентов пользователями я встречаюсь на практике настолько часто, что вижу основания выделить это в качестве проблемы. На моей практике примерно в каждом 3 инциденте выясняется, что приоритет должен был быть другим.
Наше решение: форма подачи заявки
Наша система подачи тикетов предусматривает возможность полностью описать инцидент и его важность для пользователя. Мы разрабатывали её на основе информации из обработанных тикетов, если говорить конкретнее, того, что пользователи писали о важности и срочности тикета по ходу его решения. Система выглядит как мастер-форма, предлагающая пользователю последовательно выбирать варианты ответов на вопросы. Вариант каждого следующего вопроса зависит от ответа на предыдущий. При постановке вопросов пользователю, помимо вариантов ответа предлагаются подсказки, для выбора ответа, наиболее подходящего для его конкретной проблемы. Пример того, как выглядит выбор характера воздействия проблемы при создании тикета:
После введения данной формы в эксплуатацию, в созданных инцидентах пользователи начали предоставлять существенно больше информации чем раньше. А иногда даже прикладывали необходимые логи для анализа проблемного поведения, что несомненно большой плюс! Но, что нас, все еще не удовлетворяет в найденном нами решении, так это то, что немалое количество пользователей ставят признаки неправильно, вследствие чего получают некорректный приоритет в инциденте. Что само по себе заложенная бомба эскалации с темой (цитирую) «У меня все горит, а техподдержка решает мой инцидент медленно!!!111».
Почему происходит так, что пользователи ставят неправильно признаки, напрямую влияющие на проставление приоритета? После анализа ряда инцидентов стало понятно, что люди не всегда понимают взаимосвязь информации, которую они дают, и приоритета, который после проставляется в инциденте. И что с этим делать?
Панацея?
Есть ли панацея, которая могла бы помочь в таких случаях? Какие есть еще варианты избежать подобного недопонимания?
- Нанять 100500 специалистов 1 линии, которые вместе с пользователем будут создавать каждый инцидент, задавая ему правильные наводящие вопросы, интерпретировать ответы, проставлять правильные признаки для определения приоритета – эффективно, но невыгодно.
- Обязать компании, пользователи которой обращаются к вам за техподдержкой, обучать своих коллег премудростям сообщения в инцидентах необходимой информации, которая напрямую влияет на выставление приоритета. Вариант, как мне кажется, неплохой в теории. На практике нам пока такого реализовать не удалось.
- Задать лимит на создание инцидентов с возможностью самостоятельно проставлять высокий приоритет. При этом каждое последующее обращение, созданное сверх лимита, идет по дополнительной стоимости. С одной стороны, это вынудит коллег более внимательно относиться к предоставляемой информации о критичности и срочности влияния инцидентов на работу, с другой стороны, это может побудить вопросы вроде «А почему мы должны платить деньги за баги в вашем продукте?». Стоит добавить, что такая практика — не выдумка, я сам с ней встречался, правда, в зарубежных компаниях.
Мы пока не нашли панацею, которая позволила бы нам избежать этого влияния «человеческого фактора» и вытекающей из него неоптимальной траты ресурсов – как наших, так и пользовательских.
Интересно, сталкиваются ли с проблемой выставления корректного приоритета другие компании и какие решения вы встречали?
Комментарии (0)