Thirty vendors, one catalog: keeping option names consistent
Give staff an exact vendor identity and customers a readable choice, without letting similar finish names merge into the same specification.
The OrderPilot team·
In an illustrative multi-vendor showroom, Espresso is a finish offered by three makers. One sample is nearly black, another has a red undertone, and the third is a brown stain on open-grain oak. The website shows one Espresso swatch. Coffee has become an unexpectedly complicated specification.
Separate the internal identity from the customer's label. Staff need the vendor, collection, and code that distinguish the choice. Customers need words and pictures they can understand. OrderPilot's internal names and customer-facing labels let the catalog do both, provided the store doesn't merge distinct materials merely because they share a name.
What belongs in an internal option name?
An internal option name should identify the source and the job the option performs. Use a stable vendor identifier, add the collection when its choices differ, and name the option plainly. “Atelier Nord – Madison – leg finish” is more useful to a catalog owner than another unexplained “Finish.”
Keep vendor value codes with the choices they identify. In a sample naming convention, internal value “Walnut 07” belongs to the vendor-specific option, while the customer sees “Walnut.” The internal identity lets purchasing distinguish it from another maker's walnut; the customer label avoids making the showroom conversation sound like an inventory count.
Don't put volatile information into the identity when a separate field exists. A temporary lead time or selling price doesn't belong in the option name. Otherwise, a routine update becomes a rename, making it harder to match the next vendor file with the catalog already in use.
How do you keep look-alike finishes and grades separate?
Treat each vendor's finish as its own specification unless the vendor relationship truly establishes that it is shared. Similar color, similar wording, or similar photography is not enough. A shared name should never be the only reason two physically different finishes become one value.
Use a separate grade option for each vendor's pricing scale. Grade C and Price Group C are not interchangeable because their letters match. Keep the grade-to-fabric relationship inside the maker's own library, as explained in fabric grades.
| Sample internal identity | Customer label | What remains distinct |
|---|---|---|
| Atelier Nord – leg finish / Walnut 07 | Walnut | This maker's finish code |
| Harbor Works – dining finish / Walnut W2 | Walnut | The dining maker's separate finish |
| Atelier Nord – upholstery grade / D | Grade D | This vendor's pricing scale |
| Harbor Works – upholstery group / C | Group C | A different vendor's pricing scale |
The sample vendor names are illustrative. The principle works whether the store carries a few collections or a broad assortment: share a record because the underlying choice is shared, not because the names can be made to match.
Which words should customers see?
Use the language an associate would use beside the piece. “Removable cover” can explain a slipcover. A short description can clarify the looped texture of boucle. A picture can show a trestle base more directly than a long definition. Keep the customer's selected label specific enough to recognize on the quote.
Baymard's research on industry-specific filters describes confusion when shoppers encounter unfamiliar product terminology without an explanation. Treat that as a prompt to review your own labels, not a reason to strip all furniture vocabulary from the catalog.
For visually distinct choices, put an image beside the words. Baymard's visual-filter research supports showing attributes customers may recognize by sight before they know their names. Use that approach for arm shape, leg style, or the outline of a sectional arrangement.
Keep descriptions factual. A value description can explain material, finish, or care information that the vendor actually supplies. It shouldn't quietly promise that a fabric is pet-proof or that a finish matches every sample. The catalog's role is to clarify the choice, not improve the maker's claim.
Should you rename collections to discourage comparison shopping?
Use a store-facing collection name only when it helps the customer understand your assortment, and preserve the original vendor model and code internally. A different selling name doesn't change the underlying product. It also doesn't solve the more useful question of why the customer should buy it from your store.
Avoid aliases that obscure construction, imply exclusivity without support, or make a later warranty inquiry harder to resolve. If the store uses a house name, keep a clear mapping so sales, purchasing, and service can identify the maker's exact model. The customer should still receive an accurate description of what they are buying.
Choose the naming policy before the next import. Ad hoc renaming by individual associates produces a harder problem than deliberate house names: several internal aliases for the same frame, none of which reliably matches the acknowledgment.
How does OrderPilot separate names and labels?
OrderPilot options have an internal name and a What the customer sees label. Values have the same distinction. The customer label is used on customer-facing documents and POS field labels, while staff can maintain a precise catalog identity behind it.
Use vendor-specific bundles for repeated choices and organize product templates by their vendor and category. The template should attach the intended library, not whichever Finish option happens to appear first in search.
OrderPilot also lets the store change Vendor wording in Admin, such as using Supplier. That setting changes the app's business vocabulary rather than renaming the records inside the catalog; POS keeps Vendor. The store terminology guide explains that distinction.
How do you clean up an established catalog?
For a catalog of 300 templates, begin with an export and a naming map. List the current internal identities, intended customer labels, and any suspected duplicates. Decide which are genuinely shared and which are merely similarly named before changing anything.
Change labels first where the identity is already correct. The CSV import includes option and value label columns, so a focused re-import can improve customer wording without rebuilding every template. Preserve the matching internal names and template Handles; renaming those identities inside an import can turn an intended update into a different matching problem.
Test one vendor's sample templates before widening the cleanup. Build a fresh quote, inspect the customer labels, and inspect the vendor-facing specification. Then check an existing quote separately: saved records preserve what was sold, so a label cleanup is not a promise to rewrite every historical document.
Use the price-book import process to review overwrite behavior and blank-cell warnings. Keep a record of the label changes and the reason for them. A later catalog owner should be able to explain why a code remained internal or why two Walnut values stayed separate.
What should a short naming style guide contain?
Keep the guide short enough that someone preparing a vendor file will actually use it. The following is a reusable structure for the store to complete with its own conventions, rather than a set of app-enforced rules.
| Decision | Suggested store rule |
|---|---|
| Internal option name | Vendor identifier – collection when needed – option purpose |
| Internal value | Vendor value name and code, preserving the source identity |
| Customer label | Plain, recognizable material or choice name |
| Grade systems | A distinct option for each vendor's scale |
| Similar finishes | Keep separate unless the underlying specification is truly shared |
| Units | Write the unit explicitly and use the same unit within a size option |
| Exceptions | Record the reason and the person responsible for maintaining it |
| New entries | Review naming before import or attachment to templates |
Schedule a recurring cleanup around the store's catalog work. Look for missing customer labels, ambiguous names, obsolete aliases, and options attached from the wrong vendor library. Prioritize the errors that could change a purchase specification, then improve browsing language.
The test is simple: can an associate explain the choice to a customer, and can a buyer identify the exact choice for the vendor? If both answers are clear, the naming system is doing its job. Use the bundle guide to make those settled names reusable across the frames that share them.
Sources
- Explain industry-specific filters — Baymard Institute, February 27, 2024. Original research on unfamiliar filter terminology.
- Use visual filters for visually distinct product attributes — Baymard Institute, July 9, 2024. Original research on visual attribute explanations.
Share a record because the underlying choice is shared, not because the names match.