Комментарии 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' и т.д.).
Спасибо за статью. Очень хорошо написано, сбалансированно, последовательно и по делу. Может быть что-то и очевидно, но все в одном месте, однозначно (не спорно) и обязательно для прочтения.
Еще забавный эффект от статьи: вдруг появилось ощущение важности этого дела — техподдержки, сопричастности к большому и важному общему делу. А это самое главное: объяснить сотруднику ТП, что его работа заключается в «сделать клиента довольным», а не в чем-то другом.
Еще забавный эффект от статьи: вдруг появилось ощущение важности этого дела — техподдержки, сопричастности к большому и важному общему делу. А это самое главное: объяснить сотруднику ТП, что его работа заключается в «сделать клиента довольным», а не в чем-то другом.
Рад, что вам понравилось :) Вы, кстати отметили важный момент: цель статьи была в том числе и в показании важности техподдержки внутри организации. Есть такая тенденция — на первых порах (пока компания еще только становится на ноги) относиться к своей техподдержке с неким пренебрежением. Это ощущается и со стороны менеджмента и девелоперов, но к счастью понимание важности и полезности хороших специалистов по общению с клиентами, приходит достаточно быстро — как показывает практика техподдержка, хоть и является одним из самых затратных отделов, но именно ее качество влияет на впечатление от компании со стороны клиентов, так что «профита» все равно получается больше.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Принципы успешной техподдержки