A website enquiry form should do more than send an email. It must ask for enough information to route and qualify the request, remain easy to complete, protect personal data, confirm success and create a traceable record for follow-up. This website enquiry form checklist for Malta businesses turns those requirements into a practical design and acceptance process.
The guide focuses on contact, quotation, consultation and lead-generation forms. It complements the broader website testing checklist by examining what happens before, during and after someone submits an enquiry.
1. Define the form’s single purpose
Start with the business action the form should support. “Contact us” is often too vague. A visitor requesting a website quotation needs a different conversation from an existing customer reporting a problem or a candidate asking about a vacancy.
Write one sentence that describes the intended enquiry and the team responsible for it. If several types must share a form, use a clear first question to route them. Do not make every visitor answer fields that are relevant only to another department.
- What decision or response will the submission enable?
- Who owns the first response?
- Which enquiries are outside scope?
- What information is genuinely needed before the first conversation?
- What alternative route is available for urgent or sensitive matters?
2. Ask only for information the business will use
W3C guidance notes that people generally prefer short, simple forms and that irrelevant or excessive requests can increase abandonment. EU data-protection guidance also states that personal data should be adequate, relevant and limited to what is necessary for the purpose.
For a basic business enquiry, a name, reply method, subject and message may be enough. A quotation form can justify additional questions when they affect scope, eligibility or routing. Review every field with the person who processes the leads. If nobody can explain how an answer changes the next action, remove it or make it optional.
Do not collect sensitive information “just in case”. If the business legitimately needs health, financial, identification or other high-risk information, design the process with appropriate legal and security advice rather than placing a general text box on a public form.
3. Use clear labels and instructions
Every control needs a visible label that describes its purpose. Placeholders are examples or hints, not reliable replacements for labels. W3C recommends associating labels with controls so browsers and assistive technologies can identify the relationship correctly.
- Mark required and optional fields consistently.
- Explain expected formats before an error occurs.
- Keep instructions close to the relevant control.
- Group related options with an appropriate heading or fieldset and legend.
- Avoid internal terminology that a potential customer may not understand.
Use examples that fit Malta and the actual markets served. Telephone and address fields should accept realistic formats rather than forcing one rigid pattern. If a budget, company size or deadline question uses predefined ranges, include an option that does not force a false answer.
4. Support autofill and practical input methods
Use suitable input types and recognised autocomplete values for common personal details. W3C’s guidance on identifying input purpose explains that programmatic input purposes can help browsers and assistive technologies present and autofill fields consistently.
An email field should use the email input type, a telephone field should support telephone entry, and multiline enquiries should use an appropriate text area. Test the keyboard displayed on mobile devices. Do not disable copying and pasting, because that can make accurate entry harder for everyone, including people using password managers or assistive technology.
5. Write validation that helps people recover
Validation should prevent unusable submissions without punishing harmless formatting differences. Check required values and obvious structural errors, but do not reject legitimate names, punctuation, international telephone formats or business email addresses because of narrow assumptions.
W3C advises that custom validation notify users accessibly and that data also be validated on the server, since client-side validation alone does not provide security. When an error occurs, identify the affected field in text, explain the correction and preserve the other answers wherever appropriate.
- Show an error summary when several fields need attention.
- Place a specific message next to each affected field.
- Move keyboard focus or provide links so the errors can be found.
- Do not rely only on red borders or icons.
- Keep the person’s entered message after a correctable error.
- Test errors created after a delayed server response, not only instant browser checks.
6. Make the submit action and progress state obvious
Use a button label that describes the action, such as “Send enquiry”, “Request a quotation” or “Book a consultation”. A generic “Submit” label gives less context. When the form is processing, show a clear progress state and protect against repeated clicks that create duplicate leads.
Define what happens if the network is slow or the request times out. The visitor should not have to guess whether the enquiry was received. If retrying is safe, explain how. If a duplicate may already exist, the back-office process should recognise and manage it rather than sending several identical replies.
7. Provide a useful success confirmation
W3C’s form-notification guidance says users should receive clear feedback about successful completion as well as errors. A disappearing green line is easy to miss. Provide a persistent confirmation or dedicated confirmation page that states what was received and what happens next.
- Confirm the type of request, without exposing the full message in a public URL.
- Set a realistic response expectation without promising a time the team cannot meet.
- Provide a reference number when it helps support or auditability.
- Offer an alternative contact route for urgent matters.
- Avoid presenting another blank form in a way that makes the person think submission failed.
If an automatic acknowledgement email is sent, it should confirm receipt rather than claim that a person has already reviewed the request. Do not include sensitive form content in an unencrypted email unless the business has assessed and accepted that handling method.
8. Route enquiries to an owned business process
The form should create a business record, not depend on one person’s inbox. Decide whether submissions go to a shared mailbox, CRM, ticketing system or another controlled workflow. Assign a primary owner, backup owner and escalation route.
Test the full website integration, including field mapping, notification rules, lead source, attachments, duplicate handling and system outages. A successful on-screen message is not proof that the business received the lead.
- Verify the submission appears in the destination system.
- Check that required fields are mapped to the correct records.
- Confirm that replies use the intended business address.
- Test staff absence and mailbox access changes.
- Define retention and deletion rules for submissions.
- Keep enough technical logging to investigate failures without storing unnecessary personal data.
9. Control spam without blocking genuine customers
Use layered controls rather than a challenge that every visitor must solve. Common measures include honeypot fields, rate limits, server-side checks and reputation-based services. The exact design depends on the platform and risk.
Test controls with keyboard navigation, screen readers where practical, mobile devices, privacy tools and visitors from the locations the business serves. Monitor false positives. A spam tool that silently discards real enquiries can be more damaging than the visible junk it removes.
Do not disclose which security checks failed in a way that helps automated attackers. Give legitimate visitors a recovery route if a submission is rejected.
10. Explain privacy at the point of collection
Tell people who is collecting the information, why it is needed, how it will be used and where they can read the relevant privacy information. The wording and lawful basis should be reviewed for the actual process, not copied from an unrelated website.
Keep marketing consent separate from the enquiry. A person should not have to subscribe to promotional messages merely to ask a question. Avoid preselected marketing boxes, and record consent evidence where consent is used.
Coordinate the form with the site’s privacy and cookie implementation. If third-party form, spam, scheduling, analytics or CRM services receive data, include them in the business’s assessment and documentation.
11. Measure submissions without counting false success
Google Analytics recommends the generate_lead event when someone submits a form or request for information. Trigger measurement only after the system confirms a valid submission, not when someone merely clicks the button or sees an error.
Avoid sending names, email addresses, telephone numbers, free-text messages or other personal data in analytics parameters or page URLs. Test that refreshing a confirmation page does not create repeated lead events. Reconcile analytics counts with the form or CRM records because blocked scripts, consent choices and integration failures can produce differences.
Where lead quality matters, define later stages such as contacted, qualified, proposal issued or customer won in the operational system. Form volume alone does not show whether the website is attracting suitable work.
12. Test realistic scenarios
Build a small acceptance matrix rather than submitting one perfect enquiry. Include:
- A complete valid enquiry on desktop and mobile.
- Missing required fields and incorrectly formatted details.
- Long names, punctuation and international telephone formats.
- A long message and an allowed attachment, if attachments are supported.
- Keyboard-only completion and browser zoom.
- Slow connection, server error and destination-system outage.
- Repeated clicks and a deliberate duplicate submission.
- Spam-like input and a legitimate submission that might resemble spam.
- Successful routing, acknowledgement and staff follow-up.
- Analytics event and CRM source verification.
Use the broader pre-launch testing guide for browser, content and performance checks outside the form itself.
13. Monitor the form after launch
Forms can stop working after plugin updates, mailbox changes, DNS changes, CRM edits, expired licences or spam-rule adjustments. Assign an owner and test important forms on a documented schedule. Use a controlled test record that staff can recognise and remove.
Monitor delivery failures, destination-system errors, spam volume and sudden drops in submissions. A fall in enquiries may reflect demand, traffic or the offer, but it can also be a broken form. Check the technical path before drawing a marketing conclusion.
A concise sign-off record
Before launch, record the form purpose, approved fields, privacy wording, routing destination, owners, validation rules, spam controls, confirmation behaviour, analytics trigger, test scenarios and open limitations. This gives the business a reference when the form or receiving system changes.
DCP’s web design service can help Malta businesses design enquiry journeys that connect page content, accessible forms, integrations and follow-up. The objective is not simply a shorter form. It is a reliable path from customer intent to an owned business response.
Sources and further reading
- W3C Web Accessibility Initiative, Forms Tutorial.
- W3C Web Accessibility Initiative, Labeling Controls, Validating Input and User Notifications.
- W3C, Understanding Identify Input Purpose.
- European Commission, Principles of the GDPR, including data minimisation.
- Google Analytics Help, Recommended events.
Featured photo by Burst on Unsplash.
