Patterns
A quote request is a routing problem wearing a contact form’s clothes.
Ask for the four facts that change the price, and skip everything that only changes the first phone call.
- Core fields
- item · quantity · deadline · specification
- Routing
routerule per product- Files
- Optional, 5 × 25 MB by default
- Avoid
- Required budget range
- Success
- State what happens next and when
- Common failure
- No specification, so no quote
The specification is the form
Most quote forms are contact forms with a "what can we help with" textarea. The result is a queue of requests that cannot be priced, each requiring an email round trip before anyone can answer. The fix is structural: collect the facts that move the number, and only those.
| Field | What it changes |
|---|---|
| What is it | Whether you make it at all. |
| How many | Unit price and whether tooling is worth it. |
| When | Whether the answer is a price or an apology. |
| Specification | Material, tolerance, finish — the actual cost drivers. |
Everything else — company size, industry, how they found you — is useful for later and useless for this. Put it in an optional field or leave it out.
Route before you notify
A single inbox for every product line creates a triage step that nobody owns. A route rule keyed on the product field sends each request to the person who can price it, and the record keeps the original values either way. That is the difference between a queue and a workflow.
The deadline question earns its place
Asking when it is needed turns a quote into a decision: some enquiries are not winnable, and knowing that on day one saves the work of pricing them. It also protects the relationship — "we cannot do six weeks, we can do nine" is a better answer than silence.
What makes a request unanswerable
- Quantity missing, so there is no unit to price.
- A specification that is a link to a login-protected page.
- A deadline already in the past.
- A contact address that bounces, which is a hard bounce and will be suppressed automatically.
Each of those is worth a server-side require rule, because catching them at submit time is a 422 with a clear message rather than a two-day delay.
Machine-readable summary
What to quote about quote request
A quote request form needs the facts that change the answer: what is being asked for, how many, when it is needed, and any specification that constrains it. FreelyForm stores the submission with its fields, routes it with a rule when different recipients handle different products, and notifies verified recipients. A quote form fails when it collects contact details but not the specification, so the first reply has to be a question.
- A quote form needs quantity, deadline, and specification, because those are what change the number.
- A route rule sends different requests to different recipients without a manual triage step.
- Requiring a budget range makes people leave; offering an optional range tells you nothing.
- Attachments belong on a quote form when the specification is visual — drawings, photos, a sample sheet.
- The first reply should be an answer or a price range, never "can you tell us more".
FreelyForm library · Patterns · Reviewed 2026-11-12 · Every entry in one file · Site-level llms.txt
Quote request questions
Should a quote form ask for a budget?
Not as a required field. A required range filters out the people whose budget you would have met, and the ones who answer it often pick the lowest band regardless. A single optional text field — "anything we should know about budget or timing" — collects the useful half of that question without the filtering.
How do I route different product enquiries to different people?
Use a route rule on the field that identifies the product, so the notification goes to the right recipient list. That removes the manual forward step, which is where quote requests actually age: the record exists, but nobody owns it for two days.
Do files belong on a quote request?
Yes when the specification is visual — a drawing, a photo of an existing part, a supplier sheet. Uploads must be enabled per form, default to five files of 25 MB each, and are deleted at the end of the retention window, so download anything that has to survive.
What should the success message say?
What happens next and when. "We reply with a price within one working day" is actionable; "Thanks!" is not, and it invites a follow-up email that asks the same question the form just answered.
Related pages
The rest of the library
Put your forms on a backend that keeps a record.
Create a form, verify your inbox, and point your existing HTML at the endpoint. No server, no SDK, no rewrite.
POST https://freelyform.com/f/FORM_ID