Если ИИ-ассистент просто отправил команде уведомление, обращение ещё не передано. Нужно определить, кто отвечает клиенту, где хранится исходная переписка, какие действия уже выполнены и что произойдёт при повторном событии. Иначе сотрудник и ассистент могут ответить одновременно, а внешняя операция — выполниться дважды.
Рабочая передача меняет владельца всего обращения. Ассистент останавливает самостоятельные содержательные ответы, сотрудник получает контекст и принимает дальнейшую коммуникацию. Возврат к автоматизации происходит только по явному правилу и с актуальным состоянием.
Ниже — требования к проектированию. Это не перечень функций, которые автоматически доступны в любой платформе.
Когда диалог должен перейти к сотруднику
Правила передачи задаёт владелец процесса. Универсальный процент уверенности модели не заменяет такие правила: один и тот же ответ может быть допустим как справочная подсказка и недопустим как основание для изменения заказа.
Диалог следует остановить и передать сотруднику, если:
- клиент прямо просит позвать человека;
- в разрешённых источниках нет подтверждённого ответа;
- запрос выходит за полномочия ассистента;
- сообщения содержат противоречивые или неполные сведения;
- клиенту нужно профессиональное или управленческое решение, которое система принимать не уполномочена;
- канал, рабочая система или сам маршрут передачи дал сбой.
Для каждого основания заранее задают видимый клиенту статус и следующее допустимое действие. Например, при отсутствии ответа ассистент может сообщить, что обращение передано сотруднику, но не должен придумывать решение или обещать неподтверждённый срок.
В официальной документации n8n описан демонстрационный workflow: он пытается ответить пользователю, а при невозможности вызывает вспомогательный workflow и отправляет сообщение в Slack с просьбой о помощи человека. Это подтверждает возможность построить такую учебную последовательность в n8n, но не готовую очередь операторов, назначение ответственного или передачу полной истории разговора.
Чем передача диалога отличается от подтверждения действия
Передача диалога и human-in-the-loop решают разные задачи.
| Процесс | Что получает человек | Что происходит с диалогом |
|---|---|---|
| Передача обращения | Переписку, состояние, причину передачи и ответственность за следующий ответ | Ассистент прекращает самостоятельные содержательные ответы |
| Подтверждение действия | Запрос на разрешение отдельного вызова инструмента | Владелец диалога может не меняться |
Если таблица не помещается, прокрутите её вправо. С клавиатуры используйте стрелки.
Документация n8n для AI Agent описывает проверку выбранного инструмента человеком: workflow приостанавливается, показывает проверяющему инструмент и предложенные ИИ параметры, затем ждёт одобрения или отказа. Одобрение запускает инструмент, отказ отменяет действие. Это не означает, что сотрудник принял весь разговор.
Например, менеджер может разрешить отправку сообщения, но не становиться владельцем обращения. И наоборот: оператор может принять диалог, не одобряя никаких действий агента. Если процессу нужны оба механизма, для них задают отдельные состояния и события, а не один общий флаг «нужен человек».
Какие состояния нужны маршруту обращения
Состояние должно отвечать на три вопроса: кто сейчас владеет следующим действием, кому разрешено отвечать и при каком событии маршрут изменится. Состав и названия состояний выбирают под конкретный процесс.
| Состояние | Владелец следующего действия | Разрешённое действие и переход |
|---|---|---|
| Ассистент ведёт диалог | Ассистент | Ответить в пределах полномочий либо запустить передачу |
| Требуется передача | Система маршрутизации | Создать одну карточку передачи |
| Ожидается назначение | Очередь или ответственная роль | Назначить сотрудника либо зафиксировать ошибку |
| Сотрудник принял обращение | Назначенный сотрудник | Подтвердить принятие; заблокировать содержательные ответы ассистента |
| Сотрудник ведёт диалог | Назначенный сотрудник | Ответить, запросить сведения, решить вопрос или подготовить возврат |
| Ожидаются сведения клиента | Назначенный сотрудник | Принять новое сообщение без смены владельца |
| Решено | Сотрудник | Закрыть обращение либо выбрать разрешённый следующий маршрут |
| Возвращено автоматизации | Ассистент | Выполнить только переданную ему задачу |
| Закрыто | Нет активного владельца | Новое обращение открыть по отдельному правилу |
| Ошибка передачи | Ответственный за восстановление | Повторить доставку или применить ручной маршрут без второй карточки |
Если таблица не помещается, прокрутите её вправо. С клавиатуры используйте стрелки.
Повтор одного события не должен создавать новую передачу или повторять внешнее действие. Для этого проектируют идемпотентную обработку: у передачи и операции есть устойчивый идентификатор, а обработчик сначала проверяет уже записанный результат.
Также нужен единый источник текущего состояния и владельца ответа. Запись «сотрудник принял обращение» должна запрещать ассистенту содержательные ответы до явного возврата.
Какой контекст передать сотруднику
Карточка передачи помогает сотруднику продолжить разговор без просьбы пересказать всё заново. В неё включают только разрешённые для этого процесса данные:
- идентификаторы обращения и клиента;
- канал общения;
- исходную переписку и последнее сообщение;
- причину передачи;
- подтверждённые факты и их источники внутри рабочего процесса;
- неизвестные или противоречивые сведения;
- уже выполненные действия и их результаты;
- незавершённые операции;
- вложения и ссылки на записи в рабочих системах;
- действия, которые нельзя повторять.
Краткая сводка экономит время, но не заменяет оригинал. Её следует хранить рядом с исходными сообщениями и помечать как производный текст. Если сводка утверждает то, чего клиент не сообщал и система не подтвердила, сотрудник должен увидеть расхождение, а не принять догадку за факт.
В механизме проверки инструментов n8n сотруднику можно показать название инструмента и параметры, которые предложил ИИ. Эти сведения полезны для согласования отдельного действия, но не доказывают полноту карточки всего обращения: история, вложения и журнал предыдущих операций требуют отдельного проектирования.
Как назначить ответственного и сообщить клиенту статус
Маршрут назначения описывают до запуска: какая команда принимает обращения, как учитываются специализация и доступность, кто считается текущим владельцем и куда уходит задача, если назначение невозможно.
Полезно разделить четыре события:
- Система создала карточку передачи.
- Канал доставил уведомление команде.
- Конкретный сотрудник принял обращение.
- Сотрудник ответил клиенту.
Доставка уведомления не равна принятию обращения. Поэтому клиенту показывают только фактический статус: «обращение передано», «сотрудник принял обращение», «нужны дополнительные сведения» или «канал временно недоступен». Неподтверждённый срок ответа обещать не нужно.
Если уведомление не доставлено, система должна оставить наблюдаемую ошибку. Повторная доставка использует тот же идентификатор передачи и не создаёт вторую карточку. Для случая, когда автоматический маршрут не восстановился, заранее назначают ручной способ найти обращение и передать его ответственному.
Как исключить параллельные ответы и повторные действия
Одновременно содержательно отвечать клиенту должен один владелец. После принятия обращения сотрудником ассистент может показывать технический статус, если это предусмотрено процессом, но не продолжать консультацию и не запускать внешние действия.
Для этого нужны:
- единая запись о состоянии диалога и владельце ответа;
- проверка состояния непосредственно перед отправкой сообщения;
- отдельные события создания передачи, уведомления, назначения и ответа;
- идентификатор каждой операции с внешними последствиями;
- проверка результата операции перед повторной попыткой;
- журнал смены состояний и попыток выполнения.
Например, сообщение в командный канал подтверждает только отправку уведомления в рамках заданного подключения. Оно не подтверждает, что сотрудник увидел задачу, принял её и ответил клиенту.
Эти ограничения не возникают автоматически из самого факта использования ИИ-агента, чат-бота, n8n или CRM. Их закрепляют в архитектуре и проверяют на согласованных сценариях.
Как вернуть диалог автоматизации
Возврат разрешает уполномоченный сотрудник либо заранее описанное событие процесса. Истечение произвольного таймера не должно молча передавать ответственность обратно ассистенту.
Перед возвратом ассистент получает:
- актуальное состояние обращения;
- подтверждённое решение сотрудника;
- одну разрешённую следующую задачу;
- перечень уже выполненных действий;
- запреты на повтор операций;
- сведения, которых всё ещё не хватает.
Неподтверждённые догадки из краткой сводки нельзя загружать как факты. В зависимости от процесса ассистент может продолжить информационный диалог, выполнить один ограниченный шаг или остаться отключённым до закрытия обращения.
Если после возврата клиент сообщает новые рискованные, противоречивые или выходящие за полномочия сведения, правила передачи запускаются снова. Новое событие связывают с существующей историей, но обрабатывают по актуальному состоянию.
Условный маршрут одного обращения
Ниже — синтетический учебный пример. Это не клиентский кейс Switch On AI и не результат выполненного теста.
Клиент просит изменить уже согласованные условия заказа, а новые сведения сообщает частями. Ассистент не уполномочен менять условия, поэтому прекращает самостоятельные ответы и создаёт передачу сотруднику.
| Событие | Состояние и владелец | Доступный контекст | Разрешённое действие | Запись в журнале |
|---|---|---|---|---|
| Клиент просит изменить условия | Требуется передача; система маршрутизации | Исходные сообщения, канал, причина остановки | Создать карточку с устойчивым идентификатором | Причина и время смены состояния |
| Система уведомляет команду | Ожидается назначение; очередь | Оригинал, сводка, подтверждённые и неизвестные сведения | Доставить уведомление; не обещать принятие | Результат доставки |
| То же уведомление приходит повторно | Ожидается назначение; очередь | Идентификатор существующей передачи | Не создавать вторую карточку | Повтор распознан |
| Клиент добавляет новые условия | Ожидается назначение; очередь | Новое сообщение рядом с исходной историей | Дополнить карточку; не отвечать по существу | Сообщение добавлено |
| Сотрудник принимает обращение | Сотрудник ведёт диалог; назначенный сотрудник | Полная переписка, сводка, действия и запрещённые повторы | Заблокировать содержательные ответы ассистента | Новый владелец и время принятия |
| Сотрудник уточняет условия | Ожидаются сведения клиента; сотрудник | Исходный запрос и заданный вопрос | Принять ответ клиента без смены владельца | Вопрос и новое сообщение |
| Сотрудник фиксирует решение | Решено; сотрудник | Подтверждённое решение и журнал действий | Закрыть обращение или подготовить возврат | Решение и выбранный исход |
Если таблица не помещается, прокрутите её вправо. С клавиатуры используйте стрелки.
У примера два допустимых завершения. В первом сотрудник закрывает обращение, и ассистент больше ничего не выполняет. Во втором сотрудник возвращает автоматизации конкретную задачу, например сообщить клиенту уже утверждённое решение. Вместе с задачей передаются актуальное состояние и список выполненных действий, чтобы система не повторила изменение заказа или уведомление.
Проверка, ограничения и подготовка внедрения
До рабочего запуска маршрут проверяют на смысловых сценариях, а ожидаемый результат записывают заранее.
| Сценарий | Что проверять |
|---|---|
| Клиент просит человека | Ассистент останавливается, клиент видит верный статус |
| Ответа нет или запрос вне полномочий | Нет догадки; сотрудник получает исходную переписку |
| Сведения противоречат друг другу | Противоречие отмечено, сводка не выдаёт вывод за факт |
| Очередь сотрудников недоступна | Ошибка видна, обращение доступно для ручного восстановления |
| Событие передачи повторилось | Вторая карточка и повторное внешнее действие не созданы |
| Клиент пишет во время ожидания | Сообщение добавлено в ту же историю, владелец определён |
| Сотрудник отвечает | Ассистент не отправляет параллельный содержательный ответ |
| Ассистент пытается действовать после передачи | Действие заблокировано и зафиксировано |
| Сотрудник возвращает диалог | Переданы решение, состояние и ограниченная следующая задача |
| Клиент пишет после закрытия | Применяется заранее выбранное правило нового обращения |
Если таблица не помещается, прокрутите её вправо. С клавиатуры используйте стрелки.
Отдельно проверяют права сотрудника на просмотр диалога, допустимый состав данных, сохранность оригинальной переписки, журнал состояний, сбой канала уведомления и восстановление без потери обращения. Универсального числа проверок, срока ответа или порога уверенности здесь нет: критерии определяет владелец конкретного процесса.
Документированный пример n8n подтверждает, что workflow может вызвать вспомогательный workflow и отправить сообщение человеку. Документация human-in-the-loop подтверждает приостановку перед выбранным инструментом, показ его параметров и ожидание решения. Эти функции не подтверждают готовую очередь операторов, назначение владельца, полную передачу истории, SLA или безопасный возврат диалога — всё это нужно спроектировать и принять отдельно.
До оценки внедрения подготовьте один тип обращения, несколько обезличенных диалогов, список участвующих сотрудников и систем, правила полномочий и желаемые состояния. Также отметьте, какие сообщения и действия нельзя повторять.
Switch On AI разрабатывает ИИ-агентов под конкретные операции компании: от требований и прототипа до проверки, внедрения и передачи кода в согласованном объёме. Чат-бот здесь служит каналом диалога, агент выбирает следующий шаг из разрешённых, а обычная интеграция выполняет заранее заданную последовательность — эти роли не следует смешивать.
Чтобы обсудить свой процесс, покажите один тип обращения, правила передачи и используемые каналы. На созвоне можно разобрать маршрут, затем подготовить ТЗ и коммерческое предложение и при необходимости собрать бесплатный прототип ключевого сценария. Прототип не равен полноценному внедрению; подключения, доступы, эксплуатация и сопровождение согласуются отдельно.
Вопросы по этой задаче
Когда ИИ-ассистент обязан передать диалог сотруднику?
Когда клиент просит человека, подтверждённого ответа нет, запрос выходит за полномочия, сведения противоречат друг другу, требуется профессиональное решение или произошёл технический сбой. Конкретные основания задаёт владелец процесса.
Что передавать сотруднику: всю переписку или краткую сводку?
Сотруднику нужна исходная переписка, а сводка может храниться рядом как производный текст. В карточку также включают причину передачи, подтверждённые и неизвестные сведения, выполненные действия, незавершённые операции и запреты на повтор.
Как не допустить одновременных ответов ИИ и сотрудника?
Нужны единый источник состояния, один текущий владелец ответа и проверка состояния перед отправкой. После принятия обращения сотрудником ассистент не отвечает по существу до явного события возврата.
Чем передача диалога отличается от ручного подтверждения действия?
При передаче сотрудник принимает ответственность за дальнейшую коммуникацию. При ручном подтверждении человек только разрешает или отклоняет отдельный вызов инструмента; владелец всего диалога при этом может не меняться.
Когда диалог можно вернуть ИИ-ассистенту?
После явного решения уполномоченного сотрудника или заранее описанного события. Ассистенту передают актуальный статус, подтверждённое решение, ограниченную следующую задачу и перечень уже выполненных действий.