Cоздать службу поддержки с нуля: почему эмпатия и tone of voice важнее ИТ-систем

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

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

Определите, нужна ли вам служба поддержки и какие задачи перед ней стоят

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

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

Читайте по теме: Служба поддержки клиентов в EdTech: на что обратить внимание при найме и как выстроить работу такой команды

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

Найдите свой tone of voice и сформируйте команду

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

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

В работе над tone of voice нам очень пригодилась книга Максима Ильяхова «Новые правила деловой переписки». Это помогло нам задать правильный тон ответов, с упором на уважение к каждому человеку.

Читайте материал Шесть правил деловой переписки от специалиста по цифровому этикету — как эффективнее общаться в почте и мессенджере

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

После определения tone of voice можно приступить к формированию команды саппорта. Многие делают ставку на ИТ-инфраструктуру, покупают дорогие системы и пишут подробнейшие инструкции (которые очень быстро устаревают после начала работы). Но на самом деле большинство вопросов, особенно на начальном этапе, вытягивают люди. Поэтому очень важно, чтобы сотрудники обладали качествами, которые отвечают выбранному стилю общения.

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

Техническая часть: что необходимо

ИТ-инфраструктура — важная, хотя и не ключевая часть системы поддержки пользователей. Когда служба состоит из одного сотрудника, нет смысла покупать дорогие Service Desk системы — достаточно файла в Excel. Понятно, что с ростом количества заказчиков и команды придется перейти на специальный софт — мы используем Jira Service Desk.

Но можно подобрать и отечественные аналоги:

1. «Юздеск»,
2. Naumen Service Desk.

Кроме этого необходимо:

• составить регламенты работы с обращениями

В них описывается, что делает сотрудник после поступления по одному из каналов (почта, чат или телефон) запроса от клиента.

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

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

• сформировать базу знаний о продукте

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

• определить SLAService Level Agreement — соглашение об уровне обслуживания — стандарты нашей работы

Как я уже сказала, в течение максимум 30 минут мы должны отреагировать на обращение.

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

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

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

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

Все это в совокупности позволило снизить эмоциональный накал и перевести разговор в конструктивное русло.

Читайте также:

Шесть главных болей клиентского саппорта

Как организовать мультиязыковую поддержку клиентов

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

1. подготовкой инструкций по работе с системой,
2. описанием нового функционала,
3. разбором самых сложных обращений.

Фидбек и постоянная работа над качеством

Создание и запуск службы — это только полдела. Если саппорт не будет получать обратную связь от пользователей, это сильно уменьшит его полезность. Поэтому мы всегда просим оценить качество ответов (и около 20–30% обратившихся это делают), а потом разбираем комментарии.

Средняя оценка нашей работы составляет от 4,5 до 4,8 баллов из 5, в зависимости от университета.

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

По итогам дополняем базу знаний и корректируем регламенты.

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

Итак, для формирования саппорта вам нужно:

1. Определить, необходима ли вам такая служба и, если да, — какие задачи перед ней стоят.
2. Выбрать стиль работы службы — tone of voice. 
3. Сформировать команду под ваш tone of voice.
4. Выбрать софт для работы — это может быть, например, Jira Service Desk. 
5. Прописать регламенты работы с обращениями.
6. Создать базу знаний по вашему продукту для ответов на обращения.
7. Установить стандарты работы службы — SLA.
8. Регулярно проводить опросы клиентов о работе службы и встречи сотрудников для разбора сложных задач.

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

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

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