ТЗ на бота поддержки: ответы, эскалация и передача оператору

Определите границу самостоятельной помощи

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

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

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

Назначьте владельцев знаний и сроков обновления

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

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

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

Опишите уточнение и выход из тупика

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

Документация Microsoft Copilot Studio показывает отдельный системный сценарий fallback для ситуаций, когда обычный маршрут не найден. В собственном проекте важно согласовать смысл такого выхода: предложить релевантные варианты, уточнить вопрос или передать обращение. Наличие встроенного механизма не доказывает, что ваш диалог перестал зацикливаться; это проверяют на характерных примерах.

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

Согласуйте контракт передачи оператору

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

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

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

Предусмотрите нерабочее время и потерю соединения

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

Разберите закрытие чата и повторное обращение. Как человек находит существующий запрос? Сохраняется ли история между каналами? Что происходит, если он пишет с другого устройства? Требования должны учитывать ограничения идентификации и не объединять разные обращения только по похожему имени. При отсутствии достоверной связи лучше предусмотренная проверка, чем случайное раскрытие чужой истории.

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

Измеряйте помощь, а не объём переписки

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

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

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

Принимайте бота на наборе сложных обращений

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

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

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

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

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

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

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

Передайте редакционную и операционную ответственность

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

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

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