Your website generates an enquiry. Somebody wants a quote, but the message says only “Please call me”. Your colleague rings during a meeting, tries again the next day, then discovers the customer needs a service you do not offer. Website enquiry forms can prevent some of that wasted effort, provided they ask useful questions without making contact feel like an application.
The aim is a clear first conversation. A customer should understand what to provide, and your team should receive enough information to choose the next step. This guide explains how to plan that balance within a First Essential UK website project, including a supported connection to your customer system where agreed.
Contents
Start with the decision your team must make
Before changing a field, ask the person answering enquiries what they need to decide. Is the first step a callback, a site visit, a project discussion or an answer by email? Different decisions need different information.
For a website project, a short description of the business and intended outcome may be useful. For an existing customer asking for support, the relevant service and a clear description of the problem matter more. Asking everyone the same long list can make both journeys worse.
The GOV.UK guidance on structuring forms recommends understanding why each question is necessary. Use that principle as a planning tool: write the action each answer supports beside the proposed question. Remove questions with no immediate purpose.
Our guide to custom websites and website builders explores the broader choice of website approach. Website enquiry forms deserve attention whichever route you choose.
Decide what website enquiry forms should collect
A sensible starting set is a name, a suitable contact method, the service of interest and a short explanation of the request. Add location only when it affects delivery or coverage. Ask for a preferred callback time when someone will genuinely use it.
Separate required answers from optional context. A budget range may help scope a development discussion, but a customer who cannot estimate one should still be able to describe the problem. A deadline field should distinguish a firm event date from a general preference.
For each field, specify where the answer goes and who reads it. If no one uses an answer, collecting it merely creates more work. If the customer is asked for both a telephone number and an email address, explain whether both are needed or offer a choice where the process allows.
Website enquiry forms work best when the customer can recognise the purpose of each question before answering it.
Write questions in the customer's language
“Tell us what you want to improve” is easier to answer than “Describe your digital transformation requirements”. A small business owner may understand the customer problem without knowing the correct name for an integration or application.
The GOV.UK guidance on interface writing supports clear, direct wording. Use questions your team already asks during helpful first calls, then shorten them for the screen.
Avoid asking visitors to choose between technical categories they cannot distinguish. A service list can include “Website or app project”, “Customer system” and “Automation”, alongside an “I'm not sure” option. The latter should lead to a useful human review rather than a dead end.
Our AI web chat guide considers another way to handle initial questions. Chat and website enquiry forms can have different jobs; the form remains useful when a visitor already knows what they want to ask.
Choose a form structure that suits the request
A short enquiry usually belongs on one manageable page. A longer project questionnaire may benefit from several steps, especially when later questions depend on earlier answers. More screens are not automatically better; test whether people understand the journey.
The GOV.UK question-page pattern explains how focused questions can support a clear journey. For a commercial enquiry, adapt the principle to the actual task rather than copying a government service layout.
| Approach | Useful when | Main consideration |
|---|---|---|
| Short contact form | The team can clarify scope later | It must still explain the request |
| Service-specific form | Different services need different starting details | Keep wording consistent across services |
| Several-step brief | A complex project needs structured preparation | Preserve answers when moving backwards |
| Form plus an enquiry conversation | Some visitors need help choosing a service | Define which route captures the final request |
The First Essential One service may form part of the subsequent enquiry process. Its agreed configuration should influence what the form sends, without turning the public form into an internal staff screen.
Make labels and hints useful
Keep a visible label beside every field. A disappearing example inside the input is a poor substitute: customers still need to know what an answer represents after they start typing.
The W3C guidance on form labels describes how controls should be identified accessibly. A designer must check the underlying implementation as well as the visual appearance.
Use a short hint when a question has a predictable source of confusion. “Describe what happens now and what you want to change” helps someone explain an automation request. A long explanation repeated below every field makes the page harder to scan.
The GOV.UK text-input component illustrates visible labels and supporting hints. Website enquiry forms should also preserve readable spacing, usable field sizes and clear focus when a keyboard is used.
A practical example: an enquiry about follow-ups
This is a fictional planning example, not a customer case study or a completed integration.
A business owner visits a service page because quote requests are being missed. The form asks for their name, contact details, service interest and what happens today. They explain that messages arrive in separate inboxes and nobody knows who has replied.
The agreed website setup captures the request. If a supported connection has been included and tested, the relevant details also reach the chosen customer system. A named person reviews the enquiry, checks the requested outcome and makes contact through the selected channel.
The visitor sees a confirmation explaining that the enquiry has been received and what happens next. It does not promise an appointment or a price that nobody has approved.
Our guide to automated customer follow-ups examines the later stages. Website enquiry forms should supply the information those stages actually need, with any further questioning left to the right point in the conversation.
Explain what happens after submission
A submitted form should lead to a clear outcome. Tell the visitor what was received, whether any further action is needed, and how they can contact the business if the matter changes.
The GOV.UK confirmation-page pattern gives useful guidance on explaining the next step. Your wording must match the real process and the team's availability.
Be precise about the difference between an enquiry and a confirmed booking. “We have received your request” is different from “Your appointment is booked”. Only show confirmation of a booking where the relevant availability and booking process have actually completed.
If messages pass to a customer system, agree whether the visitor receives an acknowledgement, whether a colleague is notified and who checks unassigned requests. Supported integrations require those decisions alongside the connection itself.
Design mistakes that customers can recover from
An invalid answer should help someone fix the problem. “Enter an email address in the format name@example.com” is more useful than “Invalid input”. Preserve valid answers so the customer does not have to start again.
The W3C form-validation guidance explains accessible feedback when information needs correction. The GOV.UK error-summary component shows how several errors can be brought together clearly.
Website enquiry forms should distinguish a field error from a submission failure. If the receiving system is temporarily unavailable, do not claim the enquiry succeeded merely because the customer pressed the button. Agree what the customer sees, where a safely captured request can wait and who investigates.
Avoid restrictions that reject ordinary names or descriptions unnecessarily. Test punctuation, international telephone formats where relevant, and realistic messages written by people who do not know your internal terminology.
Connect the form to a manageable staff workflow
A polished public form can still produce a poor customer experience if enquiries wait in an unattended inbox. Decide the destination, owner and cover arrangement before launch.
Where small-business automation is appropriate, the process might include an agreed notification or staff task. Those actions should be confirmed in scope; they are not automatic features of every website project.
Keep the enquiry's original meaning visible. A selected service category helps routing, but a person's explanation often contains the important detail. Avoid reducing it to a label that makes the team miss a specific request.
If several people share responsibility, the process should show who is taking the next action. Our guide to a unified business inbox considers the wider problem of conversations split across channels.
Plan costs and ongoing ownership
The cost depends on the number of enquiry journeys, the design work, conditional questions, receiving-system requirements, testing and ongoing changes. A simple form and a detailed multi-service intake process are different projects.
Define what is included in the written scope: fields, confirmations, staff notifications, any supported connection and the tests required for acceptance. Ask how later changes will be handled when services, team members or customer questions change.
Our website ownership guide is relevant to access and control after handover. Website enquiry forms also need an operational owner who knows when something has changed and can request a correction.
Agree appropriate handling of personal information with the responsible business team. The form should not encourage visitors to send unnecessary confidential details. Clear form instructions can explain the expected information before the visitor types it.
Test the whole journey before rollout
Test website enquiry forms on a narrow phone screen as well as a desktop. Use the keyboard, check visible labels and review what happens when an answer is missing. Ask someone unfamiliar with the business to explain what each question means.
Then follow a complete test enquiry to its destination. Can the right colleague find it? Are the original words intact? Does a repeat submission create unnecessary work? Does the acknowledgement accurately describe the next step?
Include an unavailable receiving system, an unusual request and a person who chooses “I'm not sure”. Keep test enquiries clearly identified and avoid triggering live customer messages during a rehearsal.
Record the acceptance results and the owner for unresolved issues. Start with a manageable journey, then improve it using real feedback rather than adding speculative questions.
Measure useful enquiries and follow-up effort
Submission volume alone cannot tell you whether website enquiry forms help. A shorter form may increase submissions while leaving staff with more clarification calls. A longer form may discourage suitable prospects.
Review whether enquiries contain enough information for the next decision, how often customers must repeat themselves, and how long requests wait before an owner acts. Compare similar periods and note changes in visitor traffic or campaigns.
Read a sample of actual requests with the appropriate access and permissions. If people misunderstand one question, change that question rather than assuming they are poor leads. The best improvement may be clearer wording, not an extra field.
Key takeaways
- Ask only for information that supports a real next step.
- Give website enquiry forms clear labels and distinguish optional context from essential answers.
- Explain exactly what submission means for the customer.
- Test the customer screen and staff destination together.
- Give someone responsibility for reviewing the wording and receiving process as the business changes.
Frequently asked questions about website enquiry forms
How many fields should website enquiry forms have?
Use the number needed for the first useful decision. Start with contact details, the request and genuinely necessary context. Add a field only when its answer supports an action the team can explain.
Should every customer provide a budget?
Only ask when it helps the relevant enquiry. Allow uncertainty where appropriate. Someone can have a clear operational problem without knowing the likely cost of a solution.
Can we connect an existing form to First Essential One?
That depends on the website, form method, account setup and supported connection. First Essential UK should review those details before including the integration and its behaviour in an agreed scope.
Do we need an AI Assistant as well as a form?
They serve different purposes. A form collects a structured request; an AI Assistant can support agreed enquiry conversations. Choose based on customer needs and confirm each service separately.
What should happen if submission fails?
Give an accurate message and an appropriate alternative contact route. The implementation should define how to handle safely captured requests and who checks the failure, rather than displaying a false success message.
How often should we review the form?
Review it when services, staff responsibilities or receiving systems change, and when actual enquiries reveal confusion. A regular operational check helps identify issues before they become a pattern.
Plan a clearer enquiry journey
Discuss your website enquiry form with First Essential UK and identify the details, staff workflow and supported connections your project needs.
Author: David