How Should a Chemical Supplier Categorize Technical Inquiries?

This method is for a chemical manufacturer's or distributor's own log of technical questions from customers and sales staff. Formal complaint handling, product recalls and regulated adverse event reporting have their own required records, which this scheme does not replace.

Which fields should every technical inquiry record carry at a chemical supplier?

Every technical inquiry record at a chemical supplier should carry four classification fields, kept separate: product family, inquiry type, symptom and outcome. Each field answers one question, and each takes one value from a written list.

Product family says what the question is about, at the level you report on, such as hydraulic fluids, metalworking fluids or anaerobic adhesives. Inquiry type says what the customer asked for: a document, a selection, a compatibility answer, an application method, a failure diagnosis, a regulatory statement. Symptom says what the customer saw, and stays empty when there was no problem. Outcome says how the inquiry ended.

Around those four, keep the facts that let you count and audit: date received, date closed, customer, channel, the person who handled it, and the product name or grade as the customer wrote it. Free text for the question and the answer stays in the record too, because a later definition change may need it to re-tag old inquiries.

ISO 10002:2018 lists "analysing and evaluating complaints in order to improve the quality of products and services" among the aspects of complaints handling it addresses (ISO, 2018). Technical inquiries are broader than complaints, but the same logic holds: data can only be analysed if each record was classified the same way.

How do you separate technical inquiry type from symptom and product family?

Separate technical inquiry type from symptom and product family by giving each dimension its own field and its own list, so that no single category mixes a product with a problem. A mixed category such as "hydraulic oil foaming" can be counted, but it cannot be added to "coolant foaming" to see how many foaming inquiries arrived, or to "hydraulic oil leak" to see how many hydraulic inquiries arrived.

The UN Statistics Division's guidelines state that categories at the same level must be mutually exclusive, meaning "each member of the population of primary units must only be classified to one category" (UNSD, 2022). Three separate fields let each list meet that rule on its own terms.

The table below shows one way to split the dimensions; all values are illustrative and should come from your own portfolio and records.

The key row is symptom: keep it as its own field, with "none" as an allowed value, so that document and selection requests do not inflate problem counts. A foaming question on a coolant then tags as metalworking fluid, failure diagnosis, foaming.

How do you write technical inquiry category definitions before tagging starts?

Write technical inquiry category definitions before tagging starts by giving every category a one-sentence definition, what it includes, what it excludes, and one real example, and by fixing the rule for the "other" category. Tagging without written definitions turns each person's judgement into a separate scheme.

The UN Statistics Division's guidelines recommend explanatory notes that "explain the content by giving examples of inclusions and exclusions" (UNSD, 2022). For an inquiry type such as compatibility, the include line might name questions about mixing two fluids or a fluid and a seal material, and the exclude line might send questions about switching products to selection. Each example should be an inquiry from your own log, with names removed.

The "other" category needs its own rule. The same guidelines describe residual categories as "primarily for operational purposes only" and say that vague responses "should not generally be coded to residual categories" but to the most detailed level the information supports (UNSD, 2022). In practice, set a limit on the share of inquiries in "other" (for example 10%, an illustrative figure your team sets), and review its contents each quarter; recurring themes there become new categories with dated definitions.

Before rollout, have two people tag the same set of past inquiries with the draft definitions and rewrite every definition they disagree on.

How do you record the outcome of a technical inquiry so it can be counted?

Record the outcome of a technical inquiry so it can be counted by choosing it from a short closed list at closure, with "outcome unknown" as an explicit value, and by setting the close date at the same time. An inquiry closed without an outcome should be counted as outcome unknown, not as resolved.

A workable outcome list separates what was done from whether it worked. What was done: answered from an existing document, answered with a new recommendation, field visit or test arranged, escalated to the manufacturer, converted to a formal complaint, no answer possible. Whether it worked is often unknown at closure; a follow-up field, filled in only when the customer confirms, keeps that fact separate and honest.

Two counting rules follow. First, the denominator is every inquiry closed in the period, including outcome unknown, so the share of unknowns is visible rather than hidden. Second, an inquiry reopened for the same problem stays one inquiry with a reopen date, not a new one, or repeat problems disappear from the counts. Lubinpla's technical support performance analysis fixes the metric definitions, the denominator and the exclusion rules before querying the records, and diagnoses within the organization's own scope.

The outcome field is also the one that shows where work stops. Open inquiries with no outcome and no recent activity are the starting point when you find where technical support cases get stuck, and that analysis only works if closed ones carry an outcome.

What do you do with old data when a category definition changes?

When a technical inquiry category definition changes, log the change with its effective date, map each old category to the new ones, and either re-tag past records or report the two periods separately. Counts before and after an undated change cannot be compared, because the same number now means something different.

The UN Statistics Division's guidelines say time series "can be managed through the use of correspondences (which map or link together different versions of classifications), back-casting or dual-coding" (UNSD, 2022). A correspondence records how each old category relates to the new ones: unchanged, split into several, merged with others, or with no equivalent.

For a technical inquiry log, that becomes four practical moves. Keep a definition log with version number, effective date, the category changed, the old and new definition, and who approved it. Write the mapping table for every changed category. For a split, re-tag the affected past records from their free text, or flag the earlier period as not comparable. For a short overlap, an illustrative one month, tag new inquiries under both versions so the size of the shift can be measured.

Trend reports should state which definition version they use, so a reader can tell whether a rise in a category reflects the market or the rulebook.

How do you check that technical inquiry categories give usable data?

You check that technical inquiry categories give usable data by running five pass or fail checks on the scheme and on a sample of tagged records. The table below decides whether the counts can be reported and compared over time.

The key row is the tagging check: two people tag the same sample independently, and if they agree on fewer than 80% of a sample of at least 30 inquiries, a threshold McHugh (2012) reports from health research texts, the definitions need work before any trend is reported. Look at where the two taggers split, not only at the overall figure: disagreement usually clusters in two or three neighbouring categories, such as selection and compatibility, and those are the definitions to rewrite first. Repeat the check after every definition change.