On 7 August we argued that the winning customer interface is the one connected to a functioning decision and fulfilment system. This piece takes that claim one level deeper. The usual response to an online-to-offline gap is more integration, but integration cannot decide which stock position is real, which price can be promised, who may correct a conflicting state or who owns the customer exception.

Digital parity exposes the handoff

J.D. Power's 2026 China Customer Service Index gives a useful aftersales example. Digital appointment usage reached 44.7%, up 1.1 percentage points year on year, while digital services are described as moving from differentiator to basic expectation. The more revealing finding sits behind the interface: automatic identification of appointment users declined by 6.4%, the unidentified-user rate rose by 7%, and the share of customers asked to provide information again on arrival increased to 4.7%.

The evidence is China-specific and limited to owners of internal-combustion-engine vehicles. It should not be treated as proof for every market or retail model. It does show the mechanism clearly: the front end can know who the customer is while the operating process that follows fails to preserve the same state.

The same source also points to a different reason for aftersales leakage. Independent providers are gaining relevance where proximity and service-hour convenience matter more to customers. If the customer never chooses the authorised journey, interface integration is not the binding issue. The narrower claim here begins once a digital journey has been chosen: the organisation should preserve the state it has already captured and be able to execute the commitment it has made.

Integration does not settle ownership

Once a front-end/back-end gap is visible, the obvious response is to connect the systems. That is necessary, but it does not resolve the operating decision. If the commerce layer shows a vehicle as available while the allocation system already treats it as committed, moving both records faster does not tell the customer-facing channel which state it may promise.

Management therefore needs one authoritative definition for each critical state, a rule for which source wins when systems disagree, and a role authorised to correct the record or recover the customer commitment. Without that, connectivity can distribute inconsistent information faster.

Repeated data entry is the easiest symptom to recognise. If a customer explains the same issue to the app, call centre and workshop, the organisation is using the customer to carry state between systems. The same problem appears commercially when different channels present different availability, delivery timing or order status and the customer has to work out which one is real.

The hard work starts after the click

Consider stock shown online. A vehicle can be visible in a commerce system while already reserved in allocation or committed locally. If the website reads one record but fulfilment runs from another, the customer promise is unstable before checkout starts. The design question is therefore which stock state may be exposed, when that state becomes reserved and who can override it when reality changes.

Once the order is accepted, finance, registration, logistics and the delivery point have to work from the same transaction state. A delay then needs a named owner for the customer commitment, and a specification change needs someone with authority to approve the recovery offer rather than sending the case back through the organisation.

Aftersales has the same requirement. A digital booking only becomes useful when the workshop recognises it, sees the relevant case history and has the parts and capacity behind the promised slot. If diagnosis changes the repair, the case should continue from the state already established rather than restart with the customer.

Direct sales makes the coupling visible

In an anonymised at.Pointe direct-sales engagement, facility choices, network reach, volume, pricing, inventory, capacity, logistics, margin and break-even were connected in one modular economic and operating model. That was not a modelling preference. A network choice altered the footprint that had to be funded and the coverage the business could provide; pricing and volume assumptions changed whether that footprint was viable; inventory and capacity then determined whether the customer promise could actually be delivered.

Separate workstreams could each have produced a sensible answer while relying on assumptions the rest of the operating model could not support. Keeping the economics and execution logic together made those dependencies visible before they became launch exceptions. The integrated strategy and business cases received board approval, and pricing, retail and aftersales progressed into implementation with one economic and operating model.

Build the journey from fulfilment backwards

A stronger design starts with the customer commitment and works backwards through the operating requirements.

1. Define the executable promise. Decide what availability, price, delivery timing or service slot can actually be committed externally.
2. Define the authoritative state. Specify which record governs the promise at each stage and what event changes that state.
3. Define ownership and exception rights. Name the role that can correct the state, resolve a conflict and recover the customer commitment without sending every decision upward.
4. Define the physical dependency and fallback. Capacity, parts, logistics, registration and local execution must support the commitment, with a recovery route when one dependency fails.
5. Measure promise completion. Track the break between what the interface committed and what fulfilment delivered.

Two measures worth defining precisely

Availability accuracy is the share of customer-visible availability that remains executable on the stated terms when the customer commits. It is more useful than counting how often inventory data refreshed.

Exception recovery time runs from the moment a promise break is identified to the point at which the customer has a confirmed, executable alternative with one owner. Internal ticket closure is not the same outcome.

Other useful boundary measures include price and offer consistency, order-state continuity, repeated data entry, delivery exception rate, service handoff quality and first-owner resolution.

Do not build heavyweight integration behind a simple promise. Where a customer commitment crosses physical capacity, regulated processes or several organisations, define the operating state and decision rights before the interface exposes it.