Last month I argued that the data an agent reads is the foundation under the foundation—that all our governance and security machinery is only as good as the data beneath it, and that SAP Business Data Cloud is how we make that analytical foundation trustworthy. I promised a sequel on the one domain where the data question gets hardest for utilities: the customer. This is that sequel, and it opens with a confession.

For years I used “SAP Customer Data Platform,” “SAP Customer Data Cloud,” and “the customer 360” more or less interchangeably. Most of us have. That imprecision is harmless in a hallway conversation and dangerous in an architecture review—because these are different products, with different jobs, different lifecycles, and very different implications for a regulated utility. The customer-data corner of SAP’s portfolio is the most misunderstood in the entire stack, and the misunderstanding is about to get expensive as customer-facing agents arrive.

So this month’s question is plain: when a customer-facing agent answers a ratepayer next year, what customer does it actually see—and is that customer real, current, and consented?

The Series So Far Part 1 — The Right Move: why the Autonomous Enterprise vision puts governance, security, and performance first.
Part 2 — Who Secures It: the agent-governance and security-operations story for utilities.
Part 3 — The Data an Agent Reads: SAP Business Data Cloud as the trustworthy analytical foundation.
Part 4 — The Customer an Agent Sees (this piece): SAP’s customer-data tools, untangled for a regulated utility.

Why a Customer-Facing Agent Raises the Stakes

An analytical agent that hallucinates produces a wrong number on a dashboard, and a human usually catches it. A customer-facing agent that misreads the customer does something worse: it acts, externally, in front of the ratepayer and—eventually—the regulator. It quotes the wrong rate schedule to a customer weighing a move to a time-of-use tariff. It offers a deferred payment arrangement the account is not eligible for, or misses one the customer is entitled to. In the worst case, it advances a disconnection for non-payment on an account flagged for a life-support or medical-certificate protection, or during a state disconnection moratorium. Every one of those failures traces back not to the model but to a fragmented, stale, or unconsented view of the customer.

SAP’s utilities leadership has framed this as the shift from understanding the customer “from a bill perspective” to understanding them across the full arc of consumption and creation—and insisting that every channel, from the call-center agent to the virtual agent to the website, works off the same thing. That is exactly right, and it is exactly what most utilities cannot do today, because the customer lives in a dozen places at once.

Three Products We Keep Confusing

Untangling the portfolio starts with naming the pieces precisely. Three SAP products get conflated, and a fourth is on its way out.

SAP Customer Data Cloud is the identity and consent layer—the former Gigya technology. Its job is customer identity and access management: login, registration, and, critically for us, enterprise consent and preference management. This is where “who is this person, have they authenticated, and what have they agreed to” gets answered.

SAP Customer Data Platform is the profile-unification layer. Its job is to assemble a unified, 360-degree engagement profile by stitching together identity, consent, and behavioral and transactional signals from across channels. It is the closest thing in the portfolio to the “single view of the customer,” but—read this twice—it is an engagement profile, not a system of record.

SAP Engagement Cloud is the activation layer—the product most of us still call Emarsys, renamed in early 2026 and now offered in two editions, including a new enterprise tier with cross-cloud orchestration, real-time ERP signals, and Joule-based AI. Its job is to act on the unified profile: segmentation, journeys, and omnichannel campaigns.

And the fourth piece is a caution rather than a recommendation: SAP Marketing Cloud is in the process of being retired. If any part of your customer engagement still runs through it, its sunset belongs on your roadmap now, not later.

The Distinction That Matters Most for Utilities

Here is the point the marketing language obscures, and the one your data architect will insist on: none of these is your customer system of record. For a utility, the authoritative customer master lives where it always has—in the business partner and contract account model of IS-U or S/4HANA Utilities. That is the record that bills, that a regulator audits, that a disconnect or a tariff change is executed against.

The customer-experience tools consume that record; they do not own it. A Customer Data Platform that unifies a beautiful 360 profile on top of a flawed business-partner record has produced a well-presented version of a wrong customer. Which means the real customer-data cleanup—deduplication, address and meter-to-account integrity, business-partner harmonization—is a master data governance exercise, the province of SAP Master Data Governance and disciplined data quality work, not something a marketing CDP does for you. Conflate the two and you will buy an engagement tool expecting a data-quality tool, and get neither.

A Measured Sequence for the Cleanup

If the goal is a customer an agent can safely see, the order of operations matters as much as the tooling. A defensible sequence for utilities:

Fix the system of record first. Harmonize the business partner and contract account in IS-U or S/4HANA Utilities through master data governance. This is the foundation; everything above it inherits its quality.
Resolve identity. Use Customer Data Cloud to establish one authenticated customer identity across the web portal, mobile app, and self-service channels, so the same person is not three different customers to three different systems.
Reconcile consent and preferences. Treat enterprise consent and preference management as a compliance control, not a marketing convenience—one consent ledger, enforced consistently across every channel.
Unify the engagement profile. Only now assemble the 360 view in the Customer Data Platform, layering behavioral and engagement signals onto a clean, identified, consented foundation.
Activate deliberately. Use Engagement Cloud for segmentation and journeys—with clear boundaries on what a customer-facing agent may decide versus what it must escalate to a human.

Notice that the cleanup is mostly finished before the marketing tools enter the picture. That is the inversion most programs get wrong: they start with the activation platform because it demos well, and discover the data problem only when the campaigns—or the agents—start behaving badly.

The Honest Caveats

Three cautions belong in the open.

First, this portfolio is in motion. Products are being renamed, repackaged, and retired on overlapping schedules, and integration methods carry their own deprecation timelines. Before you commit to any single component, confirm its lifecycle status and its supported integration paths directly with SAP. The names in this article are current as I write; treat them as a snapshot, not a constant.

Second, consent is a regulatory obligation, not a marketing feature. For a regulated utility, mishandled consent and preference data is not a campaign-performance issue; it is a compliance exposure. The tooling exists to do this well, but only if we scope it as the compliance control it actually is.

Third, a unified profile is not a clean profile. The single most important sentence in this article is the one worth repeating: these tools assemble and activate the customer; they do not, on their own, make the underlying record correct. Master data governance remains our work.

What We Still Need to Influence

A utility reference architecture, not a marketing diagram: We need SAP to publish how the business partner in IS-U or S/4HANA Utilities, Master Data Governance, Customer Data Cloud, the Customer Data Platform, and Engagement Cloud actually fit together for a regulated utility—with the system-of-record boundary drawn explicitly.
Consent mapped to utility regulation: Enterprise consent and preference management should be mapped against the privacy and customer-protection obligations utilities actually carry, so each of us is not translating marketing documentation into a compliance posture alone.
Lifecycle clarity and migration protection: With one customer-engagement product retiring and others rebranding, utilities need clear timelines, supported migration paths, and protection for the integrations we have already built.
Agent authority on customer accounts: As in the security discussion, we need explicit guidance on which customer-facing actions an agent may take autonomously—and which, such as disconnections for non-payment, deferred payment arrangements, and rate-schedule changes, must route to a human with documented approval.
The system-of-record principle, defended: We should hold the line, together, that the customer master stays authoritative in the utility’s core of record. Customer-experience tools are consumers of that truth, never its owner.

A Call to Our Community

Across this series I have asked you four questions: whether you had a better governance answer than SAP’s, whether you could tell your regulator who secures your agents, whether the data your agents read is trustworthy, and now—whether the customer your agents see is real, current, and consented. They are the same question wearing different clothes. Autonomy is only as safe as the foundation beneath it, and for the customer-facing work ahead, that foundation is a clean record, a resolved identity, an honored consent, and a clear line around what an agent is allowed to decide.

If a customer-facing agent went live in your utility tomorrow, could you guarantee it saw one accurate, consented, current view of each ratepayer—and knew exactly where its authority stopped? If not, the path is not a new platform purchase. It is the unglamorous, essential work of getting the customer right, in the order that the work actually demands, before the agents arrive to read it.

Start by naming the pieces correctly in your own shop. Hand this to your CX lead and your data governance lead in the same meeting, and make them agree on which product owns which job—and which one owns the truth. That conversation, more than any procurement, is where a trustworthy customer foundation begins.

To get involved and keep up with the latest, https://utility.community/all-subscriptions/