Портал №1 по управлению цифровыми
и информационными технологиями

Checklist: хороший сотрудник поддержки пользователей

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

  1. Обладает необходимыми знаниями и навыками  в своей области ответственности
  2. Дисциплирован, четко соблюдает установленные в компании / подразделении правила и инструкции
  3. Хорошо обучаем: быстро усваивает и применяет в своей деятельности новую информацию, технологии, модели поведения
  4. Обладает развитыми коммуникативными навыками
  5. Обладает хорошей скоростью реагирования, понимания сути вопроса
  6. Умеет отделять в большом потоке информации главное и второстепенное 
  7. Умеет слушать других, а не просто «общаться», задавать правильные вопросы
  8. Не обладает высокими творческими амбициями, готов работать с потоком однотипных задач
  9. Обладает  развитой способностью к эмпатии (сочувствию, сопереживанию)
  10. Умеет быстро и самостоятельно принимать решения по возникающим проблемам, готов нести ответственность за результат
  11. Устойчив к стрессовым ситуациям, контролирует свои эмоции, способен быть подчеркнуто вежлив в общении со «сложными клиентами»
  12. Умеет коротко и грамотно излагать информацию в письменной и устной форме
  13. Получает удовольствие от своей работы и общения с людьми

 

 

Комментариев: 14

  • Обладает необходимыми знаниями и навыками  в своей области ответственности

    ИМХО необязательное условие, зачастую сотрудники первой линии получают знания и навыки в процессе первоначального обучения, перед выходом "в бой".

    Умеет быстро и самостоятельно принимать решения по возникающим проблемам, готов нести ответственность за результат

    Самостоятельность бывает неуместна как раз на первой линии, да и ответственность у них другая, не за результат. Опять же, все из собственного опыта. Наверное, у кого-то работает по-другому.

    • Первое время тоже была первая линия поддержки, которая работала только по созданным статьям из базы знаний. Была вторая линия поддержки: ребята руки/ноги которые в случае чего выезжали к клиенту. Ну и третья линия поддержка: мозговой центр, который только решал глобальные инциденты/проблемы. Скажу честно: на нашем предприятии дело оказалось малоэффективным. В итоге, пришли к мнению что первую и вторую линию поддержки могут взять на свои плечи ребята руки/ноги, которых посадили на телефоны, а вместо 4 операторов взяли 2 инженеров. Во первых, пусть немного, но все же выиграли по зарплатному бюджету, во вторых, среднее время решения заявок сократилось с 11 часов до 7, но стремимся к 3 (мечтать не вредно).

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

      Инженер – образ фантазийный, у которого всегда вертится очень много драйва в голове, поэтому не вижу смысла ставить узкие рамки для работы человека. Пусть инженер работает самостоятельно, бороздит просторы сети и серверной в рамках своих прямых и не прямых обязанностей в ИТ.

      • Мои комментарии чуть ниже 🙂 Неверно привязала ответ.

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

         

        • Про передачу ответственности между линиями поддержки вроде не упоминала. Тут немного другое, я пыталась обратить внимание Евгения на то, что ответственность за результат по заявке лежит не на первой линии, не на инженере (как было указано Евгением), а на конкретном сотруднике, назначенном ответственным за конкретную заявку. И этот самый сотрудник может быть на 1 линии, на 2-ой, а может, и на 3-ей. При этом правила передачи заявок между линиями никто не отменял 🙂 И да, не забываем про часто используемый KPI first line resolution.

    • Обладает необходимыми знаниями и навыками  в своей области ответственности

       

      ИМХО необязательное условие, зачастую сотрудники первой линии получают знания и навыки в процессе первоначального обучения, перед выходом "в бой".

      "Перед выходов в бой" вы имеете ввиду адаптацию и обучение? Тогда все правильно, просто требования к готовому работнику (адаптированному), а не при найме. Тут уже решать кадому самостоятельно – нанимат ьподготовленыхили учить, и там и там есть плюсы и минусы.

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

  • Давайте попробуем разобраться.

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

    Руки/ноги я бы не выделяла во вторую линию: они либо часть первой линии, либо линия 1+. У вас (взгляд со стороны) вырисовывались как раз 2 линии поддержки. 3 линия, скорей всего была, но в виде привлечения вендоров/внешних поставщиков.

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

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

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

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

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

      Не совсем. Очень долго (почти три года) шли к тому, чтобы бОльшая часть обращений решалась удаленно (не рекламы ради, перешли на radmin), что позволили на текущий день решать 60% обращений, не поднимая своего тела со стула. По оставшимся 40% уже катаются только два инженера, у которых есть автотранспорт. Да, немного дольше обрабатываются "вездные" заявки в силу расстояний, но конечная цель – сокращение таких заявок и увеличение количества решенных обращений по телефону с помощью radmin.

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

    Если по сути:

    1. Не хватает качества результативности: скорость, качество и т.д. Это очень важно для сотрудника поддержки.

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

    3. Не хватает качества убедительности. Общаясь с клиентами для достижения результата необходимо проявлять убедительность.

    4. И мое любимое – проактивность!

  • Пункты 2 и 10 плохо сровмещаются в одной голове.

  • Таких не бывает. Сферический сотрудник в вакууме.

  • 1 Пункт думаю хватит и 60%, сами на курсах говорили, что в ТП особенно1 уровень поддержки дикая текучка и малообученный персонал.

    9-10-11 Подходят скорее на начальника ИТ или ИТ менеджера.К тому же 9 пункт исключает 8)) Это просто психология. В рассылке ITIL Practitioner по моему немного другие были вещи)

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

    Если принять за объект рассмотрения чуть более суженный профиль, включающий в себя приём и общение с конечным пользователем, обеспечение среднего First Call Resolution порядка 60-70% (типовые массовые проблемы), я бы выделил следующие группы компетенций.

     

    Коммуникационные навыки и клиенто-ориентированность.

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

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

    Обучаемость и дисциплина.

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

    Способность к работе с большим и широким охватом информации.

    В данном случае как технологической – знание предметных областей поддержки, многих, пусть не на глубоком уровне, но зато с широким охватом и пониманием взаимовлияния. Так и возможность "помнить" большие объёмы проходящих заявок. Если первая линия работет не просто "прими и передай", то всё что не решится на первом звонке неплохо бы держать под присмотром. Пользователь-то прийдёт в случае чего опять на первую линия.

     

    Все остальные компетенции я б скорее отнёс к "старшим", "VIP-саппорту", 1,5-2й линии и тому подобному.

    Хотя несомненно для каждой конкретной организации приоритеты и профили могут быть свои.

     


Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Заполняя форму, вы соглашаетесь с нашей политикой обработки персональных данных и даете согласие на их обработку.

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM