SAP Customer Experience (CX) explained

SAP Customer Experience — CX, the family once branded C/4HANA — is the set of customer-facing SAP products that sit in front of the ERP: commerce storefronts, sales and service clouds, customer data and marketing. This guide covers which products carry the name, where CX ends and the ERP begins, what changes between discovery and run, and the routes in.

Which products carry the CX name, and which were bought?

Commerce, sales, service, quote-and-subscription, customer data and marketing each ship as a separate product, several of them bought and rebranded rather than grown in the module tree. Practitioners name the product they run, and old names stick:

Commerce Cloud (still called Hybris) — B2B and B2C storefronts, the catalogue, promotion and price rules, and checkout.
Sales Cloud (grown out of Cloud for Customer, C4C) — accounts, opportunities, quotes and territories.
Service Cloud — cases, entitlements, routing rules and the agent desktop. SAP Field Service Management ships in the same portfolio and is deployed against both Service Cloud and S/4HANA Service.
Quote and subscription — SAP CPQ for configurable products and approval steps; Subscription Billing for recurring models.
Customer Data Cloud (Gigya) and Emarsys — registration, login, consent and preference records, then the segments and campaigns that read them.
Classic SAP CRM — the on-premise predecessor many landscapes still run; migrating off it is its own project type.

Where CX ends and the ERP begins

The customer-facing product owns the interaction; the ERP 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.

What changes between discovery and run

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 agreed with the ERP team. 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.

Routes in, and the evidence that gets someone hired

CX is configured through browser UIs and a Java and JavaScript stack rather than through classic core customizing, so the door is open to people from commerce operations and engineering. They arrive as webshop managers and service leads now configuring the system they used; from software engineering, since Commerce is a Java application with a JavaScript storefront; from the core, where SD and Service consultants extend outward 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. 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.
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 BTP the companion skill.
Data & Analytics: Channel behaviour is only useful joined to the order history, which lives in the reporting stack.