Как выстроить работу отделов R&D и Customer Support, чтобы они друг друга не переубивали
В последнее время читаю про взаимодействие программистов и техподдержки, записала тезисы из отличного выступления по теме 🔥 Ссылку на видео как обычно оставлю в конце статьи.
Вводные данные из выступления:
- Техподдержка закрывает 3000–4500 обращений в месяц со средней оценкой 4.8 / 5.
- При этом существует целый пласт вопросов, с которыми надо ходить к другим отделам (продакты, программисты, девопсы).
- По числам это 500–100 обращений за двухнедельный спринт.
С одной стороны, это немного, с другой стороны — это постоянный поток обращений🙈 - В результате ребята наладили у себя режим обращения техподдержки с вопросами в другие отделы. Об этом ниже 👇
Шаг 1: Оптимизация трэдов в Slack
Изначальная проблема: программисты тратили много времени, чтобы понять, на что конкретно жалуются клиенты, так как сотрудники поддержки всегда по-разному описывали проблему (кто-то писал своими словами, а кто-то копипастил в чат всю простыню жалоб клиента).
Как решили: договорились, что саппорт пишет клиентские вопросы программистам по единой схеме:
- номер обращения
- адрес аккаунта, тариф
- цитата клиента
- что он делает
- что при этом видит
- что хочет видеть (ожидаемое поведение)
- контекст вопроса (настройки, техническая информация, пр.)
Пример:
Да, пункты немного “капитанские”, но это здорово увеличивает читаемость вопроса 👍
Из интересного:
- Поскольку Slack поддерживает трэды, удобнее всего оказалось писать по принципу “1 вопрос — 1 трэд”.
- Для вопросов в разные отделы сделали разные каналы (техподдержка ↔ интеграторы, техподдержка ↔ девопсы, техподдержка ↔ ядро и т.п.)
Шаг 2: Дежурства
Изначальные проблемы:
- Сотрудники техподдержки иногда писали вопросы в личку одному конкретному программисту вместо того, чтобы писать в канал.
- При этом в выделенном канале в Slack отвечали все программисты подряд. В результате стало сложно переключаться между спринтовыми задачами и ответами ребятам из поддержки, и возникла проблема, что на вопросы вообще никто не отвечает 😢
Как решили: организовали дежурство
- Дежурный назначался от каждого отдела (ядро, интеграторы, девопсы) на соответствующий канал в Slack.
- Дежурный назначался на спринт, если команда большая, и на неделю — если маленькая.
- В начале недели/спринта “старые” дежурные добивают свои хвосты, чтобы не оставлять их “новым” дежурным.
- Разработчиков, недавно пришедших в компанию, включали в график дежурства через 3–6 месяцев.
Логично, что в минусы дежурства можно записать доп.нагрузку, но есть и плюсы:
- это ответственность за продукт
- это хороший способ узнать продукт и вширь, и вглубь
- это понимание реальных проблем продукта у реальных пользователей
Ну и заодно на берегу договорились про правила обработки багов:
- Если клиент неправильно понимает логику, то надо объяснить, почему она именно такая.
- Мелкий баг (до 2 часов) фиксится в рамках дежурства.
- Трудоёмкий баг заводится в трекер на профильную команду:
✅ только если удалось понять первопричину проблемы;
✅ с понятным и ёмким названием задачи
✅ с фиксацией всего контекста проблемы (описание, логи, выявленная причина) - Баг не заводится, если не удалось понять причину проблемы, или не удалось его воспроизвести.
На этом этапе у всех, кто пробовали внедрить у себя дежурства (я в одной компании их внедряла 3 раза 🤪) возникает вопрос: как техподдержке избежать соблазна отдать задачу дежурному, чтобы он разбирался, вместо того, чтобы разбираться самим?
Докладчик рассказал, что они договорились с руководителем технической поддержки, что он на своей стороне будет следить за долей задач, которые уходят из саппорта программистам.
Шаг 3: PatrolBot в Slack
Чтобы ничего не терялось, в канал в Slack, куда техподдержка пишет вопросы програмистам, добавили специального бота, который мониторит динамику обработки обращений и подсвечивает нерешённые треды:
Из интересного: можно дополнительно делать графики нагрузки на дежурных.
Шаг 4: Уровни техподдержки
Изначальная проблема: иногда к дежурным программистам попадали вопросы, которые, по-честному говоря, техподдержка могла бы решить сама.
Как решили: команду саппорта разбили на уровни
- L1: пользовательские сценарии с нулевым намёком на техническую/инженерную составляющую
- L2: технические спецы, которые знают основы интеграций
- L3: инженерное крыло поддержки, способное влезть в интеграции клиента и поправить/доработать их.
Соответственно, сложные обращения клиента шли по уровням L1 → L2 →L3, часть вопросов решалась в отделе техподдержки и только действительно нерешаемые силами поддержки попадали к дежурным программистам.
Из интересного: договорились, что необязательно быть L3, чтобы прийти с вопросом к программистам, при необходимости к дежурному могут прийти сотрудники поддержки любого уровня.
Шаг 5: База знаний техподдержки
Докрутили следующие моменты:
- Назначили ответственных за базу знаний: периодически проверять поток вопросов клиентов и однотипно-повторяющиеся заносить в базу знаний.
- Каждые 3 месяца сотрудники уровня L1 проходят переаттестацию с учётом всех изменений и новых фич в продукте.
Шаг 6: Привлечение саппорта на внутренние митапы
В компании они проходили каждый месяц, в какой-то момент на них стали звать ребят из поддержки, чтобы они получали более полноценное погружение в инструменты и внутреннее устройство продукта:
- как работать с логами
- как деплоятся сервисы
- как устроены изнутри маркетинговые рассылки
Выводы:
- Постоянно налаживайте коммуникацию между отделами R&D и Customer support, это очень важно и всегда есть куда улучшаться.
- Договоритесь о формате обращения к дежурным, вовремя пополняйте базу знаний и по максимуму используйте ботов в Slack.
- В целом дежурство работает, но это не silver bullet 💪
Бонусные статьи в тему 🔥
- Bug Manager из техподдержки как адвокат клиентских проблем для разработчиков
- Как запустить внутренние митапы, от которых все выиграют
- 5 критериев того, что ваша база знаний работает неэффективно
- Knowledge-centered support
- Передача знаний в соревновательной форме через игру Capture the flag
- Agile в техподдержке
Ссылка на видео:
