{"id":13506,"url":"\/distributions\/13506\/click?bit=1&hash=27fcb5113e18b33c3be66ae079d9d20078d1c30f1b468cdc86ecaeefa18446c2","title":"\u0415\u0441\u0442\u044c \u043b\u0438 \u0442\u0432\u043e\u0440\u0447\u0435\u0441\u0442\u0432\u043e \u0432 \u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0438? \u0410 \u0435\u0441\u043b\u0438 \u043d\u0430\u0439\u0434\u0451\u043c?","buttonText":"\u0423\u0436\u0435 \u043d\u0430\u0448\u043b\u0438","imageUuid":"2c16a631-a285-56a4-9535-74c65fc29189","isPaidAndBannersEnabled":false}
Карьера
Polina Parshakova

Как мы построили распределённую команду 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%.

Команда Miro Customer Support, лето 2019​

Первый зарубежный сотрудник поддержки

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

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

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

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

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

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

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

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

  • Настоящий 24/7 и спокойные ночи дежурного в Перми — теперь во всех срочных ночных запросах помогал разбираться коллега в Америке, у которого в это время был день.
  • Появился эксперт для американских офисов. Это стало настоящим спасением для Sales, Success и Marketing команд.
  • Наш продукт создан для распределённых команд, теперь у Support Team появился шанс на все 100% почувствовать на себе, с чем сталкиваются наши пользователи и другие команды в компании.
  • Новый культурный опыт благодаря тесному ежедневному сотрудничеству с американским коллегой.
  • Мощная прокачка английского для пермских сотрудников поддержки.

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

Командные встречи при 12-часовой разнице

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

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

Онлайн-встреча глазами удалённого сотрудника ​

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

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

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

Единый новостной канал для команды

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

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

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

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

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

Новостной канал команды поддержки в Slack​

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

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

Адаптация новичков вдали от своей команды

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

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

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

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

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

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

План адаптации нового сотрудника, созданный в Miro

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

Внутренняя база знаний

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

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

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

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

Часть структуры внутренней базы знаний команды поддержки​

Построение доверия на расстоянии

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

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

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

Рабочее окно Fellow​

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

Итоги: о чём важно не забыть при построении распределённой команды

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

  • Комфортные условия для всех на командных встречах: принцип One remote — All remote.
  • Простой удобный инструмент, чтобы быть в курсе всех важных новостей: канал в Slack weekly_news.
  • Место для самовыражения и фана: закрытый командный канал 0_days_without_memes.
  • Выстроенный процесс адаптации новичков, который прозрачен для всех участников и работает вне зависимости от того, находятся ли они в одном или разных офисах.
  • Актуальная внутренняя база знаний, у которой есть владелец.
  • Продуктивные встречи 1:1 с руководителем, с чёткой повесткой и достаточным временем для обсуждения важных тем.

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

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

0
6 комментариев
Написать комментарий...
Сергей Болисов

Казалось бы, все шаги довольно очевидные, но спасибо, что поделились опытом. Принцип «One remote — All remote» действительно очень важен)

Ответить
Развернуть ветку
Polina Parshakova
Автор

Спасибо за фидбек :) А какой у вас опыт с этим принципом? Может есть какие-то крутые модификации/апгрейды в добавление к нему?)

Ответить
Развернуть ветку
Сергей Болисов

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

Ответить
Развернуть ветку
Polina Parshakova
Автор

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

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

Ответить
Развернуть ветку
Racoon Lee

А в чём разница между распределённой командой и удалённой?

Ответить
Развернуть ветку
Sergey Shabalin

Думаю, в России ещё не договорились о терминах. С одной стороны, так могут называть команду, которая, например, работает из двух офисов. С другой стороны, могут называть команду, все члены которой работают из дома. По сути всё одно, remote.

Ответить
Развернуть ветку
Читать все 6 комментариев
null