Последние пять лет я работаю в тех. саппорте. И у меня сложилось некоторые принципы, следование которым, на мой взгляд, сделает любой тех. саппорт клёвым и офигительным. А если им не следовать, то саппорт будет унылым и неклёвым.
Сразу поясню, что эти советы/правила больше относятся к саппорту через HelpDesk или e-mails, у телефонной поддержки есть некоторые свои особенности.
1. Быстрая реакция и ответы
Клиенты любят быстрый саппорт, они его обожают. Из-за быстрого саппорта они могут закрыть глаза на многое: на высокую цену продукта, ваши ошибки, баги софта. Чем быстрее отвечает и решает проблемы ваш саппорт — тем лучше.
К сожалению быстрый саппорт, доступный 24/7, это дорого: нужно больше людей и нужна круглосуточно доступная инфраструктура. Чаще всего это просто невыгодно, особенно если вы не крупная корпорация, а маленький стартапчик.
В этом случае нам поможет одна интересная штука.
Клиент в любой момент времени должен знать, в каком состоянии находится его запрос, что в настоящее время делается по его проблеме и когда ожидать следующего ответа от инженера.
Добавьте несколько статусов в запросы, сделайте так, чтобы на каждое изменение статуса запроса клиент получал информацию об этом, объяснение, что сейчас происходит с его проблемой, и дату следующего checkpoint, т.е. когда ждать новой информации от инженера.
Эта штука позволяет сильно повысить удолетворенность от саппорта, не увеличивая штат и количество работающих саппортеров.
К примеру, клиент А известил нас о проблеме. Инженер Ц приступил к её решению, через 20 часов проблема была решена. Инженер известил клиента об этом. То есть время от репорта проблемы до её решения — 20 часов.
Вторая ситуация: клиент Б известил нас о проблеме. Ему тут же приходит нотификация, что его запрос получен и примерное время реакции — N часов.
Инженер Ц приступил к решению проблемы и написал, что, скорее всего, проблема вызвана вот этим вот и ближайшие результаты будут через два-три часа. Через три часа инженер пишет, что нашел точную причину, но решение займет время и будет готово завтра. Завтра, через 20 часов от исходного репорта, проблема решена.
И в первом и во втором случаях проблема была решена одинаково быстро — за 20 часов. Но во втором случае у клиента останется впечатление, что мы отреагировали и решили проблему быстро.
Информированный клиент, — радостен и щастлив с большой буквы ща.Это вообще отдельная тема, затронутая ниже. Неинформированный — злится, пишет гневные письма и топает ногами. И его можно понять — у него проблема, а он не знает, чего ожидать от будущего.
2. Ясное объяснение
На мой взгляд, ответ/отчет саппортера о решенной проблеме должен отвечать на следующие вопросы:
- чем вызвана проблема?
- что было сделано для решения проблемы? что еще надо сделать?
- решена ли проблема полностью сейчас или нет?
- может ли возникнуть проблема в будущем? если да, как этого избежать? [опционально]
Пример
Клиент пишет: «Мой сайт не работает, ПОМОГИТЕ!»
Инженер отвечает: «Мы решили данную проблему, проверьте пожалуйста ваш сайт.»
Это плохой, негодный ответ, несмотря на наличие слова «пожалуйста». Хорошо, что сайт работает, но что же все таки было?
Хороший ответ выглядит примерно так:
«Мы проверили ваш сайт. В файле site/file.php была синтаксическая ошибка, из-за которой всё не работало.
Мы отредактировали этот файл и исправили данную ошибку, в настоящий момент все работает правильно, проверьте пожалуйста: example.com
Мы не знаем, кем был изменен файл. Дата изменения — ДДММ. Я проверил последние ваши последние запросы, никто из наших инженеров не работал с вашим магазином. Я сохранил файл до моего изменения. Оригинальный и измененный файлы присоединены к моему сообщению. Пожалуйста свяжитесь с Вашим хостингом и проверьте FTP логи, чтобы выяснить, кем было сделано некорректное изменение.»
Этот ответ даёт информацию, тем он и хорош. Используя этот ответ, клиент может найти виноватого в проблеме или, например, решить подобную проблему в дальнейшем самостоятельно.
Насколько детально описывать причины проблемы — зависит от вас. Если вы знаете, что клиент технически подкован, можно и углубиться в детали. Если же клиент слабо разбирается в этом, можно обойтись и общим описанием.
3. Никогда не спорьте с клиентом
Вообще спорить с человеком неэффективно в плане договориться. А спорить с клиентом это самое плохое и неправильное, что вы можете делать. Даже если вы правы. Вы всегда проиграете в споре с клиентом, уже в тот самый момент, как затеете этот спор.
Не нужно спорить с клиентом: он всегда прав, даже если не прав. Серьезно.
Людям свойственно не признавать своих ошибок, особенно публично, поэтому они будут до последнего стоять на своём, даже если в глубине души они знают, что неправы.
Поэтому переубеждайте клиента, если нужно, излагайте свою точку зрения, но никогда не спорьте, не говорите «ты неправ, мы правы, вот смотри сюда.».
Пример из жизни:
Клиент захотел переместиться из одного хостинга в другой. В процессе перемещения сайта, клиент без предупреждения слишком рано изменил DNS сервера своего домена. Как результат — сайт недоступен. Он пишет: «Ах, вы, олухи, у вас отвратительный сервис, у меня всё не работает. Вы все сломали!
А-а-а, панике!!».
По сути клиент не прав. Его некорректные действия вызвали проблему. Но нужно ли ему сейчас говорить это, тыкать его в свои ошибки, спорить, что на самом деле виноват он?
Нет, это не нужно. Поэтому пишем такое: «Дорогой клиент, тысяча извинений за эту проблему. Это наша ошибка, мы виноваты. Мы должны были предупретить вас, что менять DNS сервера еще рано. Мы вас не предупредили и это вызвало ошибку.
Еще раз извините и попробуйте изменить их еще раз. Все будет работать как надо»
Клиент может побурчать, но чуть-чуть, и на самом деле он будет доволен, что не он накосячил, а мы, и мы это признаем. И он нас полюбит.
Мы забыли о своей гордости, взяли отвественность на себя, а взамен получили довольного клиента, который хочет дать нам денег.
4. Давайте решение
Саппортер должен всегда предложить решение. Всегда. Если саппортер не может предложить хотя-бы какого-то решения — это плохой саппортер.
По возможности лучше предложить несколько решений, с описанием их плюсов и минусов.
Например, сайт не работает из-за ограничений хостинга. Какие могут быть решения?
- можно изменить сайт, приспособив его под ограничения хостинга
- можно сменить хостинг
- можно обратиться к хостингу и попросить убрать ограничения
5. Клиент не дурак
Не считайте клиента идиотом. Одна из проблем IT-индустрии и саппорта в том, что клиента считают существом низшего сорта, потому что он не знает, что такое Perl и PHP, считает, что компьютер это такой телевизор на столе, и зависает на одноклассниках.ру. Да, клиент не разбирается в технических штуках.
Да, он «блондинка», ничего не умеет и бывает, всё ломает. Так радуйтесь же этому!
Именно поэтому клиент приходит к нам, в саппорт, к IT-спецам. Если бы клиент разбирался бы в этих штуках, то в нас не было бы нужды.
Он зато, наверное, разбирается в других вещах, в продажах, ведении бизнеса, и так далее.
А если считать клиента идиотом, то это всё прекрасно чувствуется. А кому хочется общаться с людьми, которые считают тебя идиотом?
Вы скажете: а как же вредные, странные, неадекватные клиенты, как общаться с ними? Ребята, таких клиентов не бывает. И чем раньше вы в это поверите, тем быстрее ваш саппорт будет клёвым и офигительным.
Cчитайте их просто такими взрослыми детьми. Дети могут не понимать каких-то вещей, капризничать, топать ногами, обижаться. Вы же не обижаетесь всерьёз на детей, ведь так? Так и тут, пожалейте их, успокойте, объясните простыми словами, что желаете им добра. Это действует.
Когда клиент не понимает, что мы хотим сказать, объясняйте как себе, как своей собственной маленькой сестре, которая этого технического языка не понимает, объясняйте образами.
Ну и самое главное: клиентов нужно любить. Они это чувствуют и отвечают тем же: -)
Источник: habr.com
Checklist: хороший сотрудник поддержки пользователей
Какими качествами должен обладать хороший специалист поддержки? Давайте сначала определим о ком пойдет речь. В данном случае имеется ввиду сотрудник, непосредственно взаимодействующий с пользователями и решающий определенный круг задач в части поддержки (при этом предметная область может быть любая, в зависимости от специфики организации и структуры службы поддержки).
Мы составили короткий список, включив в него, на наш взгляд, самое главное, чем должен обладать такой специалист. Если есть пункты, вызывающие у Вас вопросы, либо Вы с ними категорически не согласны, либо считаете необходимым внести уточнения или добавить что-то важное, пишите. Обсудим вместе.
- Обладает необходимыми знаниями и навыками в своей области ответственности
- Дисциплирован, четко соблюдает установленные в компании / подразделении правила и инструкции
- Хорошо обучаем: быстро усваивает и применяет в своей деятельности новую информацию, технологии, модели поведения
- Обладает развитыми коммуникативными навыками
- Обладает хорошей скоростью реагирования, понимания сути вопроса
- Умеет отделять в большом потоке информации главное и второстепенное
- Умеет слушать других, а не просто «общаться», задавать правильные вопросы
- Не обладает высокими творческими амбициями, готов работать с потоком однотипных задач
- Обладает развитой способностью к эмпатии (сочувствию, сопереживанию)
- Умеет быстро и самостоятельно принимать решения по возникающим проблемам, готов нести ответственность за результат
- Устойчив к стрессовым ситуациям, контролирует свои эмоции, способен быть подчеркнуто вежлив в общении со «сложными клиентами»
- Умеет коротко и грамотно излагать информацию в письменной и устной форме
- Получает удовольствие от своей работы и общения с людьми
Также по теме:
- Checklist: хороший менеджер процесса
- Checklist: хороший портал для пользователей
- Как составить карту путешествия пользователей для службы поддержки и улучшить пользовательский опыт
- Тесты интеллекта как инструмент поддержки пользователей
- Чаяния служб поддержки пользователей-2013
«VAP: Управление поддержкой ИТ-услуг»
Концентрация знаний и опыта без натаскивания на экзамен
Узнать больше
Комментариев: 14
Nargiza Suleymanova
Обладает необходимыми знаниями и навыками в своей области ответственности
ИМХО необязательное условие, зачастую сотрудники первой линии получают знания и навыки в процессе первоначального обучения, перед выходом «в бой».
Умеет быстро и самостоятельно принимать решения по возникающим проблемам, готов нести ответственность за результат
Самостоятельность бывает неуместна как раз на первой линии, да и ответственность у них другая, не за результат. Опять же, все из собственного опыта. Наверное, у кого-то работает по-другому.
Евгений Хон
Первое время тоже была первая линия поддержки, которая работала только по созданным статьям из базы знаний. Была вторая линия поддержки: ребята руки/ноги которые в случае чего выезжали к клиенту. Ну и третья линия поддержка: мозговой центр, который только решал глобальные инциденты/проблемы. Скажу честно: на нашем предприятии дело оказалось малоэффективным.
В итоге, пришли к мнению что первую и вторую линию поддержки могут взять на свои плечи ребята руки/ноги, которых посадили на телефоны, а вместо 4 операторов взяли 2 инженеров. Во первых, пусть немного, но все же выиграли по зарплатному бюджету, во вторых, среднее время решения заявок сократилось с 11 часов до 7, но стремимся к 3 (мечтать не вредно).
На мой взгляд, ответственность за результат на коротких дистанциях всегда должна ложиться на инженера поддержки, так как именно этот человек непосредственно, подчеркиваю, на данным момент времени, работает с возникшей проблемой. А руководитель инженера несет соответсвенно уже ответственность за деятельность своего инженера. Инженер — образ фантазийный, у которого всегда вертится очень много драйва в голове, поэтому не вижу смысла ставить узкие рамки для работы человека. Пусть инженер работает самостоятельно, бороздит просторы сети и серверной в рамках своих прямых и не прямых обязанностей в ИТ.
Nargiza Suleymanova
Мои комментарии чуть ниже Неверно привязала ответ.
Сергей М.
Но ведь вашем случае получается не прослеживается четких границ ответственности между первой и второй линией. Не боитесь ли, что когда-нибудь первая линия облениться и станет добрую половину запросов просто переправлять к гуру?
Nargiza Suleymanova
Про передачу ответственности между линиями поддержки вроде не упоминала. Тут немного другое, я пыталась обратить внимание Евгения на то, что ответственность за результат по заявке лежит не на первой линии, не на инженере (как было указано Евгением), а на конкретном сотруднике, назначенном ответственным за конкретную заявку. И этот самый сотрудник может быть на 1 линии, на 2-ой, а может, и на 3-ей. При этом правила передачи заявок между линиями никто не отменял И да, не забываем про часто используемый KPI first line resolution.
Ivan Krouglyi
Обладает необходимыми знаниями и навыками в своей области ответственности ИМХО необязательное условие, зачастую сотрудники первой линии получают знания и навыки в процессе первоначального обучения, перед выходом «в бой».
«Перед выходов в бой» вы имеете ввиду адаптацию и обучение? Тогда все правильно, просто требования к готовому работнику (адаптированному), а не при найме. Тут уже решать кадому самостоятельно — нанимат ьподготовленыхили учить, и там и там есть плюсы и минусы.
Nargiza Suleymanova
Совершенно верно, я про адаптацию и обучение. Кстати, бывает, что без обучения никак, потому что системы на поддержке уникальные.
Nargiza Suleymanova
Давайте попробуем разобраться.
Первое время тоже была первая линия поддержки, которая работала только по созданным статьям из базы знаний. Была вторая линия поддержки: ребята руки/ноги которые в случае чего выезжали к клиенту. Ну и третья линия поддержка: мозговой центр, который только решал глобальные инциденты/проблемы.
Руки/ноги я бы не выделяла во вторую линию: они либо часть первой линии, либо линия 1+. У вас (взгляд со стороны) вырисовывались как раз 2 линии поддержки. 3 линия, скорей всего была, но в виде привлечения вендоров/внешних поставщиков.
В итоге, пришли к мнению что первую и вторую линию поддержки могут взять на свои плечи ребята руки/ноги, которых посадили на телефоны, а вместо 4 операторов взяли 2 инженеров.
Тут есть риск возникновения ситуации, когда всех инженеров в виде ног разобрали, а на телефоны отвечать и регистрировать заявки никого не осталось. С другой стороны, судя по количеству сотрудников, объем заявок небольшой.
На мой взгляд, ответственность за результат на коротких дистанциях всегда должна ложиться на инженера поддержки, так как именно этот человек непосредственно, подчеркиваю, на данным момент времени, работает с возникшей проблемой.
Соглашусь, только с небольшим дополнением. Ответственность за заявку несет тот, кого назначили по ней ответсвенным- это может быть инженер 1 или 2 линии, а может, и 3-й.
Евгений Хон
Тут есть риск возникновения ситуации, когда всех инженеров в виде ног разобрали, а на телефоны отвечать и регистрировать заявки никого не осталось. С другой стороны, судя по количеству сотрудников, объем заявок небольшой.
Не совсем. Очень долго (почти три года) шли к тому, чтобы бОльшая часть обращений решалась удаленно (не рекламы ради, перешли на radmin), что позволили на текущий день решать 60% обращений, не поднимая своего тела со стула. По оставшимся 40% уже катаются только два инженера, у которых есть автотранспорт. Да, немного дольше обрабатываются «вездные» заявки в силу расстояний, но конечная цель — сокращение таких заявок и увеличение количества решенных обращений по телефону с помощью radmin.
Rafhat Osmonov
Если отбросить все «но» и «если», то перечислены все необходимые качества. Как только речь заходит о линиях поддержки, то тут требуются правки и дополнения. И тут уже дело каждого, кто и что вкладывает в свою линию поддержки. Если по сути: 1. Не хватает качества результативности: скорость, качество и т.д. Это очень важно для сотрудника поддержки.
2. Не хватает качества получения обратной связи. Одно дело обладать коммуникативными навыками, другое дело получать подтверждение своей полезности. 3. Не хватает качества убедительности. Общаясь с клиентами для достижения результата необходимо проявлять убедительность. 4. И мое любимое — проактивность!
Александр
Пункты 2 и 10 плохо сровмещаются в одной голове.
Сергей Семикин
Таких не бывает. Сферический сотрудник в вакууме.
peaceful
1 Пункт думаю хватит и 60%, сами на курсах говорили, что в ТП особенно1 уровень поддержки дикая текучка и малообученный персонал. 9-10-11 Подходят скорее на начальника ИТ или ИТ менеджера.К тому же 9 пункт исключает 8)) Это просто психология. В рассылке ITIL Practitioner по моему немного другие были вещи)
Vyacheslav Potov
Согласен с рядом комментариев выше, что список несколько избыточен, а специалист владеющий всеми описанными компетенциями будет явно дорог для среднестатистического сотрудника первой линии поддержки. Если принять за объект рассмотрения чуть более суженный профиль, включающий в себя приём и общение с конечным пользователем, обеспечение среднего First Call Resolution порядка 60-70% (типовые массовые проблемы), я бы выделил следующие группы компетенций.
Коммуникационные навыки и клиенто-ориентированность. Сюда можно сгруппировать умение слушать и слышать, отделяя зёрна от плевел, но при этом не додумывая за пользователя того, что он не говорит. Умение общаться с пользователем вежливо, дружелюбно, стабильно с течением времени, при этом сохраняя стрессоустойчивость и контроль за конфликтом.
Твёрдо верю, что на первой линии, если вы уж решились поставить туда человека а не безликий портал, должен быть в первую очередь психолог, а потом уже технарь. Обучаемость и дисциплина. Сгруппируем сюда умение быстро обучиться от старших специалистов, и существующих инструкций и знаний, а так же умение этим инструкциям следовать.
Чрезмерная самодеятельность на первой линии грозит непрозрачностью ситуации с обращениями, несоблюдением процессов и нестабильным результатом. Способность к работе с большим и широким охватом информации. В данном случае как технологической — знание предметных областей поддержки, многих, пусть не на глубоком уровне, но зато с широким охватом и пониманием взаимовлияния.
Так и возможность «помнить» большие объёмы проходящих заявок. Если первая линия работет не просто «прими и передай», то всё что не решится на первом звонке неплохо бы держать под присмотром. Пользователь-то прийдёт в случае чего опять на первую линия. Все остальные компетенции я б скорее отнёс к «старшим», «VIP-саппорту», 1,5-2й линии и тому подобному. Хотя несомненно для каждой конкретной организации приоритеты и профили могут быть свои.
Источник: cleverics.ru
Хороший саппорт — кто это? тактика Dota 2
В первую очередь надо понять подходит эта роль вам или нет. Если вы любите звук монет и возгласы комметатора, то саппорт не для вас. Если вы любите ощущать чувство выполненного долга в душе и помогать окружающим, то саппорт это для вас.
В хороших саппортах нуждаются в каждой игре. От вас зависит как мне кажется исход любой игры. Если саппорт выйграет начало игры для своей команды, то скорее всего это выйгрышь. Что я подрозумеваю под «выйграть начало игры» — успешные ганги, фарм вашего керри, враг боится вас и вашу команду. Теперь мы перейдём к пикам.
Прежде чем пикнуть героя вам надо его правильно выбрать. Если против вас играет много масс ультов, то наиболее лучшим вариантом для вас будет и . Рубик может обратить ульты врага против их самих. Сайленсер одним нажатием кнопки может испортить весь план вражине. Но опять же этими героями надо понимать ситуацию и понимать какую ульту лучше украсть или же в какой момент прожать сайленс.
Если против вас играет 3 и более керри рекомендуется брать 
. Первые два героя бейн и трент дадут вам преимущество в лейте. У этих героев ульта пробивает бкб. У трента корни не дают врагу атаковать вас.
По мне так это лучшая ульта после РП магнуса. Что касается последних двух — эти герои остановят вражеского керри в фарме голды и помешают ему дожить до позднего лейта. У обоих персонажей довольно сильные ульты — т.к. большинство керри вначале довольно хилые, то эти герои идеально подходят для того, чтобы убить врага. Я рекомендую больше лину т.к. у неё меньше кд ульты на первом лвле в два раза, но при этом у лиона больше урон.
Следующий вариант если против вас играет такие герои как 
, то я рекомендую брать
опять же . Этот герой может вылечить быстро свою башню. Но он не эффективен против , т.к. зачастую эти герои уносят вашу башню за один заход. Трент был первым героем против пуша, но не самым лучшим.
Такие герои как 
могут остановить пуш своими сильными прокастами или просто переградить проход к башне. Но при дефе не стоит забывать, что враг может вас обойти со спины.
И последний вариант если против вас пикнули несколько сильных танков на подобии 
, то хорошим вариантом будет 
. У него не большой кул даун ультимейта и урон идёт не по хп а по %. Так же хорошо подойдут масс ульты 
. У энигмы так же есть навык который снимает хп врага по процентам. У шейкера мощная ульта и сильным стан.
Мы разобрались с пиками теперь перейдём к самой игре.
Самое начальное это ваш закуп.
Есть пару вариантов.
Вы саппорт которому нужна мана ( 
),
то лучшим закупом для вас будет [item= Tango ], 3х 
, 
,
и несколько 
если хватает денег.
Вы со своим тиммейтом собрались играть в агрессивную доту. Я вам посоветую купить [item= Tango ] 
. Так же можно заменить баночку Healing Slave на Tango .
Мой обычный закуп: [item= Tango ]
Вот и всё, что я хотел сказать по начальному закупу. Но в основном надо смотреть по ситуации в игре и по вашим планам в начале игры.
Ура! Мы услышали гул трубы и идём рядом с крипами. Стоп! Что? Рядом с крипами?
В первую очередь мы должны застопить наш лайн. Это надо для того, чтобы вражеские крипы подошли намного ближе к вам и вашему тиммейту, но не перестарайтесь т.к. если вражеские крипы будут под вашей башней, то линия сильно запушится не в вашу сторону, а это нам не надо.
Ну вот наш керри стоит и добивает крипов, но лайн всё же запушен. Что же сделает хороший саппорт? Мой ответ — отвод! Отоводятся крипы очень легко. На 12-13 или 42-43 секунде бьёте нейтральных крипов которые находятся рядом с вашей линией и ведёте прямо на ваших крипов сквозь проходы в лесу. Но не стоит забывать, простой отвод навредит вам и вашему керри.
При обычном отводе нейтральные крипы быстро умирают и ваши помощники попадают обратно на линию, но уже со второй пачкой крипов. Чтобы такого не произошло вам понадобится стак! Нет, стак это не вещь — это ещё один способ улучшить игру. На 51-53 секунде вы бьёте крипов на спавне для отвода и убегаете подальше от спавна так, чтобы на месте спавна образовалась новая пачка монстров. И после этого можно спокойно отводить.
Мы продолжаем стоять на лайне. У нашего керри всё хорошо, враг не подходит к крипам. Мы больше не нужны на этом лайне. Со спокойной душой мы можем идти гангать. Ганги нужны не для каждого саппорта, а для того у которого есть стан или замедление.
Для гангов нам хорошо подойдут герои 
и это далеко не все герои. Для хорошего ганга нам понадобится две вещи. Это 
— это предмет который можно купить в основном магазине, вторая вещь это понять куда нам надо гангать. Если ваш мидер выигрвает свою линию, то лучше пойти на оставшийся лайн и помочь вашей команде.
Всё складывается очень хорошо для нас и нашей команды. Теперь речь пойдёт о полезности наших дорогих саппортов к лейту. Многие говорят, что саппорты к лейте бесполезны и умирают с 2-ух или 3-ёх ударов. Но это не так. Мы не теряем нашу полезность со временем.
Большинство саппортов имеет ультимейты очень полезные для лейта. Герои такие как наносят хороший урон и в поздней игре, и хорошо останавливают вражеского керри.
Со временем у нас появляются веши. Для нас — саппортов нужны вещи которые повысят нашу полезность и выживаемость в игре.
Предметы 
повысят нашу мобильность в игре. И с помощью этих предметов можно инициировать или сейвить.
Так же отлично подойдут предметы 
эти предметы помогут вам выйграть не только драку, но и игру. Но всё же предметы которые должны быть у саппорта к 30-ой минуте это: 
.
Этой три основных предмета. Барабаны или мека могут заменять друг друга к этому времени. Кажется я что-то забыл. Ах да куда же ставить варды.
.Отличный гайд который поможет вам разобраться в постановке вардов. К завершению хочу сказать, что саппортов много, но хороших саппортов по пальцам перещитать.
Источник: dota2.ru