Обучаем и формируем команду саппорта для проекта ААА-класса

«Один из самых надежных способов потерять веру в победу добра над злом и возненавидеть человечество — устроиться на работу в техподдержку. Саппорт — уж точно работа не для слабаков. Пока ваши коллеги генерят идеи и разрабатывают разные клевые штуки, вы в техподдержке проходите все круги ада. Вас будут обзывать полными придурками и криворукими недоумками, обвинять в том, в чем вы не виноваты, и просить о том, чего вы сделать не в состоянии.» ©

На написание данного материала меня сподвигло мелькание на Хабре/Меге статей о саппорте. До голов руководителей стала все чаще доходить светлая мысль о том, что кроме хорошего продукта к нему должен так же прилагаться и качественный сервис.

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

Как упоминалось выше, работа в поддержке — не для слабаков. И уж тем более не для слабаков обучение и формирование команды. Но вот только чаще звучат мнения о том, ЧТО должен делать саппорт, но я не сталкивался с материалами КАК его этому научить. В материале ниже я поделюсь практическим опытом обучения целого отдела для сопровождения ААА-проекта практически с нуля. В определенный момент я попал в жернова реструктуризации департамента и оказался единственным квалифицированным сотрудником в своей смене из восьми человек. Четверо потом ушли, поэтому в общей сложности за полгода я смог подготовить 12 (с учетом выбывших — 16) сотрудников, продолжая выполнять служебные обязанности на показателях 120-150% от «средних».

Зачем вообще нужен саппорт?

Перед тем, как начать набор, вам необходимо четко понимать, какие именно функции будут выполнять и какую аудиторию сопровождать эти люди.

Три основных модели саппорта:

• Call-центр
• Технически-консультативная поддержка
• Прямая поддержка продукта

С первыми знакомы все — это девочки, отвечающие по памятке сидя на телефоне. Второй вариант — то, с чем работал я. Телефонов не было, общались при помощи переписки. Подходит для по-настоящему крупных проектов, особенно игр. Третий тип — решение для бизнеса. Когда от действий саппорта зависят деньги и работа сотрудников со стороны клиента. С этими ребятами необходим весь возможный спектр средств связи, если вы хотите обеспечить ААА-сервис. Понимая собственную бизнес-модель вы должны корректно выбрать модель вашей службы поддержки. Первый и второй вариант — высокие нагрузки. Третий — фокусная работа на заказчика.

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

Набор команды

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

Помните:

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

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

Так же стоит делать оглядку на возраст коллектива. Мне в 21 год было очень неловко учить работе 27-31 летних мужчин, да они и не прижились особо при среднем возрасте в 22-23 года, который сформировался изначально.

Взрывной рост

Если вы столкнулись с ситуацией, что нагрузка на уже сформированный начальный костяк саппорта (3-4 человека), которые занимались поддержкой проекта изначально, превывает их штатные возможности хотя бы на 20%, то я могу вас поздравить — вы прощелкали вспышку.

Если саппорт работает «Впритык», то любое падение, патч, проблема или информационный повод, который заставит сообществой пойти жаловаться «разработчикам в саппорте», завалит службу поддержки с головой, т.е. время отклика вырастет с часа-двух до нескольких суток минимум из-за разовой нагрузки. На разгребание этого завала может уйти неделя, а то и месяц, что сразу же снизит качество предоставляемого Вами сервиса. Саппорт должен иметь запас прочности в 30-40% минимум, т.е. для людей выставлена почасовая оплата, а не норма «тикетов». Если саппорт сменный, то необходимо озаботиться дополнительными рабочими местами в кол-ве 30-50% от числа сотрудников. Многие захотят «подработать» в выходной на завалах и помочь себе и коллегам. Людям — деньги, вам — быстрое решение «завала». (актуально для схемы работы 2 через 2, 24/7).

Окей, значит, нам нужны люди. Так как же их подготовить?

Картина обучения

Я привык называть новичков котятами, потому что они слепые и беспомощные и постоянно мяукают, чтобы попросить помощи :). Поэтому предлагаю перенять эту классификацию. Итак. Вам понадобилось расширить отдел. Если вы это делаете планово — отлично, мы набираем по одному котенку на 3-4 матерых специалиста каждые два месяца и у нас мир, счастье и радуга.

Но что делать, если набор надо было начинать еще позавчера, а проснулись вы только сегодня, т.е. если Вам надо расширить команду примерно в 3-4 раза в кратчайшие сроки?

Много не всегда хорошо

Как показывает моя практика, один хорошо обученный сотрудник заменяет 5-6 новичков. Да, толпа из пяти котят может сделать вал в 400-500 тикетов, однако, большой их процент будет с возвратом (>50%), когда как из 100-150 тикетов специалиста вернутся 15-20% из них.

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

Специалистам на местах

Для спецов и руководителей отделов у меня есть отличная схема, сделанная мной когда-то для моих учеников. Она отражает в обобщенном виде полный цикл рассмотрения тикета в минимальное кол-во ответов. Понятно, что в жизни так не бывает, но от нее мы и будем отталкиваться в вопросах того, чему именно нужно учить сотрудника саппорта:

А теперь поехали.

Классификация тикета

Работа начинается с определения того, с чем же пришел пользователь и что ему от саппорта надо. Это может показаться простым на первый взгляд, но четкое понимание типа тикета приходит только с опытом (>5000 обработанных заявок).

Вопрос или Проблема?

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

Цель саппорта: разжевать и объяснить одним письмом.

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

Проблема, в свою очередь, может быть вызвана как действиями пользователя, так и сбоями внутри продукта.

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

• Причины сбоя;
• Уведомленность саппорта о данной ситуации;
• Примерные сроки решения.

Если проблема локальная, а не глобальная, то она решается в штатном порядке «Пуск — панель управления — и т.д.» о чем я расскажу отдельно.

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

Идем дальше.

Оценка информативности тикета

Я часто сталкиваюсь с тем, что саппорт делает неправильные выводы исходя из информации в первом обращении. В первую очередь котят необходимо научить, что если при прочтении тикета возможны разночтения проблемы, то необходимо получить уточняющую информацию. Зачем это делать? Неправильно оценив ситуацию можно начать решать не ту проблему, не в том порядке, в каком нужно пользователю или вообще отказать ему в обслуживании, когда саппорт в состоянии помочь. Именно поэтому каждый сотрудник должен задаваться вопросом: «В чем проблема пользователя конкретно?» и только получив на него однозначный ответ приступать к ее решению.

Лишние запросы информации

Болезнь всех новичков и большинства саппортов как таковых. Если вы хотите оказывать сервис уровня ААА, то будьте готовы к тому, что работать должен саппорт, а не пользователь, само собой, если это возможно. Получение данных об аккаунте, если используется единая форма авторизации, просмотр истории операций, тестирование своими силами в попытках вопроизвести — все это должен делать саппорт. И только после сбора максимального кол-ва информации собственными каналами давать ответ пользователю. Если вы будете просить очевидную информацию, или то, что могли бы сделать сами, причем заготовками (о них скажу отдельно), знайте, ваша служба поддержки — отстой.

Вторым немаловажным фактором является запрос инфомрации в один подход. Одно уточняющее письмо пользователь может понять, но когда с ним разводят километровую переписку с вопросами в одну строчку, вместо одного конкретного письма — это не ОК. Котята часто грешат тем, что задают один вопрос из трех, в среднем. Этому необходимо учить как молитве: хорошенько подумать, что тебе необходимо, чтобы решить проблему сразу.

Но дьявол кроется в деталях. Если это техподдержка и она запрашивает сразу три вида логов, отчетов, просит прислать результаты тестов и связаться с провайдером — это провал еще худший. В любых действиях должна быть последовательность. Не бойтесь говорить пользователю, зачем вы просите у него DxDiag, или дампы памяти, поясните, в каком месте вы пытаетесь локализировать проблему. Если саппорт промахнулся, а так бывает — скажите, что отчеты не выявили аномалий и вам нужна еще информация. Пользователь должен понимать ЗАЧЕМ он все это делает, должен чувствовать сопричастность. Если вы держите человека в курсе решения его проблемы, то он будет только стараться вам помочь в 90% случаев, а это огромный плюс к лояльности с его стороны и стороны его окружения, которое узнает за стаканом пива, какая у вас внимательная и заботливая служба поддержки. Сухие рекомендации и требования без пояснений «зачем это нужно» вызывают негатив. Новичкам это необходимо объяснять с первого и до последнего дня обучения.

Макросы

О них кратко. Макрос (готовый ответ) — это зло. Нельзя давать новичкам готовые ответы, т.к. они используют их некорректно. Все должно писаться руками, пусть вопросы и однотипные. Только после того, как человек изучит все нюансы через постоянное изложение одной и той же проблемы разными словами, можно позволять пользоваться заготовками, которые обязательно должны редактироваться по ситуации. «Автоматические» ответы шаблонами — убийца лояльности аудитории. Не скатывайтесь до этого и молодежь не приучайте.

Работа с котятами

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

Почему? Был у меня ученик по имени Валера, молодой парень с татухами и в кепке. Я тратил много сил и времени на его обучение, давал советы, проверял его тикеты и бил VGA-кабелем за косяки отчитывал за ошибки. Он прошел испытательный срок, но еще 2 месяца я продолжал работу с ним, т.к. не заметил этого момента. И вот, в один прекрасный день он стал помогать другим вместе со мной, и помогать правильно, сняв с меня нагрузку по двум котятам. Специалист, подавая своими действиями пример заботы о новичках рано или поздно вырастит из одного из них себе толкового помощника, и ни в коем случае не конкурента. Если же бросить человека на произвол судьбы после испыталки, то можно и не дождаться от него инициативы в передаче своего опыта другим, который он получил от вас. Человек не поймет, что он готов учить других, если не столкнется с тем, что на все вопросы, которые он хотел вам задать, он, в итоге, и сам знает ответ, только не сразу его вспомнил.

Гласность

Хорошим приемом является громкое объяснение кому-то одному проблемы, с которой он столкнулся. Я часто видел, как мои котята переговаривались потом между собой на курилке, вспоминая именно такие моменты. Нельзя объяснять что-то только одному человеку лично, чтобы другие не слышали. Ошибаться — нормально. Недопустимо формирование культа «безгрешности», потому что вы просто погибнете под завалом однотипных вопросов от разных людей, если вкрадчиво будете объяснять индивидуально каждому. Имея же единый поток информации, пусть и фоновый, молодые сотрудники получают почву для обсуждений проблемы между собой. После же, может сформироваться «делегация», которая попросит разрешить спор, что было правильно, а что нет. Я считаю подобный подход более эффективным, чем персональные беседы. Он позволяет доносить информацию до всех и сразу. Кто не знал — узнает, кто знал — повторит.

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

Подводя итоги

Стоит ясно понимать, что если вы планируете взрывной рост своего саппорта, то у вас должен быть крепкий специалист в наличии, готовый делиться опытом. От себя я крайне не рекомендую женщин как транслятор информации для молодых парней и нет, я не сексист (картинка с крутой рубашкой сюда бы подошла). Из-за присущего им, в основной массе, более высокого уровня ответственности, со временем необходимость постоянно отвлекаться от своих прямым обязанностей на новичков может перерасти в неприязнь к последним или конфликт, особенно, если они получат выговор, что не справляются. Так же не стоит принуждать к проведению обучения интровертов и людей замкнутых — помощь сквозь зубы поможет новичку слабо, а вы выбросите деньги на ветер на его содержание, спецом он станет врятли.

Если вы хотите матерую команду из опытных сотрудников, то с новичками придется параллельно работать индивидуально и со всеми сразу. На формирование самостоятельного сотрудника уходит от 6 до 12 месяцев, если проект сложный, поэтому нельзя рассматривать закрытие испытательного срока как «билет в жизнь» и «теперь ты сам по себе». Это не только не позволит сформировать команду, но и остановит развитие всех сотрудников отдела, в том числе и опытных. Причем тут опытные? Вы не представляете, как бодрят мозг ^[1] каверзные вопросы :).

Взрывной рост численности сотрудников — испытание для уже набранного персонала. Все же крайне рекомендую составить бессрочный план набора и добирать по 1-2 человеку в месяц «на вырост», пока не достигнете 60-70% загруженности в тихий, или средний период. Это убережет вас от многих проблем, с которыми мне пришлось когда-то столкнуться.

P.S. Данный материал опубликован при поддержке моих друзей из IlkFinKom, активно ведущих свой блог на Хабре ^[2]. В ближайшее время они планируют альфа-тест своего проекта VirCities и приглашают всех желающих:

^[3]

С Уважением.

Автор: ragequit

Источник ^[4]