Привет! Я - Катя Леханова, менеджер проектов в компании iSpring.

В компании iSpring одна из главных ценностей - удовольствие клиента от использования наших продуктов.

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

Такой процесс действует до сих пор и упрощает обработку поступающих запросов.

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

Статистика по числу активных пользователей аккаунтов iSpring Learn LMS по годам 2022, 2023, 2024

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

И - вишенка на торте - амбициозные планы по выпуску новых фич, нового функционала, новых продуктов. Разработчики и QA-специалисты задействованы в этом развитии и, конечно, мы стремимся работать над обновлениями, а не править баги.

В итоге - рост клиентской базы, наращивание функционала, развитие новых решений привели нас в декабре 2023 года к увеличению числа обращений в саппорт.

Число задач в пуле превысило 50. Для сравнения, ещё в июле 2023 года в очереди на решение было 10 задач, которые можно было решить за 2-3 дня работы дежурного разработчика.

Нужны были решительные действия! Как мы с этим справились?

Первый шаг. Анализ.

Когда мы поняли, что пул открытых задач насчитывает более 50 тикетов (невиданная ситуация!) - собрали рабочую группу.

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

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

Количество обращений в саппорт;

Количество обращений в саппорт за 2023 год

Прирост активных пользователей продукта;
Прирост клиентов с on-premise решениями (на данный момент у нас более 100 действующих развернутых серверов);
Соотношение приоритетов в саппортовых задачах (blocker/critical/major);
Тип задач, которые решала дежурная команда;
Пропорция затраченного времени по типам задач;
Крупные релизы за год. При релизе большого продуктового апдейта затрагивается много модулей и возрастает вероятность допущения ошибки.

После анализа мы выявили причины возросшего количества клиентских запросов:

Увлекались быстрыми решениями проблем.
Пример. Обнаружили кейс: не подтянулась информация о прохождении курса у пользователя. У нас есть таск, после прогона которого решается конкретная ситуация. Выполняем таск, а задачу на исследование причины проблемы не завели, и в перспективе еще несколько клиентов обращаются с подобными запросами.
Не было четкого регламента реагирования на алерты системы мониторинга ошибок.
Неоптимальная обработка событий в аккаунтах.

Второй шаг. Что делать сейчас?

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

Решительное действие - дергаем стоп-кран!

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

Беспрецедентный случай, о котором мы вспоминаем до сих пор, спустя несколько месяцев. Мы не только решили саппортовые задачи, это было реальное сплочение команд.

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

Третий шаг. Совершенствование процессов. Support 2.0

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

Взяли в продуктовый план разработки задачи по оптимизации обработки доменных событий.
Создали новую схему работы дежурной команды разработчиков.

Область ответственности дежурного разработчика:

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

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

Настроили процесс мониторинга и диагностики алертов (дежурный реагирует на каждый алерт - оставляет комментарий в специальном чате):

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

Результат.

На 27% сократилось количество задач, поступающих в дежурную команду, благодаря оптимизациям и устранению ряда проблем на корню;
За 2024 год мы решили саппортовых задач на 24% больше, чем в 2023;
Возросла ответственность команд: если баг попадает на прод - он в итоге отправляется на решение в команду, ответственную за фичу или сервис.

Support в iSpring. Как мы непрерывно улучшаем процессы при изменяющихся нагрузках