Главная › Блог › Что написать клиенту при падении сайта: шаблоны для первых 10 минут

Что написать клиенту при падении сайта: шаблоны для первых 10 минут

4 августа 2026 · 12 мин чтения

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

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

Базовая формула:

Что происходит → на кого влияет → что мы делаем → когда сообщим снова.

Например:

С 14:07 сайт example.ru недоступен для посетителей. Мы подтвердили сбой из нескольких сетей и начали восстановление. Причину уточняем. Следующее обновление отправим до 14:30.

Коротко

Сообщайте о подтверждённом критическом сбое до того, как найдена полная причина.
Отделяйте наблюдаемый факт от гипотезы.
Пишите о пользовательском результате, а не о CPU, 502 и контейнерах.
Всегда называйте время следующего обновления.
Не обещайте «через пять минут всё заработает», если это не подтверждено.
Используйте один источник статуса и одного ответственного за сообщение.
После восстановления проверьте критическую операцию, а не только зелёный мониторинг.

Что сделать до первого сообщения

Не отправляйте клиенту каждое одиночное срабатывание. Сначала быстро подтвердите событие.

За первые несколько минут ответственный должен:

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

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

Подробнее о порядке действий: регламент веб-студии на первые 60 минут.

Конструктор первого сообщения

Блок	Что написать	Чего избегать
Факт	Что именно не работает и с какого времени	«Кажется, что-то случилось»
Влияние	Что не может сделать посетитель или сотрудник	Список внутренних метрик без смысла для бизнеса
Действие	Что команда уже проверяет или восстанавливает	Непроверенные обвинения хостинга или разработчика
Неизвестное	Что пока не установлено	Молчание, создающее видимость, что причина скрывается
Следующий контакт	Точное время или интервал	«Будем держать в курсе»

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

Универсальный шаблон на первые 10 минут

[Имя], с [время и часовой пояс] наблюдаем [подтверждённый симптом].

Влияние: [что сейчас не может сделать пользователь / какая часть сайта затронута].

Мы [какое действие уже выполняется].
[Причина пока не установлена / предварительно проверяем такую-то зависимость].

Следующее обновление отправим до [точное время].
Ответственный со стороны студии: [имя и контакт].

Фразу о часовом поясе стоит добавить, если клиент, студия или инфраструктура находятся в разных регионах. Внутри российского проекта обычно достаточно один раз закрепить, что все времена указаны по Москве.

Шаблон 1. Весь сайт недоступен

С 14:07 мск сайт example.ru недоступен для посетителей.
Мы подтвердили сбой из нескольких сетей и начали восстановление.
Причину уточняем, плановых работ в это время не было.
Следующее обновление отправим до 14:30 мск.

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

Шаблон 2. Не оформляется заказ

С 11:42 мск покупатели не могут завершить оформление заказа:
после подтверждения корзины появляется ошибка.

Каталог и карточки товаров доступны. Мы воспроизвели проблему
и проверяем этап создания заказа и связанные интеграции.

Следующее обновление — до 12:05 мск.

Вместо «сайт частично сломан» названа конкретная операция. Клиент сразу понимает бизнес-влияние.

Шаблон 3. Не работает онлайн-оплата

С 16:18 мск не проходит оплата через [название способа].
Заказ создаётся, но покупатель не может завершить платёж.

Мы временно [включили резервный способ / скрыли проблемный способ,
чтобы не оставлять покупателя на ошибке] и проверяем обмен с платёжным сервисом.

Другие способы оплаты: [работают / также проверяются].
Следующий статус — до 16:40 мск.

Не утверждайте, что виноват банк или платёжный провайдер, пока это не подтверждено их статусом или диагностикой.

Шаблон 4. Форма показывает успех, но заявки не приходят

Мы обнаружили, что форма [название] принимает данные на сайте,
но тестовая заявка не доходит до [почты / CRM].

Проблема подтверждена с [время]. Посетитель может видеть сообщение
об успешной отправке, поэтому сбой незаметен снаружи.

Проверяем маршрут от формы до получателя. До восстановления предлагаем
[временный канал: телефон, резервную почту, другую форму].

Следующее обновление — до [время].

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

Шаблон 5. Сайт недоступен только части пользователей

С [время] подтверждаем проблемы с доступом к example.ru
у пользователей из [регион / сеть / сегмент].

Из других проверенных сетей сайт открывается. Мы собираем маршруты
и диагностические данные, параллельно проверяем DNS, CDN и хостинг.

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

Следующее обновление — до [время].

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

Шаблон 6. Остановился обмен интернет-магазина с 1С

Последний подтверждённый успешный обмен сайта с 1С завершился в [время].
Новая выгрузка не обработана, поэтому цены и остатки могут быть неактуальны.

Оформление заказов [работает / временно ограничено].
Мы проверяем очередь обмена, журнал ошибок и доступность обеих сторон.

До уточнения просим [не запускать повторный полный обмен / подтверждать
остатки вручную — только если это заранее согласованный безопасный порядок].

Следующее обновление — до [время].

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

Шаблон 7. Подозрение на взлом или подмену

В [время] мы обнаружили несогласованное изменение на сайте:
[нейтральное описание наблюдаемого факта].

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

Просим до отдельного сообщения не выполнять изменения в административной
панели и не пересылать доступы в общий чат.

Следующее защищённое обновление направим [кому и по какому каналу] до [время].

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

Шаблон 8. Зависимость от внешнего провайдера

С [время] на сайте не работает [функция].
Мы подтвердили, что сбой связан с [сервис], и получили подтверждение
от провайдера: [ссылка на официальный статус или номер обращения].

Со стороны сайта [что проверено / какой обход включён].
Мы продолжаем контролировать состояние и не считаем инцидент закрытым,
пока пользовательская операция не будет проверена после восстановления сервиса.

Следующее обновление — до [время].

Даже если первопричина находится у подрядчика клиента, студия остаётся владельцем коммуникации в пределах своей зоны ответственности.

Шаблон 9. Клиент сообщил о проблеме раньше мониторинга

Спасибо, получили сообщение в [время].
Мы воспроизвели проблему: [краткий подтверждённый симптом].

Сейчас определяем время начала и выясняем, почему автоматическая проверка
не обнаружила событие. Восстановлением занимается [роль / имя].

Следующее обновление — до [время].
После инцидента отдельно сообщим, какую проверку добавим или изменим.

Не защищайте мониторинг и не спорьте с клиентом. Признайте факт, восстановите функцию, а затем закройте пробел в обнаружении.

Шаблон 10. Сигнал не подтвердился

В [время] мониторинг зафиксировал кратковременное отклонение [что именно].
Повторные проверки из [количество] точек прошли успешно,
пользовательское влияние пока не подтверждено.

Мы продолжаем наблюдение до [время / количество успешных циклов].
Если событие повторится или появится влияние, откроем инцидент уровня [P2/P1]
и сообщим отдельно.

Такое сообщение нужно не для каждого ложного срабатывания, а когда клиент уже получил сигнал, событие затронуло согласованный критический объект или требует прозрачной фиксации.

Как писать промежуточное обновление

Промежуточный статус не должен быть вариацией «мы всё ещё работаем». Добавьте новый факт или честно сообщите, что изменилось только в плане действий.

Формула:

Текущее влияние → что установили → что сделали → что проверяем дальше → следующий контакт.

Обновление на 14:30 мск.

Сайт по-прежнему недоступен для большинства посетителей.
Мы исключили проблему DNS и подтвердили ошибки на основном приложении.
Последнее изменение откатили, но доступность пока не восстановилась.

Сейчас проверяем [следующая ветка] и готовим [безопасное действие].
Следующее обновление — до 15:00 мск.

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

Как сообщить о временном восстановлении

Используйте слово «восстановлено» только после пользовательской проверки. Если команда внесла изменение, но ещё наблюдает результат, статус лучше назвать «работоспособность восстановлена, продолжаем наблюдение».

В 15:12 мск доступность сайта восстановлена.

Мы проверили главную страницу, вход и контрольное оформление заказа.
Новые проверки проходят успешно из [количество] точек.

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

Как закрыть инцидент

Итоговое оперативное сообщение отвечает на пять вопросов:

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

Инцидент закрыт в 16:05 мск.

Период подтверждённого влияния: 14:07–15:12 мск.
В этот период сайт был недоступен для посетителей.

Работоспособность восстановлена, контрольные проверки сайта,
формы и оформления заказа проходят успешно. Наблюдение до 16:00
не выявило повторов.

Предварительная причина: [только подтверждённый факт или
«причина уточняется»]. До [дата и время] подготовим короткий разбор
с корректирующими действиями.

Не пишите «проблема полностью исключена», если остаётся риск повтора или первопричина ещё не подтверждена.

Сообщения для статус-страницы

Статус-страница должна быть короче личного сообщения клиенту и не содержать внутренние подробности.

Исследуем

Исследуем недоступность сайта

С 14:07 мск часть пользователей не может открыть сайт.
Команда занимается диагностикой. Следующее обновление — до 14:30 мск.

Причина определена

Причина определена, выполняется восстановление

Мы определили источник недоступности и применяем безопасное исправление.
Сайт пока доступен нестабильно. Следующее обновление — до 15:00 мск.

Наблюдаем

Работоспособность восстановлена, продолжаем наблюдение

С 15:12 мск сайт доступен, контрольные операции проходят успешно.
Продолжаем усиленную проверку состояния.

Решено

Инцидент решён

Работа сайта восстановлена в 15:12 мск и подтверждена контрольными
проверками. Период влияния: 14:07–15:12 мск.

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

Как выбрать канал

Ситуация	Основной канал	Дополнительный канал
P1 в рабочее или согласованное дежурное время	Аварийный чат или телефон	Статус-страница + email с фиксацией
P2	Helpdesk или согласованный чат	Email / статус-страница при внешнем влиянии
P3	Helpdesk	Плановый отчёт
Массовый публичный сбой	Статус-страница	Email, чат, сайт компании
Подозрение на безопасность	Закрытый согласованный канал	Телефон назначенному представителю

Telegram или MAX удобны для скорости, но карточка инцидента должна сохранять хронологию независимо от мессенджера. Важные решения, согласования и итог стоит перенести в Helpdesk, email или отчёт.

Когда нужно позвонить

Звонок полезен, если:

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

После разговора отправьте письменное резюме:

Подтверждаем договорённость по звонку в 14:18 мск:
временно отключаем [функция], сохраняем [данные / журналы],
следующее обновление отправим до 14:40 мск.

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

Что нельзя писать

«У нас всё работает»

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

Лучше:

Из двух проверенных сетей сайт открывается. Собираем данные по затронутому региону и проверяем маршрутизацию. Следующий статус — до 12:30.

«Это точно хостинг»

Не назначайте виновного до подтверждения.

Лучше:

Ошибка возникает на этапе соединения с сервером. Проверяем инфраструктуру и открыли обращение провайдеру №1234.

«Скоро всё починим»

Слово «скоро» каждый понимает по-своему.

Лучше:

Срок восстановления пока не определён. Следующее обновление с результатом проверки резервного сценария — до 15:00.

«Ничего страшного»

Студия не всегда знает стоимость пропущенных заказов.

Лучше:

Затронута одна из трёх форм; основной канал заказа работает. Уточняем количество возможных пропущенных обращений.

«Разработчик уже смотрит»

Это не описывает влияние и не назначает следующий контакт.

Лучше:

Проблема подтверждена, восстановлением занимается дежурный разработчик. Следующее обновление — до 10:45.

Технический поток сознания

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

Кто должен отправлять сообщения

Для P1 назначьте одного владельца коммуникации. Он:

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

В студии из трёх человек роли могут выглядеть так:

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

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

Матрица согласования сообщений

Чтобы коммуникация не ждала директора, заранее определите права:

Сообщение	Кто может отправить без согласования
Подтверждение P1 по утверждённому шаблону	Дежурный или аккаунт-менеджер
Промежуточный статус без оценки ущерба	Владелец коммуникации
Временное отключение критической функции	Только роль, указанная в договоре
Предположение об утечке или компрометации	Ответственный за безопасность и уполномоченный представитель
Публичное сообщение о причине	Согласованная ответственная сторона
Финальный технический разбор	Руководитель инцидента после проверки фактов

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

Копируемая карточка коммуникации

# Коммуникация по инциденту [ID]

Сайт: [домен]
Уровень: [P1/P2/P3]
Владелец коммуникации: [имя]
Основной канал: [канал]
Контакт клиента: [имя, роль]

## Подтверждённое влияние

[Что не может сделать пользователь]

## Неизвестно

[Каких фактов пока нет]

## Первое сообщение

Время: [чч:мм]
Текст: [сообщение]
Доставка подтверждена: [да/нет]

## Обновления

| Время | Новый факт | Отправленный текст | Следующий контакт |
|---|---|---|---|
| | | | |

## Решения клиента

- [время] — [кто] согласовал [действие]

## Закрытие

Восстановлено: [время]
Проверено: [операции]
Итог отправлен: [время]
Разбор до: [дата]

Как отрепетировать коммуникацию

Проведите короткое упражнение без реального падения:

Руководитель выбирает сценарий: «не проходит оплата».
Техническому специалисту дают факты, часть информации оставляют неизвестной.
Ответственный за коммуникацию за пять минут пишет первое сообщение.
Через десять минут вводится новый факт: проблема только у одного способа оплаты.
Команда готовит промежуточный статус и решение о понижении уровня.
В конце разбирает каждую фразу: где факт, где гипотеза, где обещание.

Шаблон считается готовым, если сотрудник может заполнить его под давлением за две–три минуты.

Как помогает Pingvera

Pingvera может дать основу для сообщения:

точное время первого нарушения и восстановления;
результат повторных проверок;
затронутую проверку или бизнес-функцию;
подтверждение из нескольких точек;
историю события;
доставку алерта в Telegram, email, MAX или webhook;
независимую статус-страницу.

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

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

Часто задаваемые вопросы

Нужно ли сообщать клиенту, если причина ещё неизвестна?

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

Как быстро отправлять первое сообщение?

Срок зависит от критичности и договора. Для P1 сообщение отправляют после короткого подтверждения и первичной оценки. Не устанавливайте десять минут как обязательство, если команда не может обеспечить его в согласованное сервисное окно.

Как часто давать обновления?

Для активного P1 часто используют интервал 20–30 минут, но это пример, а не универсальное правило. Важнее назвать конкретное время и не пропустить его. Для P2 можно сообщать по контрольным точкам.

Следует ли указывать прогноз восстановления?

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

Что делать, если клиент не отвечает?

Следуйте матрице эскалации: второй канал, резервный представитель, телефон для P1. Фиксируйте попытки связи. Безопасные заранее разрешённые действия выполняйте в пределах договора; решения, требующие согласия, не додумывайте за клиента.

Нужно ли извиняться?

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

Что писать, если проблему вызвал релиз студии?

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

Главное

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

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

Источники и дополнительное чтение

Следующий материал курса: «SLA технической поддержки сайта: что обещать клиенту и как это измерять».

Узнавайте о проблеме раньше клиента

Pingvera следит за сайтами клиентов «снаружи и изнутри» — доступность из регионов, формы, оплата, домен, SSL, сервер — и предупреждает в Telegram, email и Max раньше, чем напишет клиент.

Попробовать Pingvera бесплатно

← Все статьи · Политика конфиденциальности · pingvera.ru · Telegram-канал