Техническая поддержка. Как это работает в Яндекс Плюс
Привет! Меня зовут Данил Глушков, я руководитель технической поддержки Плюса (Яндекс Фантех). В этом посте я расскажу вам о нашей работе.
Мы занимаемся решением технических вопросов, связанных с использованием сервиса (помощь в использовании функций и возможностей, а также решении технических проблем), в том числе являемся входной точкой для вопросов и запросов в продуктовую разработку.
Для затравки — немного «до» и «после».
Как всё работало до нас:
проблемы и вопросы клиентская поддержка относила в разработку через задачи в таск-трекере;
была единая дежурная очередь, где каждый дежурный в свободное от продуктовых задач время смотрел и решал репорты клиентской поддержки;
при наличии конкретной проблемы задача эскалировалась в общую очередь разработки для решения проблемы в рамках спринта;
если решение проблемы занимало 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 человек;
отдельное направления тестирования в технической поддержке;
занимаемся багхантингом на заказ и созданием кастомных процессов;
самостоятельно занимаемся автоматизацией процессов, сбором статистики и так далее;
самостоятельно разрабатываем и выводим в прод инструменты для сокращения времени решения, а также создаем их для клиентской поддержки, чтобы коллеги отвечали и решали вопросы наших пользователей быстрее
Про наших сотрудников
Мы стараемся дать развитие сотрудникам Плюса, но и всегда готовы рассмотреть кандидатуру извне. Но сейчас так получилось, что в команде 22 человека, и 20 из них — это бывшие сотрудники клиентской поддержки Плюса.
Еще двое не из Плюса — это я и руководитель команды операционного управления, мы с ней пришли в Плюс из Маркета.
Сейчас у каждой платформы разработки есть своя группа технической поддержки, внутри группы есть команды — технический саппорт и тестирование. Лидами данных групп являются наши самые первые сотрудники, которые в прошлом были как раз клиентским саппортом (тут хотелось бы сказать им отдельное спасибо за желания расти и развиваться).
Все сотрудники, пришедшие к нам из клиентской поддержки, довольны текущими проектами и задачами, а также демонстрируют высокую производительность и вовлечённость в жизнь нашего коллектива.
При этом в команде саппорта выработана и применяется стратегия непрерывного роста в зависимости от результатов и желаний самого сотрудника. Как только с точки зрения бизнеса нам необходимо расширять команды вне саппорта, мы даем возможность техническому саппорту расти дальше в проджекты, лиды или тестирование.
Выводы
В общем, вот так устроена техническая поддержка в Яндекс Плюсе. Я постарался подробно всё описать, но если у вас есть какие-то вопросы, то просто спрашивайте в комментариях.
