A useful contact-form message tells the visitor what happened and what to do next. If the website has accepted a request, acknowledge that specific step. If a field needs correcting, identify it and keep the other answers. If the send result is uncertain, say so and offer a monitored alternative rather than promising the enquiry arrived.
These messages are part of the enquiry journey. They need to match the form’s actual behaviour and the way your business handles requests.
Decide what each message can truthfully say
A form can pass through several stages: the visitor sends it, the website accepts it, a notification is attempted and someone receives it. A screen message normally knows only what the website reports at that point. Unless the system has reliable evidence of inbox delivery, “Your message has reached our team” promises more than the screen can establish.
A safer acknowledgement for an accepted request might be: “Thank you. Your request has been submitted. We will review the details and contact you using the information you provided.” Use it only if the form really has accepted the request and the follow-up describes the business’s process. A request for a quote is not a confirmed appointment or an agreement to do the work.
Give a response window only if the team can maintain it, including during leave and busy periods. If enquiries are not monitored for urgent work, say so before the visitor submits and offer an appropriate contact route where one exists.
Write errors that show how to recover
Place a clear message beside the field that needs attention. Name the field and tell the visitor what to do: “Enter an email address so we can reply about your request.” If a format is genuinely required, show an example before entry as well as in the error. Do not rely on a red border alone to explain the problem.
When more than one answer needs correction, a summary at the top can list the problems and link to the relevant fields. Keep the wording consistent with the message beside each field. Preserve the other answers where safe, so a visitor who missed a postcode does not have to write the job description again. The GOV.UK validation pattern illustrates this approach.
Check the rule as well as its wording. A valid international phone number, a customer who uses autofill, or someone without a photograph should not be rejected merely because the form expects a narrower pattern than the business needs. Ask only for details necessary for the next step; the quote-form guide helps choose those fields.
Separate a rejected entry from an uncertain send
A missing required field is different from a network interruption after the visitor presses Send. For the first, explain what to correct. For the second, the website may not know whether the request reached the server. A message such as “We could not confirm that your request was sent. Please contact us using the telephone number below before sending it again” is suitable only if that number is actually monitored and the business can check for a possible duplicate.
Agree the wording with whoever handles enquiries. If the form can establish that it did not accept the request, it can say so and offer a retry. If the result is unknown, avoid both “received” and “not sent”. Keep the visitor’s text available where the implementation can do so safely; avoid placing personal details in a public URL or showing them on a shared confirmation page.
An alternative email or telephone route should be visible, current and usable on a phone. Tell staff how to recognise and handle a repeated request. A useful message cannot repair a broken notification: trace the stages using the contact-form delivery checks.
Make the message noticeable and accessible
Put the outcome where the visitor can find it after submitting, with clear text and sufficient visual contrast. For an error, link any summary to the relevant field and associate the individual error with that field. For a confirmation on a new page, a descriptive heading and page title help identify the result.
If the form updates the current page without moving focus, ask the developer how the new status is exposed to assistive technology. W3C’s status-message guidance explains this situation; its form notifications tutorial shows several approaches. The appropriate implementation depends on the form and whether the page or focus changes. Adding an announcement alone does not establish that the whole form is accessible.
Avoid announcing every keystroke as an error while someone is still entering an answer. Check that a keyboard user can reach the correction and continue, and that a screen reader communicates the result without hiding the next action.
Give your designer an acceptance checklist
Agree test submissions with the person who monitors the form and use clearly labelled dummy details. Record the device, expected outcome and actual result. Do not use a real customer’s private information for a demonstration.
- Leave a required answer empty. Can you identify and correct it while the other answers remain?
- Try a valid submission on a phone and desktop. Does the message describe the actual accepted state and next step?
- Ask the developer to reproduce a known failure and, separately, an uncertain result in a safe test environment. Is the recovery route correct for each?
- Use a keyboard and, where available, a screen reader. Can you find the result and reach the field or alternative contact route?
- Trace an agreed successful test through any stored entry and notification to the intended inbox. Confirm who will deal with it.
Repeat the relevant checks after changes to the form or its protection. The spam-protection guide covers testing genuine enquiries after filtering changes. If the wider route from service page to conversation needs attention, start with the enquiry-journey review.
For help improving a Formby, Freshfield or L37 business website, send the page address and describe the difficulty. There is no need to include customer messages or login details in the first enquiry.
