Chapter 5 walkthrough from The AI Contact Center Handbook by Sho Shimoda. Available on Amazon.
Three seconds at 11:47 PM
A call arrives at a large U.S. bank's authentication line. The caller ID belongs to Maria Alvarez — 43, Phoenix, eleven-year customer, $184,000 across three accounts. The voice pattern-matches Maria's stored voiceprint at 91% confidence. "Hi, I need to reset my online banking password." Between the arrival of the call and the moment the system decides what to do about it, three seconds elapse.
In those three seconds, four separate systems have to be consulted. The telecom carrier's SIM-swap API reports that the SIM associated with Maria's number was swapped three hours ago at a T-Mobile store already flagged twice this month for suspicious activity. The bank's own authentication history shows Maria's usual login pattern is an iPhone in Phoenix, 6 AM–10 PM local; never after 10:30, never from a call. The CRM shows Maria has never previously called the authentication line — she has always used the app to reset her password, four times in three years. The fraud analytics engine cross-references all of it and flags the interaction as a 78% probability of an authorized push-payment-scam pattern.
In those three seconds, one decision has to be made. Route to a human fraud specialist for step-up? Route to the routine password-reset queue? Or hang up on the caller entirely and send the real Maria — the one whose phone has been hijacked — a security alert on her registered backup channel? Only one kind of system can make that decision in three seconds. It is called an Experience Orchestration Platform, or XOP.
The old stack stored data. The XOP decides what to do with it, right now.
Why the old CDP is too slow
The Customer Data Platform emerged in the mid-2010s to solve a real marketing problem: customer data scattered across a dozen systems, no single view of who the customer actually was. The CDP unified them, resolved identities across sources, produced a profile any downstream system could query. Segment, mParticle, and Tealium came out of the marketing tech stack. Salesforce Data Cloud, Adobe Real-Time CDP, and Oracle Unity came out of the big application suites. A smaller cluster — ActionIQ, Simon Data — leaned into more operational use cases.
A CDP takes all the different systems where you store customer data, figures out which record in one system is the same person as which record in another (that's called identity resolution), and produces a single profile every other system can read. Segment, Adobe Real-Time CDP, and Salesforce Data Cloud lead the market.
CDPs did their job for the marketing use case they were built for — which is structurally batch-friendly. Marketing wants to know which customers should get the July email campaign; a nightly job producing today's segment from yesterday's data is fine. If the answer is six hours old, no one notices. The customer-service use case is different. It wants to know who is on the phone right now, what they did in the last five minutes, and what should happen next. The right answer at 11:47 PM cannot wait for tomorrow's overnight batch. It cannot even wait for the top-of-the-hour incremental refresh. It has to be available in the second the decision is being made.
Vendors know this. Most CDPs have added "real-time" capabilities in the last three years, mostly by bolting a streaming pipeline onto the front of the batch architecture. That helps at the margins. It does not solve the fundamental problem, which is that CDPs were designed to be a store of truth — a place where data comes to rest so it can be queried — and what the modern contact center needs is a nervous system: a live network of signals, aggregated in flight, that produces a decision at the exact moment the decision is needed.
| Dimension | CDP | XOP |
|---|---|---|
| Primary purpose | Unified store of customer truth | Real-time decision on the customer in front of you |
| Latency budget | Minutes to hours; often batch | 200–500 ms — sub-second loop |
| Typical use case | Segment for the July email campaign | Route the call arriving right now |
| Data scope | Marketing/sales stack: CRM, MAP, ESP, web/app analytics | Everything above, plus live network/carrier/fraud signals |
| Consumer | Downstream systems that query on their own schedule | CCaaS, CRM, and agent-facing tools waiting on the answer |
| Metaphor | Warehouse | Air traffic control |
A CDP is a warehouse. An XOP is a decision-making layer that reads from the warehouse and from every live signal happening right now, fuses them, and tells the operational systems what to do — all in the time it takes a customer to say hello.
What an XOP actually is
The best analogy is one that keeps recurring in the industry conversations: air traffic control. The controller does not fly the plane. Does not build the runway. Does not manufacture fuel. The controller's job is to know where every plane is, right now, and to decide — in real time — which plane lands on which runway in which order. The intelligence layer above the aircraft, the ground crew, the weather service, and the passengers. Without it, everything else still exists. Nothing lands safely. An XOP plays the same role for customer interactions.
Technically, it has three components. An event bus — a live stream of everything happening across the customer's journey. Kafka, Amazon Kinesis, or Google Pub/Sub for the underlying transport. Every page view, every mobile-app open, every call arriving on the CCaaS, every email opened, every SIM swap detected on the carrier network. A decision engine — the reasoning layer that reads the event stream, reads context from the CRM/CDP/systems of record, and produces a decision: route here, offer this, block that, escalate. In 2026 the engine is a mix of traditional rules (still useful for hard compliance), classical ML (fraud scoring, next-best-action ranking), and LLM-based agents (open-ended reasoning). The mix matters. Pure rules are too brittle. Pure LLMs are too slow and too expensive for high-volume, low-latency decisions. And an orchestration layer — the hands. Route this call in Genesys. Update the profile in Salesforce. Send this SMS through Twilio. Trigger this workflow in Zendesk.
The vendor landscape is unsettled. In 2026, three categories are converging from different directions. The CCaaS vendors — Genesys, NICE, Five9, Amazon Connect — are extending upward, adding decision-making and orchestration on top of channel and routing. Genesys Cloud CX in particular has been aggressive about positioning as an experience orchestration platform rather than a contact center. The CRM vendors — Salesforce, Microsoft Dynamics, ServiceNow — are extending outward, adding real-time decision-making on top of systems of record. Salesforce Data Cloud + Agentforce is the clearest example. And a smaller number of pure-play XOP vendors, some spun out of the composable-DXP movement, are trying to build the orchestration layer as a standalone product that sits above every channel and system.
Network-aware intelligence and CAMARA APIs
Return to Maria Alvarez and her hijacked SIM at 11:47 PM. The specific piece of information that broke that scam attempt — the SIM swap three hours earlier — is not a piece of information any enterprise system historically had access to. It lives inside the telecom carrier's network. Until recently, the only way to get it was to have a specific commercial contract with each carrier, use each carrier's proprietary API, and hope the API worked in the moment you needed it. That has been changing.
The change is called CAMARA — an open-source project of the Linux Foundation, launched in 2022 in partnership with the GSMA, the global trade association of mobile network operators. CAMARA standardizes a set of APIs that expose telecom network capabilities to enterprise applications in a common way. Rather than every enterprise negotiating a bespoke integration with AT&T, Verizon, T-Mobile, Vodafone, Deutsche Telekom, and every other carrier, CAMARA defines a shared API vocabulary that any carrier can implement and any enterprise can call.
CAMARA lets your enterprise app ask the phone network questions — "did this SIM card get swapped recently?" "is this number really the number of the person registered to it?" "what country is this device physically in right now?" — using the same API call regardless of which carrier the customer uses. Before CAMARA, this was years of bilateral deal-making. After CAMARA, it is a REST call.
| CAMARA API | What it tells you | Where it matters |
|---|---|---|
| Number Verification | Confirms the phone using the number right now is the phone registered to the account | Beats caller-ID spoofing |
| SIM Swap Detection | Reports the date of the most recent SIM swap on a number | The Maria Alvarez case |
| Device Location Verification | Reports whether the device is inside a specified area — without revealing precise location | "Where they say they are" |
| Roaming Status | Whether the device is currently roaming, and where | Fraud + personalization |
| Quality of Service on Demand | Temporarily boost network priority for a device | Video support that doesn't drop |
The one caveat, worth naming, is that CAMARA APIs raise real privacy questions. Every one of them touches data the customer probably assumes is private to their carrier. Regulators, particularly in Europe under GDPR, have been paying attention. The current pattern is that CAMARA APIs are called only for specific, disclosed purposes — typically fraud prevention or step-up authentication — with the customer's consent captured either at account opening or at the moment the API is invoked. Enterprises that treat these APIs as a general-purpose data feed rather than a targeted anti-fraud tool are going to end up in court.
Real-time fraud prevention as the flagship use case
Fraud prevention is the flagship XOP use case for a simple reason: the ROI is clear, the outcomes are measurable, and the regulatory tailwind is strong. Every dollar of fraud prevented is a dollar the bank does not write off. Every fraud attempt caught in the first three seconds is a customer who does not spend three hours on the phone with the fraud desk tomorrow.
The specific pattern that has emerged is worth walking through, because it makes visible what an XOP actually does when it is working. A call arrives. In the first 200 milliseconds, the XOP fuses voice biometrics (Pindrop, Microsoft-Nuance, NICE Real-Time Authentication — match confidence as a probability), phone-number reputation (was this the registered number? for how long? does it appear in any fraud database — Pindrop, LexisNexis, TransUnion TruContact, Neustar?), CAMARA network signals (SIM swap, number verification, device location), behavioral history (does the account holder normally call at this time of day? recent unusual activity?), and session context (what did they do on the website or app in the last hour?). All fused into a single fraud score in 200–500 ms. The score determines the routing.
The XOP's fraud role is to be the referee. It does not itself decide who is fraudulent. It listens to every specialist vendor's opinion, weighs them, and makes the call — in the first three seconds — about how to handle the specific customer in front of it.
The tension worth naming is between fraud prevention and customer experience. Every step-up added to protect against fraud is friction added to the legitimate customer's day. The best XOP deployments minimize that friction by only adding step-up when the signal actually justifies it — which requires the fraud engine to be well-calibrated, and requires the XOP to be smart enough to distinguish a customer who lost their phone from a fraudster who stole one. When it works, the customer barely notices. When it does not, the customer is asked to answer their mother's maiden name three times in a row and hangs up. This is the tuning problem that separates a well-run XOP from a badly-run one.
Where the XOP fits in the stack
The final question — the one every CX leader asks after the first XOP vendor pitch — is: where does this sit relative to what I already have? The industry has not fully agreed. Here is the current best understanding, based on how the mature 2026 deployments are actually configured. The CCaaS remains the channel infrastructure (phone, chat, email routing, omnichannel plumbing) — the ears and mouth. The CRM remains the system of record (accounts, interaction history, case management) — the long-term memory. The CDP remains the unified profile store — the working memory. The XOP is the decision layer that reads from all three plus external signals (fraud, network) and decides what to do next.
In the vendor conversation, this creates a specific problem: every layer's vendor wants to expand upward into the layer above. The CCaaS vendors are building CRM-like features (case management inside Genesys Cloud). The CRM vendors are building CCaaS-like features (Salesforce Service Cloud Voice, Microsoft Dynamics 365 Contact Center). Both are building CDP-like features (Salesforce Data Cloud, Dynamics Customer Insights). And all of them are building XOP-like features. The result is that a mid-sized contact center in 2026 is often being sold four different XOPs by four different vendors, each claiming to be the "one platform" they need.
The right architectural response, based on the mature deployments, is roughly this. Pick your CCaaS based on channels and reliability. Pick your CRM based on where your customer data already lives. Pick your XOP based on which vendor's ecosystem you are already invested in, or on a pure-play if you want to stay vendor-neutral. Accept that best-of-breed integration is the reality; the single-vendor stack is a marketing fiction.
In the 2026 stack, the CCaaS handles the channel, the CRM holds the record, the CDP unifies the profile, and the XOP makes the decision. Only the last one is new. Only the last one is the difference between an old contact center with AI features and a modern experience platform.
What to take with you from Chapter 5
The Experience Orchestration Platform is the layer of the stack that did not exist in 2020 and cannot be absent from a 2026 build. It is not a new database. It is not a new channel. It is the intelligence that reads from every existing system, fuses the signals in real time, and decides what to do about the specific customer in the specific moment they are in the system.
The old CDP was built for the marketing use case, where a day-old answer is fine. The new customer-service use case demands a second-old answer. That difference — between batch and real-time — is why the CDP alone is not enough. The XOP is the operational nervous system that sits above the CDP and gives the enterprise the ability to act on the data, not just store it.
The most transformative single set of inputs to the XOP is the telecom network itself, exposed through CAMARA APIs. For the first time, the enterprise can ask the carrier network, in real time, whether a customer's phone number has been hijacked, verified, or roamed. In fraud-heavy verticals like banking and telco, that capability is the difference between an account takeover prevented and a customer's savings gone.
The vendor landscape is unsettled. CCaaS, CRM, and pure-play XOP vendors are all converging on the category from different directions. The specific choice matters less than the recognition that the choice has to be made, and made deliberately, before it gets made for you.
That closes Part 2. Part 3 turns from the intelligence layer to the operational muscle. Modernization is not just AI. It is workforce management, quality assurance, journey design — every operational function the contact center has ever built, rebuilt for the AI-first reality. Chapter 6 opens with a workforce manager's Sunday night and the spreadsheet that is about to become obsolete.