How to Build a Request-a-Quote Catalogue on Wix

Some products need a conversation before a price can be confirmed. Dates, quantities, suitability or delivery can change the final offer. A catalogue should still help visitors assemble what they need before that conversation starts.

A request-a-quote list connects browsing to the enquiry form. The visitor selects items once, and the team receives those selections with the relevant project details. Here is how to plan that journey on Wix.

Decide what the request actually means

Is the visitor asking for a price, requesting availability or placing a reservation? Those are different commitments. If staff must confirm the details, say so near the submit button and in the acknowledgement.

Use a standard ecommerce checkout when the price, fulfilment and purchase rules are sufficiently defined. A custom CMS catalogue can suit an enquiry-led journey that does not need immediate payment. It should not imply that a selected item has been allocated unless reservation logic exists.

Build one useful product record

Wix dynamic pages let a reusable layout display different collection items. Start with a catalogue model that supports both discovery and staff follow-up: stable item ID, title, category, images, key specifications and whether the item is available for enquiry.

Keep filter values consistent. Slight variations in category spelling can make products unexpectedly disappear from a filter. Decide how archived products should behave when someone opens an old link or restores an old shortlist.

You do not need every specification on the listing card. Put the details that help comparison there, then let the item page explain the rest.

Keep the shortlist visible and editable

Visitors should be able to see how many items they have selected, remove a mistake and return to browsing. If quantity or dates apply per item, capture them at that level rather than squeezing every requirement into one message field.

Choose deliberately whether the list survives a page reload or a later visit. Browser storage may be enough for a temporary anonymous list; a saved member shortlist has different identity and persistence requirements. In either case, stored selections can become stale.

Validate catalogue IDs on submission

The browser can submit selected IDs and visitor-entered requirements. Backend logic should then resolve those IDs against the current catalogue, check they are eligible and build the saved enquiry.

Do not trust a price or product title simply because it arrived from your own page. Browser requests can be altered. If an item has been removed, give the visitor a clear correction instead of silently dropping it.

For staff reference, consider saving a snapshot of the relevant item details alongside the stable IDs. That helps explain what the customer saw if the catalogue changes later.

Save the request before sending the alert

The enquiry record should be retrievable even if a notification fails. Keep customer contact details in a private collection, separate from publicly readable product information. Provide a reference number and distinguish a saved request from an email successfully sent.

Repeated taps should not create multiple requests for the same submission attempt. A backend request identifier and a clear processing state can help prevent accidental duplicates.

A project example: equipment enquiries

The Kiwi Hire & Sales design combined a CMS catalogue, dynamic equipment pages and a multi-item enquiry list. That illustrates the value of passing the selected equipment into the conversation. The diagram shows that project-specific journey.

Measure the quality of the handover

Before adding more filters or animation, ask staff whether requests contain enough information to reply usefully. Track missing details and follow-up questions, then improve the form around those patterns.

Wix Rocket can help turn a disconnected catalogue and contact form into one clear enquiry journey.

Technical references

Wix CMS dynamic pages

Wix CMS collection permissions