Активное общение с инженером по кейсу существенно ускоряет разрешение проблемы
Менеджер: “Как дела с нашей большой проблемой X?”
Инженер:” Мы открыли кейс номер CS221134 в ТехПоддержке!”
“Хорошо, что привлечены правильные ресурсы, проблема скоро будет решена!” - думает менеджер.
“Наконец-то у нас есть универсальная отмазка для любых сложных случаев!” - думает инженер.
Открыть кейс в тех. поддержке по серьезной проблеме - это всегда правильный заход. Когда инженеры умеют правильно общаться по кейсам, так это еще и заход с козырей: экономит время, экономит силы, дает возможность получить знания и рекомендации на будущее.
Есть два правила, которые надо знать и соблюдать, работая по любым кейсам(даже если это кейсы в вашей внутренней системе HelpDesk):
- Один кейс – одна проблема.
- Непрерывная коммуникация между инеженерами заказчика и тех. поддержки.
Одна проблема – один кейс, основное правило любой эффективной службы поддержки
Любые процессы хорошо работают и автоматизируются, если они повторяемые и достаточно простые, поэтому в эффективной службе поддержки всегда действует правило: одна проблема - один кейс. Именно этот подход позволяет контролировать сроки разрешения проблем и привлекать необходимых экспертов для решения кейсов в нужный момент.
Из правила есть два важных следствия:
- Необходимо сразу правильно сформулировать проблему так, чтобы кретерии разрешения были связаны с тем, что вы реально хотите увидеть в жизни.
- Если у вас есть две проблемы по одной и той-же системе, то либо сразу заводите два разных кейса, либо заводите их по-очереди, даже если вы считаете, что они связаны.
Формулировка проблемы – очень важный этап, который я немного уже описывал в своем блоге, надо ставить перед собой реальные цели и не забывать делиться ими с окружающими. Распространенная причина недопонимания в том, что задается вопрос глубоко техничский, который по мнению спрашивающего является причиной проблемы. Этот подход не так эффективен, чем сразу обрисовать реальную жизненную проблему, ведь вам могут посоветовать другое решение, которое точно работает.
Непрерывная коммуникация между техподдержкой и заказчиком – ключевой элемент оперативного решения проблем
В эпиграф вынесено очень распространенное ошибочное ожидание многих людей от общения с техподдержкой: “Мы эскалировали проблему в тех. поддержку! Теперь это не наша проблема!”
Проблема как была вашей, так вашей и остается, у вас лишь появился ресурс, который может помочь решить эту проблему. Можно провести аналогию с доктором: ангина у пациента – это больше проблема пациента, чем доктора.
Открытие кейса – это только самое начало работы, далее надо активно отвечать на все запросы инженера техподдержки, помня что лучшее – это враг хорошего. Обязательно будет запрошен длинный список дополнительной информации, ее надо предоставить полностью, но предоставлять надо как только появилось что-то, так и предоставлять(если принудительно не запрошено, что соберите вот эти данные вместе с другими).
Активно надо писать вопросы в кейс: правильно ли мы поняли, вот мы вам выслали и т.п. Иначе более общительные владельцы кейсов будут в приоритете – т.к. они общаются, высылают данные и задают вопросы.
Почему пишу именно так? Потому что в общем случае любой кейс в любой ТП имеет два статуса:
- мяч на стороне заказчика
- мяч на стороне тех. поддержки
Каждый ответ от ТП может переводить мяч на сторону заказчика… и далее в ТП никто по кейсу может не работать, поэтому критически важно предоставлять запрошенную информацию как можно быстрее, не теряя время и не прерывая коммуникацию.
Еженедельный анализ активности по кейсу в ТП – необходимое условие для эффективной работы с внешней службой технической поддержки
Если работа по кейсу затянулась больше чем на неделю, то необходимо раз в неделю проводить формальный анализ состояния, основываясь в первую очередь на формальных данных: логи кейса, переписка по эл. почте, протоколы переговоров. В любой ТП одновременно работает несколько десятков(иногда тысяч человек) и решается по несколько сотен кейсов , поэтому того, что не существует в логах кейса(а соответственно в туле учета), не существует в жизни.
Если вы ИТ-менеджер, то обязательно лично еженедельно контролируйте прогресс решения проблем и запрашивайте логи из службы ТП. Может оказаться, что о важных деталях вашего кейса никто и не в курсе, а от этого может многое зависеть в решении инцидента.
В рамках премьер поддержки подобную работу делает менеджер поддржки, т.е. он контролирует:
- Правильность формулировки задачи, т.е. задача по кейсу отражает реальные ожидания заказчика.
- Непрерывность общения между инженерами заказчика и ТП, напоминает обоим сторонам о следующих шагах.
- Еженедельно просматривает логи кейсов и переписку, контролируя прогресс решения и полноту данных.