Adding channels without an orchestration layer breaks the experience
Organisations with multiple digital channels face a common problem: they add more surfaces (mobile app, kiosk, voice interface) without a coherent layer managing how those surfaces compose a consistent experience for the user. Content gets delivered differently on each surface. Personalisation is managed by separate systems that do not share data. Each new channel requires a new integration that was never designed to scale.
A Digital Experience Platform exists to solve this problem architecturally: not by unifying every tool into one product, but by creating a defined layer that orchestrates content, personalisation, and delivery across all surfaces from a shared foundation.
A DXP combines content, personalisation, orchestration, and multi-surface delivery
A DXP is built from four components that must work together:
- Content management and delivery. A headless CMS stores and manages content independently of how it is displayed, so the same content can be rendered correctly on a mobile app, a web page, or a voice assistant. Tools like Contentful, Sanity, and Storyblok function as this layer.
- Personalisation and targeting. Integrates with customer data platforms and AI models to determine what to show, when, and to whom. According to McKinsey's Next in Personalization 2021 report, faster-growing companies derive 40% more revenue from personalisation than their slower-growing counterparts.
- Orchestration logic. The decision-making layer that coordinates content, personalisation, identity, and service calls into a single unified response. Without this, the platform is a set of tools pointed at the same users, not a coherent experience system.
- Multi-surface delivery. The DXP must serve every channel — web, mobile, in-store, IoT, conversational AI — without requiring custom integration for each new surface. This is the test that exposes whether the orchestration layer was designed to scale.
The fix is designing the orchestration layer first, then choosing tools that fit
A retail platform team has a headless CMS, a customer data platform, a personalisation engine, and a payment service. Each tool works. Six months later they are asked to extend to a mobile app and an in-store kiosk. There is no orchestration layer managing how these systems present a unified experience. Each new surface reveals a new set of custom integrations. The team spends more engineering time maintaining connections than shipping new capability. The fix is not replacing the tools — it is designing the orchestration layer first, then selecting tools that fit it.
Going headless solves content delivery, not orchestration
Going headless is not the same as building a DXP. A headless CMS solves the content delivery problem. It does not solve the orchestration problem. Organisations that adopted composable architecture (Microservices, API-first, Cloud-native, Headless) and concluded that DXP as a concept was obsolete often found themselves with a set of well-chosen, loosely connected tools and no coherent orchestration model — fast content delivery, but no platform. The DXP is the orchestration layer. The headless CMS is one component of it.
