Where Standard Configuration Ends and Custom Furniture Begins
How to distinguish standard furniture configuration, requests that need review and genuinely custom work, including where COM fits.
A sofa range offers six published fabrics. A customer asks for a seventh, either one they own or one sourced for the project.
That request is not automatically custom. It might sit inside an established Customer's Own Material process. It might need review. Or it might require a new specification and a genuinely custom route.
The useful boundary is not whether the request feels unusual or introduces new information. It is whether the requested specification, combination and fulfillment route sit within the business's approved scope.
Use three categories, not a forced yes-or-no answer
Furniture teams need somewhere sensible to put uncertainty. Without it, sales either approves an unchecked request as standard or labels anything unfamiliar as bespoke.
Use three working categories:
- Standard configuration: The requested combination is approved and covered by an established commercial and fulfillment process.
- Review required: Applicability, evidence or approval is missing or uncertain. Review may return the request to the standard process or route it to custom.
- Custom: The request sits outside the approved standard scope and follows a project-specific specification, pricing and approval process.
"Not yet checked" does not mean custom. It does not mean approved either.
The line is about approved scope, not difficulty
For this framework, standard configuration means selecting a combination that falls within an approved product specification and established ordering process. The complete combination must be valid, not merely assembled from options that are individually approved.
A large frame in an approved made-to-order fabric may be difficult to produce and still count as standard configuration. An apparently simple change to a frame dimension may be custom because it sits outside the engineered specification.
New order information does not decide the classification. Standard orders routinely introduce quantities, delivery requirements, material batch details and customer references. Missing catalog data may be an administrative gap rather than proof of custom work.
The reverse is also true. A previously engineered bespoke design may already have complete structured records and still follow a custom-order process.
Ask three questions:
- Is the requested specification approved?
- Is this exact combination valid for the product?
- Is the commercial and fulfillment route established?
If all three are covered, follow the standard configuration process. If the answer is uncertain, hold the request for review. If it falls outside the approved scope and needs a project-specific specification or design change, use the custom process.
Where COM fits
COM means Customer's Own Material: material supplied by the customer for use on the product. It is a sourcing arrangement, not automatically a custom-product classification.
An established COM program may allow suitable materials through a documented review and acceptance process. Confirm that the process applies to the particular frame, construction and intended use. Check the relevant material requirements, quantity allowances, commercial terms and delivery timing before confirming an unconditional price or delivery commitment.
If the request meets those requirements without changing the approved product specification, the business may treat it as controlled configuration. If it requires a construction change or falls outside the approved process, route it for further review or custom development.
Approval for one frame or project should not silently become approval for every use.
Write the operating rule around decisions
A useful internal rule needs to tell sales what happens next, not merely define two labels.
For a request inside the approved scope, sales can use the established configuration, pricing and fulfillment process. For an uncertain request, the team records what is missing and sends it to the right reviewer. For custom work, the business opens a project-specific specification and approval route.
The review stage matters because it creates two legitimate outcomes. The reviewer may confirm that the request already sits within the standard process. Or the review may reveal a new material, dimension, construction detail or fulfillment condition that requires custom control.
Keep the decision and its evidence. If the same reviewed request keeps recurring, the business can decide whether to formalize it as a standard option rather than repeatedly treating it as an exception.
Standard and custom work both need structured records
Standard configurations need reusable product, option and variant records. The configurable furniture product data guide explains how to structure that approved range without pretending every theoretical combination is sellable.
Custom work also needs structured records, but those records may be project-specific: an agreed specification, revision history, drawings, material decisions, approvals, quoted terms and production instructions.
Do not disguise an unapproved custom request as an approved catalog variant. Equally, do not leave custom work in emails and informal notes simply because it is not a standard catalog item. Give it a traceable identifier and define the information and approvals required at each stage.
The same business systems and identifier conventions may support both routes. What changes is the scope, review and release process, not the need for reliable information.
What goes wrong when the boundary is unclear
Treating a custom request as standard can put an unapproved construction, price or delivery date into a routine quote. The problem appears later, when production or purchasing discovers that the promise depended on work nobody had assessed.
Treating an approved configuration as custom creates a different mess. A sellable option goes through unnecessary project review, and the team may rebuild pricing or specifications it already has.
Uncertain requests cause the most argument when there is no review state. One person assumes that a familiar fabric is fine; another assumes that anything outside the published list is bespoke. Neither has a shared rule for deciding.
Audit the recent edge cases
Review the last 10 requests that felt unusual: an outside fabric, a different size, a one-off finish or a changed delivery condition.
Classify each one against the approved scope and the information available when it was quoted, not just how difficult the request felt or what the team learned afterward. Use standard configuration, review required or custom.
Record why it was classified that way, who approved any exception and whether the decision should change the standard option rules. That turns the exercise into a better operating boundary rather than a retrospective judgment on individual quotes.
