SAP Customer Experience (CX) explained

Written by an SAP Finance & Treasury practitioner working with SAP since 2008 · how the guides are written · Updated 10 October 2026 · facts checked against the SAP Help Portal, October 2026

SAP Customer Experience is the family of customer-facing SAP products that sit in front of the ERP: SAP Commerce Cloud for storefronts, SAP Sales Cloud and SAP Service Cloud for selling and support, SAP Engagement Cloud (formerly SAP Emarsys) for marketing, and SAP Customer Data Cloud and Customer Data Platform for identity and profiles. Short name: CX, formerly C/4HANA.

As of October 2026, Sales Cloud and Service Cloud each ship in two versions: Version 1, the former Cloud for Customer, and Version 2, SAP's cloud-native rebuild, which is extended through SAP BTP. The C/4HANA umbrella brand has been dropped, and SAP renamed Emarsys SAP Engagement Cloud in February 2026. SAP lists the current portfolio on its CX product page, and SAP Commerce's documentation is on the Help Portal.

What is SAP Customer Experience (CX)?

SAP CX is SAP's answer to the customer relationship management question — the web shop, the sales pipeline, the service desk, the marketing campaign and the customer's login — delivered as separate cloud products rather than as modules of one system. That last point is the one to hold on to. Finance, Procurement and Sales in the core share one database, one customizing tree and one transport route; the CX products share a brand, a set of integration packages, and the S/4HANA order they all eventually hand to. Each has its own tenant, its own release cadence and its own configuration tools, and most were bought rather than built, so a CX consultant is a specialist in one or two of them, not in "CX". Classic SAP CRM, the on-premise predecessor, is a different product again, and many landscapes still run it.

Which products are in SAP CX, and where did they come from?

Nine carry the name today, and five of them arrived through an acquisition whose old name practitioners still use in conversation.

The two versions of Sales Cloud and Service Cloud are not one product. Version 1 is still maintained and still running at many customers; Version 2 has its own data model, extension approach and user interface, and it is where SAP puts new capability, including Joule. Moving from V1 to V2 is a re-implementation, not an upgrade, so a CV or an advert that says "Sales Cloud" without the version says less than it seems.

Where does CX end and S/4HANA begin?

At the order: the CX product owns the interaction, and S/4HANA owns the priced, committed order and its posting. Prices are replicated from SD or called live from it, availability comes from the ERP's availability check, the basket becomes a sales order, and delivery, invoice and the receivable posting in Finance never leave the core. Customer and product records arrive already governed. Most CX design decisions and defects live on that seam, which is why nearly every CX role carries integration work, and why the interface catalogue agreed with the ERP team is the most contested document on a CX programme.

What does a CX project look like by phase?

Like a web project bolted to an ERP project, with the two running at different speeds: the storefront team ships every fortnight and the ERP team ships at go-live, and the project manager's job is keeping the interface between them from being redesigned every sprint.

• Discovery — journeys, catalogue scope, channel ownership, and the blunt question of what stays in the core.
• Build — sprints on the storefront, data model and pricing rules, plus the interface catalogue. Output is visible in a browser, so opinions form at the first demo, not at a specification review.
• Test — functional cycles plus two CX specialities: a load test sized for the trading peak, and a browser and device matrix no core module had to pass.
• Cutover — catalogue, customer and consent loads, redirects for old URLs, certificates and DNS, and a launch window away from peak season.
• Run — the storefront keeps changing long after the ERP settles, so support here is release work, not ticket work.

How do you get into SAP CX?

Through the product you already know, because CX is configured through browser UIs and a Java and JavaScript stack rather than through classic core customizing. Webshop managers and service leads arrive configuring the system they used; software engineers arrive because Commerce is a Java application with a JavaScript storefront; SD and Service consultants extend outward from the core to the channel.

What gets someone hired is evidence: a storefront release you shipped, a catalogue or customer migration you reconciled, an interface you operate, and the version of Sales Cloud you did it on. Interviews go at the operational edge: how a catalogue change reaches the live storefront, and who owns the consent record every channel reads.

What sits on the other side of the seam

Sales (SD)

Every checkout lands in order-to-cash, making SD plus CX a documented combination, and the order-to-cash questions of an SD interview a fair test of the SD half.

Service

The after-sales half of the same customer: tickets, contracts, field visits.

Integration and BTP

Extensions belong beside the core, not inside it, which makes SAP BTP the companion skill.

Data & Analytics

Channel behaviour is only useful joined to the order history, which lives in the reporting stack.