Сценарий — это набор разрешённых фактов, веток, действий и стоп-условий. Качество речи не компенсирует ошибку в маршруте после разговора.
Отличия LLM бота от IVR видны в способе обработки неожиданного ответа, но оба варианта требуют проверенного источника фактов. Чат бот или голосовой агент выбирайте по задаче и предпочтениям клиента, а не по общей моде на канал.
Определите результат до настройки
Сформулируйте целевое событие одним проверяемым действием. Для первого участка процесса вопрос звучит так: как отделить входящий сценарий от исходящего? Для второго: как использовать базу знаний без выдуманных ответов? Не подменяйте ответ на эти вопросы количеством звонков: после контакта должно появиться подтверждение клиента, запись в системе или задача конкретному сотруднику.
Первая механика: как отделить входящий сценарий от исходящего
Задайте разные первые реплики, длину вступления и критерии успеха. Общими оставьте только проверенные факты и правила эскалации. Это правило стоит превратить в схему «событие → проверка данных → вопрос клиенту → действие». Укажите для каждого шага источник информации и владельца. Если исходный факт недоступен, агент не должен угадывать: он сохраняет недостающий параметр и передаёт его сотруднику с обещанным сроком.
Голосовой ИИ для звонков проверяйте на шуме, перебиваниях и неверно названных датах, а не только на чистой демонстрационной записи. AI агент для звонков должен повторить критичные данные перед действием и перевести разговор человеку, если уверенность в распознавании недостаточна.
Во входящем разговоре повод звонка принадлежит клиенту. Задача агента — быстро выяснить его и помочь, а не озвучить презентацию. В исходящем разговоре повод должен быть назван агентом и принят собеседником. Разные старты требуют разных критериев успешного разговора.
Для входящего звонка первая полезная реплика может быть вопросом по запросу клиента; для исходящего — объяснением повода и права продолжить. Эти тесты нельзя объединять.
Практический пример. При входящем запросе агент сразу помогает с темой клиента. При исходящем сначала сообщает причину звонка и спрашивает, удобно ли говорить. После разговора проверьте не только формулировку ответа, но и финальную запись: какой исход выбран, какие данные подтверждены самим клиентом, кому назначено действие и когда оно должно быть выполнено. Без этой проверки красивый диалог может закончиться потерей заявки.
Вторая механика: как использовать базу знаний без выдуманных ответов
Разбейте знания на небольшие утверждённые блоки с датой, источником и областью применения. Для отсутствующего ответа предусмотрите уточнение или передачу специалисту. В этой части процесса человек может изменить очерёдность вопросов, выбранную ветку или условие остановки. Поэтому храните последнее подтверждённое состояние и историю изменений. Если финальная карточка расходится с последней репликой клиента, следующий сотрудник повторит вопрос или выполнит неверное действие.
Для базы знаний ведите версии цен и дат вступления условий в силу. Если две карточки отвечают на один вопрос по-разному, правило приоритета должно быть явным. Тестируйте вопросы, где требуется не просто извлечь фразу, а выбрать верную редакцию для конкретного клиента или региона.
У каждого факта в базе знаний должна быть область действия: регион, продукт, период и источник. Без неё правильная цифра из неправильного документа превращается в ошибку.
Сценарий для проверки. В базе есть два прайс-листа. Агент должен видеть действующий тариф для конкретного региона, а не выбирать знакомую цифру из старого файла. Проиграйте соседний вариант: собеседник перебивает агента и меняет ответ на уже заданный вопрос. Агент должен показать границу своих полномочий, обновить именно изменившийся параметр и оставить сотруднику точный открытый вопрос.
Рабочий инструмент и поля для команды
Для входящего сценария приоритет — понять запрос и ответить; для исходящего — быстро объяснить повод и получить разрешение продолжить. Факты храните с источником, владельцем, датой действия и процедурой обновления.
Голосовой ИИ агент для входящих звонков получает контекст до приветствия, чтобы не задавать повторные вопросы после формы на сайте.
В карточке обращения нужны версия сценария, подтверждённые факты, выбранная ветка и стоп-условие. На втором этапе обновляйте эти поля после каждого подтверждённого изменения. Рядом с каждым значением отмечайте источник: сказал клиент, пришло из CRM или рассчитано системой. Сотрудник должен видеть последнее подтверждённое состояние и причину передачи.
Запуск на ограниченном потоке
Быстрая проверка для первого цикла: Возьмите пять вопросов о цене, сроках и наличии и найдите для каждого утверждённый источник, владельца и дату проверки. Не расширяйте охват, пока хотя бы один критичный переход регулярно теряет данные или создаёт необоснованное обещание. При ошибке меняйте конкретный факт, ветку или интеграцию, а затем повторяйте тест на исходном случае и соседних сценариях.
Метрики, формула и интерпретация
Сравнивайте результаты каждого направления отдельно, включая причины завершения и согласие на следующий шаг. Тестируйте точность ответа на наборе типовых и конфликтующих вопросов, а также частоту эскалаций. Точность фактов = подтверждённые актуальные ответы / проверенные ответы; долю раннего отказа исходящих считайте отдельно. В таблице всегда показывайте абсолютные числа рядом с процентами: 4 ошибки из 10 разговоров и 4 из 1000 означают разные задачи. Для длинного цикла сделки задайте окно наблюдения и не приписывайте вчерашней кампании продажи старых лидов.
Ошибки и правила остановки
Один универсальный промпт смешивает ожидания и заставляет входящего клиента слушать ненужную презентацию. Большой объём документов не гарантирует правильный ответ; конфликтующие версии повышают риск ошибки. Для каждого такого случая пропишите стоп-условие: что агент отвечает, какой статус ставит, кому передаёт вопрос и в какие сроки человек возвращается к клиенту. Сохраняйте отдельные исходы для отказа, недозвона, переноса и технического обрыва — повторный контакт для них должен работать по разным правилам.