Когда крупные предприятия обращаются к нам в Bandwidth в задумчивости насчет голосового ИИ, они часто пытаются ответить на один вопрос: какую платформу голосового ИИ мне выбрать? Это разумный вопрос. Существует множество устоявшихся и новых компаний, которые могут подойти в зависимости от варианта использования, географии, цены, степени сложности и множества других факторов. Но это может оказаться не самым важным вопросом.
Более судьбоносные решения (и те, которые труднее изменить) носят архитектурный характер. Где ИИ встраивается в поток вызовов? Как он взаимодействует с вашим контакт-центром? Вашей 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, либо дублируются в разных системах, создавая головную боль при их сопоставлении, либо медиаданные принудительно направляются через одну базовую платформу таким образом, что возвращается проблема накопления задержек из первого паттерна. Ни один из путей не приводит к чистому результату.
Несколько вендоров
Выбор ИИ-провайдера и размещение его в начале потока вызовов может привести к привязке к поставщику. Многие предприятия стремятся сохранить гибкость, чтобы добавлять альтернативных провайдеров или использовать разных провайдеров для различных сценариев использования. Это сложно оркестрировать и создает зависимость от каждого провайдера в плане последовательной интеграции с выбором, сделанным для других компонентов модели, таких как CCaaS или CRM.
Паттерн 3: Параллельная модель с оркестрацией
Прогрессивные компании из списка Global 2000 — особенно те, которые управляют многовендорными средами, глобальными филиалами или технологическим долгом от слияний и поглощений — приходят к параллельной архитектуре. В этой модели независимый программный уровень оператора/CPaaS-оркестрации располагается непосредственно перед вашей ИИ-платформой (или платформами) и вашей CCaaS-инфраструктурой. Интеграции формата BYO (Bring Your Own), популярные в сфере CCaaS за то, что позволяют предприятиям подключать собственного оператора, дают компаниям возможность быстро и легко добавлять предпочитаемых вендоров в топологию. Подход BYO позволяет предприятию сохранять прямой контроль над своим стеком ИИ и дорожной картой. Оркестрация, такая как Bandwidth Maestro, позволяет контролировать потоки вызовов.
Входящие вызовы сначала попадают на этот уровень оркестрации, где предприятие получает полный контроль над тем, какая система первой принимает звонки, а также точку привязки для перенаправления вызовов между платформами. Это обеспечивает бесшовную передачу вызовов от ИИ-агента к системе CCaaS для операторов-людей без возникновения проблем с накоплением задержек, сохраняя при этом централизованное расположение основных функций, таких как запись разговоров.
Этот паттерн особенно полезен для предприятий со сложными портфелями вендоров. У нас есть клиенты в сфере услуг, которые уже пришли к выводу, что одна ИИ-платформа работает лучше для определенных сценариев использования, в то время как другая — для прочих. Без уровня оркестрации на периферии реализацию такой гибкости в масштабе практически невозможно осуществить. С ним вы можете маршрутизировать вызовы разных типов к разным ИИ-провайдерам, сохранять ту же систему CCaaS для ваших операторов-людей и продолжать усложнять потоки вызовов, не опасаясь, что вся система станет хрупкой.
Совместное использование контекста также становится проще отслеживать. Вместо того чтобы требовать от каждого вендора в вашем стеке независимой интеграции с одной и той же CRM, вы получаете точку привязки на сетевом уровне, которая может применять согласованную логику передачи контекста для всех сегментов вызовов и точек передачи. Один набор интеграций вместо разрастающейся паутины попарных соединений.
Решение для предприятия в текущей ситуации
Даже если ваш текущий вопрос звучит как «какого вендора (или вендоров) мне выбрать?», воздержитесь от коммерческого запуска, пока не зададите критически важный вопрос: «какая архитектура мне нужна?». Выбор любого из трех паттернов может оказаться правильным при определенных условиях.
- Развертывание ИИ за вашей CCaaS — это быстрый и простой способ оценить, насколько хорошо ваши варианты ИИ-вендоров поддерживают ваши сценарии использования, удовлетворяют клиентов и отвечают бизнес-целям.
- Размещение ИИ перед контакт-центром может обеспечить аналогичные преимущества, устраняя при этом недостатки паттерна 1, однако оно не обладает достаточной готовностью к обработке роста и эволюции многовендорной среды.
- При принятии долгосрочных архитектурных обязательств, которые должны масштабироваться в рамках бизнес-подразделений, географических регионов и смен вендоров, параллельная модель с приоритетом оркестрации обеспечивает максимальное качество обслуживания клиентов, экономическую эффективность и простоту интеграции.
Основной риск заключается в принятии архитектурных обязательств на ранних этапах тестирования без проверки ее производительности в масштабе или соответствия вашим будущим потребностям. Когда объемы вызовов растут, непроверенные модели часто вызывают непредвиденные расходы, проблемы с задержками и ухудшение пользовательского опыта. Аналогичным образом, модели, которым не хватает гибкости или корпоративного контроля, не могут поддерживать развивающиеся многовендорные решения и сложные сценарии использования.
Предприятия, которые задумываются об архитектуре уже сейчас, окажутся в выигрышном положении. В противном случае будущее может принести сложные и дорогостоящие миграции.
Дэвид Ресс (David Ress) — старший директор по стратегии экосистемы разговорного ИИ в компании Bandwidth. Дэвид обладает многолетним опытом работы в телекоммуникационной отрасли и специализируется на проектировании инновационных голосовых решений.
