Организация поддержки в SaaS-продуктах: как не потерять время и мотивацию команды

Поддержка пользователей — одно из ключевых ответвлений в общей структуре использования SaaS-продукта в IT индустрии. Но даже если продукт идеальный, у пользователей возникнут вопросы или уточнения. 

На этом этапе возникает развилка, как лучше организовать этот процесс:

1. бесконечно нанимать людей в штат, залить решение задач человеческим ресурсом. 
2. выстроить систему, в которой поступающие задачи будут рассматриваться быстро, системные проблемы — исправляться, а повторяемые запросы на определенный функционал — обрабатываться продуктовой командой.

Помните закон Парето? Скорее всего, ваши команды менеджеров и инженеров работают так, что 80% задач выполняются без проблем. Но оставшиеся 20% продолжают копиться, откладывание их решения начнет генерировать негативную обратную связь. Чаще всего они занимают больше всего времени и наиболее критичны для покупателей и партнеров.

Читайте по теме:

«Учитесь расставлять приоритеты»: как руководителю управлять временем

7 методик, чтобы находить выход из сложностей — на случай кризиса и резких изменений

Результат для компании одинаковый: недополученная или потерянная прибыль и снижение репутации. 

С помощью решений, о которых я рассказываю в колонке, нам удалось добиться таких показателей:

Поддержка — не только про быстрое закрытие задач 

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

RB.RU проводит третью ежегодную Премию по цифровой трансформации для бизнеса — RB Digital Awards 2023. Участие в премии бесплатно. Подать заявку можно на сайте.
Церемония пройдет при поддержке CLOUD и ГК «Самолет»

Верхнеуровнево можно разделить все обращения на два типа:

1. Локальная проблема: затрагивает одного пользователя или небольшой процент аудитории;
2. Системная проблема: затрагивает значительную долю аудитории.

Шаги работы на первом этапе по каждому типу будут похожими: 

• Убедиться, что проблема существует;
• Локализовать ошибку;
• Предоставить заказчику сроки решения. 

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

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

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

Приоритеты

Существует несколько известных фреймворков, по которым обычно делается оценка приоритетов:

• RICE от компании Intercom;
• модель Кано;
• ICE.

В продуктах, над которыми работал я, лучше всего подходили ICE или WSJF — либо кастомная матрица по ключевым параметрам продукта. 

Оптимальная стратегия: 

1. протестировать разные варианты, 
2. оценить требуемое время, 
3. обсудить с командой,
4. после — итерационно внедрять изменения.

Определение точек роста

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

Хорошая практика — категоризировать все типы обращений, от базовых «ошибка» и «фичреквест» до специфических параметров конкретного продукта. Взгляд на каждый тип задач через призму воронки и анализ входящих обращений помогает закрыть несколько направлений:

• Влияние на роадмап: можно использовать этот канал коммуникации со своим покупателем, чтобы определить, чего не хватает аудитории и на что обратить внимание;
• Выделение проблемных зон продукта: если обращения часто повторяются, затрагивают конкретную часть (например, «не понимаю, как зарегистрироваться») — это явный сигнал, что что-то работает не так и надо подумать над системным решением;
• Оценка качества службы поддержки и менеджмента: как меняется количество, темы, повторяемость входящих обращений за определенный период?

Читайте также:

Топ-4 ошибки при построении команды и управлении ей в кризисный период

3 правила коммуникации и управления в новой реальности

Чтобы улучшить процессы по последним двум пунктам, можно выделить несколько направлений для работы:

1. Сократить время на поддержку за счет разработки внутреннего инструментария;
2. Обучить первую линию поддержки (это могут быть сейлзы, аккаунт-менеджеры, выделенная команда) и составить инструкции;
3. Настроить инструменты для работы с потоком задач.

Что делать с этим на практике?

Чтобы саппорт стал быстрее, мы с командами инженеров и менеджеров разработали и прописали:

• Внутренний инструментарий для повторяющихся задач

В идеальной системе это должно стать частью продукта, плюс это хорошее решение как быстрый фикс.

• Конкретные и подробные инструкции для всех коллег, которые работают на входящих сообщениях
• Описание терминологии

Иногда в компанию приходят классные сейлз- и аккаунт-менеджеры, при этом они не всегда знакомы с IT-терминологией; плюс уже сейчас разные команды используют разные названия для одних и тех же явлений. Единый документ помогает хорошо разобраться.

• Мануал по использованию продукта
• FAQ с техническими деталями
• Разделение рабочей среды по сложности и приоритетам задач
• Описание рабочего процесса
• Чек-листы решения задач из определяемых категорий и для различных проблем
• Выделение процесса поддержки в отдельный интерфейс

Декларация, что любая проблема, требующая больше ~15 мин для исследования, должна фиксироваться менеджером в виде задачи. 

Это нужно, чтобы лучше понимать:

1. куда тратится больше ресурсов, 
2. на что уходит время, 
3. где слабые места. 
4. Снять когнитивное напряжение.

• Регламенты и шаблоны для задач по саппорту

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

• Изменение подхода к саппорту

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

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

При внедрении процесса с такими компонентами команды получали:

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

А процесс становился прозрачным и понятным каждому сотруднику.

Фото на обложке: Shutterstock / Gorodenkoff