Колонки

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

Колонки
Глеб Синев
Глеб Синев

Ведущий продакт-менеджер в Mantika

Анастасия Удальцова

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

Глеб Синев, ведущий продакт-менеджер в Mantika, рассказал, как выстроить совместную работу команды инженеров и отдела поддержки при развитии основного продукта.

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

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

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

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

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


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

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

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


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

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

Направление Было (дни) Стало (дни) Скорость работы
Кастомизация продукта для заказчика на стороне фронтенда: дизайн, верстка  3–6 1–3 +50%
Реализация на стороне бэкенда индивидуального запросы  <10 1–4 +70%
RnD: тестирование кастомизированных под конкретный проект алгоритмов для повышения продуктовых и финансовых метрик 7–12 <4 +60%

 

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

Важно научиться понимать ценность и вес каждого обращения. Не только чтобы соблюсти 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

Подписывайтесь на наш Telegram-канал, чтобы быть в курсе последних новостей и событий!

Нашли опечатку? Выделите текст и нажмите Ctrl + Enter

Материалы по теме

  1. 1 Перейти от проекта к продукту в IT: когда и зачем это нужно
  2. 2 Ловушка для продакт-менеджера: стоит ли идти в компанию на стадии цифровой трансформации
  3. 3 Как компания хотела автоматизировать процесс, но запустила новый продукт: история роста и масштабирования
  4. 4 Что меняется в стратегии продвижения в кризис и какие задачи решает продуктовый маркетолог
  5. 5 Кем быть, чтобы стать продакт-менеджером: карьерный путь и нужные навыки