Комментарии 30
У меня опыт техподдержки более ограничен, так как до меня как до девелопера доходят только важные клиенты со сложными окружениями, но за свою практику удаленных сессий с клиентами у меня тоже сложились шаблоны поведения, которые вселяют в пользователя уверенность и надежду. Поделюсь своим опытом.
- Пользователь свято верит в вас — доступ к разработчику пользователь получает не сразу, а после прохождения через уровни T1 и T2, зачастую порядком уставший. Получение доступа к программисту для него сродни прямому контакту с богом. Не обманите этих ожиданий и умело пользуйтесь этим мнением.
- Источайте уверенность — что бы вы ни делали, делайте это уверенно. Пользователь все равно не понимает, что вы там делаете. Чем больше на экране непонятных приложений и бинарных данных, тем комфортнее пользователю, ведь «бог запустил свою магию»
- Как это ни странно, пользователи чаще лучшего мнения о продукте, чем сами разработчики. Многие (не особо продвинутые) пользователи вообще не представляют себе возможность бажности продуктов и им кажется, что в том, что продукт не работает, виноваты они сами, неправильно его используя. Поэтому, видя отчаянный и позорный баг, не краснейте и не паникуйте. Пользователь этого не знает. Баг пофиксите после сессии. Пользователь не должен видеть ваше замешательство.
- Действуйте энергично — ничто так не угнетает, как когда ничто не происходит. Если продукт тупит, долго перезапускаясь или что-то там подчищая или переиндексируя, запустите regedit и просмотрите реестр. Либо займитесь профилактическим осматриванием пользовательского окружения. Если прямо на месте напишете простенький скрипт для мониторинга, пользователь будет счастлив выше крыши
- Не торопитесь — помните, что пользователь где-то в глубине души гордится тем, что нашел «очень сложный кейз», так что ему персонально выделили разработчика. Если вы за пять секунд удалите глючную запись в реестре и уйдете с сессии, пользователь может подумать: «ага, у них есть баг, они о нем знают, и не фиксят. да и непонятно, почему это не мог сделать специалист технической поддержки?». Быстро исправили проблему — не уходите сразу. Присмотритесь к окружению. По любому не помешает, а пользователю приятно, что его диагносцируют по полной программе.
- Не затягивайте сессии. Где-то на втором часу пользователь понимает, что вы не так божественны, как он думал. Если ничего не понятно, и наступает тупняк, снимийте дампы, трейсы и копии баз и конфигурации, и уходите с сессии в оффлайн анализ. Фраза: «мы собрали все нужное, мы разберемся и все вам исправим» вселяет в пользовательскую душу мощную надежду.
Очковтирательство какое-то. У вас задача решить проблему клиента или покрасоваться?
> Чем больше на экране непонятных приложений и бинарных данных, тем комфортнее пользователю
— алло, здравствуйте, я не могу найти иконку браузера на рабочем столе
— да, минуточку (открываешь у клиента консоль, запускаешь make world...)
— алло, здравствуйте, я не могу найти иконку браузера на рабочем столе
— да, минуточку (открываешь у клиента консоль, запускаешь make world...)
ну, тогда уж IconFinder, и чтоб обязательно был написан на Haskell.
На самом деле, хотелось бы уточнить, что мой комментарий не про всех пользователей, а тех, которые дошли до разработчика, т.е. чьи проблемы специалисты технической поддержки уровня tier 2 (T2) не смогли решить. Т.е. проблема у них явно не в мозгах пользователя (:
На самом деле, хотелось бы уточнить, что мой комментарий не про всех пользователей, а тех, которые дошли до разработчика, т.е. чьи проблемы специалисты технической поддержки уровня tier 2 (T2) не смогли решить. Т.е. проблема у них явно не в мозгах пользователя (:
Правильный ответ:
С: Окей, я понял срочность проблемы, и мы попытаемся ее решить как можно скорее. Мне понадобится ваш идентификационный номер клиента для того, чтобы правильно обработать ваше обращение, но мы можем пропустить этот этап с учетом важности проблемы. Расскажите, пожалуйста, симптомы.
Неправильный это ответ. Правильно то, что нужно пытаться решить проблему, а не выполнить формальную процедуру. Неправильно то, что вы говорите «можем пропустить этот этап». То есть, неважно, откуда он возьмётся у вас, но вы должны в итоге иметь «идентификационный номер» — а сообщит ли вам клиент его или он сообщит своё имя, а вы его найдёте в своей базе — вопрос другой. Во многих случаях клиент вообще определяется по номеру телефона, с которого звонок.
В общем, оба первых предложения — фактически мусор, занимание времени клиента. Проще надо быть: «Представьтесь, пожалуйста, кто вы, и сообщите, что именно вы наблюдаете.». Всё.
Каждое обращение необходимо зафиксировать, получив хоть какую-нибудь контактную информацию от клиента (история заносится в базу, которая потом позволяет выяснить с чем к нам этот клиент приходил, с чем ушел, и т.п.). Впрочем в чем-то вы правы и вспоминая свой опыт — действительно довольно часто я действовал именно так как вы и описали. Здесь важен именно баланс между формальностью и непосредственно переходом к решению проблемы.
Есть еще такой момент, что техподдержка — это платный сервис. Оплата за 1 год поддержки в случае Acronis уже включена в цену лицензии корпоративных продуктов (для home пользователей существует отдельно покупаемая поддержка). Соответственно проверка валидности обращения по идентификационному номеру тоже входит в стандартный шаблон, обязательный для исполнения. В нашем конкретном случае этот номер проверяется инженером техподдержки голосом, но как вы правильно заметили — это может раздражать. Поэтому мы планируем переход на автоматизированную систему проверки валидности обращения по телефону. К концу этого года такая автоматическая проверка должна заработать для home пользователей, и если все пойдет хорошо, то мы расширим данный функционал на все обращения.
Есть еще такой момент, что техподдержка — это платный сервис. Оплата за 1 год поддержки в случае Acronis уже включена в цену лицензии корпоративных продуктов (для home пользователей существует отдельно покупаемая поддержка). Соответственно проверка валидности обращения по идентификационному номеру тоже входит в стандартный шаблон, обязательный для исполнения. В нашем конкретном случае этот номер проверяется инженером техподдержки голосом, но как вы правильно заметили — это может раздражать. Поэтому мы планируем переход на автоматизированную систему проверки валидности обращения по телефону. К концу этого года такая автоматическая проверка должна заработать для home пользователей, и если все пойдет хорошо, то мы расширим данный функционал на все обращения.
Не согласен. Мне важно услышать по телефону " Окей, я понял срочность проблемы, и мы попытаемся ее решить как можно скорее." — это, блин, очень важно.
Ваш звоноккоммент очень важен для нас.
Не обижайтесь. Возможно, кому-то нужно услышать «да-да, мы понимаем, что у вас проблема». Лично мне гораздо лучше, когда ответят грубо, но при этом сразу реально начнут решать проблему, а не увиливать и тянуть время. А фразы типа «мы понимаем, что у вас срочная проблема» и «ваш звонок очень важен» — это именно затягивание времени.
Не обижайтесь. Возможно, кому-то нужно услышать «да-да, мы понимаем, что у вас проблема». Лично мне гораздо лучше, когда ответят грубо, но при этом сразу реально начнут решать проблему, а не увиливать и тянуть время. А фразы типа «мы понимаем, что у вас срочная проблема» и «ваш звонок очень важен» — это именно затягивание времени.
НЛО прилетело и опубликовало эту надпись здесь
Я в таких случаях говорю — «проблема в голове» (у пользователя)
Суть в том, что таких клиентов в первую очередь надо убедить в том, что лично вы верите в их проблему. Таким людям важно даже не само решение, в первую очередь то, что их проблему признали сначала, а потом уже можно приступить непосредственно к решению. Убеждать пользователя в том, что проблемы не существует — гиблое дело. На вашем примере:
(с) -Да, Интернет у вас не работает, давайте разберемся
(к) -Ничего не работает — открываю интернет и не работает
(с) -Окей, давайте посмотрим, что именно вы открываете, какие символы печатаете… О, а попробуйте напечатать вот так… Заработало? Спасибо что обратились :)
Я считаю, что есть большая разница между «Вы вот здесь ошиблись, проблемы на самом деле нет» и «Попробуйте пожалуйста сделать вот так, чтобы заработало» — это принципиально разные подходы.
З.Ы. И да — вы немного не угадали, опыт работы у меня есть и на первой, и на второй, и на N-ой линии, вплоть до девелоперов. В том числе пришлось поработать как с мистическими случаями (проблема происходит только в «каждый третий четверг месяца в високосный год»), где без магии не обошлось, так и с простыми, где достаточно было удалить один ключик в реестре :)
(с) -Да, Интернет у вас не работает, давайте разберемся
(к) -Ничего не работает — открываю интернет и не работает
(с) -Окей, давайте посмотрим, что именно вы открываете, какие символы печатаете… О, а попробуйте напечатать вот так… Заработало? Спасибо что обратились :)
Я считаю, что есть большая разница между «Вы вот здесь ошиблись, проблемы на самом деле нет» и «Попробуйте пожалуйста сделать вот так, чтобы заработало» — это принципиально разные подходы.
З.Ы. И да — вы немного не угадали, опыт работы у меня есть и на первой, и на второй, и на N-ой линии, вплоть до девелоперов. В том числе пришлось поработать как с мистическими случаями (проблема происходит только в «каждый третий четверг месяца в високосный год»), где без магии не обошлось, так и с простыми, где достаточно было удалить один ключик в реестре :)
Ну, например, как бы вы провели диалог в эпическом случае не было разрыва? Где тут проблема? Что тут надо признавать?
Процитирую вырезку из лурка, которая является на мой взгляд самым адекватным мнением:
«Клиент сообщает о проблемах — не важно, выдуманных или настоящих, — первым делом нужно протестировать ping-ом его адрес, а также весь сектор. И сказать клиенту, чтобы он со своего сделал то же самое. В большинстве случаев это локализует проблему. Четыре обрыва связи подряд — это ненормально, подобные вещи парализуют работу в интернете и реально вызывают гнев юзера. Суппорт же постеснялся спросить очевидную вещь — подряд были эти четыре обрыва или раз в день?»
Данное суждение, кстати, вполне соответствует пункту «Понимание и признание проблемы пользователя» моей статьи.
«Клиент сообщает о проблемах — не важно, выдуманных или настоящих, — первым делом нужно протестировать ping-ом его адрес, а также весь сектор. И сказать клиенту, чтобы он со своего сделал то же самое. В большинстве случаев это локализует проблему. Четыре обрыва связи подряд — это ненормально, подобные вещи парализуют работу в интернете и реально вызывают гнев юзера. Суппорт же постеснялся спросить очевидную вещь — подряд были эти четыре обрыва или раз в день?»
Данное суждение, кстати, вполне соответствует пункту «Понимание и признание проблемы пользователя» моей статьи.
НЛО прилетело и опубликовало эту надпись здесь
Здесь тогда получается вопрос о том, что понимать под проблемой. Я могу решить «любую проблему» именно с точки зрения пользователя. Под этим я понимаю начало, развитие и завершение некоего конкретного диалога в определенный момент времени (грубо говоря звонок от юзера). Результат завершения диалога это «удовлетворенность» пользователя. При этом «реальная» проблема, которая может быть в софте (баг в самом плохом случае), конечно же никуда не уйдет, т.к. требует воспроизведения у тестеров, написания фикса в коде, создания билда, тестирования и т.д. (в лучшем случае это минимум неделя). Таким образом в общем случае мы имеем:
а) Удовлетворенного пользователя
б) Решенную или не решенную фактическую проблему
При этом зависимость между а) и б) далеко не однозначная. Пользователь может уйти удовлетворенным и при нерешенной проблеме, если ему адекватно объяснить, почему нельзя пофиксить, когда пофиксим, какие есть альтернативные решения и т.п. С другой стороны он может и быть крайне расстроенным своим опытом обращения при по факту решенной проблеме, если долго отвечали, тянули с ответом, тратили его время впустую при очевидном решении.
П.С. Я вас прекрасно понимаю :) По началу я крайне боялся таких кричащих пользователей и всячески избегал подобных эскалаций, но потом после пары инцидентов, переменил точку зрения. Из таких вот людей, как ни странно, довольно часто получаются самые преданные клиенты при правильном подходе :)
а) Удовлетворенного пользователя
б) Решенную или не решенную фактическую проблему
При этом зависимость между а) и б) далеко не однозначная. Пользователь может уйти удовлетворенным и при нерешенной проблеме, если ему адекватно объяснить, почему нельзя пофиксить, когда пофиксим, какие есть альтернативные решения и т.п. С другой стороны он может и быть крайне расстроенным своим опытом обращения при по факту решенной проблеме, если долго отвечали, тянули с ответом, тратили его время впустую при очевидном решении.
П.С. Я вас прекрасно понимаю :) По началу я крайне боялся таких кричащих пользователей и всячески избегал подобных эскалаций, но потом после пары инцидентов, переменил точку зрения. Из таких вот людей, как ни странно, довольно часто получаются самые преданные клиенты при правильном подходе :)
НЛО прилетело и опубликовало эту надпись здесь
Если вы можете сказать «это фича, а не баг» так, что клиент останется довольным — то да, для него это будет решением на данный текущий момент времени. Существуют баги, которые крайне тяжело исправить в ближайшей перспективе и если на этот факт невозможно повлиять (приходится с ними мириться), то на отношение клиента к такой ситуации повлиять можно и нужно. Уйдет он довольный или нет — зависит в первую очередь от техподдержки, а не от продукта, которых без багов как известно не существует.
Извиняюсь за стилистические ошибки в правописании — иногда слишком спешу. Хабр злой — слишком мало времени на редактирование коммента дает. Надеюсь со временем привыкну. А то сейчас перечитываешь и глаза сломать можно в паре мест :(
НЛО прилетело и опубликовало эту надпись здесь
Телефон это просто канал коммуникации, но ведь никто не отменял удаленную поддержку (через TeamViewer, WebEx или что-либо еще), в случае если разговорами проблему не решить. Очень удобно удаленно подключиться и воочию увидеть проблему, параллельно голосом выясняя подробности.
«Ой, а мы перезагрузились и проблема исчезла. Но такое уже не в первый раз.»
В таком случае все равно остаются логи, по которым можно восстановить картину произошедшего. Если же это невозможно (кривые логи, либо они уже протухли), то попросить клиента позвонить ДО ребута :)
Мы же про акронис?
Случай «загрузился с диска, заворачивание раздела в бекап повисло» — ну куда логи? И никаких тимвьюеров.
Случай «загрузился с диска, заворачивание раздела в бекап повисло» — ну куда логи? И никаких тимвьюеров.
Если честно с такими ситуациями, когда именно наглухо зависает _в процессе_ рестора сталкивался крайне редко (последний раз емнип года 3 назад, где был явный баг). Там помогают только танцы с бубнами аля «попробуйте еще вот этот .iso образ с обновленным ядром», либо сбор информации (так называемой «сисинфы») после загрузки с диска, но до воспроизведения проблемы — по такой информации тоже что-то можно понять. Либо на крайний вариант есть еще дебуг загрузочного диска с другого компа подключенного к проблемному через COM порт — но это уже совсем хардкор :)
Обычно же, если проблема есть, то она происходит на этапе загрузки с диска (виснет), для чего есть вполне определенные шаги траблшутинга (нажмите F11 в меню, уберите 'quiet' и т.д.).
Обычно же, если проблема есть, то она происходит на этапе загрузки с диска (виснет), для чего есть вполне определенные шаги траблшутинга (нажмите F11 в меню, уберите 'quiet' и т.д.).
Спасибо за статью. Очень хорошо написано, сбалансированно, последовательно и по делу. Может быть что-то и очевидно, но все в одном месте, однозначно (не спорно) и обязательно для прочтения.
Еще забавный эффект от статьи: вдруг появилось ощущение важности этого дела — техподдержки, сопричастности к большому и важному общему делу. А это самое главное: объяснить сотруднику ТП, что его работа заключается в «сделать клиента довольным», а не в чем-то другом.
Еще забавный эффект от статьи: вдруг появилось ощущение важности этого дела — техподдержки, сопричастности к большому и важному общему делу. А это самое главное: объяснить сотруднику ТП, что его работа заключается в «сделать клиента довольным», а не в чем-то другом.
Рад, что вам понравилось :) Вы, кстати отметили важный момент: цель статьи была в том числе и в показании важности техподдержки внутри организации. Есть такая тенденция — на первых порах (пока компания еще только становится на ноги) относиться к своей техподдержке с неким пренебрежением. Это ощущается и со стороны менеджмента и девелоперов, но к счастью понимание важности и полезности хороших специалистов по общению с клиентами, приходит достаточно быстро — как показывает практика техподдержка, хоть и является одним из самых затратных отделов, но именно ее качество влияет на впечатление от компании со стороны клиентов, так что «профита» все равно получается больше.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Принципы успешной техподдержки