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

Однако многоуровневая техническая поддержка может фактически ухудшить качество вашего обслуживания, если агенты не сохранят четкое и твердое чувство ответственности за проблемы. Использование уровней в качестве предлога для отказа от проблем снижает время решения, разочаровывает клиентов и снижает NPS. Это также лишает инженеров возможности расти и улучшать свои навыки.

Итак, в чем большая угроза собственности и как с ней бороться? Давайте рассмотрим проблему более подробно и извлечем уроки из моего опыта управления командой инженеров технической поддержки.

Многоуровневая техническая поддержка - это здорово

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

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

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

Это больше не моя проблема.

Проблема возникает, когда вы объединяете многоуровневую техническую поддержку с необходимостью быстрого решения проблем. Иногда агенты сосредотачиваются на том, чтобы избавиться от проблем, а не на их решении.

Ситуация такого типа возникает чаще всего, когда мы устраняем проблемы с разными технологиями с помощью одного продукта, какова моя ситуация.

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

Но это делает цель «Это больше не моя проблема».

Очевидно, что это тоже не хорошо для покупателя. Ожидание решения и передача от группы поддержки группе поддержки из-за того, что инженер не сосредоточен на решении проблемы, не является хорошим чувством и отрицательно повлияет на ваш Net Promoter Score.

Другой способ, которым агенты и технические специалисты могут сделать проблему «не их проблемой», - это попросить помощи у члена команды, а затем оставить заявку.

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

Простое ожидание других линий поддержки - огромный источник задержек в технической поддержке. Одна группа будет ждать следующей строки, или передняя линия будет ждать следующих действий на продвинутой линии. Между тем, билеты стареют, а ваше среднее время разрешения билетов стремительно растет.

Возвращаясь к первому примеру; если бы цель заключалась в том, чтобы просто избавиться от клиента, решением было бы попросить клиента обратиться в службу поддержки операционной системы. Но на самом деле способ решить проблему состоял в том, чтобы продолжить отладку и провести некоторое исследование, чтобы выяснить, была ли сама эта ошибка VSS вызвана нашим приложением. Затем, если мы узнаем, что это так, связаться с поставщиком ОС вместе с заказчиком и вместе устранить неполадки.

Первый способ - это подход «это больше не моя проблема». Во - вторых, лучше один, является «Это не проблема больше» подход.

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

Стать владельцем

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

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

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

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

Другой подход, ведущий к успеху, - рассматривать каждую проблему как возможность обучения. Когда вы работаете с людьми в своей команде, вместо того, чтобы просто переходить к другим тикетам, найдите время, чтобы поучиться у них. Вы также можете поучиться у других команд, например, на примере поддержки ОС, приведенном выше. Всегда хорошо знать, как решать проблемы, даже если это не ваша специальность.

Откажитесь ждать

Если вы инженер первого уровня, вам может понадобиться помощь разных групп. В этом суть многоуровневой технической поддержки. А иногда это означает, что вам, возможно, придется их подождать. Это не значит, что вы должны бездействовать. Будьте нетерпеливыми. Конечно, это слово может иметь негативный оттенок, но нетерпение - это достоинство, когда дело касается поддержки клиентов. Думайте об этом больше как о «страстном желании облегчения или перемен; беспокойство »или« нетерпимость ко всему, что мешает или задерживает ».

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

Проявите творческий подход

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

1. Свяжитесь с большой группой специалистов через внутренние или внешние форумы.
2. Отправьте электронное письмо с описанием проблемы в список рассылки команд следующего уровня.
3. Подойдите к специалисту лично и попросите обновить или напомните ему по электронной почте.

Вывод

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

Вместо того, чтобы закладывать проблемы, возьмите на себя ответственность за каждую проблему, которая встречается у вас на столе. Рассматривайте каждую задачу как возможность учиться и расти. Убедитесь, что независимо от того, где возникает проблема или кто участвует, в конце дня вы всегда проверяете и убеждаетесь, что проблема продвигается вперед. Развивайте чувство безотлагательности. И не просто ждать. Проявите творческий подход к решению проблем.
Является ли отношение «это больше не моя проблема» проблемой для вашей команды? Как вы воспитываете в своей команде чувство сопричастности, нетерпения и творчества? Дайте нам знать об этом в комментариях!

Заголовок Эбби Калер