Три паттерна развертывания речевого ИИ

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

Более судьбоносные решения (и те, которые сложнее изменить) — это архитектурные решения. Где ИИ вписывается в ваш процесс обработки вызовов? Как он взаимодействует с вашим контакт-центром? Вашим CRM? Вашими политиками безопасности? Инфраструктурой вашей компании и сценариями использования? Что происходит с контекстом, записями для контроля соответствия требованиям и логикой маршрутизации, когда что-то идет не по плану?

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

Паттерн 1A: ИИ за CCaaS

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

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

Накопление задержек и клиентский опыт

В во многих случаях путь к платформе агента не оптимизирован, и каждый вызов проходит через несколько сегментов, создавая накопление задержек: аудио проходит через CPaaS -> CCaaS -> ИИ-вывод -> обратно. Декодирование, преобразование речи в текст и перекодирование на нескольких этапах добавляют сотни миллисекунд, вызывая заминки у звонящего и нарушая ритм разговорной речи.

Коммерческая модель

Если они все делают простым, провайдеры CCaaS, скорее всего, не делают экономически выгодным выбор ИИ другого вендора.

• Плата за подключение агентов: провайдеры CCaaS часто взимают ежемесячную плату за интеграцию агентов. Многие корпоративные клиенты сообщают, что только это может существенно повлиять на их бизнес-кейс.
• Плата за разговор: в зависимости от архитектуры интеграции CCaaS может сохранять свое присутствие в сквозном потоке вызовов и взимать традиционную плату за минуту. К этому добавляется плата, взимаемая провайдером агента.
• Разовые сборы: провайдеры CCaaS также могут взимать разовую плату за настройку или внедрение, особенно если они задействуют свои команды профессиональных услуг для настройки возможностей маршрутизации.

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

Паттерн 1B: Вариант нативного агента CCaaS

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

Паттерн 2: ИИ перед CCaaS

По мере развития речевого ИИ предприятия начали размещать агента ИИ на “входе” в сеть для перехвата трафика PSTN до того, как он попадет в CCaaS. Ценностное предложение простое: поместите агента ИИ в начало процесса вызова, перед CCaaS. Если агент может обработать 70–80% взаимодействий с клиентами, нет необходимости вообще направлять эти вызовы в контакт-центр. Для предприятий, ожидающих высоких показателей автономности, эта архитектура является убедительным аргументом. Но предприятия должны критически оценить свои изначальные предположения, прежде чем принимать на их основе решение о развертывании.

На практике показатели автономности варьируются. Если вы получаете разрешение <35% вместо запланированных 70–80%, значительная часть вашего объема по-прежнему поступает к живым агентам. Это создает две ключевые проблемы для бизнес-кейса. Во-первых, модель накопления задержек, обсуждавшаяся в случае размещения ИИ за CCaaS, часто применима и здесь. Существуют и другие проблемы, включая обмен контекстом, соответствие требованиям и сценарии использования с несколькими вендорами.

Проблемы обмена контекстом

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

Существуют способы обмена контекстом между системами. Один из распространенных подходов — регистрация в CRM, но для этого требуется, чтобы каждый компонент в вашей экосистеме интегрировался с одной и той же CRM и стабильно записывал в нее данные. Чем больше задействовано вендоров, тем больше точек интеграции может сломаться. В мультинациональном предприятии с несколькими вендорами CCaaS, несколькими платформами ИИ и бизнес-подразделениями, принимающими собственные технологические решения, интеграция каждого компонента с одной и той же CRM не является гарантированным предположением.

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

Соответствие требованиям

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

Несколько вендоров

Выбор одного ИИ-провайдера и размещение его в самом начале потока вызовов может привести к зависимости от поставщика (vendor lock-in). Многие компании стремятся сохранить гибкость, чтобы добавлять альтернативных провайдеров или использовать разных поставщиков для различных сценариев использования. Это сложно координировать, кроме того, возникает зависимость от каждого провайдера, которому приходится последовательно интегрироваться с решениями, выбранными для других компонентов модели, таких как CCaaS или CRM.

Паттерн 3: Параллельная модель с оркестрацией

Прогрессивные компании из списка Global 2000 — особенно те, которые управляют мультивендорными средами, работают по всему миру или сталкиваются с технологической задолженностью из-за слияний и поглощений — выбирают параллельную архитектуру. В этой модели независимый программный уровень оркестрации оператора/CPaaS располагается непосредственно перед вашей ИИ-платформой (или платформами) и вашей CCaaS-инфраструктурой. Интеграции по принципу Bring Your Own (BYO), популярные в сфере CCaaS за то, что позволяют предприятиям подключать собственных операторов связи, дают возможность быстро и легко добавлять предпочитаемых вендоров в топологию. BYO позволяет компании сохранять прямой контроль над своим стеком ИИ и планом развития. Оркестрация, такая как Bandwidth Maestro, сохраняет за ними контроль над потоками вызовов.

Входящие вызовы сначала поступают на этот уровень оркестрации, где компания получает полный контроль над тем, какая система первой принимает звонки, а также точку привязки для перенаправления вызовов между платформами. Это обеспечивает бесшовную передачу вызовов от ИИ-агента к CCaaS-системе для операторов-людей без возникновения проблем с накоплением задержек, при этом такие основные функции, как запись звонков, остаются в централизованном управлении.

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

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

Выбор для компании сегодня

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

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

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

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

Дэвид Ресс (David Ress) — старший директор по стратегии экосистемы разговорного ИИ в компании Bandwidth. Дэвид обладает многолетним опытом работы в телекоммуникационной отрасли и специализируется на проектировании инновационных голосовых решений.