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