One Source of Truth

The customer sees one answer

A customer sees an image, a product option or an availability date. Behind that answer may sit several systems and teams.

For a multi-brand retailer, work across product information, commerce platforms, middleware and product presentation required those connections to be understood. When an answer looked wrong, the task was to trace the information and establish where a correction belonged.

This case examines another part of the client relationship covered in Building Knowledge & Confidence.

Problem: the visible issue may start elsewhere

A missing image is visible on the website. An incorrect availability date is visible to the customer. Neither symptom identifies the system or record responsible.

The reviewed meetings covered image handling, differences between markets, product feeds and the relationship between source data and customer-facing behaviour.

The challenge was to connect the business question with the relevant data, integration and presentation logic, then involve the people able to verify each part.

Approach: follow the information through the systems

In one recorded example, a missing New Zealand product image was restored with a new link, and the client contact acknowledged the resolution. The discussion also raised consistent image naming as a practical way to manage product assets.

Another meeting investigated an availability-date problem. The team ran a middleware synchronisation to pick up source-system changes, observed its effect and continued checking the result.

The issue remained after the sync. Laura requested verification of location and postcode information in the source system, while further investigation of changes and logs was proposed.

Running a sync is an action; confirming the correct customer-facing answer is the result that needs testing.

Keep scope and business ownership connected

Product information also had potential uses beyond the main website. A separate discussion explored a product feed for licensees, including the information to provide and restrictions on available assets.

A clear scope was needed before an integration could be estimated or delivered. Ticket organisation by business unit was also proposed to help prioritise different needs.

Data ownership is a business responsibility as well as a technical one. A developer can investigate a mapping, while the business must confirm what a product, region or availability rule should mean.

Outcome: specific fixes and a clearer investigation path

The records support a resolved image issue and documented work to investigate availability data, request source verification and define further product-feed requirements.

They preserve an unresolved result too: the availability-date problem was still present in the cited meeting.

This account focuses on observable work and results. It does not turn every investigation into a completed remediation or imply that all product information had been reconciled.

What one source of truth requires

For important information, establish where it originates, who can confirm it, how it is transformed and where people should correct it.

Then test the answer that matters to the user. A connection running without an error is useful evidence, but only one part of the check.

Start your free Initial Analysis or discuss the information your team struggles to trust.

Related reading: The tech stack grew without a plan.

More insights and tips