Как ускорить предоставление решения технической поддержкой

Правильный вопрос

Для тех, кто не любил читать в школе произведения по литературе с начала и до конца вот краткое содержание статьи и ответ на вопрос:

Правильный вопрос – половина ответа

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

Снижают нагрузку на службу поддержки

Ускоряют получение ответа на вопрос

Упрощают предоставление развернутого ответа

Рекомендации для пользователей перед обращением в поддержку

Поиск ответа в базе знаний

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

- Видишь документацию?
- Нет.
- А она есть.

Что такое управление знаниями и зачем нужна база знаний организации?

Конкретизировать суть в обращении

На правах исполнителя расположите пример желаемого представления «тела» заявки и перечислите существенные данные, необходимые для корректного понимания вопроса и интерпретации сотрудниками поддержки.
Ясное и лаконичное содержание письма в теме составляет 70% для формирования скорейшего ответа. Несодержательные слова, вроде: «Помогите», «Ошибка», «Случилась проблема» и т.п. не приемлемы, так как не конкретизируют факты.
Вместо этого следует, использовать темы вида «Не удается создать учетную запись в AD», «Не заполняются табличные части в разделе списание», «Выставление счета СФ-1234567890» и т.п.
Для наглядности приведите на странице обращения пример сравнения или образец запроса:

Запрос №1:
«Здравствуйте, техподдержка программы, которой я пользуюсь для автоматизации своего IT отдела. Уж больно давно не пользовался своей любимой программой, а сегодня днем, когда включил компьютер, был повергнут в шок - он не включился. Я начал подозревать, что это технические работы на сервере стали причиной, по которой сайт на захотел грузиться. Зайти в личный кабинет на сервере не смог - пароль не корректный. Помогите мне скорее, пожалуйста!»

Запрос №2:
«Здравствуйте!
1. На сайте softonit.ru не загружается страница «softonit.ru/FAQ/» - ошибка 500 Server Error
2. Подключался на сайт так: логин: userMDV; пароль: ImnF32»

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

Предоставлять как можно больше деталей

Достаточное количество полезных дополнительных материалов в разы ускоряет локализацию проблемы и дальнейшее устранение причины.
Так предоставление справки «О программе», где обозначается информация о редакции продукта - будет стартовой точкой для разработчика в процессе поддержки. Скриншоты и видео, устраняют необоходимость «играть в пинг-понг» по типу вопрос-ответ и наглядно покажут, что видно на экране глазами клиента.
Логи ошибок объяснят причину поломки на программном уровне - такое подспорье быстрее наводит технических специалистов на понимание «природы» возникновения ошибки, тем самым время обработки заявки и предоставление ответа становится гораздо меньше.

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

Не дублировать заявки

Некоторые пользователи дублируют обращения для акцентирования внимания на себе или таком образом надеются получить ответ первого «клюнувшего» сотрудника, так сказать - дают поучавствовать каждому сотруднику техподдержки в процессе - ну, чтобы скучно не было, наверное :)
Такой аттракционн неслыханной щедрости заканчивается забитой очередью потока обработки обращений и только вносит путаницу в работу службы поддержки, тем самым увеличивается итоговое время получения ответа.
Регламент обращения дополняется просьбой обойтись одним обращением и напоминанием о единых сроках обработки заявок вне зависимости темы и источника.

Обучить пользователя

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

Проверить ответ в базе знаний

Правильно формулировать суть обращениям

Добавлять детали

Не дублировать обращения

Остается определить каким образом донести информацию и выбрать место подачи - где и как предоставить правила: на отдельной странице; в процессе формирования обращения или рассылкой и т.п.
Регламент обращений в поддержку «приучает» пользователя к образцовому формированию заявки, как результат снимает часть рутинной нагрузки с сотрудника.
Итогом введения рекомендаций становится уменьшение времени обработки заявки и улучшение показателей отдела поддержки: среднее время реакции, среднее время решения, количество закрытых обращений и т.п., а главное - здоровые нервы сотрудников и довольные клиенты.