Стивен Вест в недавней статье «The Importance of Managed Emotional Metrics in ITSM» на портале ITSM.tools высказывает известный тезис о том, что помимо объективных показателей, согласованных в SLA, необходимо контролировать удовлетворённость потребителя (слышать голос заказчика (voice of the customer, VoC). Многие компании делают подобные замеры. Некоторые компании делают показатели удовлетворённости частью параметров SLA.
Но автор использует интересный (и жизненный) пример для демонстрации идеи и делится своей практикой получения этого самого VoC. Поэтому ниже его пример, и описание его практики.
Рассмотрим два сценария.
- Вы договорились с обслуживающей компанией о визите к вам техника. Дата назначена, время согласовано. Вы всё подготовили. К сожалению, за 48 часов до визита поставщик услуг информирует вас о том, что в связи с обстоятельствами, независящими (действительно независящими) от данной компании, они вынуждены отложить визит. И предлагают другие даты. Вы раздосадованы. Однако позанимаете, что в сложившихся обстоятельствах работы в вашей квартире действительно имеют более низкий приоритет.
- Вы договорились с обслуживающей компанией о визите к вам техника. Дата назначена, время согласовано. Вы договорились, что будете ждать дома визита техника в первой половине дня. Поставщик услуг сообщил, что проинформирует вас с помощью СМС за 30 минут до визита техника. И, поскольку ваш дом находится в 15 минутах от работы, вы смело отправились на работу, понимая, что, получив СМС, спокойно успеете добраться к приезду техника. В какой-то момент времени вы получаете входящий звонок (не СМС). Это звонит техник. Он у двери вашего дома. На часах 11:00. Он предупреждает, что может ждать не более 30 минут, так как у него дальше по плану следующие работы у других клиентов. Вы понимаете, что даже если успеете вернуться домой до отъезда техника, работы выполнить уже не удастся. Техник говорит, что может быть получится вернуться к вам вечером, после окончания прочих запланированных работ. До самого вечера от него нет никаких вестей. Вы даже отложили ужин на всякий случай. И лишь после окончания рабочего дня он позвонил, чтобы извиниться и сказать, что сегодня приехать не получится.
В каком из сценариев (если) нарушен SLA?
В первом – скорее всего. Но потребитель был проинформирован заранее, и была предложена (и принята) разумная альтернатива. Вы были расстроены, но это было совсем небольшое неудобство. Вероятнее всего, вы сочтёте такую ситуацию приемлемой.
Во втором сценарии SLA скорее всего нарушен не был {прим. если, конечно, «предупреждение с помощью СМС за 30 минут» не являлось частью SLA}. Техник прибыл вовремя. Т.е. поставщик был готов оказать услугу. Техник даже предложил вернуться позже. Т.е пошёл навстречу клиенту. Великолепный сервис, не правда ли? Скорее всего, нет.
В ИТ мы видим подобную боль довольно часто. В управлении инцидентами, например. Масса инцидентов, устраняемых в рамках регламентных сроков, но при отсутствии простейших коммуникаций с потребителем, приводит к неудовлетворённости и раздражённости потребителя.
Автор предлагает контролировать не только объективные показатели качества предоставления услуги, но и «эмоциональные метрики». И если классикой ITSM является сбор обратной связи у пользователей по закрытию обращений (запросов на обслуживание или инцидентов), а у заказчиков на регулярной основе в виде опросников или интервью (некоторые компании также практикуют регулярные опросы пользователей), то Стивен рассказывает о том, что он создал документ с простой структурой, снабдив простым руководством по его использованию. Структура документа:
- Имя
- Дата
- Комментарий
- Подтверждающие высказывание свидетельства
Доступ к документу имею все заинтересованные лица заказчика.
Цель – услышать голос заказчика (VoC), узнать о его опыте потребления продукта или услуги, его ожидания относительно продукта/услуги. Такой метод позволяет, по мнению автора, проактивно получать обратную связь (что также является отличным каналом информации для постоянного совершенствования). Постоянная работа с содержимым данного документа и регулярная отчётность прямо там же, по каждой записи, позволяет заинтересованным сторонам понимать, что было сделано, что делается. И каждая запись остаётся в открытом статусе, пока соответствующее заинтересованное лицо не поймёт, что запрос удовлетворён.
Интересно, кто-нибудь использует именно такой подход?
Тема важная.
В данном подходе (при использовании предлагаемого документа) не совсем понятно, к какому событию привязан документ, что должно послужить триггером к его появлению, непонятна частота появления.
В своей работе по сбору обратной связи мы стараемся сочетать два подхода:
1) Возможность обратной связи с оценкой и комментарием от пользователя по каждому его обращению
2) Периодические (раз в квартал) опросы по качеству обслуживания с оценкой, комментариями, идеями.
Причем, п.1 мы внедрили позже, чем п.2. И взлетел он не сразу. Оно и понятно: гораздо проще раз в квартал написать на портале общими фразами “все хорошо” (или нет…), чем взять на себя труд оценить каждое свое обращение.
Тем не менее, практика показывает, что важно использовать оба подхода. п1. для анализа по конкретным кейсам и, если необходимо, изменению используемых практик.
п.2 бывает ценен тем, что в комментариях к общим оценкам качества сервиса мы слышим
тот самый VoC, что дает нам потенциальную возможность совершенствовать качество своих услуг. Насколько этот потенциал может быть использован и используется – вопрос для отдельного диспута )