Как поддержке подготовиться к релизу и не умереть на запуске
Устали узнавать об обновлениях от внешних пользователей? Проклинаете вечер пятницы?
В истории будут три действующих лица:
🚀 Релиз — это новая фича в приложении, рекламная рассылка со скидками, изменение в ценовой политике, запуск реферальной системы, в общем, всё, что меняет пользовательский опыт и может вызвать вопросы у клиентов.
👫 Смежники — это все, кто забывают рассказать о релизе саппорту: менеджеры, разработчики и маркетологи.
💌 Саппорт — операторы и их руководители, которые на разных уровнях будут отбивать релиз по всем каналам связи. В этой статье мы говорим о саппорте не как о конкретном сотруднике, а обо всём отделе поддержки.
По ITSM релиз проходит следующие этапы:
1. Планирование (planning)
2. Сборка (building)
3. Тестирование (testing)
4. Подготовка (preparing)
5. Деплой/доставка (deploying)
6. ⬅️ Вот здесь поддержка обычно узнаёт об обновлениях
На первом шаге мячик ответственности будет на стороне смежников, потому что на стадии подготовки релиза только они обладают всей информацией о том, что выпускают. Пока он посередине:
1. Планирование (planning)
2. Сборка (building)
3. Тестирование (testing)
4. Подготовка (preparing)
5. Деплой/доставка (deploying)
6. ⬅️ Вот здесь поддержка обычно узнаёт об обновлениях
На первом шаге мячик ответственности будет на стороне смежников, потому что на стадии подготовки релиза только они обладают всей информацией о том, что выпускают. Пока он посередине:
Шаг 0. Сядьте за стол переговоров
Подготовка поддержки начинается вообще не в поддержке. Как известно, к релизу невозможно успеть всё вовремя, поэтому продуктовые команды обычно в мыле: непонятно, откуда появляются задачи, как берутся в работу, как выполняются и уходят на прод, какими инструментами и на каких средах выполняется тестирование, кто и как будет фиксить критические проблемы… Такая категория как «а что саппорты будут отвечать на вопросы юзеров» регулярно вылетает у всех из головы, поэтому поддержка узнаёт о релизе по факту релиза.
На этом этапе нужно договориться о двух принципиальных вещах:
Подготовка поддержки начинается вообще не в поддержке. Как известно, к релизу невозможно успеть всё вовремя, поэтому продуктовые команды обычно в мыле: непонятно, откуда появляются задачи, как берутся в работу, как выполняются и уходят на прод, какими инструментами и на каких средах выполняется тестирование, кто и как будет фиксить критические проблемы… Такая категория как «а что саппорты будут отвечать на вопросы юзеров» регулярно вылетает у всех из головы, поэтому поддержка узнаёт о релизе по факту релиза.
На этом этапе нужно договориться о двух принципиальных вещах:
✅ Поддержка тоже участвует в подготовке
Саппорт — это не сбоку к продукту прилеплено, а команда, которая будет держать все удары. Неважно, кто ошибся в коммуникации или наделал багов, все шишки полетят в чаты с операторами.
Зафиксируйте это знание на любом из этапов. Шаг «поговорить с поддержкой» должен быть не только в голове запускающего менеджера, а зафиксирован на бумаге. Если ведёте релизный чек-лист, добавьте пункты про обязательную подготовку саппорта.
Саппорт — это не сбоку к продукту прилеплено, а команда, которая будет держать все удары. Неважно, кто ошибся в коммуникации или наделал багов, все шишки полетят в чаты с операторами.
Зафиксируйте это знание на любом из этапов. Шаг «поговорить с поддержкой» должен быть не только в голове запускающего менеджера, а зафиксирован на бумаге. Если ведёте релизный чек-лист, добавьте пункты про обязательную подготовку саппорта.
Пример чек-листа: список дел перед релизом
✅ Когда релизим
Если не знаете, когда у вас релиз, то вы самурай, у которого есть только путь, но нет цели. Разыщите у разработчиков или маркетологов релизный календарь и потребуйте к нему доступы.
Если вы сделаете только это, уже будет неплохо. Даже если запускающий менеджер забудет про поддержку, вы-то не забудете, что ничего не знаете о релизе и затребуете информации.
Пока даты релизов будут только у кого-то в голове, вы никогда не договоритесь. Если релизного календаря нет, заведите релизный календарь.
Если не знаете, когда у вас релиз, то вы самурай, у которого есть только путь, но нет цели. Разыщите у разработчиков или маркетологов релизный календарь и потребуйте к нему доступы.
Если вы сделаете только это, уже будет неплохо. Даже если запускающий менеджер забудет про поддержку, вы-то не забудете, что ничего не знаете о релизе и затребуете информации.
Пока даты релизов будут только у кого-то в голове, вы никогда не договоритесь. Если релизного календаря нет, заведите релизный календарь.
Пример оформления календаря релизов в Конфлюэнс
Шаг 1. Подключите поддержку к подготовке релиза
Это нужно сделать не слишком рано, чтобы не занимать голову руководителя саппорта проектом, который ещё не факт, что релизнется, но и не слишком поздно, чтобы не вышло, как обычно.
1. Планирование: формируются цели, сроки, архитектура. На этом этапе саппорту пока рано подключаться, слишком много неизвестного.
2. Сборка: разработка, интеграции, первые сборки. Поддержке тут тоже делать особо нечего, продукт ещё сырой.
3. Тестирование ⬅️ Тут нужно подключать поддержку
4. Подготовка
5. Деплой/доставка
На тестировании релиз ещё не продовый, но уже достаточно живой, чтобы саппорт мог его потрогать и понять, что вызовет вопросы у пользователей. Это минимальная достаточная точка, где обновление можно рассмотреть глазами клиента.
Привлекайте линейных саппортов к тестированию и спрашивайте их мнение: ребятам хочется влиять на продукт, а не только отвечать на бесконечные тикеты. Если у компании есть поддержка, у неё есть и руки, которые скучают по интересным задачам. Раскатите тестовые доступы на операторов, дайте им потыкать новое руками, это лучше любой документации.
Это нужно сделать не слишком рано, чтобы не занимать голову руководителя саппорта проектом, который ещё не факт, что релизнется, но и не слишком поздно, чтобы не вышло, как обычно.
1. Планирование: формируются цели, сроки, архитектура. На этом этапе саппорту пока рано подключаться, слишком много неизвестного.
2. Сборка: разработка, интеграции, первые сборки. Поддержке тут тоже делать особо нечего, продукт ещё сырой.
3. Тестирование ⬅️ Тут нужно подключать поддержку
4. Подготовка
5. Деплой/доставка
На тестировании релиз ещё не продовый, но уже достаточно живой, чтобы саппорт мог его потрогать и понять, что вызовет вопросы у пользователей. Это минимальная достаточная точка, где обновление можно рассмотреть глазами клиента.
Привлекайте линейных саппортов к тестированию и спрашивайте их мнение: ребятам хочется влиять на продукт, а не только отвечать на бесконечные тикеты. Если у компании есть поддержка, у неё есть и руки, которые скучают по интересным задачам. Раскатите тестовые доступы на операторов, дайте им потыкать новое руками, это лучше любой документации.
Шаг 2. Затребуйте базовый минимум
- Какие поверхности затрагивает обновление: если в продукте есть и сайт, и приложения для разных ОС, и другие вещи, то нужно указать вариативность релиза для разных платформ (тарифов, устройств, версий приложения)
- Доступ к тестовой среде (staging/beta): где можно самим пощупать фичу, если доступы не выдали раньше
- Внутренние релиз ноутс: короткий список изменений с акцентом на то, что клиент увидит и почувствует
- % выкатки: релизы обычно выезжают не всех пользователей сразу, а постепенно: сначала на 1%, потом на 10%, и только потом на всех
- FAQ от продукта: черновые вопросы и ответы, которые разработчики или маркетинг уже предполагают
- Сценарии использования (юзкейсы): что и в каком порядке клиент будет тыкать в новой логике
- Описание новой фичи/релиза на человеческом языке: что изменится для клиента, зачем это нужно
- Контакты ответственных: кто из продукта разработки может быстро ответить на вопросы поддержки
- Сроки релиза и коммуникационный план: когда и где клиент узнает об изменении, какими словами (письмо, баннер, уведомление)
- Скриншоты или демо-ролик: даже черновые макеты сильно ускоряют понимание
Саппорт здесь должен сыграть роль первого клиента, который задаёт неудобные вопросы:
- Какие известные баги остаются на момент релиза?
- Как будет выглядеть ошибка, если что-то пойдёт не так?
- Что делать, если у клиента нестандартные данные (например, старая версия браузера, нет карты для оплаты, другой язык)?
- Будет ли логгироваться информация о действиях клиента, чтобы отследить шаги?
- Видит ли саппорт в админке все данные, чтобы помочь клиенту по новой фиче?
Шаг 3. Задавайте вопросы
Определите ответственных как со стороны смежников, так и со стороны поддержки, подружите их в одном месте.
Не проводите эти обсуждения в личке. Вопросы, которые возникли у одного человека, могут возникнуть и у другого. Чтобы сохранять информацию хотя бы в переписке, заведите общий чат или общий таск для вопросов-ответов и храните все промежуточные обсуждения в нём.
Этим чатом мы будем пользоваться для любых вопросов, связанных с релизом.
Определите ответственных как со стороны смежников, так и со стороны поддержки, подружите их в одном месте.
Не проводите эти обсуждения в личке. Вопросы, которые возникли у одного человека, могут возникнуть и у другого. Чтобы сохранять информацию хотя бы в переписке, заведите общий чат или общий таск для вопросов-ответов и храните все промежуточные обсуждения в нём.
Этим чатом мы будем пользоваться для любых вопросов, связанных с релизом.
Шаг 4. Составьте ЧаВо
Из первого пакета данных должен родиться список основных вопросов-набросов, на которые поддержка должна уметь отвечать. Составьте красивые заготовленные ответы и убедитесь вместе со смежниками, что они корректные, а вы всё правильно поняли.
Из первого пакета данных должен родиться список основных вопросов-набросов, на которые поддержка должна уметь отвечать. Составьте красивые заготовленные ответы и убедитесь вместе со смежниками, что они корректные, а вы всё правильно поняли.
Шаг 5. Подготовьте роскошный максимум
Когда у поддержки есть вся информация мира, наступает время готовить команду. Подготовка поддержки к релизу — это не «ну как-нибудь сами успеют», а полноценная часть проекта, которую нужно закладывать сразу. На обучение команды, обновление базы знаний, настройку хелпдеска и перерасчёт нагрузки нужно время.
Когда у поддержки есть вся информация мира, наступает время готовить команду. Подготовка поддержки к релизу — это не «ну как-нибудь сами успеют», а полноценная часть проекта, которую нужно закладывать сразу. На обучение команды, обновление базы знаний, настройку хелпдеска и перерасчёт нагрузки нужно время.
📄 Документация и БЗ
- Внести новые кейсы и шаблоны ответов в базу знаний (внешнюю и внутреннюю)
- Обновить существующие статьи, чтобы не было противоречий с новой логикой
- Составить FAQ для операторов: Вопрос → Ответ → Где посмотреть подробнее
👩💻 Подготовка команды
- Провести обучение для саппортов: встреча, скринкаст, бета-версия, чтобы пощупать самим
- Закинуть шаблоны ответов в макросы/чаты/почту
- Показать точки эскалации: к кому бежать, если пользовательский вопрос выходит за рамки подготовки или случилась катастрофа
- Предложить задавать вопросы сейчас, показать, куда
📊 Нагрузка
- Прикинуть рост обращений (например, +30% в первые 3 дня)
- Вывести на смену дополнительных сотрудниов в пиковые часы
- Согласовать с HR возможные перераспределения по линиям и графикам
🛠️ Инструменты
- Проверить, есть ли в админке/логах вся информация, чтобы саппорт мог ответить на вопросы. Если чего-то не хватает, заказать доработку инструментов
- Настроить разметку для отслеживания тикетов в хелпдеске: теги, категории и другие поля
- Договориться о формате баг-репорта для релизных тасков
📢 Коммуникация
- Обозначить для саппорта, какими словами рассказываем клиентам об изменении (ToV, ключевые формулировки).
- Подготовить ответы для соцсетей и публичных площадок (форумы, инста и сторы)
- Добавить всю команду/тимлидов в общее пространство для вопросов
🚨 Контроль и мониторинг
- Настроить дашборды для отслеживания тикетов по релизу (по тегу, категории)
- Договориться о формате сбора обратной связи: собираем? в каком формате? что ходим выведать?
- Подготовить план «что делаем, если прод рухнет»
🤖 Чат-бот
Если вы сразу понимаете, какие вопросы будут супер-популярными, отдайте их роботам. Пусть отвечают.
Если вы сразу понимаете, какие вопросы будут супер-популярными, отдайте их роботам. Пусть отвечают.
Необязательный шаг: калибровка
Если релиз крупный, убедитесь, что все участники одинаково понимают понятие «поддержка отработала хорошо». Для этого можно создать несколько тестовых тикетов с вопросами о релизе и попросить саппортов, которые уже обучились, ответить в них так, как будто бы они настоящие. Следите за разметкой тикетов и качеством баг-репортов.
Почитайте эти тикеты вместе со всеми ответственными за релиз. Привлеките людей, которые будут читать баг-репорты. Договоритесь о том, что вы все одинаково оцениваете эти тикеты.
Если релиз крупный, убедитесь, что все участники одинаково понимают понятие «поддержка отработала хорошо». Для этого можно создать несколько тестовых тикетов с вопросами о релизе и попросить саппортов, которые уже обучились, ответить в них так, как будто бы они настоящие. Следите за разметкой тикетов и качеством баг-репортов.
Почитайте эти тикеты вместе со всеми ответственными за релиз. Привлеките людей, которые будут читать баг-репорты. Договоритесь о том, что вы все одинаково оцениваете эти тикеты.
Шаг 6. Отбиваем релиз
Нагрузка на релизах ожидаемо возрастает: у нас остались все вопросы, которые были, и добавились новые. Хороший релиз в поддержке — это тот, в котором хаос получить снизить до управляемого уровня.
Предусмотреть всё невозможно. Убедитесь, что саппортам есть куда задавать вопросы, чтобы не отвечать «Уточняю, ожидайте» в каждый тикет. Оперативно дописывайте FAQ с частыми вопросами.
Держите руку на пульсе. Если можете, читайте ответы поддержки в живом режиме: тема новая, незнакомая, чтобы не допускать массовых ошибок, специалистов лучше поправлять в процессе.
Собирайте статистику по обращениям и следите за метриками онлайн: нагрузка растёт так, как вы посчитали? Команде хватает на всё рук? Будьте готовы достать ресурсы из дополнительного кармашка. Если поддержка перегружена, выясните причину, почему это случилось.
Поддерживайте команду. Присылайте им мемы с котами. Они не просили релиз и теперь должны оперировать новой информацией, к которой ещё не привыкли.
Нагрузка на релизах ожидаемо возрастает: у нас остались все вопросы, которые были, и добавились новые. Хороший релиз в поддержке — это тот, в котором хаос получить снизить до управляемого уровня.
Предусмотреть всё невозможно. Убедитесь, что саппортам есть куда задавать вопросы, чтобы не отвечать «Уточняю, ожидайте» в каждый тикет. Оперативно дописывайте FAQ с частыми вопросами.
Держите руку на пульсе. Если можете, читайте ответы поддержки в живом режиме: тема новая, незнакомая, чтобы не допускать массовых ошибок, специалистов лучше поправлять в процессе.
Собирайте статистику по обращениям и следите за метриками онлайн: нагрузка растёт так, как вы посчитали? Команде хватает на всё рук? Будьте готовы достать ресурсы из дополнительного кармашка. Если поддержка перегружена, выясните причину, почему это случилось.
Поддерживайте команду. Присылайте им мемы с котами. Они не просили релиз и теперь должны оперировать новой информацией, к которой ещё не привыкли.
Хелпдеск завален уведомлениями. Случилось страшное: поддержку завалило, и вы в непроглядной тьме тикетов, которым конца и края не видно.
Шаг 7. Пост-релизные вычисления
На пятом шаге вы договорились о формате сбора обратной связи — время её рассмотреть. Соберите и рассортируйте всю полезную для продукта информацию: как пользователи приняли релиз? сколько было багов?
Соберите статистику и для себя, это пригодится на следующих релизах. Сохраните в одном месте:
Не останавливайтесь на цифрах, почитайте и разные тикеты: одинаково ли операторы объясняли новую фичу или кто-то писал «уточнияю у разработчиков», а кто-то давал решение? Обратите внимание, нет ли в ответах сухости, раздражения или паники, это случается, когда саппорт завалило и у сотрудников голова кругом.
Похвалите команду, они у вас все молодцы. Спросите, как было на этот раз, узнайте, чего не хватило, и обязательно учтите это на следующий раз.
Вы выжили. Скоро следующий релиз.
На пятом шаге вы договорились о формате сбора обратной связи — время её рассмотреть. Соберите и рассортируйте всю полезную для продукта информацию: как пользователи приняли релиз? сколько было багов?
Соберите статистику и для себя, это пригодится на следующих релизах. Сохраните в одном месте:
- Цифры по нагрузке: CR по разным каналам, час пик, размер очереди и бэклога.
- Цифры по скорости: FRT, Time to Resolution, ER.
- Цифры по удовлетворённости: CSAT/NPS по релизным тикетам, доля негативных.
- Темы: топ популярных тем и частых формулировок вопросов.
- Контент: просмотр статей БЗ (какие искали, чего не нашли), клики по FAQ.
- Сбои: инциденты и баги, время простоя, сколько клиентов задело.
Не останавливайтесь на цифрах, почитайте и разные тикеты: одинаково ли операторы объясняли новую фичу или кто-то писал «уточнияю у разработчиков», а кто-то давал решение? Обратите внимание, нет ли в ответах сухости, раздражения или паники, это случается, когда саппорт завалило и у сотрудников голова кругом.
Похвалите команду, они у вас все молодцы. Спросите, как было на этот раз, узнайте, чего не хватило, и обязательно учтите это на следующий раз.
Вы выжили. Скоро следующий релиз.
📚 Эти ссылки подобрали для вас вручную:
Как не умереть, если вы только что стали руководителем поддержки
Евгений стал руководителем в саппорте и умер от обезвоживания, пока ждал, когда его сотрудники начнут работать, как надо. Труп Евгения ещё неделю получал сообщения «Почему на тикеты на отвечаете?»
«Ой, мы не хотели»: кризисные ситуации в работе поддержки
«Ой, это было не вам» — фраза, которая хотя бы раз заставляла кровь стынуть в жилах любого саппорта. Ещё не отправляли клиенту скриншот своего чата с подругой вместо ответа по тикету? Ваш час придёт. Встретьте его во всеоружии.
Как писать о багах
Сообщаем о проблемах так, чтобы их тут же решали
Что делать, когда поддержка перегружена
Хелпдеск завален уведомлениями. Случилось страшное: поддержку завалило, и вы в непроглядной тьме тикетов, которым конца и края не видно.