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

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

Удобнее всего заранее настроить ИИ-сотрудника в Ное, который будет отвечать клиентам по утверждённым фактам и передавать всё непонятное человеку. Я предлагаю использовать маршрут: зайти на новый лендинг Нои → зарегистрироваться или войти → создать ИИ-сотрудника для клиентского сервиса → выдать ему промпт из этой статьи → протестировать на учебных вопросах до подключения каналов.

Коротко

1. Не тяните с первым коротким уведомлением, даже если срок восстановления неизвестен.
2. Я советую заранее продумать четыре типа сообщений: первый статус, обновления, перенос работы, завершение.
3. Я советую подготовить сообщение заранее и выбрать подходящий для этой договорённости канал; сам текст не означает, что он уже отправлен.
4. Я предлагаю использовать простые шаблоны сообщений и один ответственный канал для обновлений.
5. Ноя может помочь готовить ответы и вести переписку в рамках заданных правил, а вопросы «выше уровня» отдавать человеку.

Что считать «сбоем» и почему клиенты злятся

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

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

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

Четыре типа сообщений клиентам при проблемах с сервисами

Я предлагаю всегда держать в голове четыре типа сообщений и под каждый иметь набор шаблонов:

1. Первое уведомление о сбое.
2. Обновление статуса, даже если срок не прояснился.
3. Сообщение о переносе работы или изменении условий.
4. Завершение инцидента и фиксация договорённостей.

В таблице ниже — краткая схема.

В документации AWS RTO — допустимая задержка восстановления, RPO — допустимый промежуток от точки восстановления. Это цели конкретного бизнеса, а не прогноз или обещание провайдера. В разговоре с клиентом отдельно уточняют его договорённость и фактический статус задачи.

Случай отказа: есть только первое сообщение, а дальше — затишье. Тогда клиенты начинают придумывать своё объяснение ваших действий.

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

Для подготовки фактов сначала отделите сообщение статуса от собственного наблюдения. Дата поставщика не время вашей проверки.

Я советую проверить три пункта перед первым сообщением:

1. Вы можете описать подтверждённый симптом конкретной операции; общий диагноз не обязателен.
2. У вас есть хотя бы ориентир, когда вы обновите статус, даже без срока.
3. Вы выбрали основной канал для статуса (например, страница статуса или отдельный пост).

Структура первого сообщения:

• Факт: что именно не работает и для кого.
• Область: какие клиенты/функции затронуты.
• Действие: что действительно начато, если это подтверждено; иначе внутренний вопрос ответственному.
• Следующий шаг: когда и где ждать следующего обновления.

Пример с полями, которые заполняет ответственный:

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

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

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

Обновления без нового срока: как говорить «пока не знаем»

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

Если срок всё ещё непонятен, обновление всё равно нужно. Структура:

• Статус диагностики: что уже понятно, а чего нет.
• Конкретное действие, которое вы сейчас делаете.
• Новое время следующего обновления, даже если это «послезавтра».

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

Обновление статуса по оформлению заказов:
Мы сузили проблему до сбоя в модуле приёма заявок. Сейчас проверяем два варианта обходного решения. Срок восстановления пока не можем назвать: тестирование ещё идёт. Следующее обновление опубликуем завтра до 13:00 (оценка).

Пометка «оценка» не делает неподтверждённый срок правдивым и не изменяет договорённость автоматически. Назовите источник оценки и её пределы. Юридический эффект формулировки эта статья не устанавливает.

Случай отказа: вы просто повторяете первое сообщение без новых деталей — у клиента ощущение, что никто ничего не делает.

Перенос работы и изменения условий: как не потерять договорённости

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

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

Когда вы предлагаете перенос, сообщение должно содержать:

1. Что именно переносится и почему.
2. Какие у клиента есть варианты (минимум два).
3. Как вы зафиксируете выбранный вариант.

Пример шаблона переноса для заранее согласованных доступных вариантов; обещания связи и изменения условий также утверждает ответственный:

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

1. перенести старт на первую доступную дату после восстановления;
2. перераспределить часть работ на другой формат (обсудим по телефону). Ответ можно дать в этом чате, мы зафиксируем договорённости и отправим вам подтверждение.

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

Завершение инцидента: как закрыть тему и сохранить лицо

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

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

Структура завершения:

1. Краткий итог: что восстановлено.
2. Уточнение: возможны ли остаточные эффекты.
3. Напоминание о перенесённых договорённостях.
4. Куда писать, если клиент считает, что его ситуация не закрыта.

Пример после проверки конкретной функции и сохранения согласованных условий:

Работа онлайн-заказов восстановлена, новые заказы снова принимаются через сайт и мессенджеры. Возможны единичные задержки в отражении статуса заказов в личном кабинете; если вы видите несоответствия, напишите в чат поддержки. Все переносы и изменения, которые мы с вами согласовали за время сбоя, остаются в силе. Если что-то в вашем заказе выглядит неверно, сообщите нам, мы разберёмся и предложим решение.

Случай отказа: вы просто сообщаете «починили», но клиенты с незакрытыми вопросами не понимают, что делать дальше; часть из них просто перестаёт к вам возвращаться.

Отдельные шаблоны для разных каналов: сайт, мессенджер, email, телефон

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

Я считаю ошибкой писать одно и то же сообщение для всех каналов. Тон и длина должны отличаться.

Краткая таблица подходов:

Я предлагаю:

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

Случай отказа: менеджеры на телефоне говорят одно, чат — другое, страница статуса — третье. В результате клиенты чувствуют хаос.

Две учебные ситуации малого бизнеса и разбор решений

Ситуация 1. Небольшое туристическое агентство

Вымышленное турагентство «Город рядом» продаёт авторские туры выходного дня. Основной канал продаж — сайт и VK, заявки уходят в CRM.

В пятницу вечером CRM перестаёт открываться. Доступ к базе клиентов ограничен; бронирования последних двух дней под вопросом.

Я предлагаю агентству такой план:

• Первое сообщение на сайте и в соцсетях: статус проблемы с CRM, кого затрагивает.
• Личные сообщения клиентам с ближайшими турами: текст о подтверждённом статусе конкретной брони; проверку и будущий ответ обещают после решения ответственного.
• Согласованный закрытый журнал как временный реестр; клиентские данные не отправляют в промпт или открытую таблицу.

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

Случай отказа: агентство ждёт до утра понедельника, надеясь, что CRM «сама поднимется», а клиенты в субботу стоят на вокзале без подтверждения тура.

Ситуация 2. Небольшой онлайн-магазин одежды

Магазин «Тихие рубашки» принимает заказы через сайт. В вымышленной ситуации после попытки оплаты появляется ошибка; успешность конкретных операций пока не установлена.

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

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

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

Типичные ошибки при сообщениях о сбое и как их избежать

Я предлагаю заранее проговорить с командой типовые ошибки:

1. «Всё под контролем», когда на самом деле вы ещё не знаете причину.
2. Слишком оптимистичные сроки восстановления без оговорки, что это оценка.
3. Обвинение провайдера по догадке: «виноват хостинг», «банк не проводит платежи».
4. Полное молчание в надежде, что никто не заметит.

Как их избежать:

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

Случай отказа: вы кидаетесь из крайности в крайность — сначала умалчиваете, потом публикуете слишком подробный технический текст, который пугает клиентов.

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

Тест на понятность:

1. Даёт ли текст ответ на вопрос «что со мной и моим заказом»?
2. Понятно ли, что я могу сделать сейчас?
3. Известно ли, где и когда ждать следующего обновления?

Я считаю полезным прогонять текст через человека «со стороны» или через ИИ-сотрудника, который отмечает неясные формулировки. Но окончательное решение должен принимать ответственный менеджер.

Тест на честность:

• Нет ли обещаний, которые вы не контролируете (например, «банк точно всё решит сегодня»)?
• Не звучите ли вы так, будто перекладываете ответственность на клиента («вы сами виноваты, что не сделали резервную копию»)?
• Не создаёте ли впечатление, что всё уже в порядке, если на самом деле ещё есть риски?

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

Риски фишинга: как не превратить уведомление в повод для мошенников

По справке Яндекса , фишинговые письма и сайты часто маскируются под официальные уведомления. Мошенники могут:

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

Я предлагаю:

• Никогда не просить клиентов в уведомлениях о сбое прислать пароли, коды подтверждения или полные данные карты.
• Отдельно напомнить в письмах и на сайте, какие данные вы не запрашиваете.
• Использовать понятный, проверяемый маршрут: например, клиент сам набирает адрес вашего сайта в браузере, а не кликает по странной ссылке.

Случай отказа: вы рассылаете письма с просьбой «подтвердить данные», не объяснив, что это связано со сбоем; часть клиентов может перепутать ваши письма с фишинговыми.

Как использовать Ною как ИИ-сотрудника клиентского сервиса

Ноя — платформа, где можно создать ИИ-сотрудника, который помогает отвечать клиентам в рамках заданных правил. В нашем сценарии он:

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

Маршрут для читателя:

1. Перейти на лендинг Нои.
2. Зарегистрироваться или войти.
3. Создать отдельного ИИ-сотрудника для подготовки статусов и ответов.
4. Вставить промпт из следующего раздела как полную инструкцию.
5. Ввести учебные обезличенные данные.
6. Прогнать тестовые ситуации, похожие на ваши реальные, но без секретов и клиентских баз.
7. Настроить каналы только после ручной проверки ответов.

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

Подробный промпт для Нои по теме сбоев и статусов

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

Исходные данные:
[БИЗНЕС] — тип компании, если он задан.
[СООБЩЕНИЕ_КЛИЕНТА] — что человек сообщил своими словами, без реальных контактов и секретов.
[ПОДТВЕРЖДЁННЫЕ_ФАКТЫ] — отдельные результаты проверок. Сообщение о списании не означает подтверждённый платёж.
[ДЕЙСТВИЯ_КОМАНДЫ] — только реально начатые действия. Если их нет во вводных, нельзя написать «мы проверяем».
[СОГЛАСОВАННЫЙ_КОНТАКТ] — только проверенный путь либо «не подтверждён».
[СЛЕДУЮЩЕЕ_СООБЩЕНИЕ] — время и канал, если ответственный их согласовал; иначе неизвестны.
[ДОГОВОРЁННОСТЬ] — только реально указанные условия. Предложение скидки не означает согласованную скидку.

Формат результата — четыре коротких блока, примерно 350–500 слов, затем не более трёх важных вопросов.
1. Подтверждённые сведения. Раздели слова клиента, проверенный результат и предложение владельца. Не переносить действие с предложенной площадки на фактическое место исходной операции.
2. Неизвестное. Причина, время, статус сохранения и оплаты, наличие прежней договорённости остаются неизвестными, если не подтверждены. Не считай отсутствие данных доказательством отсутствия заказа, оплаты или договора.
3. Черновик клиенту. Напиши 3–5 предложений только по фактам его обращения. Используй «по вашему сообщению», когда это источник. Не пиши о начатой проверке, передаче менеджеру, общесистемном сбое, сохранённой заявке, будущем ответе или сроке, если пользователь этого не подтвердил. Не вставляй неизвестные поля в публичное сообщение как заполненную информацию. Если нет безопасного следующего пути, оставь вопрос ответственному во внутреннем блоке.
4. Внутренний следующий шаг. Составь до пяти вопросов/решений для человека. Не обещай выполнить действие. При неизвестной оплате сначала требуется официальный результат первой операции. При неизвестной записи — проверка её сохранения и получение ответственным. Конкретную систему и человека не угадывай.
5. Проверь текст перед выводом. Каждое утверждение о действии должно иметь явный факт во вводных. Удали «мы уже», «мы разбираемся», «сообщим», «всё сохраняется», если таких фактов или согласований нет. Не подставляй системную дату и время.
6. Если данных мало, всё равно дай короткий полезный черновик по имеющимся сведениям. Не выводи полную анкету. Не используй шаблоны будущего переноса и компенсации, если решение не принято.
7. Заверши не более чем тремя вопросами о важных неизвестных. Это помощь подготовке документа, не автоматическая отправка клиенту.

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

Предупреждение Selectel о задержке ответа и сообщение Yandex Cloud о частичной поддержке — разные источники со своими датами. Они не дают готового срока исполнения вашего заказа.

Вопросы и ответы

Как быстро нужно сообщать клиентам о сбое?

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

Что писать, если я совсем не знаю сроков восстановления?

Прямо так и напишите: «срок пока не ясен, следующее обновление будет тогда-то (оценка)». Добавьте одну-две фразы о том, что уже сделано.

Надо ли рассказывать технические детали сбоя?

Обычно нет. Клиенту важнее, что с его заказом и что он может сделать. Технику оставьте во внутреннем описании, во внешнем тексте — минимум жаргона.

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

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

Что делать, если сбой на стороне партнёра или провайдера?

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

Можно ли использовать один текст для всех каналов?

Базовую суть — да, но я советую адаптировать длину и тон. В мессенджерах короче, на сайте структурированнее, в email можно дать больше деталей.

Зачем мне Ноя, если у меня уже есть шаблоны писем?

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

Вывод и следующий шаг

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

Как мы проверяли статью и что изменилось

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

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

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

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

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