Привет! Я - Катя Леханова, менеджер проектов в компании iSpring.
В компании iSpring одна из главных ценностей - удовольствие клиента от использования наших продуктов.
В статье про двухуровневую техподдержку мы делились опытом построения процессов для решения сложных клиентских задач. При такой организации - саппортовые специалисты разделены на 2 группы: первая и вторая линия. Первая линия работает с обращениями клиентов, оформляет в задачи запросы, которые нужно решать разработчику. Эти задачи проходят контроль второй линии и передаются в дежурную команду через менеджера саппорта.
Такой процесс действует до сих пор и упрощает обработку поступающих запросов.
Вместе с тем, бизнес постоянно развивается, растет количество клиентов, растет количество активных пользователей LMS, возрастает и комбинаторика кейсов в использовании продукта.
Кроме того, мы развиваем направление on-premise решений платформы онлайн-обучения. Это означает, что аккаунты клиентов развернуты на клиентской инфраструктуре. Поддержка таких аккаунтов также требует внимания, и решением задач по обращениям от клиентов on-premise аккаунтов занимается дежурная команда.
И - вишенка на торте - амбициозные планы по выпуску новых фич, нового функционала, новых продуктов. Разработчики и QA-специалисты задействованы в этом развитии и, конечно, мы стремимся работать над обновлениями, а не править баги.
В итоге - рост клиентской базы, наращивание функционала, развитие новых решений привели нас в декабре 2023 года к увеличению числа обращений в саппорт.
Число задач в пуле превысило 50. Для сравнения, ещё в июле 2023 года в очереди на решение было 10 задач, которые можно было решить за 2-3 дня работы дежурного разработчика.
Нужны были решительные действия! Как мы с этим справились?
Первый шаг. Анализ.
Когда мы поняли, что пул открытых задач насчитывает более 50 тикетов (невиданная ситуация!) - собрали рабочую группу.
Цель для рабочей группы - проанализировать, что привело нас к текущей ситуации.
Подготовили развернутый отчет за весь год по кварталам. Вот те параметры, которые мы проанализировали тогда, и мониторим в динамике.
Количество обращений в саппорт;
Прирост активных пользователей продукта;
Прирост клиентов с on-premise решениями (на данный момент у нас более 100 действующих развернутых серверов);
Соотношение приоритетов в саппортовых задачах (blocker/critical/major);
Тип задач, которые решала дежурная команда;
Пропорция затраченного времени по типам задач;
Крупные релизы за год. При релизе большого продуктового апдейта затрагивается много модулей и возрастает вероятность допущения ошибки.
После анализа мы выявили причины возросшего количества клиентских запросов:
Увлекались быстрыми решениями проблем.
Пример. Обнаружили кейс: не подтянулась информация о прохождении курса у пользователя. У нас есть таск, после прогона которого решается конкретная ситуация. Выполняем таск, а задачу на исследование причины проблемы не завели, и в перспективе еще несколько клиентов обращаются с подобными запросами.Не было четкого регламента реагирования на алерты системы мониторинга ошибок.
Неоптимальная обработка событий в аккаунтах.
Второй шаг. Что делать сейчас?
Итак, причины были определены, но это не отменяло накопившегося пула саппортовых задач.
Решительное действие - дергаем стоп-кран!
Мы подключили всю команду продуктовой разработки и каждый разработчик взял по задаче. Понадобилось несколько дней и два релиза и мы разгребли все задачи.
Беспрецедентный случай, о котором мы вспоминаем до сих пор, спустя несколько месяцев. Мы не только решили саппортовые задачи, это было реальное сплочение команд.
А еще приоритизировали логи об ошибках из системы мониторинга, нарезали на задачи и запланировали оптимизации в продуктовых командах. На данный момент эти улучшения уже на проде.
Третий шаг. Совершенствование процессов. Support 2.0
Очевидно, требовалось решение выявленных причин, которое позволило бы адаптироваться к возросшим нагрузкам в дежурной команде.
Взяли в продуктовый план разработки задачи по оптимизации обработки доменных событий.
Создали новую схему работы дежурной команды разработчиков.
Область ответственности дежурного разработчика:
хотфиксы (быстрые правки, которые помогут клиенту прямо сейчас);
диагностика клиентских задач (дежурный вникает в суть задачи, заводит задачу на правку или исследование корневой причины);
рутинные задачи, не связанные с багфиксом. Например, подключение алиаса домена или выгрузки для системных аналитиков.
Дежурный тестировщик, помимо воспроизведения и тестирования саппортовых задач, исследует продуктовые логи и заводит задачи по обнаруженным аномалиям. Эти задачи также отправляются в продуктовую команду.
Настроили процесс мониторинга и диагностики алертов (дежурный реагирует на каждый алерт - оставляет комментарий в специальном чате):
а) если причину можно установить быстро, или она понятна сразу - описывает, что случилось.
б) если нужно исследовать причину - заводит задачу, которая отправляется в одну из продуктовых команд
Результат.
На 27% сократилось количество задач, поступающих в дежурную команду, благодаря оптимизациям и устранению ряда проблем на корню;
За 2024 год мы решили саппортовых задач на 24% больше, чем в 2023;
Возросла ответственность команд: если баг попадает на прод - он в итоге отправляется на решение в команду, ответствен/ную за фичу или сервис.