Платформы цифрового банкинга могут хорошо показывать себя во время пилотного запуска и при этом давать сбой, когда из-за мошеннических действий резко возрастает трафик или когда банк выходит на новый рынок. Поставщики часто называют платформы масштабируемыми, но это утверждение трудно оценить без четко определенной рабочей нагрузки, периода тестирования и целевых показателей уровня сервиса. Для банка главный вопрос заключается не просто в том, может ли платформа расти, а в том, какая часть пути клиента может отказать первой и при каких условиях.
В этом руководстве представлен практический подход к оценке масштабируемых платформ для цифрового CX в банковской сфере. В нем выделяются три уровня: основная банковская система (core banking), которая ведет учет счетов и транзакций; уровень взаимодействия (engagement layer), управляющий путями клиентов; и доставка коммуникаций (communications delivery), которая обеспечивает передачу взаимодействий через каналы и провайдеров. Это разграничение важно, потому что улучшение цифрового клиентского опыта не обязательно означает замену основной системы.
Семь приведенных ниже критериев предназначены для оценки поставщиков. Используйте одни и те же клиентские пути, рынки и операционные условия для сравнения интеграции, пиковой производительности, ответственности за доставку, охвата каналов, отказоустойчивости, соответствия нормативным требованиям, экономической эффективности автоматизации и языковой поддержки. Затем протестируйте шорт-лист кандидатов на сценариях массового подключения клиентов (onboarding), всплеска обращений из-за мошенничества и выхода на новый рынок. Эти проверки помогут руководителям по CX, архитекторам и операционным командам определить, что требует изменений, что может остаться прежним и какие доказательства должен предоставить поставщик.
Банковская CX-платформа масштабируется только тогда, когда она удерживает сквозные клиентские пути в рамках согласованных показателей производительности и восстановления при изменении трафика, каналов и рынков. Рассматривайте «масштабируемость» как утверждение, которое нужно протестировать, а не как свойство, вытекающее из описания продукта или облачного развертывания.
Вопрос для покупателя заключается не просто в том, может ли платформа расти. Важно понять, что может отказать в первую очередь, при каких условиях и как банк сможет обнаружить эту проблему и восстановить работу. Платформа может обрабатывать большой объем сообщений в контролируемом тесте и все равно не соответствовать требованиям реального банковского сценария. Тест может не включать интеграции банка, правила доставки для конкретных рынков или внезапный рост числа контактов с клиентами.
- Пропускная способность: Всплеск активности в день зарплаты, платежное событие или инцидент с мошенничеством одновременно увеличивают количество сообщений и клиентских сессий. Тест, основанный на среднем трафике, может не показать, как система ведет себя во время кратковременного пика.
- Задержка: Задержка между банковским событием и уведомлением клиента может сделать сообщение менее полезным. Измерьте полный путь от триггера до доставки, а затем отделите время обработки платформой от задержек в интеграциях или у провайдеров каналов.
- Доступность каналов: Путь клиента может зависеть от канала, типа отправителя или процесса регистрации, которые различаются в зависимости от рынка. Банку необходимо знать, где клиентский путь работает, а где требуется другой маршрут.
- Языковое покрытие: Клиентский путь, созданный для одного языка, может потребовать другого контента, маршрутизации и этапов проверки при выходе банка на другой рынок. Если языковая поддержка не заложена в проект изначально, региональный запуск может привести к необходимости поддерживать параллельные клиентские пути.
Превратите эти четыре типа сбоев в сопоставимые данные: спросите поставщиков, какую рабочую нагрузку они тестировали, какой порог производительности использовали и как они измеряют время безотказной работы и восстановления. Приведенные ниже критерии показывают, как изучить эти ответы в разрезе интеграций, каналов, рынков и клиентских путей.
Для каждого результата фиксируйте регион тестирования, конфигурацию системы, рабочую нагрузку, окно измерения и порог успешности. Уточняйте, включало ли тестирование интеграции банка и провайдеров доставки. Эти детали дают команде по оценке основу для сравнения. Без них цифра из презентации поставщика может не отражать реальную рабочую среду банка.
Основная банковская система, платформа цифрового банковского взаимодействия и уровень доставки коммуникаций выполняют разные задачи в рамках клиентского пути. Банки, которые объединяют их в одну категорию, в итоге могут оценивать не ту систему, которая нужна для решения их проблемы.
Основная банковская система поддерживает учетные записи, балансы, обработку транзакций и главный регистр банка. Она предоставляет необходимые данные и сервисы, но это не единственная часть стека, которая формирует клиентский опыт. Уровень взаимодействия управляет путем клиента, обращенным к пользователю. Уровень доставки определяет, как взаимодействие проходит через каналы и провайдеров, чтобы достичь клиента.
Ядро хранит записи и обрабатывает транзакции. Его данные и API могут обеспечить отличный цифровой опыт, но само по себе ядро не занимается проектированием онбординга, не ведет клиента через самообслуживание и не управляет беседой с сервисной командой. Банки должны выяснить, что ядро предоставляет другим системам и как быстро эти системы получают изменения.
Изменения в ядре могут повлиять на множество банковских процессов, поэтому команды часто подходят к их оценке с другим уровнем контроля и координации, чем к изменениям клиентского пути. Это не делает ядро менее важным. Это означает, что банк должен четко понимать, нужно ли ему менять обработку транзакций или улучшать выстроенный вокруг нее опыт.
Уровень взаимодействия управляет взаимодействиями с клиентами, такими как онбординг, обслуживание счетов, самообслуживание, обслуживание с участием сотрудников и проактивные коммуникации. Он может связывать контекст клиента с клиентскими путями и сервисными инструментами, в то время как ядро остается системой учета счетов и транзакций.
Когда клиент начинает путь в мобильном банковском приложении, а затем обращается за помощью, уровень взаимодействия должен помочь банку сохранить контекст на всех этих этапах. Банку следует проверить, как идентификационные данные, данные клиентов, решения и история взаимодействий перемещаются между приложением, платформой взаимодействия, ядром и сервисной командой. Если профили обновляются только пакетами (batch), принятие решений может основываться на устаревшей информации, даже если интерфейс выглядит актуальным.
Между уровнем взаимодействия и клиентом находится доставка коммуникаций. Она включает в себя подключения каналов, регистрацию идентификатора отправителя, доступность на уровне рынка, статус доставки и правила, которые влияют на то, дойдет ли взаимодействие до человека.
Представьте себе одноразовый пароль, который приходит после того, как клиент уже покинул страницу входа, или шаблон сообщения, который нельзя использовать на конкретном рынке. Дизайн клиентского пути может быть безупречным, но этап доставки все равно может его нарушить. Уточните, кто отвечает за каждую зависимость при доставке, кто занимается расследованием сбоев, как платформа сообщает о статусе и может ли банк направить клиента по утвержденному альтернативному маршруту.
Все три уровня работают как единый клиентский путь, но у них разные зоны ответственности. Шорт-лист должен показывать, какой продукт охватывает каждый уровень, какие системы остаются на прежних местах и где банк должен самостоятельно управлять интеграцией или отношениями с провайдером.
Оценивайте провайдеров по одним и тем же семи критериям и сценариям, но присваивайте каждому критерию вес в соответствии с приоритетами банка. Например, запуск на нескольких рынках может сделать доступность каналов и локализацию данных более важными факторами, в то время как при обслуживании больших объемов на первом месте могут оказаться пропускная способность, задержка и отказоустойчивость. Фиксируйте подтверждающие данные для каждой оценки, а не просто рейтинг вендора.
Может ли платформа взаимодействия подключиться к существующему ядру банка без замены этого ядра? Спросите о готовых коннекторах, API, потоковой передаче событий, веб-хуках и пакетной передаче данных. Узнайте, получает ли платформа событие в момент его возникновения или после запланированного обновления.
Затем проследите один реальный сценарий взаимодействия. Определите систему, которая создает событие, систему, отвечающую за идентификацию клиентов, точку принятия решения и службу, которая берет управление на себя, если в процессе взаимодействия требуется участие человека. Попросите предоставить схему, показывающую эти передачи управления и данные, которые хранит каждая система. Живая демоверсия должна использовать типичный путь интеграции, а не набор предварительно загруженных данных клиентов, не связанных с системами банка.
Спросите вендора, какие каналы доставки он обслуживает самостоятельно, какие получает через другого провайдера и где именно переходит зона ответственности. Это практический вопрос об ответственности, а не просто ярлык, который можно принимать на веру.
Задайте дополнительные вопросы: сколько сервисов находится между триггером банка и клиентом; кто проводит расследование при сбое доставки; какие данные о доставке банк может просматривать в разбивке по странам и каналам; и как изменения на стороне провайдера влияют на путь клиента? Попросите вендора показать путь сообщения и уточнить, какие именно части он может контролировать или мониторить. Не предполагайте, что «прямой» означает одинаковый путь для каждого канала, рынка или модуля.
Глобальный подсчет каналов не показывает, доступны ли нужные банку каналы его клиентам в каждой конкретной стране. Запросите информацию о каналах в разрезе рынков, типах отправителей, шагах регистрации, сроках утверждения, отчетности о доставке и доступных вариантах резервного переключения.
Проверьте точный набор инструментов в планах банка. WhatsApp, SMS, RCS, голосовые вызовы, электронная почта и обмен сообщениями внутри приложений могут иметь разные условия настройки и доступности. Уточните, какие каналы поддерживаются предлагаемым продуктом и модулем, а какие зависят от оператора связи, партнера или регистрации банка. Та же проверка применяется, когда банк добавляет новый рынок позже. Попросите вендора объяснить, что именно меняется в архитектуре и операционном процессе.
Запросите устойчивую пропускную способность в пиковые нагрузки, задержку при такой рабочей нагрузке, задокументированный процесс отказоустойчивости и четкий порядок обработки поставленных в очередь или пропущенных сообщений. Запросите условия тестирования и уровень обслуживания, применимый к предлагаемому развертыванию банка. Спросите, как система ведет себя при недоступности API или провайдера каналов, а не только в случае сбоя всей платформы.
Используйте сценарий инцидента, с которым знаком банк. Например, проблема с обработкой карт может вызвать рост числа звонков от клиентов и потребность в проактивных обновлениях. Проследите, как событие достигает уровня взаимодействия, как банк выбирает канал, как служба поддержки получает ответы и как платформа избегает дублирования или противоречивых сообщений. Включите в тест операционную команду, которая занимается ликвидацией инцидента.
Составьте карту сбора и соблюдения согласий на обработку данных, доступа к данным, их хранения, аудиторских записей, шифрования и локализации данных для каждого рассматриваемого рынка. Спросите, где обрабатываются и хранятся данные о клиентах и взаимодействиях, какие элементы управления применимы к каждому модулю и как вендор документирует изменения в этих договоренностях.
Командам корпоративного банкинга может потребоваться оценить такие нормативные базы, как GDPR, PSD2 и DORA, наряду с местными требованиями. Сам факт их упоминания в разговоре не доказывает, что вендор или развертывание соответствуют им. Попросите юридические, службы безопасности и комплаенс-отделы банка определить применимые обязательства, а затем потребуйте от вендора предоставить актуальные доказательства для конкретной службы и региона. Не рассматривайте сертификацию или элемент контроля в одной юрисдикции как доказательство для другой.
Демонстрация чат-бота или ИИ-агента не показывает, решает ли автоматизация потребности клиентов. Попросите вендоров разделять успешно завершенные обращения и те диалоги, в которых просто удалось избежать привлечения человека. Запросите определение метрик эффективности, структуру рабочей нагрузки и порядок действий системы при поступлении запроса, который она не может разрешить.
Сравните стоимость успешного автоматизированного взаимодействия со стоимостью успешного взаимодействия, в котором участвовал человек. Учитывайте комиссию каналов, плату за использование платформы, повторные попытки отправки, время поддержки, а также работы по интеграции и техническому обслуживанию. Узнайте, как банк может просматривать выборки, измерять количество повторных обращений и контролировать, получают ли клиенты правильный ответ. Само по себе сокращение числа обращений может лишь перенести нагрузку на другой канал, а не уменьшить ее.
Перечислите языки, которые необходимы банку сейчас, и те, поддержку которых он планирует добавить в будущем. Спросите, как платформа определяет язык, как команды управляют переведенным контентом и как проверяющие одобряют изменения перед тем, как они станут доступны клиентам. Уточните, доступны ли эти функции в оцениваемых продуктах и модулях.
Затем протестируйте процесс взаимодействия более чем на одном языке, включая сообщения, шаги самообслуживания и передачу диалога оператору. Проверяйте, сохраняется ли контекст, когда клиент меняет канал связи или обращается в службу поддержки. Рассматривайте локализацию как операционное требование, а не как финальную задачу перевода. Это дает банку более четкое представление об объеме работы, необходимой для поддержания пути клиента на разных рынках.
Масштабируемость имеет наибольшее значение, когда путь клиента сталкивается с пиковой нагрузкой, инцидентом или выходом на новый рынок. Эти примеры показывают, как взаимодействуют уровни ядра, взаимодействия и доставки. Это сценарии для оценки, а не клиентские кейсы.
Маркетинговая кампания приносит больше заявок на открытие счетов, чем обычно. Сервисы ядра и идентификации должны возвращать информацию, требуемую банком, в то время как уровень взаимодействия проводит каждого клиента через проверку соответствия критериям, сбор документов и следующие шаги. Уровень доставки должен отправить правильный запрос через канал, которым клиент может воспользоваться, а затем отчитаться о том, дошло ли сообщение до адресата.
Полезный тест отслеживает заявку от начала и до конца. Что происходит, если клиент делает паузу перед загрузкой документа? Может ли банк возобновить процесс с правильным контекстом? Регистрирует ли система завершенный шаг перед отправкой напоминания? Попросите вендора протестировать всплеск подачи заявок и показать, как банк может выявлять задержки, брошенные заявки и сбои доставки, не сводя каждый случай к проблеме конкретного канала.
Банк выявляет подозрительные транзакции и должен предупредить затронутых клиентов в условиях возросшей нагрузки на контакт-центр. Уровень взаимодействия должен использовать утвержденные банком правила принятия решений и формирования сообщений. Уровень доставки должен направить уведомление и вернуть статус отправки. Если клиент отвечает, служба поддержки должна иметь достаточно контекста для продолжения диалога.
Используйте этот сценарий, чтобы проверить, как платформа справляется с изменяющимся инцидентом: может ли она перенаправлять ответы команде с правильным контекстом клиента, а также останавливать или обновлять оповещение при изменении статуса дела? Это позволяет проверить обработку инцидентов и передачу обслуживания человеку в условиях стресса, а не просто повторять общие вопросы о пропускной способности, приведенные выше.
Банк расширяет цифровой сервис на другую страну. Основные функции и некоторые сценарии взаимодействия могут остаться прежними, однако доступность каналов, регистрация отправителей, правила получения согласий, язык, обработка данных и местная поддержка могут измениться. Банку следует составить карту этих зависимостей до того, как он возьмет на себя обязательства по срокам запуска.
Попросите вендора показать, что именно он настроит для этого рынка и какие задачи относятся к ведению банка, вендора, оператора связи или другого провайдера. Протестируйте один сквозной сценарий на целевом языке и в нужном канале. Уточните, как банк будет проверять локальный контент и контролировать доставку. Это упражнение поможет выявить отсутствие регистраций или вопросы с данными до того, как банк пригласит клиентов в новый сервис.
AgentOS — это платформа агентного ИИ от компании Infobip. Рассматриваемые здесь возможности взаимодействия с клиентами представляют собой модули в составе AgentOS, которые можно оценивать наряду с существующей базовой банковской платформой и системой цифрового банкинга банка, а не в качестве замены для них. Уточните, как выбранные модули подключаются к системам и сервисным службам банка, а также какие каналы доступны для каждого запланированного сценария.
AgentOS объединяет клиентские данные, оркестрацию сценариев, искусственный интеллект и возможности обслуживания с участием человека. Infobip также предоставляет каналы связи для взаимодействия с клиентами. Для банка ключевым критерием оценки является то, как выбранные модули подключаются к его основным системам, цифровым каналам и сервисным службам, а также кто отвечает за каждую передачу управления.
Банку следует определить, где создается контекст клиента, как он перемещается между системами и что происходит при сбое канала или интеграции. Не каждый модуль поддерживает все каналы, поэтому уточните доступные опции для каждого запланированного сценария.
Банку следует оценить масштабируемость на всем протяжении пути клиента — от события, инициирующего взаимодействие, до доставки и решения вопроса службой поддержки. Истории успеха клиентов Infobip отражают результаты в области поддержки с помощью ИИ, внедрения цифровых кошельков, кампаний в RCS и сценариев цифрового банкинга.
В примерах ниже описаны различные внедрения решений Infobip. Они демонстрируют опыт работы в сфере финансовых услуг, страхования и банковского дела, однако это не означает, что в каждом случае использовалась платформа AgentOS.
LAQO Insurance: В кейсе сообщается, что ИИ-ассистент Павле обработал 30% запросов клиентов, причем 90% были решены в ходе 3–5 обменов сообщениями. Павле поддерживает беседы в WhatsApp и может переводить более сложные запросы на живого оператора. Компания LAQO также сообщила о снижении нагрузки на свой контакт-центр на 10%.
Mukuru: В кейсе этого поставщика финансовых услуг сообщается, что количество активных клиентов цифрового кошелька выросло с 4 000 в декабре до 129 000 в марте, что описывается как более чем 30-кратный рост. Показатель открываемости (read rate) рассылок в WhatsApp превысил 92%. Инструмент WhatsApp Flows сократил один из процессов с 17 шагов до 2 и вдвое уменьшил отток пользователей в Ботсване. Mukuru также сообщила о снижении затрат на USSD с обратной тарификацией на 15% и затрат на транзакционные SMS на 5%.
BankBazaar: Финансовый маркетплейс сообщил, что показатель кликабельности (CTR) для RCS-кампаний оказался на 130% выше, чем для сопоставимых SMS-кампаний. В ходе нескольких кампаний было отправлено более 70 миллионов RCS-сообщений для продвижения установки приложений и проверки кредитного рейтинга.
Используйте этот контрольный список, чтобы ответы разных провайдеров можно было сопоставить:
- Какую устойчивую рабочую нагрузку, пропускную способность, задержку и уровень сервиса протестировал провайдер или гарантирует в рамках обязательств?
- Как платформа интегрируется с базовой системой банка, и какие системы отвечают за основные записи, контекст клиента и принятие решений о следующих действиях?
- Какие каналы доставки обслуживаются напрямую и кто несет ответственность за сбои на каждом рынке?
- Какие каналы и типы отправителей доступны в каждой стране и какую регистрацию они требуют?
- Как платформа сохраняет контекст при повторных попытках отправки, аварийном переключении и передаче обслуживания человеку?
- Какие средства контроля данных, согласий, аудита и локализации применимы к каждому модулю и региону?
- Как провайдер измеряет количество разрешенных взаимодействий, языковое покрытие и общую стоимость одного решения?
