Connecting customer identity across commerce and service systems

← Architectures

Reference structure · Customer data · Technology × Organisations

One customer data architecture in which identity is resolved outside the systems that act on it, and each system keeps its own operational record.

This is one possible structure, not a target state and not a record of a system observed in a specific environment. It is useful while its assumptions hold, and it says where a different arrangement would fit better.

The structural question

Which system should own customer identity when commerce, marketing and service each hold a partial version of the same person?

Components

Each part is here for a reason: what it owns, and what it depends on.

• Identity resolution

  Owns: Source of record for which records refer to the same person.

  Depends on: Depends on stable keys — email, phone, order reference — and on consent to link them.

• Commerce platform

  Owns: Source of record for orders and account credentials.

  Depends on: Depends on identity resolution only for enrichment, never for checkout to complete.

• Service system

  Owns: Source of record for cases, contacts and entitlements.

  Depends on: Depends on order state being readable, usually asynchronously.

• Consent and permission store

  Owns: Source of record for what may be used, by whom, for what purpose.

  Depends on: Every downstream activation depends on it; ignoring it is a legal exposure, not a technical one.

• Activation surfaces

  Owns: Nothing durable. They read segments and write back interaction events.

  Depends on: Depend on latency being acceptable for the decision they are making.

Ownership and source of record

No single system owns 'the customer'. Identity resolution owns linkage; commerce owns orders; service owns cases; consent owns permission. Whoever can change the matching rules changes every downstream segment, which is why that rule usually needs a named owner outside the marketing function.

Movement through the structure

1. 01

   Source systems

2. 02

   Identity resolution

3. 03

   Consent and permission

4. 04

   Shared customer view

5. 05

   Activation surfaces

Direction matters more than the diagram: operational systems write, the shared view reads, and activation writes back only events — not corrections to operational truth.

Dependencies

The question is whether the dependency matches what the organisation needs.

Intentional coupling

Consent and activation must move together. A segment that can be built without a permission check is a structural defect, not a configuration gap.

Costly coupling

Making checkout depend on identity resolution being available couples revenue to an analytical component that was not built for that reliability requirement.

What is hard to reverse

Matching logic and consent semantics are the hardest parts to move once other systems have encoded assumptions about them. Warehouse and activation vendors are comparatively replaceable.

When something fails

If identity resolution fails, commerce and service continue on their own records; personalisation degrades to unsegmented, and segments become stale rather than wrong. If the consent store is unavailable, activation should stop rather than default open.

Assumptions

A reference structure is only reusable when its assumptions travel with it.

What must hold

If these are not true in a given environment, the structure is the wrong starting point.

• The same person genuinely appears in more than one system often enough to justify the resolution layer.
• Some latency between operational event and shared view is acceptable for most decisions.
• There is capability to own matching rules over time, not only to configure them once.
• Consent requirements are known and encoded rather than inferred.

Trade-offs

Each improves something and costs something. Neither side is universally preferable.

• A shared customer view against the operational complexity of maintaining linkage rules.
• Real-time consistency against a larger failure surface in checkout and service paths.
• Vendor convenience in a suite against portability of identity logic.

What this makes possible

Teams can act on the same reading of a customer, and disagreements become arguments about the rule rather than about whose export is correct.

What it constrains

It adds a component that must be owned, and it makes ad-hoc, team-local customer definitions harder to sustain.

How you would know whether it helped

Whether teams stop maintaining private customer lists, and whether contradictory contact within a single day reduces.

What informed this

Technical reasoning about ownership boundaries, platform constraints in commerce and service tooling, and observed situations where customer models had fragmented per team.

Another structure may fit when

Another structure may fit when one platform already holds nearly all customer interaction — resolving identity inside it avoids a component nobody is ready to own.

Where this stops fitting

Stops fitting single-channel businesses, environments with one operational system of record, or organisations without the capability to own matching rules.

Related

Related reading

Industry

• Retail
• D2C
• Consumer Brands
• BFSI
• Telecom

Knowledge · Playbook

• When Every Team Holds a Different Version of the Customer
• Operating a Marketplace That Keeps Moving Underneath You

Evidence · Observed Situation

• When growth outpaced the organisation's ability to read itself

The situations linked above informed this representation. They do not establish that this structure is right for another environment — that remains a question about the specific organisation, its ownership and its constraints.

Architecture, as a question →Work with Cralgo →