What a Commercial Hire Enquiry Form Should Actually Ask

A commercial hire enquiry form should ask for everything a desk needs to produce a quote, and nothing else. Most do the opposite: they ask for a name, an email and a free text message, which produces an enquiry that cannot be answered without at least one round of questions, and often three. The cost of that round trip is not the staff time. It is the twenty-four hours during which a buyer who was ready to book is waiting, comparing, and sometimes booking elsewhere. This article sets out the field set that makes a hire enquiry answerable first time, why each field earns its place, and how the form should behave once it is submitted.

The problem with the generic contact form

The first sentence answers it: a generic contact form fails because it moves the work of specifying the enquiry from the person who has the information to the person who does not. The buyer knows they need three tippers from the north depot for six weeks starting on the twelfth. The form asks them to write a message. What arrives is some subset of that, usually the part they considered most important, and the desk has to ask for the rest.

Every one of those follow-up questions is a point at which the enquiry can go cold. The buyer is often not the person who will sign; they are gathering options. If answering your follow-up costs them more effort than reading a competitor’s published terms, the competitor wins on effort rather than on price.

What a quotable enquiry contains

An enquiry is quotable when a desk can produce a number, or a clear reason why they cannot, without contacting the enquirer. For most commercial hire that means knowing the class, the quantity, the dates, the collection point and whether it is a one-off or a term arrangement. Five facts. A form that reliably collects five facts is doing its job, and a form that collects two of them and a paragraph is not.

The free text field is not the enemy

None of this argues against a message field. It argues against a message field doing all the work. Keep it, put it last, and label it for what it is actually useful for: the constraint the structured fields did not capture. A tail lift requirement, a site access restriction, a named account. Labelled that way, the free text field produces useful specifics instead of a restatement of the fields above it.

Short-term hire and contract hire are different forms

These two enquiries have different shapes and they should not share a field set.

A short-term hire enquiry is fundamentally a booking question. The buyer knows what they want and when, and the only real uncertainty is availability and price. The form should be short, fast and dominated by dates and quantities.

A contract hire enquiry is a procurement question. The buyer is specifying a multi-year arrangement, often on behalf of a committee, and the answer depends on fleet size, contract length, mileage expectations, replacement cycle and service arrangements. The form is longer because the question is bigger, and a buyer at that stage expects it to be. A three-field form for a two-year contract reads as though you have not understood what they are asking.

Let the buyer pick the path

The cleanest way to serve both is to ask one question first: is this a short hire or a longer term arrangement. Everything after that is the relevant field set. This is a single extra click and it removes every irrelevant field from both paths, which is a better trade than showing everyone a long form with half of it marked optional.

Do not branch further than that

Two paths is useful. Five is a maze. Resist the urge to branch on vehicle class, on customer type, on region. Each additional branch multiplies the states the form can be in, and every state is one more thing that can be broken without anyone noticing. Two paths, each short enough to see the end of, is the sweet spot.

The field set, in order

Field order should follow the order the buyer already has the information in, which is roughly the order they would say it out loud.

Vehicle class. First, because it is the thing the buyer came for and because it determines whether the rest of the questions are even relevant. A select list of the classes you actually run, in the words your customers use, not internal fleet codes.

Quantity. A number input with a sensible default of one. Quantity changes the answer more than almost anything else and it is frequently missing from generic forms.

Dates. Start date and either an end date or a duration. For contract hire, a term in months rather than dates. Do not make a buyer compute a duration from two dates you already have.

Collection depot. A select list of your depots, defaulting to none rather than to the largest, so an unanswered question is visible rather than silently wrong. If the buyer has arrived from a depot page, this should be pre-filled with that depot.

Delivery or collection. Whether they will collect or need delivery, and the delivery address if relevant. This one field removes a very common follow-up.

Contact detail. Name, company, email, phone. Company matters more than most forms treat it: it is how the desk checks for an existing account, and an existing account changes the answer.

The constraint field. The labelled free text described above, last.

For contract hire, three more

Fleet size, expected annual mileage per vehicle, and whether maintenance is expected to be included. Those three turn a contract hire enquiry from a conversation starter into something a desk can actually price. They are also the three that a procurement buyer will have to hand, because they are already in the specification they are working from.

Every field, defended

Before a field ships, someone should be able to say what the desk does differently based on the answer. If nobody can, the field is costing submissions and returning nothing. This test removes more fields than it sounds like it will. It usually removes job title, how did you hear about us, and preferred contact time, none of which change a quote.

Making the form fast to complete

The field set is only half of it. How the form behaves decides whether a buyer finishes it on a phone in a yard.

Use the platform

Set the autocomplete attribute properly on name, company, email and phone fields. MDN documents the full token list, and using it means a returning buyer fills four fields with one tap rather than typing them on a phone keyboard. This is the single highest-return change on most enquiry forms and it is invisible in a design review, which is why it is so often missing.

Use the right input types so mobile keyboards match: email for email, tel for phone, number for quantity, date for dates. A buyer entering a phone number on an alphabetic keyboard is a small friction repeated on every enquiry.

Validate helpfully, not aggressively

MDN’s guidance on client-side validation is worth reading in full, but the practical rules are short. Validate on blur rather than on every keystroke, so a half-typed email is not marked wrong while it is being typed. Describe the problem and the fix in text next to the field, not in a summary at the top. Never rely on color alone to mark an error, which is both a WCAG requirement and simply better for everyone reading in daylight.

Keep the whole form visible

Multi-step forms with progress bars are appropriate for applications with twenty fields. A nine-field hire enquiry is not that. Showing the whole form lets a buyer see that it ends, which is the main thing that stops people abandoning at field three.

Accessibility is not a separate workstream

The W3C forms tutorial covers everything that matters here, and none of it conflicts with a considered design.

Every input needs a visible label associated with it programmatically. Placeholder text is not a label: it disappears when typing starts, which strands anyone who was using it to remember what the field was. Group related fields with a fieldset and a legend, particularly the date range and the delivery choice. Make sure the form can be completed with a keyboard alone, in a sensible order, with a visible focus indicator at every step.

Error messages should name the field and the problem. An enquiry form that says please correct the errors below has told the reader nothing they did not already know. One that says the end date is before the start date has told them exactly what to fix.

These are the same practices that make a form fast for a buyer in a hurry on a bad connection, which is most of them. Accessibility work on an enquiry form is conversion work that happens to also be the right thing to do.

Where the enquiry goes next

A form that collects the right fields and then emails them to a shared inbox has solved half the problem.

An enquiry in an inbox has no owner, no status and no record. It gets read by whoever is at their desk, actioned or not, and becomes invisible the moment it scrolls off the first screen. An enquiry in a CRM or a transport management system has a state, an assignee and a history, which is the difference between a pipeline and a pile.

Route with the context attached

The enquiry should arrive with the depot and the vehicle class already attached as structured fields, not buried in a message body. That is what lets the system route it to the right desk automatically, and what lets you later answer questions like which depot generates the most contract hire interest. Where a system exposes an API, that is the route. Where it does not, an automation service sitting between the form and the system does the same job without a development project.

Confirm properly

The confirmation a buyer sees after submitting should state what happens next and when, specifically. A page that says thank you and nothing else is a missed opportunity to set an expectation you can then meet. Naming a response window, and then meeting it, is one of the few trust signals available before a relationship exists.

Measure the right thing

Track quotable enquiries, not form submissions. A change that reduces submissions by a fifth and doubles the proportion that can be answered without a follow-up is a large win that looks like a loss on a submission count. If you only measure the top of the funnel, you will keep removing the fields that make the bottom of it work.

Spam, and the cost of the usual defence

Every public form attracts automated submissions, and the usual answer is a challenge widget that every human has to pass in order to protect against machines that mostly do not care.

This is a bad trade on a commercial enquiry form. The buyer you most want to hear from is frequently on a corporate network, on an older browser, on a phone with a poor connection in a yard, and a challenge that fails in any of those conditions costs you an enquiry that was worth hundreds of times more than the spam it blocked. Worse, the failure is silent: you never learn about the enquiry that did not arrive.

Cheaper defences that do not tax the buyer

A hidden field that real people never see and never fill, commonly called a honeypot, catches a large share of naive automated submissions at zero cost to a human. A minimum time between the form rendering and being submitted catches most of the rest, because a person cannot complete nine fields in under two seconds. Server-side rate limiting by address handles volume attacks. None of these are visible to a buyer and none of them can fail in a way that blocks a legitimate enquiry.

Reserve a visible challenge for the case where the cheap defences have demonstrably failed, and even then prefer one that can be passed without solving a puzzle. The default position should be that the form costs the buyer nothing beyond answering the questions.

Filter after, not before

A structured enquiry form is its own spam filter. Automated submissions almost never produce a coherent vehicle class, a valid date range and a real depot together, because those are select fields with fixed options. Requiring the structured fields does more to keep the pipeline clean than a challenge widget does, and it improves the enquiry quality at the same time.

What the form should never ask

Two categories are worth naming explicitly because they appear constantly and both cost more than they return.

The first is anything the buyer would reasonably expect you to already know or to be able to look up. Asking a returning account to re-enter their account number, or asking for a postcode you are about to use only to identify a depot the buyer has already selected, reads as administrative rather than helpful.

The second is anything that feels like qualification for your benefit rather than theirs. Budget range is the clearest example. On a hire enquiry it is asking the buyer to negotiate against themselves before they have seen a number, and most will either skip it or leave. If the form is well built, the class, quantity and duration already tell the desk the scale of the enquiry without asking the buyer to price it.

There is a third, smaller category: fields added because a system somewhere requires them. If a CRM demands a value the buyer should not be asked for, supply a default from the form’s own context rather than adding a field. The system’s requirements are not the buyer’s problem.

Start from the desk, not from the form

The reliable way to design this is to sit with whoever answers the enquiries and ask what they have to chase. Every recurring chase is a missing field. Every field they never look at is one to cut. That conversation takes twenty minutes and produces a better form than any amount of general best practice, because it is grounded in the specific shape of your operation.

If you want to see what this looks like built, the features page covers how the enquiry builder is configured and routed, and the fleet types pages set out how the field set differs between a delivery fleet, a contract hire desk and a construction operator. The pricing page covers what changing it later costs, which for a form that will be adjusted as you learn is the number that actually matters.