Classify products: where the process breaks and how to spot it

Product classification usually breaks where product knowledge passes from the people who design an item to the people who code it. Rework follows when technical data arrives thin or late, and when local spreadsheets quietly replace the master record as the place where the real answer lives.

The handoff from product teams

A classifier needs to know what an item is made of, what it does and how it is presented for sale. Engineering and product management hold that knowledge. They rarely see why it matters to customs.

So the request lands with a part number, a marketing name and perhaps a photo. The classifier then chases material composition, function and end use by email. Each chase restarts the clock, and the item sits unclassified while sales waits to ship.

A second version of this failure is timing. Classification gets requested once the item is already set up for ordering, sometimes once the first shipment is booked. At that point any question becomes urgent, and urgency produces guesses.

How to tell: classification requests carry free text in place of structured attributes. Classifiers keep their own folders of datasheets. New item setup can be completed in the ERP without a tariff code, and somebody fills the gap later.

Items that do not fit a routine code

Most items classify cleanly once the facts are known. The trouble sits with the awkward ones: kits and sets, parts and accessories for machines, goods with mixed materials, software bundled with hardware, and anything that changes form between factory and customer.

These need reasoned decisions under the general interpretive rules, and ideally a written rationale. In practice they often get the code of the nearest similar item. The rationale stays in one person's head.

Country differences make it worse. The international heading may be settled while the national tariff line or export control status still differs by destination. A code that is correct for import in one market gets reused for another where it is wrong.

How to tell: customs queries and post-entry amendments cluster on the same product families. Rulings exist but cannot be traced to the items they cover. Nobody can explain why two near-identical items carry different codes, or why two quite different items share one.

Codes that drift between systems

The approved code is supposed to live in one place. It usually lives in several: the item master, a separate trade compliance tool, the broker's database and the logistics provider's booking system. They fall out of step.

Drift begins with corrections. A broker spots an error at the border and fixes the entry, but the fix never flows back to the item master. The next shipment carries the old code again. Tariff nomenclature revisions cause the same effect on a larger scale, when expired codes stay on items because the update was loaded into one system and nowhere else.

How to tell: brokers return the same corrections repeatedly. Duty paid does not match what the item master predicts. Expired or invalid codes appear on commercial invoices. Preference claims fail because the code on the certificate differs from the one on the entry.

Workarounds that hide the problem

Workarounds are a sign people care about getting goods moving. They also bury the evidence that the process is failing.

The common one is a default or placeholder code applied so an order can proceed. Another is letting the broker classify at the point of entry, which shifts the decision to someone who has never seen the product. Some teams keep a shared spreadsheet of "real" codes that overrides the system, maintained by whoever has time.

None of these show up in a process map. They show up in duty variances, delayed clearances and audit findings, often long after the original shortcut.

How to tell: search the item master for codes that appear on an unusually wide spread of unrelated items. Ask brokers whether they routinely reclassify. Look for spreadsheets with names like "HS lookup" on shared drives.

Questions to ask the people who run it

The documented process and the lived one tend to diverge most here, so ask the classifiers, the brokers and the people setting up items, not only the process owner.

• When a request arrives without enough detail, what happens next, and who gets chased?
• Can an item be sold or shipped before it has an approved code? What fills the field if so?
• Where is the reasoning for a difficult classification written down, and could someone else find it?
• When a broker changes a code at entry, how does the business learn about it?
• Which product families cause the most queries from customs or brokers?
• How was the last tariff nomenclature revision loaded, and into which systems?
• Is there a list, file or personal note that is trusted more than the system?
• Who decides when the national tariff line or export control status differs by destination?
• What would stop if the most experienced classifier were away?

The answers usually point to one or two handoffs carrying most of the rework. Fix those first, and make the approved code impossible to bypass before the process is redesigned anywhere else.

APQC's Process Classification Framework® (PCF) is an open standard developed by APQC, a nonprofit that promotes benchmarking and best practices worldwide. To download the full PCF or to view definitions and measures, please visit www.apqc.org/pcf.