Руководство для техподдержки

Структура службы поддержки клиентов: Как построить работу службы поддержки клиентов

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

В конце концов, ваши клиенты нуждаются в вас больше всего в те моменты, когда им требуется поддержка.

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

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

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

Определение KPI и стандартов поддержки

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

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

Как быстро ваша команда закрывает тикеты в службе поддержки? Сколько тикетов открываются повторно из-за некачественного решения?

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

Хотите начать работу с KPI? Прочитайте наше руководство о KPI для службы поддержки клиентов и о том, как их рассчитать.

Нанимайте правильных людей

Теперь, когда вы нашли хороший круг кандидатов, сколько из них вы должны нанять?

В большинстве случаев ответ можно найти с помощью простой математики.

Все, что вам нужно знать, — это размер вашей клиентской базы, темпы роста вашего бизнеса и некоторые контрольные показатели KPI, о которых мы уже упоминали (на данном этапе вы должны знать, каких KPI вы хотите достичь!).

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

Хотите узнать больше? Узнайте, как рассчитать необходимое количество сотрудников службы поддержки для вашей компании.

Создавайте подкоманды со специализированными навыками

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

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

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

Хотите узнать больше? Прочитайте наше пособие о различиях между службой поддержки клиентов и технической поддержкой.

Выберите правильную модель поддержки клиентов

Далее вам необходимо выбрать модель поддержки клиентов для вашей команды.

Выберете ли вы колл-центр? Может быть, внедрить стратегию самообслуживания?

В большинстве случаев, возможно, имеет смысл обратиться к цифровым решениям.

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

Заключительные размышления

На этом этапе вы будете готовы к созданию клиентской команды, настроенной на успех!

Однако не забывайте периодически отслеживать и корректировать свои KPI. В конце концов, ваша пользовательская база и потребности вашей компании будут меняться с течением времени.

Готовы приступить к работе?

---

Перевод материала подготовлен в рамках курса «Руководитель поддержки пользователей в IT».

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

• РЕГИСТРАЦИЯ НА ЗАНЯТИЕ •

Каждый раз, когда нам нужно было научить чат-поддержку видеть реальную проблему клиента, качественно ее решать и отвечать в дружелюбном стиле, мы писали книгу — чат-руководство. Если у вас есть задача развивать софт-скиллы сотрудников и улучшать клиентский сервис, вам она тоже понадобится. Рассказываем, что должно быть внутри такой книги и как ее написать.

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

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

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

Мы уже написали чат-руководства для Рокетбанка, Райффайзенбанка и европейского банка Finom. Рассказываем, как мы это делали и как написать свое.

Шаг 1. Спросить команду

Чтобы книга принесла пользу и не была чем-то навязанным, мы начинали с того, что спрашивали мнение команды поддержки (или всей компании, если она не очень большая) о том, что считать отличными показателями работы клиентского сервиса. Можно провести опрос в гугл-формах, устроить общий митап или поговорить лично с каждым сотрудником. Главное — получить ответы на следующие вопросы:

1. Кто такой клиент, или как его образно описать?
2. Какова роль поддержки в компании?
3. Какими качествами должен обладать сотрудник поддержки?
4. Что значит «решить проблему клиента»?
5. В каких ситуациях клиент чувствует себя довольным, счастливым?
6. Когда клиент бывает разочарован?
7. Что помогает саппортам донести мысль в чате ясно и конкретно?

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

Шаг 2. Сформулировать постулаты

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

Предположим, на вопрос «Что значит «решить проблему клиента»?» мы получили такие ответы:

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

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

Кроме того, есть еще несколько важных идей: 3) благодарность от клиента — подтверждение решения проблемы, 4) если возможно, нужно самому предпринять действие для решения проблемы, а не просить об этом клиента.

Записали? Это же упражнение нужно проделать для всех вопросов.

Шаг 3. Сфокусироваться на главном

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

Провести интерактив можно онлайн. Мы использовали для этого таблицу в Notion. Заголовки столбцов — вопросы, которые задавали команде в первый раз, внутри — перечисление всех постулатов, которые получились на предыдущем этапе. Примерно так:

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

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

Шаг 4. Раскрыть постулаты

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

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

Если команда сказала, что саппорт быстро находит решения проблемы, вежливый и интеллигентный, обращается с клиентом заботливо, но без панибратства, то можно метафорично представить его как Джарвиса из Железного человека. Или если главное качество специалиста поддержки — проницательность и умение с полувзгляда определить источник проблемы клиента и также быстро найти решение, то подойдет образ Шерлока Холмса.

Шаг 5. Добавить примеры

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

Шаг 6. Найти способ улучшать книгу изо дня в день

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

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

Здорово, если из книги можно сделать артефакт — сверстать и напечатать бумажные версии, придумать стикеры с постулатами, нарисовать красивый майндмэп с кратким содержанием. Любая активность будет полезной, потому что позволит каждый день актуализировать прочитанное и применять советы на практике. 

Как это сделали мы

Для команды Finom мы нарисовали иллюстрации и сделали печатную версию руководства:

• 
• 

В Рокетбанке у нас были собственные стикеры для телеграма с постулатами стиля:

---

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

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

Как организовать? Реализация техподдержки осуществляется по линиям, которых может быть до четырех. Конечно, все они нужны не всегда, поэтому необходимо отталкиваться от типа продукта и бизнес-ниши. Именно поэтому начинать нужно с постановки задач.

Суть технической поддержки

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

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

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

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

Задачи технической поддержки

Смысл деятельности саппорта будет понятен, если уточним его ключевые задачи:

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

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

Линии технической поддержки

Система технической поддержки выстраивается в организациях по-разному. Это зависит от сферы деятельности компании и применяемого типа менеджмента. Если говорить в целом, то можно выделить 4 линии (уровня) техподдержки.

Первая линия

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

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

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

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

Вторая линия

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

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

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

Сотрудники второй линии наделены следующими обязанностями:

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

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

Третья линия

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

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

Скачать
файл

Основными задачами специалистов третьей линии техподдержки являются:

• Фиксация запроса пользователя, переданного второй линией.
• Рассмотрение проблемы и установление факторов, ее повлекших.
• Создание плана действий по решению вопроса.
• Обеспечение необходимых мер технической поддержки и закрытие заявки (в случае достаточных компетенций для этого).

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

Четвертая линия

Речь идет о сотрудниках компании, производящей и распространяющей программное обеспечение и оборудование. Их задача — исправлять и приводить в порядок недочеты, ошибки и поломки, обнаруженные в поставляемых продуктах. Это отдел компании-производителя, который работает с заявками корпоративных клиентов.

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

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

Этапы создания службы техподдержки

Подготовить список оказываемых услуг и соглашение об уровне обслуживания (SLA)

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

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

Разработать структуру отдела и определиться с функциями специалистов по уровням

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

Аналогично устроена служба технической поддержки при обслуживании одновременно нескольких профилей: бухгалтерия, HR-отдел, АХО, IT и т.д. В этом случае за каждый отделом закреплена своя группа техподдержки. Это актуально и в ситуациях, когда саппорт работает для пользователей более чем одного цифрового продукта. Логика распределения различных отделов техничкой поддержки в каждой компании своя и следует региональному признаку, уровню сложности обращения, этапу обработки, тематике вопроса и т.д.

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

Разработать диалоговое окно для приема обращений

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

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

Прописать правила оказания услуг и подготовить инструкцию

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

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

Добавить KPI (ключевые показатели деятельности)

Контроль деятельности отдела техподдержки по ключевым показателям эффективности (KPI) является дополнительным инструментом мотивации сотрудников и наведения порядка.

Если речь идет о соглашении об уровне обслуживания (SLA), KPI контролирует соблюдение прописанных в нем договоренностей, качество работы с заявками, статистику повторных запросов, количество потраченного рабочего времени на решение того или иного вопроса и т.д.

Чаще всего KPI фиксирует следующие параметры:

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

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

Создать внутри команды техподдержки дружественную атмосферу взаимопомощи

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

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

Рекомендации для создания эффективной технической поддержки

• Правила оказания услуг персоналом техподдержки.

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

• Обучение.

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

• OLA (операционное соглашение об уровне сервиса) между линиями саппорта.

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

• Свободный доступ клиента к соглашению об уровне обслуживания (SLA).

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

• Сбор статистики.

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

Требования к специалисту технической поддержки

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

Функционал и основные требования к сотруднику на позицию специалиста отдела технической поддержки везде примерно одинаковые:

• Прием обращений, первичная обработка и регистрация в системе Helpdesk.
• Решение проблем пользователя и его информационная поддержка.
• Уверенное ориентирование в информации о продуктах и услугах компании.
• Развитые коммуникативные навыки, воспитанность и деликатность.
• Владение операционными системами Windows и Linux.
• Понимание логики обработки обращения (присвоение приоритетности задачи, классификация по тематике и т.д.).
• Навык работы с техническими документами.
• Опыт дистанционной работы.
• Навык дистанционной настройки сетевого оборудования (при определенной направленности работы компании).

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

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

Обращают внимание и на другие важные навыки:

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

В зависимости от уровня технической поддержки разделяют по компетенциям и ее сотрудников:

• Junior — специалисты первой линии технической поддержки. Они не обладают достаточной базой знаний, чтобы регулировать сложные вопросы. В обязанности Junior входят несложные поручения, как, например, прием и обработка заявок, их передача квалифицированным экспертам, контроль за ходом исполнения, выставление тикетов и т.д.
• Middle — специалист второй линии техподдержки. Обладает компетенциями для решения более сложных задач, в том числе административных.
• Senior — специалист третьей линии техподдержки. Руководят группой, обладают знаниями, достаточными, чтобы непосредственно заниматься серьезными проблемами пользователей.

Средства автоматизации для технической поддержки

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

Самые популярные системы автоматизации это: Омнидеск, Юздеск, IntraDesk.

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

Достоинства API:

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

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

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

Ошибки в работе технической поддержки

• Техподдержка как дополнительная нагрузка работника.

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

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

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

• Неудобная организация общения с клиентами.

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

• Не формируется список часто возникающих затруднений.

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

• Не ведется статистика запросов.

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

• Нет сбора информации по основным параметрам звонков.

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

• Нет системы Service desk, или выбран не самый подходящий вариант.

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

• Технической поддержкой занимаются работники кол-центра.

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

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

• Работа отдела технической поддержки без должного контроля.

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

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

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

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

Начало

Для любой компании, чей бизнес связан с пребыванием в онлайне, рост и развитие приводят к увеличению не только прибыли, но и нагрузки. И вот вы сталкиваетесь с необходимостью масштабировать инфраструктуру и наращивать ресурсы, потому что без этого надёжная и непрерывная работа проекта просто невозможна. Нужны люди, которые будут следить за его работоспособностью и оперативно реагировать на возникающие проблемы. Общепринятое определение для такой команды — «служба технической поддержки».

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

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

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

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

3 линии

Одна из первых проблем, с которой мы столкнулись — это, конечно же, нагрузка: в какой-то момент с ростом количества проектов одного дежурного перестало хватать на все возникающие алерты и задачи. Первое решение, которое приходит в голову, — увеличить количество дежурных! Но квалификация дежурного должна быть довольно высокой, поскольку возникающие инциденты разнообразны и некоторые требуют весьма нетривиальных скиллов. С другой стороны, к этому моменту у нас сформировалось достаточно большое количество типовых инцидентов и задач, а также различных инструкций к ним. Мысли об этом привели к выделению в нашей команде поддержки трёх линий.

Первая линия

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

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

Вторая линия

Если у вас есть набор типовых задач или инциденты, для которых давно уже известен порядок действий и написана инструкция, то внедрение второй линии техподдержки поможет в следующих направлениях:

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

Третья линия

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

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

Инструменты

База знаний

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

Всё это позволит увеличить желание сотрудников сначала искать ответы там, а не в гугле или личках у коллег.

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

Мониторинг

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

Бэкапы

У каждой уважающей себя системы, конечно же, есть бэкапы и настроен процесс резервного копирования… И тем не менее, в контексте работы техподдержки мы выработали для себя следующие требования:

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

Тикетная система

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

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

Сейчас на выбор есть большое количество как платных, так и опенсорсных тикетных систем; многие из них позволяют шаблонизировать задачи и процессы, строить различные диаграммы (всем известного Ганта, например) и использовать разнообразные метрики для формирования аналитики по процессам решения задач.

Каналы взаимодействия

Под каждый канал коммуникации можно выбрать один или несколько инструментов — или использовать один для всех. У себя мы выделяем следующие каналы:

Менеджмент задач

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

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

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

Менеджмент инцидентов

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

Также хорошей практикой является на регулярной основе анализировать статистику срабатывания алертов и на основе этого вносить корректировки в систему мониторинга.

Вместо вывода: 50 оттенков и 100 нюансов…

Организация службы техподдержки требует достаточно большого количества времени, ресурсов и не только. Обучение персонала, внедрение инструментов, адаптация процессов — всё это тернистый путь, полный скрытых грабель. На него можно вступить самостоятельно, получая зачастую сомнительное удовольствие от встречи с этими граблями и на собственном опыте разбираясь во всех оттенках и нюансах процесса организации службы техподдержки. Или можно довериться тем, кто уже разведал дорогу. У нас на поддержке находится более 400 разнообразных проектов, и мы всегда готовы принять к себе еще. Если же вы решили справиться собственными силами, мы всегда поддержим морально и проконсультируем по каждому шагу и этапу!

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

Отдел технической поддержки не должен зарождаться стихийно.

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

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

Процессный подход делит всю деятельность компании на отдельные систематические единицы — процессы.

Хотя в общем случае они могут влиять друг на друга через входные / выходные данные, управлять каждой такой логической единицей можно отдельно — в каком-то смысле применяется идея «Разделяй и властвуй».

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

Во-вторых, процессы необходимо выстраивать.

Хорошим методом для этого является известный цикл Деминга PDCA — plan-do-check-act или в переводе планирование-действие-проверка-корректировка (воздействие). Идея заключается в том, что не нужно с самого начала пытаться построить идеальную схему работы, например, процесса технической поддержки.

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

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

Важный момент заключается в том, что стадия check (проверка) не должна быть основана на субъективных наблюдениях — требуется выработать и применить методику объективной оценки.

В-третьих, надо распределить зоны ответственности каждого участника (отдела или сотрудника) в рамках выстроенных процедур процесса поддержки.

Принципы распределения ответственности в Вашей компании могут использоваться самые разные:

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

Эти и другие детали уже зависят от «внутренностей» компании и задач, которые ставятся в рамках процесса. Но идея состоит в том, что каждый сотрудник должен хорошо представлять зону своей ответственности и отвечать в её рамках. Кроме того, его работа должна оцениваться по ключевым показателям эффективности или KPI, разработанными для его зоны ответственности (о KPI чуть подробнее мы поговорим далее).

Единая точка контакта в тех.поддержке

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

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

В задачи «первой линии» обычно входит сбор максимального объема информации о клиенте и возникшей у него проблеме.

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

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

Схема KPI тех.поддержки

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

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

• KPI первой линии поддержки;
• KPI службы Help Desk;
• KPI службы качества и т.д.

В-шестых, несмотря на получение и обработку каких-то численных показателей (в рамках упомянутой выше схемы KPI), необходимо собирать отзывы от реальных клиентов.

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

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

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

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