Голосовые роботы для бизнеса: входящий звонок и передача оператору

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

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

Эта статья посвящена разговору в реальном времени. Отдельный материал объясняет, что делать после пропущенного звонка.

Какие входящие звонки подходят голосовому роботу

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

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

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

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

Как устроен голосовой диалог

Голосовой канал состоит из нескольких связанных частей:

1. Телефония принимает входящий звонок и передаёт аудио в процесс.
2. Распознавание речи, или ASR, превращает слова абонента в текст.
3. Сценарная логика или модель определяет намерение и следующее допустимое действие.
4. Инструмент обращается к системе записи, CRM или справочнику, если это предусмотрено процессом.
5. Синтез, или TTS, превращает подготовленный ответ в речь.
6. Телефония передаёт звук абоненту и принимает следующую реплику.

Официальная документация Agent Platform описывает входящие звонки через SIP-подключение и отдельные интеграции ASR и TTS. Она также описывает настройку реакции телефонного агента на паузы и перебивания. Это подтверждает общую последовательность для этой платформы, но не доказывает совместимость с телефонией, CRM или тарифом конкретной компании. Доступные провайдеры, права, регионы работы и способ перевода оператору нужно проверять для выбранной конфигурации.

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

Ответ не появляется мгновенно. Его задержка складывается из времени телефонии, распознавания, логики, внешней системы и синтеза:

T ответа = T телефонии + T ASR + T логики + T интеграции + T TTS

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

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

Как составить сценарий и подтверждать важные данные

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

1. Начало

Робот представляется, кратко обозначает свою роль и предлагает назвать цель звонка. Клиент должен понимать, что говорит с автоматической системой и может попросить человека.

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

2. Определение цели

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

3. Уточнение и идентификация

Для поиска записи робот запрашивает только сведения, разрешённые правилами заказчика. Знание номера телефона само по себе не следует считать достаточным доказательством личности. Допустимый способ идентификации определяет заказчик с учётом характера данных, риска операции и собственных требований.

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

4. Проверка номера, даты или другого значения

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

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

5. Подтверждение действия

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

Неправильная последовательность: «Готово» — затем попытка изменить запись.

Правильная последовательность: «Подтверждаете 12 октября в 16:30?» — ответ клиента — команда изменения — успешный ответ системы — «Запись перенесена на 12 октября, 16:30».

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

Как обрабатывать паузы, шум и перебивания

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

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

При второй неудаче он меняет формулировку или предлагает разрешённую альтернативу: «Произнесите дату по одной части: сначала день» либо «Введите число клавишами телефона», если DTMF допустим в этом сценарии.

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

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

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

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

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

Как передавать звонок человеку

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

Перед переводом робот формирует короткую сводку:

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

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

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

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

Учебный пример переноса записи

Ниже — синтетический пример для проектирования сценария, а не запись реального звонка, клиентский кейс или результат внедрения Switch On AI. Все значения условные.

Клиент звонит, чтобы перенести запись R-104 с 10 октября, 14:00 на 12 октября, 16:30. После успешного переноса он просит соединить его с человеком. Оператор занят.

Ключевой момент примера — разница между намерением, подтверждением клиента и результатом системы. До успешного ответа рабочей системы запись R-104 остаётся на 10 октября в 14:00. После ответа во всех последующих репликах и в сводке оператору указан новый слот: 12 октября в 16:30.

Сводка для сотрудника может выглядеть так: «Клиент запросил перенос записи R-104 с 10 октября, 14:00 на 12 октября, 16:30. Идентификация пройдена по разрешённому правилу. Система записи подтвердила перенос. Клиент попросил человека по дополнительному вопросу. Прямой перевод пока не выполнен: линия занята».

Если бы система записи вернула отрицательный ответ, сводка была бы другой: «Клиент выбрал 12 октября, 16:30, но перенос не подтверждён; действующим остаётся 10 октября, 14:00». Такое различие защищает и клиента, и сотрудника от ложного статуса.

Как проверить звонки и обсудить внедрение

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

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

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

Бюджет = минуты телефонии × тариф связи + объём распознавания × тариф ASR + объём синтеза × тариф TTS + использование модели + интеграционные работы + поддержка

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

Switch On AI может разработать ИИ-помощника, голосового бота или обычную интеграцию для одного согласованного маршрута после проверки данных, API и прав. Подходящий формат зависит от поведения системы: свободное уточнение может потребовать модели, предсказуемая ветка — сценарного бота, а обмен подтверждёнными полями — интеграции. Подробнее об услуге рассказано на странице AI-помощника продаж.

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

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