Аварийное отключение AI-агента: как вернуть процесс людям без потери заявок

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

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

Почему «просто выключить бота» — самый дорогой вариант

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

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

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

Что должно быть готово до инцидента

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

• Владелец выключателя. Один человек с именем и, желательно, заместителем, который имеет право остановить агента без согласования с подрядчиком. Если право на стоп есть только у внешней команды, время реакции измеряется не минутами, а перепиской.
• Стоп-точка в процессе. Согласованное место, после которого агент не продолжает цепочку: например, не отправляет сообщение клиенту и не пишет в CRM, а складывает действие в очередь на подтверждение. Стоп-точка должна быть одна и понятная, а не «где-то в коде».
• Снимок очереди. Возможность выгрузить список диалогов и действий, которые агент держит в работе прямо сейчас: кто клиент, на каком шаге остановились, что обещано. Без снимка передача людям превращается в «перечитайте всю переписку».
• Канал для людей. Заранее известное место, куда падают диалоги после отключения: конкретный чат, конкретная папка, конкретный список в CRM. «Менеджеры увидят в интерфейсе» — не канал, а надежда.
• Журнал. Лог решений и действий агента с временем, входом и результатом. Он нужен не для отчёта, а чтобы после отключения ответить на вопрос «что он успел сделать по этому клиенту».

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

Шаг 1. Объявить инцидент и зафиксировать стоп-точку

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

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

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

Шаг 2. Перекрыть вход, но не потерять входящие

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

Здесь чаще всего и происходит потеря. Агент выключен полностью, включая приём, и всё, что пришло за два часа, не существует ни в CRM, ни в почте, ни в журнале. На следующий день клиент говорит «я писал», а показать нечего.

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

Шаг 3. Разгрузить то, что агент уже начал

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

Удобно раскладывать на четыре группы: действие завершено и подтверждено чтением; действие отправлено, но результат неизвестен; действие начато и не завершено; действие не начиналось. Первая группа закрывается без вмешательства. Вторая — самая опасная, потому что здесь нельзя повторять действие вслепую: сначала читаем состояние у получателя (в CRM, в канале, в платёжной системе), и только если результата нет — выполняем вручную или помечаем как требующее решения. Третья и четвёртая передаются людям.

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

Шаг 4. Передать людям: кому, куда, за какое время

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

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

Отдельно стоит договориться, что делать с диалогами, где агент уже дал обещание от лица компании: цена, срок, скидка. Их нельзя просто продолжить «с чистого листа» — сначала проверяем, что обещание действительно и в каких границах, потом отвечаем. Это тот же принцип проверки перед действием, который описан в evidence-before-write.

Шаг 5. Сверить записи: CRM, деньги, обещания

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

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

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

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

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

Шаг 6. Перезапуск с проверкой

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

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

Если причина инцидента в том, что агент повторял ошибочное действие, полезно посмотреть, как в контуре устроен отзыв собственного «всё хорошо» — об этом отдельный материал про самопроверку агентов и отзыв PASS. Без такого механизма отключение остаётся единственным способом остановить ошибку, а это слишком дорогой инструмент для повседневного использования.

Что говорить клиентам

Клиенты редко замечают, что в компании что-то отключали. Они замечают другое: ответ пришёл позже, чем обычно, или пришёл дважды. Поэтому сообщение должно быть коротким и без технических подробностей: «мы отвечаем вручную, извините за задержку» — достаточно. Хуже всего два варианта: молчание в надежде, что никто не заметит, и объяснение про «сбой бота», которое превращает внутреннюю проблему в вопрос доверия.

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

Пять ошибок, которые превращают отключение в потерю лидов

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

Чек-лист на одну страницу

1. Назван владелец инцидента и человек, который отвечает клиентам.
2. Зафиксированы время, причина и граница остановки; неизвестное помечено как неизвестное.
3. Входящие продолжают фиксироваться без автоматической реакции — проверено тестовым сообщением.
4. Выгружен снимок всех диалогов и действий в работе.
5. Каждое действие отнесено к одной из четырёх групп; «отправлено, результат неизвестен» проверено чтением, а не повтором.
6. По каждому диалогу есть получатель, срок ответа и факт принятия.
7. Проведена сверка CRM, денег и обещаний; составлен реестр с числом неопределённых.
8. Причина устранена; перезапуск проверен полным тестовым диалогом с чтением записи.
9. Накопленная очередь разобрана людьми, агент начал с новых входящих.
10. Инцидент и его причина описаны так, чтобы следующий дежурный не начинал с нуля.