Как передать сложную заявку от ИИ человеку: карточка и подтверждение приёма

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

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

Определите, на каком сообщении бот останавливается

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

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

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

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

Соберите карточку, по которой можно продолжить работу

Краткое описание помогает быстро начать, а исходная переписка нужна для проверки деталей. В протоколе передачи Microsoft Bot Framework SDK v4 событие начала передачи может включать контекст для маршрутизации и запись разговора для сотрудника. Это пример устройства конкретного протокола; наличие бота само по себе не означает, что такая передача настроена.

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

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

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

Отделите уведомление от принятия

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

В том же протоколе Microsoft статус accepted означает, что сотрудник принял запрос и управление разговором; отдельно описаны failed и completed. Это технический пример различия состояний, а не обязательные названия статусов для вашей CRM.

Уведомление о необходимости передачи тоже может требовать отдельной реализации. В Dialogflow CX REST v3 объект LiveAgentHandoff используется для учёта переданных разговоров; дальнейшие действия по сигналу оставлены процедуре передачи разработчика. Поэтому при проверке конкретного решения просите показать весь переход до принимающего сотрудника.

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

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

Пройдите один случай от карточки до приёма

Учебный пример: все сведения, ID и события ниже вымышлены. Клиент в беседе H-104 пишет: «Счёт оплатили, но доступ не появился. Повторно платить не будем». Бот нашёл общую инструкцию об активации, но не имеет доступа к проверке поступления платежа. Он передаёт случай специалисту, который вправе такую проверку выполнить.

Карточка должна сохранить следующие различия:

• Желание клиента: получить доступ после заявленной оплаты; повторная оплата отвергнута.
• Со слов клиента: счёт оплачен. Подтверждение поступления денег: не проверено.
• Уже сделано: дана общая инструкция. Изменение доступа и возврат: не выполнялись.
• Следующее действие: проверить поступление платежа в разрешённой системе, затем сообщить допустимый вариант решения.
• История: ссылка на H-104. Принимающая роль: специалист по оплатам; резерв: руководитель смены.

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

Испытайте отказ, а не только обычную передачу

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

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

Начните с одной очереди

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

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