Голосовой робот и IVR компании: как пройти маршрут до человека

В учебном обзвоне компаний голосовой агент соединяется с номером и начинает объяснять предложение. В ответ звучит приветствие: «Для отдела продаж нажмите один». Агент продолжает рассказ, потому что техническое соединение уже состоялось. Система фиксирует длинный звонок, хотя никто из людей не слышал предмет обращения. На уровне телефонии событие успешно, на уровне задачи — ещё нет.

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

Робот услышал голос, но разговор с человеком ещё не начался

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

Для Фонекса, ИИ-продавца в звонках такой сценарий требует проверки конкретного подключения и возможностей телефонии. Эта статья не утверждает, что любые меню автоматически проходят в стандартной поставке. Мы рассматриваем методику задания, тестирования и учёта результата. Если нужный шаг не поддержан, корректный выход — остановить попытку и передать понятную причину, а не имитировать успешный разговор.

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

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

Технический ответ и деловой контакт должны иметь разные статусы

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

В учебном примере меню перечисляет продажи, поддержку и общие вопросы. Выбор зависит от предмета обращения. Нельзя автоматически направлять любой коммерческий разговор в поддержку только потому, что туда быстрее отвечают. Роль получателя должна соответствовать задаче. Иначе агент увеличит нагрузку на не ту команду и получит нерелевантный ответ, который потом ошибочно попадёт в аналитику.

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

Документация конкретных платформ помогает разделить эти механизмы. Twilio описывает сбор тонального и речевого ввода через Gather. Это возможность выбранного инструмента, а не подтверждение автоматического прохождения всех IVR Фонексом. Для проекта необходимо проверить, какие события и действия доступны в фактическом подключении.

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

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

Слушаем меню целиком в достаточных границах

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

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

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

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

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

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

После выбора проверяем изменение состояния

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

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

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

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

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

Ставим предел навигации до запуска кампании

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

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

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

Учебная запись маршрута может выглядеть так. Это структура задания и результата, а не API Фонекса или универсальная конфигурация телефонии.

{
  "purpose": "Уточнить деловой маршрут по предмету предложения",
  "navigation": {
    "input_mode": "Подтверждается в конкретном подключении",
    "target_role": "Функция, относящаяся к предмету обращения",
    "steps": [
      "Распознать доступные варианты",
      "Выбрать соответствующий предмету",
      "Проверить состояние после команды"
    ],
    "time_budget": "Значение, принятое для пилота",
    "loop_policy": "Остановить повтор без нового состояния"
  },
  "result": {
    "technical_connection": true,
    "human_conversation": false,
    "reason": "Нужная роль пока не достигнута",
    "commercial_interest": "Не оценивался"
  }
}

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

Проверяем IVR отдельно от текста продажи

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

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

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

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

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

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

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

Что включить в отчёт по первому опыту

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

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

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

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

Граница приёмки: система понимает, с кем она ещё не разговаривала

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

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

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