Клиент звонит в сервисную компанию: «Во вторник не получится, можно после обеда в четверг?» Сотрудник ищет запись, уточняет услугу и филиал, проверяет расписание, меняет время и отправляет подтверждение. Для голосового агента это небольшой, но законченный бизнес-процесс: разговор должен завершиться корректным изменением в системе записи.
Семейство Voxtral 3 и Voice Agents SDK Mistral позволяют построить такой диалог. Ниже — предлагаемая архитектура для сервисной компании, а не готовая интеграция с конкретной CRM. Расписание, правила переноса и подтверждение операции остаются частью приложения компании.
Что в этой схеме делает Voxtral #
Voxtral отвечает за распознавание и синтез речи. Между ними работает модель, которая ведёт диалог и вызывает инструменты приложения. В анонсе Voxtral 3 Mistral описывает объединение этих частей в потоковый голосовой сценарий; среди голосовых вариантов есть русский язык.
Само распознавание фразы «перенесите на четверг» не меняет запись. Приложение должно получить из системы доступные варианты, сформировать конкретное предложение и выполнить разрешённую операцию. Генерация ответа и доступ к расписанию — разные задачи.
По состоянию на проверку семейство Voxtral 3 находится в Public Preview . Для рабочего проекта нужно зафиксировать модели и доступный способ подключения, а затем проверить сценарий на своей русской речи, названиях услуг и условиях связи. Результаты демонстрации производителя не подтверждают качество в вашей телефонной линии.
Сначала выберите канал пилота #
В Voice Agents SDK предусмотрены сценарии для приложения, браузера и телефона. Начать можно с голосового интерфейса в тестовой веб-странице: проверить диалог, поиск записи и работу с расписанием без подключения реального номера.
Для встроенной SIP-телефонии Mistral требуется enterprise-доступ через команду провайдера; это не самостоятельное подключение обычного API-ключа. Совместимость выбранного оператора и номера нужно подтвердить отдельно. Наличие русского голоса само по себе ничего не говорит о доступности телефонного подключения.
Есть и техническое различие инструментов. В браузерном приложении могут работать обработчики в вашем коде. Для телефонного подключения документация требует доступные на стороне платформы инструменты: клиентские обработчики там не исполняются. Поэтому успешный прототип в браузере ещё не подтверждает готовность того же агента к телефонной линии. Это ограничение описано в документации Tools .
Найдите конкретную запись #
На входе у процесса должны появиться идентификатор записи и подтверждённое право её изменить. Номер звонящего может помочь найти кандидата, но одного совпадения телефона недостаточно, если у клиента несколько визитов или номер используют члены семьи. Способ подтверждения выбирают под услугу и последствия изменения.
Агенту нужен короткий ответ системы: филиал, услуга, текущие дата и время, допустимость переноса. Внутренние комментарии сотрудников и сведения о других клиентах для этого не требуются. Если найдены две подходящие записи, агент предлагает различить их по безопасным признакам, а не выбирает первую.
Правила переноса должны возвращаться из бизнес-системы. Например, можно ли менять филиал, сохраняется ли выбранный специалист и требуется ли участие администратора при особых условиях. Эти решения нельзя оставлять на усмотрение языковой модели.
Сделайте инструменты небольшими и предметными #
Для первого сценария достаточно четырёх логических операций: получить запись, найти подходящие окна, подготовить перенос и подтвердить его. Это предлагаемое разделение функций вашего приложения, а не названия готовых методов Mistral.
В телефонном варианте операции расписания нужно предоставить через поддерживаемый серверный коннектор, доступный агенту. Связь с системой записи, её авторизацию и проверку прав на конкретный визит настраивают отдельно. Создание голосового агента не даёт ему доступ к расписанию автоматически.
Поиск окон принимает ограничения: услугу, филиал, специалиста, длительность и желаемый период. Ответ содержит идентификаторы слотов и точные дату, время и часовой пояс. Модель может объяснить варианты человеку, но не должна конструировать несуществующее окно из свободного текста.
Подготовка переноса связывает прежнюю запись с выбранным слотом и возвращает параметры для устного подтверждения. «В четверг после обеда» нужно превратить в однозначную фразу: конкретное число, время, филиал и услуга. Для распределённой сети отдельно определите, в каком часовом поясе говорит клиент.
После подтверждения система ещё раз проверяет доступность окна. По возможности старое время и новое должны изменяться одной согласованной операцией в системе записи. Если такой возможности нет, требуется отдельный механизм бронирования и восстановления. Отменять старый визит до подтверждения нового рискованно: клиент может остаться без обоих вариантов.
Обрабатывайте уточнение во время разговора #
Клиент может перебить агента: «Нет, не в этот филиал» или «Я сказал в пятницу». SDK поддерживает перебивания, но их бизнес-смысл нужно обработать в вашем сценарии. Новое уточнение делает прежнее неподтверждённое предложение неактуальным.
Сохраняйте отдельно предпочтение клиента, предложенный вариант и подтверждённое действие. Если ответ о выполнении уже пришёл, последующая фраза не должна незаметно отменять результат. Агент сначала сообщает текущее состояние и начинает новый перенос при необходимости.
При неразборчивой дате полезнее повторить конкретные варианты, чем многократно задавать общий вопрос. Если клиент просит условие, которое система записи не умеет проверять, передайте задачу администратору вместе с найденной записью и желаемым временем.
Подтверждайте результат по системе записи #
После успешного изменения сохраните идентификатор операции и актуальное состояние визита. Только затем агент сообщает, что перенос выполнен. Текст «готово» от модели не является доказательством записи в расписании.
Если связь с бизнес-системой оборвалась после запроса, сначала запросите состояние операции или записи. Повтор без выяснения результата может ещё раз изменить время. При невозможности проверить исход агент должен сообщить, что перенос требует подтверждения сотрудником, и сохранить обращение.
Уведомление клиенту — следующий отдельный шаг. В нём нужны точные параметры принятой записи. Ошибка отправки сообщения не должна автоматически откатывать успешно выполненный перенос, но должна быть видна ответственному сотруднику.
Как проверять качество пилота #
Подготовьте учебные диалоги с относительными датами, похожими названиями филиалов, несколькими записями и занятым во время разговора слотом. Добавьте перебивание перед подтверждением и разрыв связи после операции. Для каждого диалога заранее определите допустимый результат.
Считайте правильно завершённые переносы, ошибочные изменения, обращения к администратору и время решения задачи. Отдельно отмечайте проблемы распознавания русских имён и терминов. Короткий разговор не считается хорошим результатом, если выбрана неправильная запись.
Расширять сценарий стоит после того, как понятны причины отказов на одной услуге и в одном расписании. Если большинство разговоров требует исключений и ручного выбора, сначала полезнее уточнить правила записи и инструменты приложения.
Подготовьте один сценарий переноса #
NetLabCS поможет связать диалог, расписание, подтверждение и передачу администратору при разработке ИИ-бота с разрешёнными действиями для сервисной компании. Для обсуждения пилота подготовьте правила переноса, описание системы записи и несколько обезличенных примеров разговоров — определим инструменты и доступный способ голосового подключения.
