Уведомление клиентов о сбое и плановых работах: шаблон

Кратко

Уведомление о сбое или плановых работах — короткое сообщение клиентам, которое отвечает на три вопроса: что не работает (или не будет работать), когда это закончится и что делать до тех пор. Плановые работы предупреждают заранее, сбой — сразу после обнаружения, не дожидаясь восстановления. Ниже — два готовых текста и правило, когда какой использовать.

Актуально на 23 сентября 2026 года.

Плановое уведомление и сообщение о сбое — не одно и то же

Разбор причин после восстановления — это уже не уведомление, а отдельный документ для команды и, при необходимости, для клиента: см. Разбор массового сбоя: образец отчёта (постмортем). Уведомление ниже — то, что клиент видит в моменте, а не после разбора.

Готовый образец: уведомление о плановых работах

Тема: Плановые технические работы <ДД.ММ> с <ЧЧ:ММ> до <ЧЧ:ММ>

Уважаемые клиенты,

<ДД.ММ.ГГГГ> с <ЧЧ:ММ> до <ЧЧ:ММ> (<часовой пояс>) будут проведены плановые технические работы: <краткая суть — обновление, перенос, замена оборудования>.

В это время: <что именно будет недоступно — сервис целиком / отдельная функция / приём заявок по каналу Х>.

Что делать: <если есть обходной способ — указать; если нет — так и написать «доступ временно ограничен, обращения будут обработаны после завершения работ»>.

По вопросам — <канал связи>. О завершении работ сообщим отдельно.

<Подпись команды / компании>

Готовый образец: уведомление о сбое

Тема: Сбой в работе <название сервиса> — уже разбираемся

Уважаемые клиенты,

С <ЧЧ:ММ> <ДД.ММ> наблюдаются проблемы: <что именно не работает или работает некорректно>.

Статус: <устраняется / устранено, ведётся наблюдение>.

Затронуто: <всё / часть пользователей — какая>.

Следующее обновление: <через сколько времени или к какому часу>.

Приносим извинения за неудобства. По срочным вопросам — <канал связи>.

<Подпись команды / компании>

Как посчитать, за сколько предупреждать заранее

Жёсткого стандарта нет, но рабочий ориентир, который не оставляет клиентов врасплох:

Чем меньше время до начала работ, тем выше цена ошибки в расчёте длительности — если названо «до 18:00», а работы затянулись до 19:30, второе уведомление обязано уйти до 18:00, а не после.

Как проверить текст перед отправкой

• Названо точное время начала и (для плановых работ) окончания, а не «в ближайшее время» или «скоро».
• Указано, что именно затронуто — сервис целиком, отдельная функция или отдельный канал приёма обращений, а не общее «возможны неполадки».
• Для сбоя есть время следующего обновления — конкретный час, а не «как только сможем».
• Есть канал для срочных вопросов, отличный от того, что может быть недоступен из-за самого сбоя.
• Уведомление отправлено во все каналы, которыми реально пользуются клиенты, а не в один.

Частые ошибки

Молчание до восстановления. Клиент, который узнаёт о сбое только по факту «уже всё работает», в следующий раз перестаёт доверять статусу «работает» без объяснений.

Уведомление без времени следующего обновления. Без него клиенты пишут повторно каждые 10–15 минут, и это создаёт вторую волну нагрузки поверх самого сбоя.

Один канал рассылки при обращениях из разных каналов. Если клиенты пишут в WhatsApp, на почту и через сайт, а уведомление ушло только в один канал, часть клиентов о нём не узнает и продолжит писать заявки по уже известной причине.

Технический текст вместо человеческого. «Наблюдается деградация сервиса на уровне инфраструктуры» ничего не говорит клиенту о том, может ли он сейчас работать. Формулировка обязана отвечать на вопрос «я могу сейчас пользоваться сервисом или нет». Тон уведомления — деловой и по существу, без оправданий; общие требования к тону общения с клиентом собраны в статье Стандарты качества обслуживания клиентов: образец.

Обещание срока, в который не укладываются. Названный и не выполненный срок восстановления вредит доверию больше, чем честное «пока не знаем, сообщим к <час>».

Частые вопросы

Нужно ли уведомлять о сбое, если он длился меньше 10 минут и его никто не заметил?

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

Кто должен отправлять уведомление о сбое — техническая команда или поддержка?

Текст готовит тот, кто ближе к фактам (техническая команда или дежурный инженер), а отправляет — поддержка или тот канал, который клиенты уже читают; смешивать составление и рассылку в одном человеке в момент аварии не стоит.

Если после уведомления клиент всё же пишет с недовольством, отвечать стоит не заново придуманным текстом, а по структуре из статьи Ответ на жалобу клиента: образец письма.

Как часто повторять уведомление во время длительного сбоя?

По названному в предыдущем сообщении времени следующего обновления — если названо «через час», обновление обязано прийти через час, даже если новостей по сути нет: «всё ещё разбираемся, следующее обновление через час».

Нужно ли извиняться в уведомлении о плановых работах?

Нет, плановые работы — это информирование, а не инцидент; извинение уместно, если работы затрагивают клиента в неудобное время, но тон остаётся деловым, а не оправдывающимся.

Связанные статьи

• Разбор массового сбоя: образец отчёта (постмортем)
• Регламент технической поддержки: готовый образец
• Как оказывать техническую поддержку: путь обращения, сроки и регламент
• Документы службы техподдержки: полный перечень