OP-003
Operator Publication — 003
Collection: Catalogue Optimisation — Building Sales-Ready Catalogues
Author: Founding Members of OPTIMASI
An Operator finds a product page showing the wrong information.
The colour is wrong. A specification sits in the wrong attribute. A product has been placed in the wrong category. A value that was corrected recently appears incorrectly again.
The problem is visible on the website, so the page is an obvious place to begin.
Sometimes that is all the Operator needs to correct.
A value may have been entered incorrectly while the page was being edited. A publishing setting may have applied the wrong treatment. A manual change may simply have introduced a mistake.
But the same kind of problem can also appear after something happened much earlier.
The supplier information may already contain the wrong value. Correct information may have been mapped into the wrong field. A transformation may have changed it incorrectly. Or an established catalogue treatment may continue to be applied when new product information is added.
By the time the problem appears on the website, the published result may already reflect several earlier steps.
Correcting the page can therefore be completely sufficient in one situation and only part of the required response in another.
The page shows where the problem is visible.
It does not always show whether the page is the only thing that needs attention.
When a catalogue problem becomes visible on the website, what does the Operator need to understand to know whether correcting the page is enough?
Some problems are clearly local.
Others result from something that happened earlier in the handling of the information.
The Operator needs to distinguish between those situations without turning every correction into an unnecessary investigation.
Suppose a supplier provides:
Material: Polyester
Colour: Black
Both values are correct.
During import, however, the supplier’s Material field has been mapped to the catalogue’s Colour attribute.
The resulting product page contains:
Colour: Polyester
The Operator changes the page to:
Colour: Black
The published information is now correct.
But another product is imported later:
Material: Nylon
Colour: Navy
Its product page contains:
Colour: Nylon
The second occurrence reveals something the first correction did not resolve.
There is nothing necessarily wrong with Polyester, Black, Nylon or Navy as supplied values.
The mistake is in the mapping between the fields.
Correcting the first page removed the first visible problem. It did not change the mapping used for the next product.
The same thing can happen without a field being mapped incorrectly.
A supplier record may correctly state:
Length: 12 in
If length is represented in centimetres in the catalogue, that value needs to be converted.
Suppose the conversion produces:
Length: 12 cm
The supplied value was correct.
The published value is not.
The problem was introduced during conversion.
Classification, normalisation and other catalogue treatments can produce similar results.
A problem that begins before publication is therefore not automatically evidence of poor supplier information. Information can be dependable when it arrives and become problematic through the way it is interpreted, transformed or placed.
Now consider a different case.
The supplier information says:
Width: 120 mm
The catalogue record also says:
Width: 120 mm
While editing the published product, an Operator accidentally changes the value to:
Width: 1200 mm
The mistake occurred during the page edit.
Changing the value back to 120 mm resolves both what is visible and what produced it.
Nothing earlier needs to be reconsidered.
That boundary matters.
The useful operating approach cannot be:
Always look earlier in the process.
A clearly local error can remain a local correction.
Two pages can therefore show the same kind of wrong value while representing different situations.
On one page, somebody typed the wrong value.
On another, a shared mapping assigned information to the wrong attribute.
Both pages need correcting.
But the first correction may be complete once the page is fixed.
The second page can also be corrected immediately while the mapping remains capable of producing another occurrence.
The question is not whether the visible problem should be corrected.
It is whether correcting it has resolved everything relevant to that problem.
That cannot be determined from the visible result alone.
A catalogue problem becoming visible on the website does not by itself establish what produced it.
The problem may have been introduced on that page.
It may already have existed in the source information.
Or it may have arisen while the information was transformed, mapped, classified or otherwise handled before publication.
Later steps can carry that problem forward without being the stage that introduced it.
A page-level correction can therefore have two different meanings.
Where the problem was introduced locally and is contained there, correcting the page can resolve it completely.
Where the page contains the result of something introduced earlier, correcting the page can resolve what is currently visible while the condition that produced it remains.
The Operator therefore needs to distinguish between where the problem appears and what produced it.
Sometimes they are the same.
Sometimes they are not.
When incorrect information is visible on the website, the Operator does not need to delay an obvious correction while investigating everything that happened before publication.
The separate question is whether that correction should be treated as complete.
Where a local edit clearly introduced the problem, there may be no reason to look further.
Where that is not clear, the Operator can follow the information back only as far as needed to understand how the published result arose.
Was the value already wrong when it arrived?
Was correct information transformed incorrectly?
Was it mapped into the wrong field?
Was an established catalogue treatment applied inappropriately?
Or did the problem arise only during publication?
The purpose is not to reconstruct every technical step. It is to decide whether anything beyond the visible problem also requires attention.
That judgement should remain proportionate.
One obvious typing mistake does not justify reviewing an entire information process. But where a shared source, transformation, mapping or catalogue treatment could plausibly have produced the problem, the page correction should not automatically be treated as complete.
The point where the Operator can act may also differ from the point where the problem first arose.
If an external supplier repeatedly provides an incorrect value, for example, the Operator may not control the supplier’s source system. The practical response may need to be made at a later point the Operator does control.
Finding what produced the problem also does not establish how far it extends. A shared treatment may have affected one product or many.
That is a separate question.
Correct the visible problem when necessary, but before treating that correction as complete, establish whether something earlier in the handling of the information also requires attention.
This gives the Operator a more dependable basis for deciding what has actually been resolved.
A visible problem can remain a straightforward page correction when the evidence supports that conclusion.
But when the page contains the result of something introduced earlier, the Operator can distinguish between correcting the current occurrence and addressing a condition that may continue to affect later catalogue activity.
That distinction matters because product information keeps changing.
New products are added. Supplier information is revised. Imports are repeated. Mappings and transformations are applied again. Established catalogue treatments are reused.
If a condition remains active through that continuing activity, another visible problem can appear after the previous page has already been corrected.
The Operator’s responsibility is therefore not only to correct the page in front of them.
It is to judge whether that correction has resolved the relevant problem or only its current visible occurrence.
That does not require control over every external source or technical process.
It provides a more precise basis for recognising when a correction is contained and when something earlier also needs attention.
Without that distinction, catalogue maintenance can become a sequence of repeated page-by-page corrections while the conditions producing them remain unchanged.