Build a Contact Form That Doesn't Lose Enquiries

A success message does not prove delivery

Many contact forms do one thing after a click: show “Submitted successfully.” The email service may have timed out, the database write may have failed, or the notification may have landed in spam, while the visitor still sees a green confirmation. Define what success means. At a minimum, the server should accept and persist the submission; a reference number makes it easier to trace. Email is a notification channel, not the only copy of the message.

Start by defining the form's purpose. If readers only need to report an error in an article, name, company, telephone number, and budget should not all be required. Extra fields increase abandonment and the amount of personal information you must manage.

Write labels for people, not for database columns

Use a visible label such as “Your email address,” not an internal name such as contact_email. A placeholder cannot replace a label because it disappears as soon as someone types. Distinguish required from optional fields, explain format rules before submission, and tell users how to correct an error rather than saying “Invalid parameter.”

Appropriate input types such as email, url, and tel improve mobile keyboards and provide basic checks. Browser validation is not a security boundary. Validate every field again on the server, limit lengths, and store accepted values safely.

Give each submission a clear server-side state

A submission may move through received, validated, stored, notified, and handled. Record at least when it arrived, which page it came from, its processing state, and a short error description. Do not collect passwords, full tokens, or other information the form does not need. If email notification fails, the saved record should remain in a queue for follow-up, with an alert for the operator.

Complete the steps that protect the user's message before returning success. If storage is essential and writing fails, return an error. If the record is safely stored but a notification fails, you can tell the visitor “We received your message” while marking the notification problem in the admin area.

Make repeat clicks and network retries predictable

Show a processing state after a click, but do not depend only on disabling the button: a mobile network may retry a request. Give the submission an idempotency key so the server can recognize the same attempt within a short period. Return the same reference number instead of creating several records.

After an error, preserve non-sensitive fields the user already entered and move focus to the error summary or first invalid field. One mistyped email address should not empty the entire form.

Add anti-spam measures in layers

Begin with a hidden honeypot field, a reasonable minimum completion time, rate limits by IP and email, and content-length limits. If necessary, score repeated text, unusual link counts, and known spam patterns. Add a CAPTCHA only when spam volume justifies the cost it imposes on real users; also check accessibility, network reachability, and the data sent to its provider.

Do not send every submission to an opaque third party simply to reduce spam. If you use an outside service, document what it receives, how long it retains data, what happens when it fails, and how you could replace it.

Put the privacy explanation next to Submit

Explain what information is collected, why it is needed, how long it is kept, who can access it, and how a visitor can request deletion. Marketing consent, if offered, should be separate from the request and not preselected. Logs may also contain IP addresses, user agents, or submitted text; retention rules need to cover logs as well as the main database.

A public tutorial should remain readable without submitting a phone number. Keep the boundary between helpful content and lead collection clear. Trust is worth more than one additional field.

Test failure cases before launch

Try an empty required field, a malformed email address, overlong text, rapid repeated clicks, an email-service failure, a database failure, and an interrupted mobile connection. Confirm the interface never reports success when the message was lost, the admin area shows stored submissions awaiting attention, and logs do not leak message bodies or secrets. Check labels and error messages with a keyboard and screen reader too.

After a week of operation, compare submissions, valid messages, notification failures, and response time—not just button clicks. Next, move to the page-level technical SEO checklist.