At 9:10, a retailer's marketing team selects Maya for a complementary-product offer. She has bought twice recently, visited the relevant category again and still has permission to receive that promotion. In the campaign report, she looks like a sensible choice.
The delivery team sees something else. Her latest order missed its promised arrival date. Support has an open case asking where it is. Maya is waiting for an answer about the purchase she already made when the company prepares to ask for another.
Each team can follow its own process correctly while the combined experience makes little sense. A shared customer record matters when it changes this collision of decisions. The task is to connect evidence, priorities and responsibility across the business.
Maya and the retailer in this article are fictional. The situation is an operating scenario: a way to design and test coordinated decisions, rather than a claim about a particular deployment or commercial result.
Start with the decision that crosses a team boundary
The first question is concrete: should this promotion proceed while Maya's delivery problem remains unresolved? Answering it requires more than marketing's view of her likelihood to buy. It needs the order's current state, the nature of the case, the purpose of the proposed contact and the company's service policy.
An open case is not a universal reason to stop every interaction. A question about changing a delivery address differs from a serious unresolved complaint. Transactional updates may still be necessary when promotional contact is paused. Define the relevant case types and permitted purposes before turning a useful instinct into an indiscriminate exclusion.
The unit of design is a bounded choice with an owner: pause this promotion, keep necessary service communication available and assign the delivery investigation to the appropriate team. This is easier to evaluate than a broad promise to create a single view of the customer.
Share meaning, not just more fields
A profile can contain a purchase count, a delivery flag and a case status while still leaving teams with incompatible interpretations. Does purchase mean an order was placed, payment settled, or goods retained after returns? Does resolved mean an agent closed a ticket, the parcel arrived, or the customer accepted the resolution? These definitions affect the next action.
Keep observed facts, maintained measures, estimates and policy separate. A carrier scan is an observation. Days beyond the promised date is a calculation. An estimated cancellation risk is a prediction. Pausing promotions during a qualifying service incident is a business rule. A prediction cannot certify delivery, and a rule cannot explain why someone feels dissatisfied.
A useful shared state might say: the latest paid order is overdue; a delivery-related case is open; the carrier status was checked this morning; promotion eligibility requires review. Each statement needs a source and a time. Avoid compressing everything into a single red or green customer health label that conceals the reason.
Keep the source of authority visible
Shared context does not require every application to own every fact. The order system can remain authoritative for fulfilment, the service platform for case handling and the payment system for settlement. The customer context connects the relevant evidence without pretending those authorities have disappeared.
Identity is part of that contract. Match the order, account and service case to the correct person using identifiers appropriate to the relationship. A shared email address or household device may be insufficient. If the match is uncertain, restrict the action and resolve the ambiguity rather than confidently attaching someone else's problem to Maya.
Freshness should fit the decision. A quarterly value band can tolerate a different delay from an order cancellation check. Record when a source observed a change and when the decision system received it. If systems disagree, use an explicit precedence rule or request a current lookup; do not let arrival order silently decide which account of reality wins.
Turn shared context into an explicit priority
For the scenario, the retailer chooses a simple priority: a verified unresolved delivery problem takes precedence over a complementary-product promotion. Marketing owns the promotional exclusion, service owns the customer update and operations owns the delivery investigation. The policy also names who can approve exceptions.
The pause needs a release condition. A ticket closing alone may be insufficient if the parcel is still missing. Reconsider the promotion after the relevant delivery and service conditions are satisfied, then check permission, contact pressure, product availability and whether the original offer still makes sense. Resolved does not mean send immediately.
A maximum review interval prevents a forgotten pause from becoming permanent silence. An overdue review should create work for the responsible team, not automatically release a promotion whose prerequisites remain unknown. The important distinction is between waiting for evidence and deciding that contact is now appropriate.
| Responsible team | Evidence needed for this decision | Response in the scenario |
|---|---|---|
| Marketing team | A qualifying unresolved delivery incident; current promotional eligibility | Pause the promotion and retain its reason |
| Service team | The authenticated order, open case and latest verified update | Give a useful update and own the follow-up |
| Operations team | Carrier evidence and fulfilment status | Investigate delivery and report the verified result |
Make the handoff survive execution
A rule that changes a profile but leaves a message in a destination queue has not yet changed the experience. Identify the final reversible point: where can a queued promotion still be cancelled or rechecked? If the destination cannot enforce the current eligibility, stop the handoff earlier or narrow the use case.
The same applies to service ownership. Assigning a task is not proof that someone accepted it. Track acknowledgement, the next review time and escalation when no team responds. Repeated events should not create repeated service tasks or duplicate communications; the operation needs a stable identifier and a deliberate retry policy.
Preserve a small decision record: the relevant state, evidence timestamps, policy version, chosen action, owner and execution result. This is a proposed operating discipline, not a claim that one product screen contains all of it. It lets teams distinguish a poor policy from an integration that failed to carry a good policy through.
Use Binoban as part of the decision path
Binoban connects profiles, events, maintained customer measures, audiences and journeys. Computed Traits can give reusable meaning to qualifying activity, such as purchases in a defined window. Journey Decide evaluates ordered conditions and follows the first matching branch, with a default when none match. These mechanisms let teams express a transparent priority instead of leaving a useful signal in a report.
To use the delivery scenario, the relevant order and service signals must first be connected and their definitions validated. A customer attribute can represent an agreed service-related exclusion, but it does not replace native consent, destination checks or the source system's authority. A condition-based branch also does not establish autonomous learning or an automatically coordinated service operation.
Begin with one promotion and one clearly defined service condition. Demonstrate the eligible path, the paused path, a change while waiting, missing source data and a failed destination update. A convincing demonstration shows the changed decision and its limits, rather than an impressive canvas with no verified downstream effect.
Evaluate the shared experience
Operational success starts with whether qualifying cases were detected, promotions were withheld before release, necessary updates continued and a responsible team acted. Measure the time from a material change to the corrected decision, together with stale-state incidents, duplicate contacts and unresolved handoffs. A suppression count alone cannot tell you whether the policy helped.
Business evaluation includes resolution time, repeat enquiries, retained orders, complaints and subsequent contribution. Treat changes in those outcomes as observations until the comparison supports a causal claim. If testing promotional suppression, do not withhold essential service or required communication. Compare permissible alternatives under a defined observation window and account for uncertainty.
For Maya, the desired result is straightforward: the company addresses the outstanding purchase before trying to create another. Whether the next useful move belongs to marketing, service or operations becomes a consequence of the situation. Shared customer understanding earns its place when that responsibility becomes clear and the experience follows it.
Take the next step