Список вебинаров русскоязычной команды технического консалтинга партнеров доступен по ссылке http://aka.ms/RUPTSOnline

Вежливый и активный стиль общения с тех. поддержкой сильно ускоряет разрешение проблем


 

Менеджер: “Как дела с нашей большой проблемой X?”
Инженер:” Мы открыли кейс номер CS221134 в ТехПоддержке!”
“Хорошо, что привлечены правильные ресурсы, проблема скоро будет решена!” — думает менеджер.
“Наконец-то у нас есть универсальная отмазка для любых сложных случаев!” — думает инженер.

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

  • Один кейс – одна проблема.
  • Непрерывная коммуникация между инженерами заказчика и тех. поддержки.

Одна проблема – один кейс, основное правило любой эффективной службы поддержки

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

Из правила есть два важных следствия:

  1. Необходимо сразу правильно сформулировать проблему так, чтобы критерии разрешения были связаны с тем, что вы реально хотите увидеть в жизни.
  2. Если у вас есть две проблемы по одной и той-же системе, то либо сразу заводите два разных кейса, либо заводите их по-очереди, даже если вы считаете, что они связаны.

Формулировка проблемы – очень важный этап, который частично описан в посте как открывать инциденты в службе профессиональной поддержки Microsoft. Во-первых, надо ставить перед собой реальные цели и не забывать делиться ими с окружающими. Распространенная причина недопонимания в том, что задается вопрос глубоко технический, который по мнению спрашивающего является причиной проблемы. Этот подход не так эффективен, чем сразу обрисовать реальную жизненную проблему, ведь вам могут посоветовать другое решение, которое точно работает.

Непрерывная коммуникация между техподдержкой и заказчиком – ключевой элемент оперативного решения проблем

tip_dayВ эпиграф вынесено очень распространенное ошибочное ожидание многих людей от общения с техподдержкой: “Мы эскалировали проблему в тех. поддержку! Теперь это не наша проблема!”

Проблема как была вашей, так вашей и остается, у вас лишь появился ресурс, который может помочь решить эту проблему. Можно провести аналогию с доктором: ангина у пациента – это больше проблема пациента, чем доктора.  Кстати, именно поэтому следует понимать, что вежливость – залог эффективной работы. Безусловно, когда есть проблема – есть много эмоций, но таких проблем у инженера в очереди может быть 20-25 штук, а скандальный “пациент” может оказаться только один. Думаю, что очевидно каким образом будет распределяться внимание “доктора”.

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

Активно надо писать вопросы в кейс: правильно ли мы поняли, вот мы вам выслали и т.п. Иначе более общительные владельцы кейсов будут в приоритете – т.к. они общаются, высылают данные и задают вопросы.  Почему пишу именно так? Потому что в общем случае любой кейс в любой ТП имеет два статуса:

  • мяч на стороне заказчика
  • мяч на стороне тех. поддержки

Каждый ответ от ТП может переводить мяч на сторону заказчика… и далее в ТП никто по кейсу может не работать, поэтому критически важно предоставлять запрошенную информацию как можно быстрее, не теряя время и не прерывая коммуникацию.

 

Еженедельный анализ активности по кейсу в ТП – необходимое условие для эффективной работы с внешней службой технической поддержки

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

В рамках профессиональной поддержки, которая доступна партнерам за статус Gold/Silver, нет выделенного менеджера инцидентов со стороны Microsoft, поэтому если вы ИТ-менеджер или заинтересованный в решении вопроса человек, то обязательно лично еженедельно контролируйте прогресс решения проблем и запрашивайте логи из службы ТП. Может оказаться, что о важных деталях вашего кейса никто и не в курсе, а от этого может многое зависеть в решении инцидента.

Кстати, в рамках премьер поддержки подобную работу всегда делает менеджер контракта премьер поддержки, т.е. он контролирует:

  • Правильность формулировки задачи, т.е. задача по кейсу отражает реальные ожидания заказчика.
  • Непрерывность общения между инженерами заказчика и ТП, напоминает обоим сторонам о следующих шагах.
  • Еженедельно просматривает логи кейсов и переписку, контролируя прогресс решения и полноту данных.
Comments (0)

Skip to main content