Pull to refresh

Техническая поддержка. Как это работает в Яндекс Плюс

Level of difficultyEasy
Reading time6 min
Views10K

Важно! Данная статья про команду которая никак не взаимодействует с пользователями, даже в рамках тикетов. Этим занимается клиентская поддержка и в данной статье речь о ней не идет.

Привет! Меня зовут Данил Глушков, я руководитель технической поддержки Плюса (Яндекс Фантех). В этом посте я расскажу вам о нашей работе. 

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

Для затравки — немного «до» и «после».

Как всё работало до нас:

  • проблемы и вопросы клиентская поддержка относила в разработку через задачи в таск-трекере;

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

  • при наличии конкретной проблемы задача эскалировалась в общую очередь разработки для решения проблемы в рамках спринта;

  • если решение проблемы занимало 1–2 часа, это всё решалось в рамках дежурной очереди.

Какие тут были проблемы:

  • слишком большие SLA для решения обращений;

  • большой бэклог задач;

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

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

  • улучшение коммуникации между клиентской поддержкой и разработкой;

  • создание базы знаний, а также описание решения типовых проблем;

  • согласование SLA обслуживания;

  • организация процесса работы с бэклогом со стороны разработки;

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

  • создание пути развития для сотрудников клиентской поддержки.

Что сейчас:

  • обработка всех обращений происходит на стороне технической поддержки;

  • разделили поток на количество платформ с последующим разделением на продукты и сервисы:

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

Какие плюсы получили сразу же после подключения технической поддержки:

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

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

  • снижение поступающих задач и вопросов от клиентской поддержки — за первые 7 месяцев их доля сократилась до 50%;

  • начали удерживать согласованные SLA в рамках допустимой погрешности в 10%.

А теперь давайте подробнее.

Чем именно мы занимаемся

Коротко расскажу, кто мы и чем занимаемся. У нас три команды:

  • команда технической поддержки;

  • команда регресс-тестирования;

  • команда операционного управления.

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

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


Спойлер — этот функционал стал отличным вектором развития для саппортов. 

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

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

В чем особенность нашей команды

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

Свежий пример

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

Это довольно серьёзная разница, притом выгодная для Плюса.

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

Ещё мы занимаемся оптимизацией процессов. Мы берем этот процесс к себе, смотрим, как всё работает, ищем, где и что можно ускорить или автоматизировать. Где-то пишем руками новые инструменты и скрипты, чтобы всё работало лучше. Причём параллельно сразу описываем это в документации (то есть пишем с нуля и документацию под нужный процесс). Само собой, со скриншотами и прочим — в общем, делаем всё, чтобы человек, который впервые этого касается, смог без проблем разобраться во всём. Де-факто это такие кастомные процессы «под ключ».

И еще один пример. У Яндекса есть Трекер — это по своей сути таск-менеджер. Инструмент не только внутренний, но и внешний в рамках сервиса Yandex Cloud (возможно, кто-то из вас им пользуется). Так вот, наша команда занимается ещё и автоматизацией Трекера там, где разработчикам, менеджерам и нам, хотелось бы что-то допилить в этом плане, но Трекер из коробки такие хотелки не предполагал. Кастомная статистика, автоматизация работы с задачами в рамках нашего сервиса – это к нам. 

Итоги

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

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

  • Сократили накопленный бэклог на начало 2022 года в ноль.

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

  • Начали собирать статистику и считать SLA. 

  • Организовали процесс, при котором клиентская поддержка может задавать любые вопросы о работе Плюса.

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

Итоги 2022 года в целом

  • По итогу 2022 года сэкономили 41 рабочий день разработки.

  • За 2022 год было решено 1931 обращение.
    Средний процент эскалации в разработку составлял ~30%.

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

  • Превратились из эксперимента с одним человеком в полноценную службу со штатом в 5 человек.

  • Поддерживаем отдельные команды, но не платформы целиком.

Итоги 2023 года

  • Две линии поддержки в каждой команде — L1 и L2.

  • Поддерживаем все продуктовые платформы разработки + часть продуктовых и операционных задач.

  • В команде 10 человек, которым не всё равно, но самое важное — 8 из них это бывшие сотрудники клиентской поддержки Плюса.

  • 15 000 решенных обращений и 93% решения технической поддержкой.

  • В 2 раза сократили SLA обработки обращений к началу Q4 (было 8 часов, сейчас это ~3,5 часа)

Итоги первых 6 месяцев 2024-го года

  • команда из 20 человек;

  • отдельное направления тестирования в технической поддержке;

  • занимаемся багхантингом на заказ и созданием кастомных процессов;

  • самостоятельно занимаемся автоматизацией процессов, сбором статистики и так далее;

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

  • держимся на уровне самостоятельного решения выше 90%. Цифры постоянно меняются, но стабильно это 6-8 % эскалации от общего потока в ~1000 обращений (только саппорт, без учета дополнительных функций)

Про наших сотрудников

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

Еще двое не из Плюса — это я и руководитель команды операционного управления, мы с ней пришли в Плюс из Маркета. 

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

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

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

Выводы

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

Tags:
Hubs:
Total votes 24: ↑17 and ↓7+19
Comments13

Articles