How a quote request should work on a catalogue site

A manufacturer’s website exists, in large part, to start a conversation that ends in a quote. If the request is awkward, the buyer calls someone else. If it arrives without the facts you need, you spend the first day asking for them. This note is about getting both sides right.

What you need to answer a quote

Think about the questions you ask every buyer on the phone, then decide which ones the page should collect. For many product businesses the list is short:

Which product or products, with grade, size or specification where that matters.
How much, in the units you sell in.
Where it is going, at least the city and state or country, since delivery shapes the answer.
What it is for, if the use decides which product fits.
When they need it, roughly.
How to reach them, a phone number or a WhatsApp number, and their name and company.

More than that makes a first request feel like paperwork. Anything you can ask in your reply does not need to be on the form.

Let the product page do half the work

The best place to request a quote is the product page, with the product already named. A button such as “Ask for a quote for this product” can open a message that begins with the product’s name, so the buyer only has to add quantity and place. That removes the question of which item they meant, which is the most common reason for a back-and-forth.

Three routes, and what each means

Route	What happens	Good for	Limits
Phone call	The buyer talks to you at once	Urgent or complex needs	Only when you can answer; leaves no written record
WhatsApp message	A chat opens with a prepared message; the buyer edits and sends	Most Indian buyers, quick questions, photos and documents	The website cannot see whether it was sent
Form with a server	Details are sent to a server and stored or e-mailed to you	Collecting structured requests	Needs a backend, spam protection, storage and a privacy decision

My packages use the first two. The enquiry form on a package website builds a message and opens WhatsApp with it; it does not send the details to a server or store them. That is a deliberate scope choice: it keeps the site simple and the data on your own phone. A form that stores requests on a server is a backend feature and would have to be agreed in your proposal. See frontend, backend and what your site needs.

Make the form easy to use

Even a form that only opens WhatsApp should follow the basics from web.dev’s forms course: a visible label for every field, the right input type so a phone shows the right keyboard, clear error messages next to the field that needs fixing, and large enough buttons. Say what will happen when the button is pressed (“Opens WhatsApp with your message”) so the buyer is not surprised.

What to promise on the page

Say how you will respond only if you will always do it. “We reply within one working day” is a promise someone will test. “Harman replies personally” or “Send the details and I will reply with a quote or the questions I need answered” is easier to keep. Do not claim round-the-clock availability from a small team.

After the request arrives

Record each request in a simple log, even a spreadsheet: date, product, quantity, place, channel, outcome. Counting enquiries from WhatsApp and phone calls shows the layout.
Reply with the quote or with the single question that blocks it.
Ask “how did you find us?” once; the answer tells you which pages work.

Check before launch

Can a stranger request a quote for a named product in under a minute on a phone?
Does the request include the product name, quantity and place?
Does every product page have a visible quote action and a phone number?
Does the page say honestly what happens next?
Do you know where requests will be recorded?

If your catalogue needs more than this, such as price lists behind a login or requests that feed a stock system, it is a different project; the catalogue or online store note explains where that line sits. For the websites I have built that follow this pattern, see the work page.