Регламент коммуникации при инцидентах для команд продаж и поддержки

Что идет не так, когда все импровизируют

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

Клиенты замечают несоответствия сразу. Они сравнивают ответы в чате, письма и звонки по аккаунту. Если история меняется каждые 15 минут, доверие падает еще до того, как техническая проблема будет устранена.

Разработчики почти сразу чувствуют цену такой путаницы. Вместо того чтобы заниматься инцидентом, они снова и снова отвечают на один и тот же вопрос в Slack, по почте и в личных сообщениях: что сломалось, кого это затронуло, что нужно говорить клиентам? Пара мелких отвлечений легко съедает 20–30 минут реального времени на исправление.

Обычно все идет по одному и тому же сценарию. Люди заполняют пробелы догадками. Клиенты получают молчание или расплывчатые ответы. Продажи продолжают вести активные сделки, не понимая рисков. Поддержка по нескольку раз эскалирует один и тот же вопрос. Инженеры становятся единственным источником истины для каждой команды.

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

Представьте сбой в биллинге утром в будний день. Поддержка говорит одному клиенту, что проблему изучают. Продажи уверяют, что новые аккаунты все равно могут подключаться как обычно. Customer success сообщает крупному клиенту, что инцидент затронул лишь небольшую группу. Между тем инженеры все еще выясняют масштаб. Теперь у команды две проблемы: сам сбой и последствия плохой коммуникации.

Теоретически решение простое. Нужны понятные действия, четкие ограничения и утвержденные формулировки для клиентов. Продажи должны понимать, когда надо притормозить. Поддержка — когда успокаивать, а когда эскалировать. Customer success — какие аккаунты нужно предупредить лично. Хороший регламент дает всей компании одно общее сообщение, меньше отвлечений и больше времени на устранение проблемы.

Назначьте ответственного за коммуникацию

Когда начинается инцидент, кто-то один должен отвечать за обновления для клиентов. Назначьте этого человека заранее, до первой поломки. Если каждый будет писать свою версию, клиенты получат противоречивые ответы, а инженеры потеряют время на одни и те же вопросы.

Этот человек не обязан чинить проблему. Задача уже и проще. Он собирает подтвержденные факты, переводит их на простой язык и отправляет обновления по расписанию. В одних командах эта роль лучше подходит поддержке. В других — customer success. Важно не подразделение, а имя в документе.

Для большинства команд подходит простое разделение. Поддержка обрабатывает входящие обращения, помечает важные аккаунты и рассылает утвержденное сообщение. Продажи ставят на паузу обещания, зависящие от сломанного сервиса, и успокаивают активные сделки без догадок. Customer success связывается с важными аккаунтами, простыми словами объясняет влияние на бизнес и отслеживает, что нужно сделать дальше.

Инженеры не должны отвечать на случайные вопросы от каждой команды во время инцидента. Вместо этого назначьте контрольные точки. Например, владелец коммуникации сверяется с инженерами каждые 30 минут или раньше, если меняется масштаб, появляется обходной путь или начинается восстановление. Если менеджер по продажам или customer success слышит новую жалобу клиента, он сначала передает ее владельцу коммуникации. Так у вас остается одна линия правды.

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

В регламенте также стоит запретить импровизацию в формулировках во время инцидента. Продажи не должны говорить «все уже исправлено», пока инженеры не подтвердят восстановление. Поддержка не должна гадать со сроками. Customer success не должен сразу предлагать компенсацию, если это не разрешено процессом согласования. Четкое владение и простые ограничения снимают огромную часть нагрузки.

Подготовьтесь до того, как что-то сломается

Клиенты обычно снова и снова сообщают об одних и тех же симптомах. Не удается войти в аккаунт. Не проходят платежи. Данные выглядят пропавшими или с задержкой. Страницы открываются, но действия завершаются по таймауту. Перестают работать письма или синхронизация с внешними сервисами. Хороший регламент начинается именно с таких клиентских сценариев, потому что поддержке, продажам и customer success нужно быстро их распознавать, не дожидаясь, пока инженер все объяснит.

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

Хорошие определения серьезности объясняют две вещи: влияние на клиента и скорость реакции. Sev 1 может означать, что продукт недоступен для многих клиентов и обновления нужно согласовывать очень быстро. Sev 2 — что сломана важная функция, но часть работы все еще возможна. Sev 3 — что проблема ограничена и есть известный workaround. Если два человека читают один и тот же отчет, они должны выбрать один и тот же уровень.

Нужно и одно место, где все неинженерные команды найдут самое свежее утвержденное обновление. Если поддержка смотрит в Slack, продажи — в письмо, а customer success — в старый документ, клиенты услышат три разные версии. Выберите один источник и сделайте его единственным.

Храните там же и готовые шаблоны для клиентов. Они не обязаны быть красивыми. Вам нужны первое сообщение, следующее обновление, сообщение с workaround и финальная заметка о восстановлении. Напишите их заранее, пока никто не находится под давлением.

Хорошая проверка очень проста. Дайте регламент новому сотруднику поддержки. Если он за пять минут может понять, что случилось, насколько это серьезно, где смотреть актуальную информацию и что отправлять, значит, настройка, скорее всего, удачная. Если он тонет в формулировках политики, регламент слишком длинный.

Запустите процесс в первый час

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

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

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

Потом придерживайтесь ритма. При полном сбое подойдут обновления каждые 15 минут. При частичном сбое обычно достаточно 30 минут. Для меньшей проблемы с ограниченным влиянием можно писать раз в час. Главное — постоянство. Молчание нервирует клиентов. Короткое обновление без изменений все равно полезно, если приходит вовремя.

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

Перед финальным сообщением убедитесь, что сервис действительно стабилен. Проверяйте клиентский симптом, а не только внутренний график. После этого закройте инцидент простой заметкой: что именно почувствовали клиенты, когда сервис восстановился, нужно ли им что-то сделать и когда ждать более подробный итог.

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

Пишите обновления, которыми реально можно пользоваться

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

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

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

«Мы видим периодические сбои входа в приложении. Некоторые клиенты не могут войти или могут быть выкинуты из системы сразу после входа. Наши инженеры уже работают над проблемой и проверяют сервис аутентификации. Следующее обновление опубликуем до 14:30 по восточному времени.»

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

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

Продажам обычно нужна немного другая версия для живых сделок и продлений, но факты должны оставаться теми же. Для активной сделки менеджер может сказать: «Сейчас у нас идет инцидент, который затрагивает вход в систему для части пользователей. Команда уже работает над ним, а следующее обновление запланировано на 14:30 по восточному времени. Я пришлю его вам, как только оно появится».

Для продления формулировка может быть такой же прямой: «Сейчас мы разбираем проблему со входом, которая затрагивает часть пользователей. Команда уже выделила инженеров на этот инцидент и пришлет следующее обновление до 14:30 по восточному времени. После восстановления сервиса я могу собрать для вас заметки по инциденту и таймлайн».

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

Пример: сбой оформления заказа утром во вторник

В 9:10 утра клиенты начинают сообщать, что при оплате картой оформление заказа не проходит. Заказы не завершаются, в поддержку резко растет поток обращений, а у продаж до обеда запланированы две живые демонстрации.

К 9:15 руководитель инцидента подтверждает проблему: платежи не проходят у части или у всех клиентов, и команда еще проверяет, вызвана ли она провайдером платежей или самим приложением. Инженеры начинают исправление. Все остальные следуют регламенту, чтобы разработчики могли работать без постоянных отвлечений.

Поддержка не ждет идеального корня проблемы. В первые 15 минут она отправляет короткое сообщение новым тикетам и обращениям в live chat: «Мы проверяем проблему с платежами, которая влияет на оформление заказа. Сейчас часть платежей может не проходить. Команда уже работает над этим, и мы опубликуем следующее обновление к 9:30 утра. Если ваша оплата не прошла, пожалуйста, не повторяйте попытку больше одного раза, пока мы не подтвердим, что сервис стабилен».

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

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

Customer success связывается с затронутыми аккаунтами, особенно если у них запуски, кампании или большой объем заказов. Короткой заметки достаточно: «Подтверждаем сбой платежей, который влияет на оформление заказа у вашей команды. Следующее обновление отправим в 9:30 утра. Если вам нужна помощь с ответами для входящих вопросов от ваших клиентов, просто ответьте здесь, и мы поможем с формулировкой».

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

В 9:30 каждая клиентская команда отправляет один и тот же статус: что сломано, кого это затронуло, что клиентам нужно делать дальше и когда ждать следующее обновление. Эта последовательность важнее, чем красивый текст.

Ошибки, которые замедляют восстановление

Одно неудачное обновление может превратить короткий сбой в длинный, хаотичный день. Чаще всего проблема не в самом баге. Проблема в путанице вокруг него.

Команды начинают гадать, когда чувствуют давление сказать что-то быстро. Так поддержка сообщает клиентам, что это «скорее всего проблема с платежами», продажи обещают вернуть сервис через 15 минут, а customer success рассказывает крупным аккаунтам уже совсем другую версию. Если причина еще неизвестна, так и скажите. Если сроки еще неизвестны, тоже скажите об этом.

Ранние обещания создают вторую проблему. Клиенты часто лучше запоминают сорванный дедлайн, чем сам баг. Безопаснее говорить просто и честно: команда нашла проблему, работа идет, а следующее обновление будет в назначенное время.

Расплывчатые формулировки тоже вредят. Фразы вроде «некоторые пользователи могут столкнуться с временными затруднениями» звучат аккуратно, но скрывают реальное влияние. Клиентам нужны прямые слова. Могут ли они войти? Могут ли оформить заказ? Задерживаются ли письма? Скажите, что именно изменилось для них.

Еще одна частая ошибка — снова и снова втягивать инженеров в один и тот же разговор. Десять человек, которые спрашивают статус каждые пять минут, не ускоряют исправление. Наоборот, они замедляют его.

Несколько правил предотвращают большую часть таких проблем:

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

Это еще важнее в маленьких командах. Если проблему решают один разработчик и руководитель уровня CTO, каждый перерыв имеет значение. Понятный язык для клиентов защищает их фокус, а значит, сервис обычно восстанавливается быстрее.

Сделайте двухминутную проверку перед отправкой

Быстрые сообщения часто приводят к вполне предотвратимому ущербу. Короткая проверка помогает остановить типичные ошибки: не тот продуктовый раздел, устаревшая отметка времени или обещание, которое никто не сможет выполнить.

Начните с последней внутренней заметки по инциденту, а не с памяти. Если инженеры обновили статус в 10:40, а ваш черновик все еще использует данные от 10:15, клиенты получат смешанные сигналы еще до того, как исправление будет готово.

Перед отправкой пройдитесь по короткому списку:

• Совпадает ли черновик с последним внутренним статусом, текущим масштабом проблемы и влиянием на клиента?
• Правильно ли указаны названия клиентов, продуктов, регионов и отметки времени?
• Есть ли в сообщении время следующего обновления, даже если решения пока нет?
• Отправили бы sales, support и customer success почти одинаковый текст, если бы три клиента спросили об этом одновременно?
• Если отвечает крупный аккаунт, ясно ли назначен человек, который ведет этот тред?

Последний пункт важнее, чем кажется большинству команд. Крупные клиенты часто просят больше деталей, и проблемы начинаются, когда sales отвечает одним тоном, support — другим, а customer success через десять минут добавляет третью версию. Один ответственный человек удерживает разговор в одном русле и не втягивает инженеров в пять отдельных переписок.

Небольшие изменения в формулировках тоже помогают. «Мы изучаем сообщения» — слабая фраза, если вы уже знаете проблемную область. «Мы проверяем сбои входа в биллинговом портале. Следующее обновление в 14:30 UTC» дает клиенту не только ясность, но и понимание, что делать дальше.

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

Разберите реакцию после восстановления сервиса

Когда сервис снова работает, большинству команд хочется просто переключиться дальше. Обычно именно в этот момент те же ошибки в коммуникации закладываются в следующий инцидент. Дайте команде 20–30 минут, пока детали еще свежи, и разберите клиентскую сторону реакции, а не только техническое исправление.

Начните с вопросов, которые клиенты задавали снова и снова. Если десять человек спрашивали, в безопасности ли их данные, значит, ваше сообщение, скорее всего, не закрыло этот вопрос. Если sales постоянно спрашивали support о статусе, значит, внутреннее обновление, вероятно, было слишком коротким или слишком медленным.

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

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

Потом обновите регламент, пока боль еще легко вспомнить. Уберите лишние шаги. Назначьте запасного ответственного для каждой роли. Установите простой ритм обновлений, например каждые 30 минут, пока проблема не стабилизируется. Если какой-то шаблон вызвал путаницу, перепишите его простыми словами и протестируйте на человеке, который не участвовал в инциденте.

Короткая тренировка помогает больше, чем длинное совещание. Дайте sales, support и customer success небольшой сценарий и попросите их отправить одно внутреннее обновление и один ответ клиенту. Вы быстро увидите расплывчатые формулировки. И сразу поймете, умеют ли люди пользоваться регламентом под давлением.

Держите весь документ настолько коротким, чтобы его можно было пробежать глазами меньше чем за две минуты. Если он читается как корпоративная политика, люди проигнорируют его, когда начнется хаос. Лучший вариант обычно умещается на одной странице: несколько шаблонов, понятные владельцы и короткий чек-лист, которому можно доверять, когда все устали.

Начните с малого и практикуйтесь

Первый регламент не обязан покрывать вообще все типы инцидентов. Начните с одной проблемы, с которой команда сталкивается чаще всего, например с недоступности входа, сбоя оформления заказа или задержки синхронизации данных. Соберите вокруг этого случая небольшой набор шаблонов и убедитесь, что sales, support и customer success понимают, когда их использовать.

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

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

Для старта достаточно простого набора: один тип инцидента, один владелец внутренних обновлений, один владелец клиентских обновлений, три шаблона — для расследования, для обходного пути и для восстановления — и одна дата тренировки в ближайшие две недели.

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

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

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