Допрос с пристрастием

На днях меня попросили показать примеры вопросов, которые можно задавать пользователям для оценки их удовлетворенности итогами решения инцидента. То есть по итогам решения инцидента пользователь не просто должен сказать: "да работает/нет не работает", а дать "развернутый" ответ о том, как все прошло и насколько он счастлив. 

Я решил заодно и на портале упомянуть эту тему и важные моменты:

  1. Нужно точно понимать, зачем проводится опрос, какие выводы предполагается сделать. Только так можно подобрать правильные вопросы и понять как затем обрабатывать ответы.
  2. Вопросов не должно быть много (2-3 достаточно) иначе есть риск вообще не получить ответов или получить случайные ответы
  3. Пользователя не надо заставлять что-то писать. Лучше если он может выбрать из имеющихся вариантов. Но при этом можно оставить возможность, что-то написать, если есть, что сказать.
  4. Варианты должны быть однозначно отличимы друг от друга.
  5. Возможны как вопросы, которые предполагают один ответ, так и вопросы, которые предполагают выбор нескольких вариантов.
  6. Вопросы с готовыми ответами иногда являются провокационными (см. 2й вопрос в примере ниже). Такие вопросы с одной стороны указывают на то, что ИТ знает о своих проблемах и борется с ними, с другой стороны может побуждать пользователей оценивать ИТ по параметрам, о которых они не задумывались ранее. В итоге все зависит от цели вашего опроса.

Примеры таких вопросов:

  1. Время решения вашего обращения соответствует вашим ожиданиям?
    1. Ожидал(ла), что будет быстрее
    2. Соответствует
    3. Не ожидал(ла), что сделают так быстро
  2. Укажите, общую оценку работы (можно выбрать несколько ответов):
    1. Все прекрасно
    2. Пришлось несколько раз повторять одно и то же
    3. Решили не с первого раза
    4. После решения стало хуже
    5. Со мной грубо общались
  3. Если вы хотите нам сообщить дополнительные сведения, то впишите их в следующем поле.

Если у вас есть примеры вопросов, которыми вы пользовались для опроса пользователей, было бы интересно узнать, что за вопросы и что из этого вышло. Возможно вы сделали какие-то выводы из проделанной работы.

ITIL ITIL Intermediate: Operational Support and Analysis

Учебный курс: эксплуатация и поддержка ИТ-услуг, Service Desk, инциденты, проблемы, операции и запросы пользователей — в ITIL и на практике.
 

Узнайте больше!

Комментарии и мнения

  1. Кирилл Федулов

    Евгений, предлагаю чуть выйти за рамки обсуждения.

    На мой взгляд, сама по себе оценка решения запроса пользователем на уровне вопроса/ответа не показательна, в виду того, что вопросы мы можем задавать нефокусные. И мы с Вами прекрасно понимаем, что дело в человеческой сущности: результат активности складывается из множества факторов. Зачастую, вклад каких-то факторов на личностном уровне гораздо выше, чем пресловутое время реакции или время решения.

    В моей практике был интересный случай, когда по всем внешним признакам (быстро, качественно, любезно) пользователи должны были быть счастливы ИТ службой, но не были 🙂 Угадайте причину 😉 Оказалось, что на определенном этапе старую команду «ИТ-шников в полях» обновили на 80% и сделали ее «более лучшей» :). Решением инцидентов стали заниматься «чужие люди». Каким вопросом вы «выловите» это недовольство? Доп.сведения — не предлагать. Пустые текстовые поля люди вообще не заполняют.

    К чему это я? Ах, да! Прежде, чем формулировать вопросы, нужно понять, а что именно не устраивает. Мы в своих проектах на этапе обследования или аудита сперва выявляем наиболее «запущенные» стороны поддержки по мнению пользователей (некий аналог соц.опроса фокус группы пользователей). Выявляя 5-6 пунктов получаем отправную точку дальнейших допросов, в том числе в части «чужих людей». Сразу оговорюсь, что более 3-4 вопросов при закрытии инцидента в средстве автоматизации/по телефону, действительно просить заполнять не стоит. Однако, регулярные фокусные опросы + другие элементы взаимодействия никто не отменял.

    Резюме, уф! 🙂 Ваш пункт 6, как всегда, самый важный 🙂 Если задача проведения опроса — проставление галочки в анкете при проведении аудита напротив пункта «Существует ли обратная связь с пользователями?», то можно спрашивать хоть про космические корабли. Истина при этом, как всегда, останется где-то рядом 🙂

    p.s. простите за много букв

    1. Евгений Шилов Автор

      «сама по себе оценка решения запроса пользователем на уровне вопроса/ответа не показательна, в виду того, что вопросы мы можем задавать нефокусные»

      Отдельная оценка конечно может быть вызвана эмоциями, фазами луны или ценами на бензин, но если мы говорим о достаточно большой выборке, то определенные тренды можно выявить даже с учетом указанных возмущающих факторов. Тоже самое относится и проведению сбора данных в рамках иных взаимодействий с пользователями (опросы, анкетирование, интервью).

      Что касается вопросов, то как раз самое интересное/сложное подобрать вопросы, которые позволят раскрыть имеющуюся проблему, а не просто выдать «правильную» отчетность о том, что все счастливы. Ведь, вопросы мы конечно можем написать очень правильные: « Выберите „да“, если вы довольны работой ИТ или „нет“, если у Вас нет претензий к ИТ» 🙂

      Именно поэтому я и предлагаю в первую очередь задуматься над целью опроса и задачами, которые стоят. И именно поэтому опрос обычно проводится в ответ на выявленную проблему (тогда вопросы можно точнее фокусировать на ней) или в качестве профилактической меры для выявления потенциально узких мест (о которых мы догадываемся, но не уверены, что они беспокоят пользователей).

      В итоге, вылавливать недовольство сменой команды конечно можно, но если смена команды не сказывается негативно на работу процессов и предоставление ИТ-сервисов, то это скорее вопрос к психологам, чем к ИТ 🙂

      Ну и конечно про «истину где-то рядом» 🙂

      Опрос — лишь один из источников для оценки, есть еще метрики процессов, наблюдения руководителей групп ИТ-специалистов и т.д. Поэтому конечно для выявления истины придется потрудиться 🙂

      1. Роман Журавлёв

        К примеру Кирилла: теоретически возможно, что меняя 80% команды на более лучших новых чужих людей, мы сознаем, что есть риск отторжения этих людей пользователями, привыкшими к своим, пусть и менее лучшим, ребятам. Тогда мы можем при смене команды включить в опросник (возможно, специальный, а не рутинный) такой, например, вопрос:

        «Доверяете ли вы команде поддержке?», или «Каково ваше мнение о профессионализме команды поддержки?», или что-то подобное. Здорово, если мы догадаемся собрать такую информацию ДО замены команды, чтобы было, с чем сравнивать.

      2. Pavel Solopov

        вылавливать недовольство сменой команды конечно можно, но если смена команды не сказывается негативно на работу процессов и предоставление ИТ-сервисов, то это скорее вопрос к психологам, чем к ИТ

        Т.е. правильно я вас понимаю, что мы сначала должны выявить деградацию процессов или сервисов, а потом уже через опросы пытаться понять его причину?

        Другими словами, опросы не могут являться инструментарием выявления деградации сервисов?

        1. Евгений Шилов Автор

          Павел, я как раз о другом.

          «Опрос — лишь один из источников для оценки, есть еще метрики процессов, наблюдения руководителей групп ИТ-специалистов и т.д.»

          Можно начинать с опроса, который позволяет оценить состояние типовых узких мест процесса, и если есть негатив, то анализируя метрики понять, что приводит к такому результату.

          Можно поступать и в обратном порядке, выявив некую деградацию в процессе через метрики, выяснить через опрос, какое влияние этот факт оказывает на восприятие пользователями результатов работы процесса.

          Опрос — это инструмент, который вы вольны использовать в том качестве, которое вам необходимо в данный момент.

    2. Vladimir Kapustin

      Доп.сведения — не предлагать. Пустые текстовые поля люди вообще не заполняют.

      Кстати, любопытное наблюдение:

      после закрытия инцидентов в анкетах пустые поля заполняет не больше 10%,

      а вот в регулярном опросе случайной выборки на предмет удовлетворённости и NPS — почти треть.

  2. Grigory Kornilov

    В теме советы 1-6 относятся к опросам вообще 🙂

    От себя:

    1. Если хотите повысить оценку, то можно сделать хитрый ход — Реализовать быстрый ответ «Спасибо!», по которому все проставляется по максимуму хорошо ).

    Сработает, если пользователь будет в целом доволен.

    2. Если хотите общаться с тем, кто готов с вами общаться — поставьте опцию — «Свяжитесь со мною!» — пользователь, ее выбравший позитивно отнесется к тому, что его будут распрашивать по результатам конкретной заявки.

    3. Не требуйте доказательств со стороны пользователя, но просите информацию.

    4. Вы ищите не виновного, но моменты к улучшению.

    5. Не запрашивайте информацию у пользователя, если она есть у вас (особенно, если он об этом знает). Если вы не уверены в ваших данных — предоставьте их пользователю для согласия\уточнения с его стороны

    1. Vladimir Kapustin

      пункты 2-4 поддерживаю.

      От себя добавлю:

      1. Стараюсь не пользоваться 5-бальной шкалой.

      2. Не делаю обязательных полей, если можно обойтись без них. Все значения в опроснике по-умолчанию выставляю в «пропустить вопрос» или «не хочу отвечать»...

  3. Andrey Kapustin

    Честно говоря больше слоняюсь к мнению Кирилла, видимо потому что до взрослого и правильного подхода Евгения не дозрели ни я ни проект.

    В своей практике выполняю оценку исполнителей, но не сервиса, через процедуру ассесмента: раз в 6-12 месяцев на каждого сотрудника поддержки запрашиваю фидбэк от десятка ключевых людей Заказчика — как представителей его IT так и Бизнеса. Как правило при опросе сосредотачиваюсь на мнении именно Бизнеса — это ключевые пользователи или руководители подразделений бизнеса, которые непосредственно часто сталкиваются с данным сотрудником поддержки. Предлагаю один единственный вопрос: укажите на сильные и слабые стороны данного инженера в нескольких предложениях. Делаю это с прицелом получить мини-360 оценку.

    Подход конечно не самый универсальный и масштабируемый. Однако работает.

  4. Владимир Аношин

    Я бы хотел добавить:

    1.Важно, что случилось ДО проведения опроса (например, неудачный change, а вы как раз спрашиваете, счастливы ли пользователи с ИТ)

    2. Фокусность опрашиваемой группы товарищей (в смысле уровень компетентности товарищей в спрашиваемых вопросах)

    3.Адаптация вопросов под особенности опрашиваемых

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Ближайшие мероприятия

Зарегистрируйтесь, чтобы получить больше полезных знаний:

ИЮН
26