A B2B product catalogue without an online shop: when a quote request is enough

A B2B product catalogue with a quote-request basket suits a business where customers can select products and quantities, but a salesperson still needs to confirm pricing, delivery terms or configuration. The website's job is to collect a clear request that can be processed without asking the customer to list the products again by email. A full online shop becomes justified when the business can also reliably confirm the transaction's terms online. The sales process should determine the choice, rather than a wish to add a payment button to the catalogue.

For a manufacturer or wholesaler, that distinction often emerges from a simple question: what does an employee check before sending a quotation? If they need to clarify the material, compatibility, production feasibility or delivery location, the website should first help collect those details. Taking payment does not resolve an incomplete specification.

When a B2B product catalogue is enough

A quote request is useful when a public product page describes the available options but does not yet define the whole order. A product might come in different sizes, packs or finishes. The buyer can specify what they need, but the salesperson must check whether that combination can be supplied alongside the other items. A quote basket gives both parties a shared starting point for the conversation.

It is less suitable when customers regularly buy standardised goods with clear prices and delivery arrangements, and the salesperson simply copies each request into an order. Manual confirmation can then become an unnecessary obstacle. Before deciding, trace a typical purchase: where does an employee genuinely make a decision, and where do they merely move information?

A mixed model is also possible. Standard products can be available to order, while custom configurations retain the enquiry route. Label both routes clearly. Customers should not discover only after submitting the form that the displayed amount was not a confirmed price, or that the date shown was not yet a delivery commitment.

Platform examples illustrate options, but cannot choose a company's process for it. Shopify's B2B catalogue documentation describes how businesses can control the range and prices available to customers. This shows that a catalogue can include commercial terms. It does not mean every catalogue needs immediate payment, or that every CMS offers the same features.

Define what a submitted request means

Agree on the outcome before designing the basket. Is the business receiving a pricing enquiry, a task to check technical compatibility, or enough information to prepare a quotation? These are different activities with different mandatory fields. A “Request a quote” button only makes sense when the next steps are defined.

The acknowledgement should explain what has been received and what happens next. If delivery and price still need to be agreed, say so at submission rather than hiding that qualification at the end of an automated email. Promise a response time only if the team can meet it. For the first release, describing the next action and who owns it is safer than publishing an unsupported speed promise.

On the sales side, distinguish a received request from a prepared quotation too. A “sent” label alone does not show whether someone has checked the attachment and understood the customer's needs. Agree where staff record that clarification is needed and where they can see that the customer has supplied it. The catalogue can then start a working process instead of creating another unmonitored inbox.

The selected product variant must reach the salesperson

On a product page, distinguish the product-family description from the specific selection. If length, material and connection type matter to the sale, a product name is not enough. Both the basket and the sales view must retain the product identifier and the selected attributes. Each item's quantity needs a unit: pieces, metres and packs are not interchangeable.

Ask customers only for information needed for the next decision. If a salesperson can quote from the variant, quantity and delivery region, there is no need to request the company's entire procurement procedure at the first step. An additional comments field helps with unexpected situations, but should not replace structured attributes needed for every request.

Customers must also be able to indicate what they do not yet know. If a customer does not know which material is required, an “advice needed” option may be better than forcing them to guess. The salesperson should see this as an unresolved question, not a confirmed specification. Explain known incompatible combinations during product selection so users do not waste time on a request that cannot be processed.

Use attachments where a drawing or specification genuinely helps. Define accepted formats and file sizes, and who can access the files. The project must include input validation and protected storage; a file must not become public simply because it was uploaded through the catalogue. Users should also see whether the upload succeeded and which file they are sending.

Several products in one quote-request basket

The basket becomes valuable when a customer builds a set of items. They need to move between product pages without losing earlier selections and review all items before submitting. A shared note may concern the delivery location, while an item-specific note explains its intended use. Do not merge these into one difficult-to-interpret block of text.

Similarly, distinguish removing an item from changing its quantity. If a product has two different variants, the basket must not combine them simply because their names match. Show the submitted request to the salesperson exactly as the customer reviewed it, retaining units and attachment associations. A total product count without specifications is not yet an actionable task.

Provide a clear summary before submission. Customers should be able to go back and correct a selection without losing their contact details. After successful submission, a request identifier and a copy are useful. If a technical error occurs, the interface must clearly indicate whether the request was received; otherwise, repeated button presses may create several ambiguous records.

A minimum-feature matrix for the first release

Define scope around the complete request journey. This matrix is a working template to adapt to the company's product range. It does not require a particular platform or the purchase of an off-the-shelf module.

A customer account is not automatically a first-release requirement. It may be useful for repeat requests or restricted information, but a public catalogue can also start without mandatory registration. Decide according to the user's actual task. Accounts bring additional access-management responsibilities, so they should solve a real need.

Assess integration with the sales system in terms of workload and error risk too. Initially, a saved record and a notification to the responsible person may suffice if the handling process is clear. However, that notification should not be the only copy of the request. An integration failure must not make the submitted specification unrecoverable.

Demonstrate the journey from product to quotation

Imagine a wholesaler whose customer needs fasteners and compatible mounting components. The customer selects several items in one request, specifies the required packaging and attaches a drawing. The delivery location applies to the whole request, but one item needs a technical check. This hypothetical scenario can be used with test data in a supplier demonstration.

Start on a product page and ask for the chosen variant to be added to the basket. Then open another product, add it and return to the earlier selection. Check that the attributes and quantity remain clear. The drawing must be attached to the correct item or clearly identified as a shared document. Finally, change one selection in the summary and submit the request.

The demonstration does not end at the customer's screen. Open the received record on the sales side and check whether an employee can prepare a quotation without guessing. Ask them to record the missing clarification and hand the work to a colleague. If the second person cannot tell which variant was discussed, fix the data display or history rather than adding another homepage button.

Demonstrate an error as well: a missing required field, an incorrect file format or a failed submission. Afterwards, check whether the entered specification was retained and whether the message shown matches the actual outcome. This test can reveal problems that a successful presentation with a pre-filled basket may hide.

To make the demonstration useful for a decision, record the expected and actual behaviour for every observation. For example, two items with the same name but different packaging must remain separate selections. If the salesperson sees only a combined quantity, the requirement is unmet even if the submit button works. Do not agree that staff will always remember this distinction from the customer's phone call.

When testing the handover, show the second employee only the information stored in the system. They should be able to identify what still needs clarification and whom to ask. If the demonstrator repeatedly supplements the screen with verbal explanations, record the missing field or action note. It becomes a specific correction to the requirements rather than a vague request to make the administration panel more convenient.

For a failed submission, base the decision on what both sides see. A record available to the salesperson while the customer sees an error is different from a request that was not saved. Distinguish these situations in acceptance testing. Otherwise, it is impossible to say reliably whether the customer should resubmit or contact the business about a request already received.

The first-release scope is clear when this journey can be completed without unforeseen re-entry of information by email. Additional conveniences can wait, but the meaning of the product selection, responsibility and receipt outcome cannot. These determine whether the catalogue helps prepare a quotation at all. This boundary also helps compare development proposals: assess the same customer action rather than lists of differently named modules.

When ordering and payment can be added

Moving to ordering requires verifiable commercial terms. The business needs to know which price a customer may use, how delivery is determined and when the selected quantity is genuinely available. If these questions still require an individual decision for every transaction, adding payment will merely move the uncertainty to a later stage.

Development can start with a limited part of the range where terms are stable. Other products retain the quote-request route. It is therefore worth maintaining consistent product identifiers and attributes in the existing catalogue rather than describing everything in a single free-text field. This makes later integration easier, but does not guarantee a transition without further development.

Distinguish accepting a quotation from placing a new order as well. When a customer accepts an agreed quotation, the system must identify which version they mean. Changes to price or specification cannot silently be applied to an earlier document. Define this requirement before automating transaction confirmation.

Customer-specific pricing priorities and confidentiality are a separate design issue. Do not overload the first public catalogue release with every possible discount mechanism when the actual need is a structured enquiry. Establish from the outset, however, which data is public and which a salesperson may share only with a particular customer.

Agreeing the scope with a developer

Bring an existing catalogue sample and an anonymised example of a typical request to the first discussion. Mark the points where a salesperson usually has to ask again about a variant or quantity. These determine the mandatory fields and checks. If a product group needs entirely different information, show that exception too rather than trying to fit everything into one form.

Ask the development proposal to separate catalogue content preparation, basket features, request handling and integrations. Product data does not appear along with the design. The team needs to know who will organise attributes, attachments and descriptions, and who will keep them current after launch. Otherwise, a working interface may remain filled with incomplete information.

For the broader platform choice, use the website and CMS development guide, then document the agreed requirements in the website technical specification. The central catalogue decision remains whether customers can prepare a useful request independently and whether the business can take it into its working process.

If you need website development for a company in Latvia, send a catalogue sample and a typical customer request to define the website's first-release scope. Start with a clear route from product selection to the salesperson's decision. Add payment when the transaction terms are ready for it too.