Give Important Product Specification Fields a Clear Owner

A product catalogue may contain thousands of completed fields while nobody can answer who verified a particular value. A supplier updates a connector specification, purchasing records a new case quantity, sales copies an old description and customer service discovers that the item pictured is not the one delivered. Each team may be doing its immediate job, yet the business has no controlled route for resolving the conflict. Giving important product specification fields accountable owners does not mean appointing someone to guess missing facts. It means defining who retrieves evidence, approves changes, records uncertainty and checks that other teams receive the correct version.

This article applies practical data governance to UK electronics and general-product trading SMEs. The UK Government Data Quality Framework, published in 2020, describes data as fit for purpose and distinguishes completeness from accuracy, consistency, timeliness, validity and other dimensions. It is public-sector guidance, not a mandatory private-retail specification. GS1 product-identification guidance supplies a separate standard for trade-item identity. Used carefully, these sources help a small business distinguish an accurate product fact from a field that has merely been populated.

Prioritise fields by what can go wrong

Begin with attributes whose errors can change a buying decision or physical operation: model identity, variant, compatible equipment, material dimensions, pack quantity, included components, safety-relevant characteristics and relevant instructions. Consider how each value is used by sales, warehouse, purchasing and customer service. A typographical error in an internal display name may be inconvenient; a wrong power requirement or quantity conversion can affect the actual product supplied.

List the most important fields and name the decision they support. Length may refer to an individual product or the outer package. A customer-facing colour variant is not interchangeable with a supplier's mixed-carton description. The definition should specify units and scope before assigning an employee to maintain it. A field called 'weight' without saying whether it is net product weight or gross shipping weight is ambiguous by design.

Prioritisation should be proportionate. A business with twenty active specialist items may need a careful compatibility review on each, while a much larger low-risk catalogue may use sampling and exception triggers. One uniform approval process for every adjective and critical technical fact can create bureaucracy without improving the data that matters.

Separate the source, owner, approver and user

The supplier or manufacturer may be the source of an attribute, while a product manager is responsible for keeping it current. A technical reviewer may have authority to approve a compatibility claim; warehouse staff may independently verify carton contents. The website team may publish the authorised value. These roles overlap in a small company, but their purposes are distinct. An editor receiving a supplier sheet should not assume possession of the document grants technical approval.

Create a simple register showing each critical field or field group, authoritative source, accountable owner, reviewer, validation rule and downstream uses. For example, purchasing maintains supplier references and terms, product specialists review function, and warehouse staff inspect actual package configuration. Finance may own the currency and cost treatment of a supplier price rather than the engineering meaning of the item.

Make the owner responsible for handling uncertainty and resolving conflicts, not for inventing a complete value. If two manufacturer documents disagree, preserve both and investigate their model or revision applicability. An owner who can record 'unverified' is more useful than one whose performance is measured solely by how few fields remain blank.

Apply the right quality dimension to each problem

The Government Data Quality Framework distinguishes completeness, accuracy, consistency, timeliness, validity and uniqueness. A populated connector field can be complete and valid in format while inaccurate for the physical product. Two websites may consistently repeat the same wrong number. Conversely, a technically correct specification may be stale because a supplier changed the item last month.

Choose the quality check that addresses the actual risk. For a quantity, validate its unit and physical package level. For compatibility, check supported models and exclusions against a current source. For unique identity, review SKU and GTIN relationships. For timeliness, record supplier revisions and the version applicable to the product batch or sale.

Do not report a catalogue as high quality merely because ninety-nine per cent of its fields are filled. That metric describes completeness, not whether critical claims match reality. The more useful measure can be a reviewed sample of material fields, discrepancies corrected at source and dependent channels confirmed as current.

Connect each attribute to an identifiable physical product

Use manufacturer model, internal SKU, variant, version and any relevant external trade-item identifier together. A specification for one regional model must not be inherited automatically by a similar international version. When physical goods are identified by barcode, confirm whether the barcode describes the saleable unit or a larger purchase pack. An outer case's item count cannot safely be applied to the individual retail product.

GS1 UK's GTIN explanation provides useful identification context. It does not prove the accuracy of a supplier's compatibility statement or certify every physical pack. Verify those separately using suitable manufacturer or receiving evidence. Keep source identifiers retrievable so a correction can target precisely the products affected.

For product successors, preserve historical specifications. A customer who purchased the older version may need its own manual and warranty information. Replacing all old field values with the latest production revision can misrepresent transactions and make support harder, even when the new data is entirely correct for current stock.

Define how evidence is requested and reviewed

Every important change should have an origin: supplier notice, verified new sample, customer complaint, goods-in measurement, updated manufacturer document or approved commercial policy. The owner records the requested field, existing value, proposed value and reason. The reviewer checks whether the source applies to the exact product population. It is appropriate to request clarification where a drawing omits the production revision or a carton label contradicts the packing list.

A physical sample can help establish dimensions or included contents, but it does not necessarily prove an electrical safety claim or technical performance. Assign competent review according to the characteristic and applicable obligations. Where a material specification cannot be verified, keep it restricted from confident customer claims until the necessary evidence is obtained.

Record approval as an explicit decision, including the version and date. A file being uploaded to a shared folder is not necessarily an approved source. Likewise, a new value in a supplier email should not immediately overwrite a customer-facing warranty statement without reviewing what was agreed with earlier buyers.

Let unresolved fields remain visibly unresolved

Pressure to complete an import can encourage guesses. A supplier may leave 'compatible devices' blank while the retailer's system insists on a value. Do not fill it with 'universal' or copy an old model's list just to pass validation. Establish a recognised unknown state, explain which downstream uses are blocked and assign a reviewer and next action.

Use proportionate restrictions. A missing decorative marketing phrase may not prevent a sale, whereas an unverified essential compatibility claim might. The business should understand the operational consequence of each gap and identify what must be confirmed before the offer can be represented accurately. A good system permits a meaningful exception rather than disguising every uncertainty as a technical error.

When the answer is ultimately unavailable, remove or narrow the unsupported claim. An honest listing can describe what is known and encourage appropriate verification. It should not give customers false confidence about an application the supplier has never assessed.

Carry changes through every dependent channel

Identify which records consume a field: product master, ecommerce site, wholesale catalogue, marketplace feeds, price lists, picking instructions, labels and customer-support knowledge. A correction in the master is only the beginning. Define who checks that each relevant destination now displays the approved value, especially when some channels depend on manual imports.

Consider an outer-carton count changed from twelve to eighteen. Purchasing must review its ordering unit, warehouse receiving its conversion, finance its cost per item and online channels any pack quantity that customers buy. A technical change to a charger may affect compatibility descriptions and bundles rather than carton conversions. The owner should not assume that every field has the same dependent systems.

Capture completion evidence. An application showing 'sync successful' may have transferred the wrong SKU or only part of an update. Check representative final customer-facing and operational views. If one destination remains obsolete, keep a visible exception with an owner rather than declaring global completion.

Preserve revisions and audit historical meaning

Maintain the old and new values, their source, approval date and effective physical or commercial version where necessary. A supplier may change packaging without changing the underlying device. Another change may create a different trade item or customer offer. Do not assume every revision requires the same SKU change; assess the nature of the change under the applicable identification and product rules.

Historical sales, return cases and supplier credits must remain interpretable. A customer complaint about an old item needs the documentation applicable to that product, not whatever happens to be in the current catalogue. Use references that survive staff turnover and system upgrades.

Check changes for accidental backward propagation. Updating a family-level default can silently change many child variants. Test one affected and one unaffected SKU before releasing a major revision. Preserve an audit trail of consequential changes so the company can identify what genuinely changed when an error appears.

Keep field responsibility useful as the team changes

Review ownership when product ranges expand, supplier relationships change or staff leave. A central register should identify a real role or accountable person and a clear backup. A former employee's name in a spreadsheet is not an effective escalation route. Train colleagues to bring relevant questions and source evidence to the right owner instead of asking the last editor to guess.

Examine recurring disputes. If carton quantities repeatedly conflict, strengthen the supplier-data and receiving process. If support continually finds mismatched compatibility statements, improve technical approval and source revisions. The goal is fewer uncontrolled changes, not more approvals for their own sake.

Start with five or ten fields whose errors have meaningful customer or stock consequences. Record the source, owner, proof required and channels affected, then test the next real change from discovery to final publication. Product specification ownership succeeds when another employee can establish who approved a value, why it applies to this item and how uncertainty will be resolved without inventing an answer.