When One Customer Belongs to More Than One Business

A Microsoft customer story published in June 2026 describes the group's move towards a common Dynamics 365 sales platform, shared sales logic and more coordinated activity. It also makes clear that the transformation is still developing. The source supports the existence of the structural problem and Rhenus's chosen direction. It does not establish completed commercial outcomes or show that decision rights across the businesses have been settled.¹

The important point is narrower than the platform story. Imagine a legal entity that buys warehousing from one Rhenus business, freight services from another and customs support in a third country. Each local team may hold an accurate record. Each may understand its own contract and operational obligations. Yet an account-prioritisation decision, a service-recovery response or the preparation for a senior customer meeting may be weaker because no one recognises the relevant context held elsewhere.

Here, belongs describes assigned commercial responsibility. It does not mean that any business owns the customer. Nor does one customer always mean one thing. A natural person, a contracting legal entity and the wider economic group are different identities. Recognising a corporate group can inform an account decision without merging its contracts, risk positions or legal duties.

Several correct records can therefore coexist with an incomplete decision. That is the management issue. The defect is not fragmentation in itself. It is the absence of context that should change a consequential judgement or action.

Even that does not justify a group programme on its own. Many relationships cross an organisation chart without requiring group treatment. The first task is to establish whether the relationship and the decision are material, and whether improving the decision is worth the burden of crossing the boundary.

The case for a shared capability should therefore pass two thresholds. The first is materiality. Missing context should be capable of changing a consequential decision. The second is proportionality. The likely improvement must justify the legal, technical and organisational burden needed to produce it.

As an executive test, materiality can be judged through a small set of factors. These are an author synthesis from the case and governance evidence, not an external standard. Consider the revenue, exposure, service dependency or strategic importance of the relationship across businesses. Consider the consequence of one business acting without context held by another. Assess how likely that information is to change the decision, how often the coordination need arises and whether the customer reasonably experiences the group as connected for this purpose. Then compare a persistent group capability with a narrower bilateral process.

Proportionality changes the conclusion. A relationship may be strategically important yet occur too infrequently to warrant new infrastructure. The relevant information may be difficult to match reliably. Access may create legal and confidentiality obligations that outweigh the expected gain. Adoption may be weak because local incentives remain unchanged. A manual escalation between two account owners may sometimes be the better design.

The economic case should be expressed as the expected improvement to a named decision, not as a promise of revenue growth. In practical terms, value depends on how often the decision occurs, the consequence of missing context, the probability that shared information changes the decision, and the quality and use of the capability. Its legal, technical and organisational costs then need to be deducted. This is a decision frame, not a validated return-on-investment formula.

In some organisations, the correct answer is to remain local. Local ownership and selective bilateral coordination can be preferable where overlap is incidental, businesses operate under different duties, specialist context is decisive or the value of a shared capability is small. Research on enterprise operating models likewise recognises settings in which business units retain substantial decision rights while shared governance or tools remain limited.²

The result is not a presumption for or against integration. It is a threshold. Only after a named decision passes both materiality and proportionality should the group ask what capability is missing.

Volkswagen Group offers a bounded illustration. A Salesforce case describes a standard stack used across several brands, connected to existing data investments. Parts of the design use zero-copy access, while brands retain flexibility in how they present themselves to customers. The case shows that a common capability can coexist with distributed systems and brand autonomy. It does not prove that this architecture is generally superior, and its reported service results are not independently established as effects of the platform.⁴

Four capabilities need to be separated.

Shared Identity establishes, at an appropriate confidence level, that records concern the same person, legal entity or economic group.

Shared Visibility gives authorised roles access to selected facts for a defined purpose.

Shared Workflow creates a referral, hand-off, escalation or coordinated process across businesses.

Shared Decisioning uses information from more than one business in a recommendation, judgement or action.

These are design choices, not stages on a maturity ladder. A group may need the first two and deliberately stop there. It may coordinate a service response while leaving the commercial decision local. It may share a policy for one use without sharing the underlying applications.

Identity resolution also creates risk. A false-positive match can attach information or action to the wrong person or company. A false negative leaves a material relationship divided. Stale data can make a connected view look more authoritative than it is. Confusing a contact with a contracting entity, or a legal entity with its parent group, can produce a coherent but incorrect picture. Entity-resolution research treats this uncertainty as intrinsic to the task, not as a temporary defect that disappears once enough data has been collected.⁵

Identity therefore requires confidence thresholds, lineage and a correction path. It answers whether records are connected. It does not decide who should see the associated information, whether its reuse is permitted or what anyone may do with it.

The number matters. Eighty strategic accounts are not a proxy for every DHL customer. The design starts with a population for which cross-divisional coordination is recurrent and consequential. It is an example of selective visibility, not evidence for universal access.

The next design question is use. A strategic-account lead may need to know which divisions serve the same economic group, who owns each relationship, whether a material service issue is open and what commitments have been made. That does not mean the lead needs every interaction, operational field or personal detail held by every division. Visibility should be built around the decision and the authorised role.

The legal boundary reinforces this management discipline. GDPR Recital 48 recognises that controllers within a corporate group may have a legitimate interest in transmitting personal data for internal administrative purposes, including client data. It is not blanket permission to combine or reuse information. Each purpose still requires an appropriate lawful basis, necessity, data minimisation, transparency and arrangements that reflect the entities' actual controller, joint-controller or processor roles. Further use may require a compatibility assessment. Availability inside the group does not establish organisational need-to-know or legal permission.⁷

The Warehouse Group shows why purpose and expectation become more visible in a consumer setting. An Adobe case describes profiles assembled from three retail brands and used for segmentation and campaign activation, while brand-specific views remained available. It is a narrow example of cross-brand marketing decisioning rather than a general group customer model. The matching design and legal basis are not disclosed, and the reported campaign comparisons do not establish causal revenue effects.⁸

A customer may know that two brands share a parent and still not expect detailed behaviour in one relationship to influence marketing, pricing or credit in another. Reasonable expectation matters to fairness and the balancing of legitimate interests.⁷⁹ It is neither consent nor a substitute for a lawful basis. The more consequential or surprising the reuse, the stronger the justification, transparency and control required.

Selective visibility also needs a route into action. Otherwise it adds another screen without changing a decision. Shared Workflow is the practical bridge. A group-account alert can trigger a referral to the local owner. A service failure can open a cross-business escalation. A relevant opportunity can be passed to another team with the customer's context and the permitted minimum of data. The final decision and customer communication can remain local.

This is often enough. Coordination does not always require a group decision. Yet the moment two businesses disagree about priority, cost or customer commitment, visibility reaches its limit. The unresolved question is authority.

Nor does a common profile govern itself. Someone must own definitions, source precedence, corrections and the hierarchy between a legal entity and its economic group. When local leaders disagree, an escalation route is needed. If users are rewarded only for local outcomes, access to broader information may change nothing.

These are operating-model choices. MIT CISR defines governance in terms of allocating decision rights and accountability to encourage desired behaviour. That distinction is useful here because information access and authority are separate design decisions.¹⁰ The public company cases rarely disclose their account-ownership rules, incentive arrangements or conflict processes. That absence is an evidence limit. It is not evidence that the organisations failed to resolve them.

For this essay, Decision Architecture means the arrangement that determines who may decide, which evidence may be used, what objective applies, how conflicts are resolved and who remains accountable. Its purpose is not necessarily to produce one group decision. It may coordinate several local decisions.

Consider a service-recovery case. A group account lead may see that a failure in one business threatens a larger relationship. The local business may still decide the operational remedy because it holds the contract, expertise and service budget. Decision Architecture can define the evidence the lead may present, who can request an exception, which executive resolves disagreement and who communicates with the customer. The group has coordinated the response without pretending that every authority has moved upwards.

The same restraint applies to commercial opportunities. Total customer value may be relevant, but it should not automatically override local economics or duties. A financing business cannot treat a retail relationship as permission to relax risk requirements. A specialist subsidiary may reasonably decline a group proposition it cannot deliver well. Local decision rights can protect expertise and accountability.

The minimum group contribution may therefore be shared identity, a limited alert and an escalation path. More extensive decisioning is warranted only where the objective genuinely spans businesses, the evidence can be used for that purpose, conflicts have a legitimate resolution rule and an accountable owner is clear.

That distinction becomes sharper when software moves beyond displaying information and starts to recommend, prioritise or act.

Reporting combines activity, while analysis identifies patterns. A recommendation may propose an offer, route or priority, while decision preparation materially shapes a person's judgement. Partial automation executes part of a workflow or narrows the available options. Fully automated decisioning takes consequential action without meaningful human involvement. As the system moves closer to action, errors in identity, purpose and authority travel further.

Rhenus currently provides a modest example. Its first AI functions summarise customer histories and help employees prepare for meetings. That is decision support. The cited source does not describe an autonomous cross-business decision.¹ Volkswagen's case points towards agents for personalised interaction, lead routing, test-drive scheduling and the hand-off of service cases to people. Many of these uses are described as planned or developing, not as settled operational practice.⁴

The evidence base does not contain a strong public case in which AI uses data from several legally or operationally distinct group businesses to make one consequential customer decision under fully documented governance. The issue should therefore be treated as a forward governance requirement, not as an established market norm.

Four questions make the requirement concrete:

1. What identity is the system acting on?
2. What objective is it optimising?
3. Which evidence is it permitted to use?
4. Who may override it and remains accountable?

These questions apply whether the data sits in one platform or remains distributed. NIST's AI Risk Management Framework distinguishes systems that act autonomously, defer to a human or provide additional input. It emphasises intended use, human roles, oversight and accountability without prescribing a central data architecture.¹¹

Natural-person creditworthiness provides a bounded contrast. A group may hold commercially useful information about a person across retail, payments and other services. That does not make all of it an appropriate dataset for a credit decision. Purpose, necessity, data quality, sector rules and model governance require separate assessment. Certain AI systems used to evaluate a natural person's creditworthiness or credit score are classified as high-risk under the EU AI Act, subject to the regulation's scope and exceptions.¹²

Profiling and recommendation are not automatically decisions under GDPR Article 22. An intermediate score or recommendation may nevertheless fall within Article 22 where the recipient gives it a determining role in the consequential decision.¹³ The stricter rule concerns decisions based solely on automated processing that produce legal or similarly significant effects. Where human review is relied upon, it must be meaningful rather than a nominal approval step.¹³ This does not make less consequential recommendations governance-free. It means that their controls should fit their actual use and effect.

AI therefore raises the value of precision. The system needs an identity level, an approved objective, defined evidence and a person or business that remains answerable. None of that requires all customer data to be centralised. It requires the organisation to decide what, if anything, should be shared before action is scaled.

1. Name the impaired decision. Define the judgement, action or hand-off that lacks relevant cross-business context. “Create a group-wide customer view” is not a decision. Prioritising a strategic account, coordinating service recovery or deciding whether a referral is appropriate is.
2. Identify the required identity level. Decide whether the decision concerns a person, a contracting legal entity or an economic group. Set the confidence required for a match and define what happens when the evidence is ambiguous.
3. Specify the minimum information needed. Start with the facts that could change the decision. This might be the services used, the responsible owner, an open commitment or aggregate exposure. Do not begin with everything the group can technically expose.
4. Define access and permitted use. State who may see the information, for what purpose, under which legal and organisational authority, and with what transparency and correction path. Technical access should reflect these choices rather than make them by default.
5. Assign decision rights and conflict rules. Name the local authority, the coordinating owner, the escalation route, the exception rule and the business accountable for the result. Align workflow and incentives closely enough that the information can affect practice.
6. Apply the burden and proportionality test. Estimate the expected improvement to the named decision against matching risk, implementation cost, legal obligations, governance effort and adoption. A relationship can be material and still fail this test.

This sequence permits several legitimate outcomes. The first is no group capability, with local ownership and occasional bilateral coordination. The second is shared identity only, perhaps to flag that another relationship exists. The third is selective visibility combined with a coordinated workflow while decisions remain local. The fourth is shared decisioning for one defined purpose with explicit authority and accountability.

These outcomes are not maturity stages. A regulated decision may remain local while a service workflow is coordinated. A group may share an economic-group hierarchy for strategic accounts and keep consumer identities separated. Another may use one platform for convenience while preserving different permission and decision models within it.

The credible value mechanisms are equally specific. DHL CSI reported duplicate research before its shared platform.⁶ Rhenus describes integrated lead capture and decision support.¹ Volkswagen reports faster service-case resolution, although the causal effect is not independently established.⁴ These examples can justify testing whether coordination improves a named decision. They cannot support a general promise of growth or return on investment.

System consolidation may be one implementation choice after the six steps. It is not their conclusion. The architectural question is how to provide the minimum shared capability that the decision requires, with enough quality, permission and accountability to make its use defensible.

Separate operating models remain legitimate. They can protect expertise, accountability, contractual clarity and regulatory duty. The case for crossing their boundaries begins only with a named consequential decision and relevant context that should materially change it. It succeeds only when the expected improvement is proportionate to the burden.

Even then, the answer may stop at recognition. It may add selective visibility or a coordinated workflow while authority stays local. Shared decisioning is the most demanding option, not the natural destination.

The objective is not to place every customer record in one system or make every relationship a group asset. It is to prevent a relevant relationship from disappearing when a consequential decision is made, and to cross organisational boundaries only as far as that decision can justify.