Деплой упал и репутация следом. Алгоритм тушения пожара в соцсетях

Пятничный релиз часто заканчивается катастрофой. База данных отказывает, приложение не грузится, а платежный шлюз выдает ошибки. Я, Пётр Сухоруких, основатель репутационного агентства, собрал для вас алгоритм кризисной коммуникации. Он поможет сохранить доверие пользователей, пока инженеры восстанавливают прод.

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

Узнавайте о сбое раньше пользователей

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

Настройте алерты на критические метрики:

• Всплеск 500-х ошибок (Internal Server Error);
• Резкое падение RPS (Requests Per Second);
• Недоступность базы данных.

Уведомления должны приходить не только в канал DevOps, но и PR-лиду.

Соберите цифровой чемоданчик

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

• Мониторинг соцсетей: Brand Analytics или YouScan (чтобы ловить негатив);
• Рассылки: Unisender или Mindbox (с заготовленными шаблонами);
• Менеджер паролей: KeePass или 1Password (чтобы не искать доступы от Твиттера полчаса).

Подготовьте шаблоны рассылок в сервисах вроде Unisender или Mindbox заранее. У вас не будет времени верстать красивое письмо с извинениями. Когда сервер лежит, счет идет на минуты. Вам останется только вставить причину сбоя и нажать кнопку отправки. Держите доступы от всех корпоративных аккаунтов в одном защищенном месте. Поиск пароля от Твиттера не должен занимать полчаса.

Подготовьте независимый статус-пейдж

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

Клиент видит подтверждение проблемы. Он понимает вашу осведомленность. Подойдут готовые решения вроде Atlassian Statuspage. Можно развернуть open-source решение типа Cachet на отдельном сервере. Главное условие заключается в независимости от вашей основной инфраструктуры. Статус-пейдж должен работать даже при падении вашего дата-центра.

Введите режим радиомолчания внутри команды

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

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

Признавайте проблему сразу и честно

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

Сразу опубликуйте сообщение о сбое. Укажите сломанный компонент. Дайте прогноз по времени восстановления согласно вашему SLA. Если прогноз дать невозможно, напишите время следующего апдейта. Пользователь готов ждать решения. Он не готов ждать в неизвестности.

Влияйте на метрики восстановления

Инженеры используют метрику MTTR. Это среднее время восстановления сервиса после сбоя. Ваша работа с аудиторией напрямую влияет на восприятие этого времени. Психология пользователя работает просто. Минута молчания компании ощущается как десять минут простоя.

Моментальная реакция в публичном поле сжимает субъективное время ожидания. Клиент видит пост и успокаивается. Ему кажется, что починка идет быстрее. Грамотная коммуникация снижает отток пользователей даже при длительных технических работах. Вы покупаете время своим инженерам. Они работают спокойнее и делают меньше ошибок.

Работайте с негативом в магазинах приложений

Пользователи пойдут ставить единицы вашему приложению в AppStore и Google Play. Удалить эти отзывы практически невозможно. Модерация магазинов неохотно убирает оценки. Даже если они вызваны временным сбоем.

Подготовьте честные ответы для рассерженных клиентов заранее. Не копируйте стандартные извинения про важность мнения. Объясняйте суть проблемы в каждом ответе. Пишите про устранение сбоя. Это поможет новым пользователям видеть актуальную картину. Они поймут причину низкой оценки. Единица поставлена за прошлую аварию. Качество продукта здесь ни при чем.

Локализуйте пожар в одном канале

Эффект толпы в социальных сетях работает против вас. Один гневный тред на популярном ресурсе способен уничтожить имидж продукта за пару часов. Разрозненные жалобы в Твиттере или Телеграме создают ощущение глобальной катастрофы.

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

Локализация негатива в одном месте помогает контролировать ситуацию. Менеджерам поддержки проще обрабатывать ветку комментариев в одном месте. Ловить сотни проклятий по всему интернету гораздо сложнее. Отвечайте там оперативно. Люди увидят вашу вовлеченность и быстрее остынут.

Публикуйте технический разбор полетов

Опубликуйте подробный отчет после устранения аварии. Этот документ в индустрии называют Post-mortem. Инженеры и технически подкованные пользователи любят детали. Расскажите публично о причинах сбоя и принятых мерах.

Хороший Post-mortem обязательно включает:

1. Таймлайн: хронология событий по минутам.
2. Причина: почему не сработали механизмы защиты.
3. Решение: как вы изменили архитектуру, чтобы ситуация не повторилась.

Зачищайте поисковую выдачу

Последствия сбоя остаются в интернете надолго. Негативные статьи в СМИ или обсуждения на форумах могут висеть в топе поисковой выдачи неделями. Потенциальные партнеры или новые сотрудники будут натыкаться на них при поиске информации о компании.

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

Согласуйте текст с юристами

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

Не обещайте денежные компенсации в первом же посте на эмоциях. Любое обещание в публичном поле становится публичной офертой. Сначала посчитайте бюджет с финансовым директором. Только потом пишите про возвраты средств. Опрометчивый твит может стоить компании годовой прибыли.

Компенсируйте ущерб действиями

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

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