Product Models and Variant Options

1. Define the three record levels before entering products

A product model is the shared concept that lets the team recognise related variants as belonging together. It may carry a plain model name, a short description, and notes that apply to every confirmed variant. A variant is one exact version that staff can select, request, or review without guessing. Its option values explain the differences that matter in daily work.

For example, “wirebound notebook” could be a model. “Wirebound notebook, A5” and “wirebound notebook, A4” could be separate variants if those sizes are confirmed. The model does not become a substitute for either exact variant. Likewise, an option value such as “blue” does not identify a sellable variant if the relevant size is missing or if blue has not been verified for that model.

Suggested practice: write a one-sentence team definition for each level. For example: a model is the shared item family; a variant is one confirmed selectable version; an option is a named attribute used to distinguish variants. Test the definitions with records already causing confusion, rather than starting with a large catalogue cleanup.

2. Choose option names that answer an operational question

Option names should describe a difference staff genuinely need to recognise. Size, format, colour, material, capacity, or finish may be useful only when the team can verify the value and it changes which exact item a request refers to. Do not add attributes merely because somebody might want them later. Empty fields make a record look structured while preserving uncertainty.

Use one agreed option name for one meaning. If “size” is sometimes used for page format and sometimes for physical dimensions, split the meanings only when the team can describe them clearly. A value such as “large” is not useful unless everyone knows what it means for that model. A short note can preserve a verified distinction without inventing a measurement.

Suggested practice: make a small option worksheet with model reference, option name, verified value, source or check point, and status. A blank field should not silently mean “not applicable,” “unknown,” or “available.” The related guide on [unknown, not applicable, or confirmed values](/blog/unknown-not-applicable-confirmed-record-values/) can help the team keep those states distinct.

3. Give the exact variant a stable reference

A recognisable display name helps a colleague read a request, but it can change with local wording, a corrected colour description, or a new naming convention. Give every confirmed variant a stable reference that points to that exact record. The reference is not a promise of a particular numbering method and does not need to encode every option value.

Keep the model reference and variant reference visibly connected. A request for a variant should resolve to one model and one known set of option values. If staff only have a model name plus a free-text note, they may be unable to tell whether two notes refer to the same exact item. If the exact variant is not known, record that uncertainty and assign the next verification step instead of selecting a near match.

Suggested practice: check whether a colleague can locate the same variant after the display name has been shortened or translated. If not, improve the stable reference and the recorded option values. [Choose a stable record reference before moving data](/blog/stable-record-reference-before-moving-data/) covers the broader discipline of preserving identity when records move between lists.

4. Keep identity separate from quantity and the order line

A variant answers “which exact item?” Quantity and unit answer “how much?” An order line answers “which requested item within this order?” These are related but different questions. Writing “two blue notebooks” in one description can hide both the exact variant and whether “two” means pieces, packs, or another unit.

Suggested practice: place the selected variant reference on the item line, then record the requested quantity beside its explicit unit. If the requester has supplied only a model or an incomplete option description, keep that as the request wording and mark the variant selection as pending confirmation. Do not convert a descriptive phrase into a confirmed variant simply to complete a form.

The guide on [recording quantity with its unit](/blog/record-quantity-with-unit/) addresses the quantity question. [Order details and line items](/blog/order-header-and-line-items-first-system/) explains where an item-specific request belongs. Neither replaces the need to identify the precise variant first.

5. Do not invent availability from an incomplete combination

A familiar model and a familiar option value do not prove that their combination exists. If staff know that a notebook model has an A5 variant and separately know that blue is a colour word used elsewhere, “blue A5” remains unconfirmed until there is evidence for that exact combination. Treating it as selectable creates a record that looks certain but is not.

Suggested practice: use a clear status such as confirmed, pending verification, not applicable, or unknown according to the team’s definitions. Record what was actually requested, the known model if one is identifiable, and the owner of the next check. Do not create a permanent variant record merely to hold a speculative request. If the check later confirms the combination, create or complete the variant from that evidence.

This restraint is important during migration. Similar spellings, copied rows, and older notes may be clues, not proof. Preserve the original wording where it matters to follow-up, while keeping the confirmed identity separate.

6. Fictional example: desk-check two known sizes

Fictional example: A fictional stationery team records a model called “Wirebound Study Notebook.” It has two confirmed variants: one with option size “A5” and one with option size “A4.” The team gives each variant its own stable reference and retains “Wirebound Study Notebook” as the shared model name. The A5 and A4 records are not two names for one variant because the verified size differs.

A message then asks for a “blue A5 Wirebound Study Notebook.” The team knows the A5 variant, but its records do not confirm colour for that variant. It records the request wording, selects the known model, identifies the A5 detail, and marks colour confirmation as pending. It does not state that a blue A5 variant is available, and it does not alter the confirmed A5 record to add blue.

Suggested practice: ask a second colleague to read the worksheet and answer four questions: what is the shared model, which exact variants are confirmed, which option values distinguish them, and what remains unconfirmed? If the answers differ, improve the labels before importing records or designing a form. This fictional example is a record-design exercise, not a customer, product availability, stock, or system-feature claim.

7. Prepare a small handoff for implementation discussion

Before requesting a build, prepare a short sample that contains one model, two or three confirmed variants, their verified option values, one renamed display label, and one unconfirmed requested combination. Include the decisions staff need to make when a request names only the model or supplies an unfamiliar option. A small sample reveals whether the distinction survives normal daily wording.

Suggested practice: agree who may confirm a new option combination, what source the team accepts, and how an unresolved request is shown to the next person. Avoid expanding the exercise into pricing, stock balance, supplier data, accounting treatment, images, or automatic identifiers unless those are separately required.

When the worksheet is consistently understood, take the real workflow and unresolved decisions to [BossFlow’s workflow review](/bossflow-workflow-review/). SME Systems provides this education; BossFlow handles workflow review, implementation, and quotation discussions. Source note: “Order Details and Line Items for SME First Systems | SME Systems” was consulted for record-granularity context. The model, variant, and option worksheet in this guide is original suggested practice.

Practical Checklist

• Write one plain-language definition of model, variant, and option for the team.
• List the facts that are shared by every known variant of a model.
• List only the option names that staff need to distinguish an exact requested item.
• Record every confirmed option value separately from the display name.
• Give each confirmed variant a stable reference.
• Keep a request for an unconfirmed combination marked as pending or unknown.
• Record the selected variant separately from quantity and unit.
• Test one model with two confirmed variants and one unconfirmed request with two colleagues.
• Bring the completed sample and open decisions to BossFlow before implementation discussion.