Внешний сервис “лежит”: план действий для бизнеса

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

1) Сначала — понять, что именно сломалось и насколько критично

Не надо гадать по сообщениям менеджеров “вроде не отправилось”. Нужно быстро ответить на три вопроса:

• Это массовая проблема или единичные случаи?
• Это полностью недоступно или работает “через раз”?
• Что именно ломается: прием заявок, оплата, выдача статуса, передача данных?

Для бизнеса это означает: кто принимает решение “включаем упрощенный режим”, и как быстро.

2) Включаем “режим деградации”: работаем проще, но не останавливаемся

“Деградация” — это когда система временно делает меньше, но стабильно. Примеры понятным языком:

• Платежи не проходят → принимаем заказ без оплаты, отправляем ссылку на оплату позже, фиксируем обязательства.
• Сервис доставки не отвечает → оформляем заказ, показываем клиенту “расчет доставки уточним”, менеджер перезванивает.
• SMS/WhatsApp не отправляются → переключаемся на email или звонок, или копим сообщения для отправки позже.

Главное правило: клиент должен получить понятный статус, а менеджер — понятную задачу, что сделать вручную.

3) Не теряем заявки: “складируем” операции до восстановления

Самая частая беда — “заявка улетела в никуда”. Чтобы этого не было, действия должны записываться у вас, даже если внешний сервис сейчас молчит.
На бизнес‑языке это выглядит так:

• каждое действие клиента (заказ/оплата/регистрация) сохраняется у вас как “ожидает отправки/подтверждения”;
• после восстановления сервисов система сама “догоняет” хвост.

В результате вы не теряете деньги и не ищете потом по чатам “кому мы не ответили”.

4) Защищаемся от повторов: чтобы не списать дважды и не создать дубль

Когда сервис “моргает”, возникает риск: пользователь нажал “оплатить” ещё раз, менеджер повторно отправил заказ, система пересоздала заявку. Итог — двойные списания, двойные заказы, хаос в отчетности.
Нужны простые бизнес‑правила:

• один заказ = один уникальный номер у вас;
• повторная попытка должна “узнавать” заказ и продолжать, а не создавать новый;
• если что-то не подтверждено — показываем статус “проверяем”, а не “платеж не прошел, платите снова”.

5) Договариваемся о ручном обходе: кто делает что, пока автоматизация “на паузе”

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

• где смотреть зависшие заказы/заявки;
• как отмечать “принято вручную”;
• какие шаблоны сообщений отправлять клиентам;
• кому эскалировать (один ответственный, а не 10 чатов).

Если это заранее не описано, в стрессовой ситуации сотрудники начинают “каждый по‑своему”, и потери растут.

6) Что фиксировать во время сбоя, чтобы потом не разбираться неделями

Бизнесу полезно не “разбирать логи”, а фиксировать:

• время начала/конца проблемы;
• сколько заявок/заказов встало;
• сколько было повторов/отмен;
• сколько клиентов пожаловались.

Эти цифры — основа, чтобы: (а) оценить ущерб, (б) обосновать доработки, (в) требовать качества от поставщика или подрядчика.

7) После восстановления — аккуратное “догоняем хвост”, а не “пуляем всё сразу”

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

• отправлять партиями;
• проверять статусы;
• иметь список “проблемных” операций для ручной обработки.

8) Профилактика: что заложить в проект заранее (и сэкономить на авариях)

Для владельца бизнеса важно не название механизма, а эффект:

• заявки не теряются;
• деньги не списываются дважды;
• менеджеры не слепнут, когда “что-то не дошло”;
• клиент видит честный статус.

Если этого нет — интеграция выглядит красиво на демо, но бьёт по выручке в реальности.