Как мы построили распределённую команду Customer Support в Miro и с какими трудностями столкнулись

Я Полина Паршакова, Customer Support Team Lead в Miro. В статье расскажу, как мы построили распределённую команду поддержки с сотрудниками в Перми и Лос-Анджелесе, улучшили качество и скорость ответов, но по пути столкнулись со множеством трудностей.

За последние два года наша команда поддержки выросла с 7 до 18 сотрудников и стала распределённой.

Кроме первой линии, Customer Support Representative, которая принимает на себя все входящие заявки, и второй линий, Technical Support Engineers, которая занимается технически сложными вопросами, в команде появились новые роли: Head of Support, Support Learning & Development Manager, Community Manager и Operations Manager.

Вместе с ростом команды изменились процессы, наше восприятие друг друга и то, как мы помогаем пользователям. Всё это дало свои результаты: количество обрабатываемых тикетов в неделю выросло с 350 в 2018 году до 900 в начале 2020, а CSAT (Customer Satisfaction Score, индекс удовлетворённости клиентов) вырос с 84% до 97%.

В 2018 году вся команда поддержки работала из Перми. У нас были 9-часовые смены, с разными вариациями: до 18, до вечера и до полуночи. В ночное время мы не работали, вместо этого использовали Opsgenie от Atlassian для звонков дежурным в случае срочных тикетов.

У Miro было уже 2 млн пользователей и их количество регулярно росло. Большинство платных клиентов находились на западном побережье США, как и вся наша команда Sales и большая часть маркетинга. Получалось, что между нами 12 часов разницы. Это создавало неудобства для клиентов и наших коллег, которые не могли получить от нас быстрых ответов.

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

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

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

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

Единственным подходящим для нас вариантом стало создание распределённой команды. Так у нас появился первый сотрудник поддержки в Лос-Анджелесе!

Какие плюсы это принесло:

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

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

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

В итоге мы ввели принцип One remote — All remote. Он означает, что даже если один человек подключается удалённо, то остальные тоже подключаются удалённо, чтобы все находились в одинаковых условиях. Этот же принцип работает в пермском офисе, когда к нам в гости приезжают иностранные коллеги: если хотя бы один человек в комнате не говорит по-русски, все переключаются на английский язык.

Благодаря такому подходу встречи стали проходить комфортнее:

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

Когда у нас появился первый сотрудник поддержки в Лос-Анджелесе, мы начали проводить 15-минутные командные звонки в начале и в конце недели, чтобы делиться новостями. В теории это помогало чаще видеться с командой, давало возможность задавать вопросы и обмениваться мнениями. На практике всё быстро сломалось:

Мы начали искать другой способ, который бы помог держать всех в курсе и не пропускать ничего важного. И в результате создали отдельный новостной канал в Slack для команды поддержки — weekly_news. В нём можно легко найти все важные новости за неделю.

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

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

Приятным бонусом к weekly_news стал канал 0_days_without_memes — наша отдушина, где мы делимся мемами, шутками и прочей милотой.

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

В 2018 году, когда Support Team работала из Перми, у нас не было чёткого плана для первых месяцев работы сотрудников. Руководитель просто садился с новичком рядом и рассказывал ему всё, что знает. И это работало.

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

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

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

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

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

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

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

Условия распределённой команды подтолкнули нас к тому, чтобы начать записывать и категоризировать командные знания. В итоге мы создали базу знаний в Confluence: у неё есть владелец, при этом вся команда вносит свой вклад, помогая добавлять и обновлять инструкции.

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

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

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

Сейчас мы пришли к формату часовых 1:1 раз в две недели, с обязательной повесткой, которая обсуждается за сутки до начала встречи. Повестку мы ведём в Fellow, который с помощью шаблона позволяет при подготовке ко встрече выгружать из головы все нужны мысли и ничего не забывать, а при окончании встречи формировать список to-do с ответственным на каждый пункт.

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

За несколько лет построения распределённой команды я пришла к пониманию того, что команда счастлива, когда у неё есть:

Разумеется, впереди ещё много сложностей и вызовов, которые нам предстоит преодолеть. Возможно, расскажу о них через год ;-)

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

#customer_support #распределеннаякоманда #поддержкаклиентов