Shorter enquiry form or better questions? How to decide what to ask

Define the action after submission

Start at the other end of the form. Who receives it? What do they do first? Which answers are necessary to make that action possible?

If the next step is a short conversation, the form should support arranging and preparing for that conversation. If the next step is a detailed quote, more information may be needed, but the page should explain why and whether the customer can submit an initial question instead.

Write down the intended response in plain language. “A team member checks service fit and replies using the preferred contact method” gives you a test for every field. “Capture leads” is too vague to guide the design.

Also check whether the business can deliver the promise shown beside the form. Avoid stating a response time unless the team has agreed it and can maintain it through leave, busy periods and enquiries requiring specialist input.

Ask what each answer changes

List every field and record its purpose, who uses it, whether it is required now and what happens if it is blank. Include hidden fields and automatically collected information in the technical review, not just what visitors can see.

Useful categories are:

• Contact: Information needed to reply in a suitable way.
• Routing: Information that sends the enquiry to the right person.
• Initial suitability: Information needed to establish whether the business can help.
• Preparation: Helpful context that can often be optional.
• Later-stage detail: Information better gathered once the relationship progresses.

A required phone number deserves scrutiny if the business always replies by email. A location field may be necessary for an on-site service but less relevant to a remote project. A budget question may help establish scope, yet a visitor may genuinely not know the answer.

Do not keep a field just because the CRM has somewhere to store it. The website experience should reflect a real decision or workflow, rather than the maximum capacity of the database.

Improve difficult questions before removing useful ones

Some fields are hard because the wording assumes knowledge the visitor does not have. “Select your solution architecture” may mean little to a person who simply needs two systems to exchange information.

Ask about the situation in familiar terms. “Which systems do you need to connect?” is more concrete. If people may not know, provide an honest route such as “I’m not sure yet” rather than forcing a guess.

Open questions also benefit from a little direction. “Tell us about your project” can feel like a large writing task. A short prompt such as “What are you hoping to change, and is there a date we should know about?” gives the reader a starting point.

For choice fields, check that the options cover real enquiries without forcing visitors into inaccurate categories. Include a sensible alternative where needed, and make sure it routes somewhere useful rather than becoming an unattended “other” bucket.

Separate initial contact from detailed scoping

Consider this illustrative example. A consultancy asks for a name, email, phone, company size, turnover, detailed scope, preferred start date, exact budget and a document upload before accepting any enquiry.

The team reviews the message and arranges a conversation. It does not use turnover or the uploaded document before that call. Those fields are candidates for a later stage. Service interest may still be worth keeping because it determines which consultant responds.

The revised initial form could ask for contact details, the area of help and a short description, with timing optional. A separate scoping process can gather the more detailed information once someone confirms that it is relevant.

This is not a universal recommendation for three or four fields. A specialist quote request may need more. The decision follows the next action, and the form should explain its purpose so the customer knows what they are starting.

Make the remaining fields easy to complete

W3C’s forms tutorial recommends simple forms that request information needed for the process. It also covers labels, grouping, validation and clear notifications. Removing questions does not fix a form whose remaining controls are difficult to understand or operate.

Use visible labels rather than relying on placeholder text that disappears when someone types. Explain required and optional fields consistently. Provide helpful error messages that identify the problem and let the visitor correct it without losing their work.

W3C’s form instructions guidance explains how to make requirements and formats clear. If you need a particular format, show it before the error occurs. Where possible, accept reasonable variations instead of making the visitor conform to an unnecessarily narrow input rule.

Test the form using a keyboard and on a small mobile screen. Check long names, valid but unusual email addresses, optional fields left empty and the behaviour after a failed submission. Ask the developer to assess assistive-technology support and any spam controls as part of the review.

Measure completion and usefulness separately

A form improvement should be judged by more than submission volume. Track whether visitors can complete it, whether submissions arrive correctly and whether the team has enough information for a useful response.

Agree the definitions first. A button click is an attempt. A confirmed submission is a recorded enquiry. A qualified enquiry is a later business judgement. Keep those stages distinct so a change in one does not masquerade as improvement in another.

Google Analytics events can record interactions, but the implementation needs checking against the actual form behaviour. Ask the technical team to test successful and failed submissions, duplicate triggers and any external form platform involved.

Review spam, out-of-scope requests and repeated follow-up questions alongside completion. If a simpler form increases enquiries but leaves staff asking the same essential question every time, you may need to restore that question in a clearer form.

Make a focused change and listen to both sides

Choose one hypothesis, such as “The required document upload is preventing suitable people from making initial contact.” Remove or defer that requirement while keeping the rest of the journey stable where possible. Record the change date and assess the result over a period that gives you enough relevant enquiries to learn from.

For low-volume B2B sites, a formal split test may not produce a dependable answer quickly. Combine observed completion behaviour, usability checks and staff feedback rather than declaring a winner from a handful of submissions.

Explore Grendesign’s website design services if the form and follow-up process need to work together more clearly. Start with the current questions and what your team actually does with each answer. That is the best place to decide what should stay.