Use a single-product RFQ when most buyers inquire about one item or need help selecting a part. Use a multi-item RFQ when a normal request includes several known products and sales needs to quote them together. In both cases, retain the selected variant, quantity and selling unit; adding a list should not turn a precise request into an ambiguous one.
Choose around an ordinary sales request
| Buying situation | Useful pattern | What to retain |
|---|---|---|
| One known part | A request button on the product page. | Part reference, variant, selling unit and product-page context. |
| Several catalog items | A visible request list, editable before submission. | Separate line items with quantity and unit on every line. |
| Uncertain replacement | A help-identifying-the-part route. | Known reference, application question and the need for human review. |
| Custom component | A scoped manufacturing RFQ. | Drawing reference, revision, quantity and an agreed document handoff. |
Review a few recent, redacted inquiries with sales. Count the items, mark unclear quantities and ask which details caused a follow-up. This is a workflow check, not evidence that a request list will improve conversion for every supplier.
A multi-item request with clear units
The working RFQ example uses fictional Halden Supply records. Three packs of HS-W08-Z contain 300 washer pieces; two boxes of HS-B08-25-Z contain 100 bolt pieces. Each line retains its own selling unit. The destination and requested date belong to the request as a whole.
Switch the washer to HS-W08-S and three packs become 150 pieces, because that variant contains 50 pieces per pack. A buyer should see this unit before preparing the request. Matching a family name does not establish an approved substitute.
Keep the requested quantity in packs or boxes as well as the equivalent piece count. Sending only “300” leaves sales guessing what the customer means. If different delivery dates apply to different lines, agree line-level date fields rather than silently applying one date to all of them.
Make the list easy to review
Let the buyer edit quantities, remove an item and return to its product details. Explain how duplicate selections behave. For example, the working demonstration asks the buyer to combine the same variant on one line rather than hiding a second entry.
For a production request list, agree whether it survives navigation, a refresh or a later visit. Display a clear empty state and test stale or retired items. The free demonstration stays in one page and clears on reload; persistent storage is a separate implementation decision.
Do not lose the uncertain buyer
Some buyers have a drawing, an old part or a description instead of a current SKU. Offer a short route to ask for help. Label the request as unresolved so sales knows a catalog match has not been confirmed. Requiring a valid catalog part for every inquiry can block that conversation.
A drawing needs an agreed document process. The manufacturing drawing-handoff guide explains reference numbers, revisions and delivery checks.
Test the complete handoff
Prepare one request, then edit a unit-sensitive variant, add another item and remove the first. Check what the buyer sees and what sales receives. Test an empty list, duplicate part, excessive quantity, missing destination and failed delivery. After a successful submission, show a receipt reference; distinguish receipt from stock reservation or order acceptance.
Include the approved catalog version or a snapshot of each selected line in the record. The catalog maintenance workflow shows why earlier requests should preserve the unit the buyer saw when a pack size changes.
Scope the first useful version
Start with the pattern that matches the common request. A multi-item list is useful when it saves buyers and sales real repetition, but it adds state, editing and error cases that need testing. Confirm this scope before accepting a proposal. Our catalog website service can be scoped around that journey.