The most common silent failure on a small business website is a contact form that shows “Thanks!” and delivers nothing. It breaks when a plugin updates, when the sending domain's mail settings change, when a spam filter learns a new rule, when a hosting migration drops an environment variable — and nobody notices, because the visitor sees success and the owner sees quiet. This week: prove yours delivers, from a phone, with a marker, and write down the evidence.
The problem
A form has two halves. The half the visitor sees — the fields, the button, the confirmation — is tested every time someone fills it in. The half that matters — the message arriving where a human reads it — is tested only when someone deliberately checks. Between checks, it fails without a sound. You cannot tell from the page whether the last message got through, and the visitor cannot tell either: they were told it did.
Prerequisites
- A website with a contact, enquiry or quote form that you own or are authorised to test.
- Access to the inbox, CRM or channel the form is supposed to deliver to.
- A phone on mobile data (not your office Wi-Fi), and ten minutes.
Scope
One form: the one that produces revenue or appointments. If the site has several, the one on the page visitors land on from search or ads. Not the newsletter signup, not the login form. This is a read-only exercise: you submit a message the way a visitor would and observe. You do not change the form this week unless it fails — and if it fails, the fix is a separate, recorded change.
Safe inspection workflow
-
Choose a marker. A short unique string with today's date, for example
WF1-2026-09-17-1412. It is what you will search for in the inbox, and what stops a test being mistaken for a real enquiry. - Submit from the phone. Fill in every field the way a visitor would. Put the marker in the message and in the name. Note the time to the second. Photograph or screenshot the confirmation the page shows.
- Watch the inbox. Search for the marker. Note the time it arrived. If it is not there in five minutes, check spam and any filters, then check the form's own log if it has one (most form plugins and services keep submissions). A submission in the log but not the inbox is a delivery fault; nothing in the log is a submission fault.
- Try the failure case. Submit again with a required field empty. The page should show a visible error and should not show success. If it shows “Thanks!” for an empty message, the visitor who forgets their email address is being told everything is fine.
- Check the sender. Open the delivered message's headers or “from” line. If it claims to be from the visitor's own address (rather than from your domain with reply-to set to the visitor), it is on borrowed time with modern mail filters — worth a note, not a panic.
- Record it. Marker, send time, arrival time, what the page showed, what the failure case did, and where the evidence is. Put it where next month's you will find it — the project's task list in My Projects, a maintenance log, a calendar note.
Copyable prompt
If you use Claude Code on the site's repository, this asks it to inspect the form's delivery path without changing anything. It reads code and configuration; it does not submit the form, and it does not have your inbox — that part is yours.
Read-only inspection of the contact form's delivery path. Do not edit any file, run any mutation, or submit the form. 1. Find the contact form: the template or component that renders it, and the handler that receives it (a plugin, a serverless function, a form service endpoint, a mailer). 2. Trace the delivery path from submit to inbox: what sends the email or webhook, which configuration it reads (environment variables, plugin settings, API keys — report their NAMES only, never values), and what happens when sending fails. 3. Report the confirmation logic: is the success message shown only after a successful response, or unconditionally? 4. Report the validation: which fields are required, whether required is enforced in the markup, in a script, on the server, or not at all. 5. List every place a failure could be silent (an unhandled promise, an ignored return code, a try/catch that swallows). 6. Output a short table: step · file · what it does · evidence (file:line) · risk. End with "Not checked" for anything you could not read. Do not guess.
Example evidence
This is the kind of record the challenge asks for. It is an example written for this page, not a real submission.
Weekly Fix #1 — contact form delivers — 2026-09-17 Form: /contact (Contact Form 7 → SMTP plugin → reception@) Marker: WF1-2026-09-17-1412 Sent from phone (mobile data) 14:12:07 · page showed "Thanks, we'll be in touch" Arrived reception@ 14:12:41 (34 s) · from: website@ourdomain, reply-to: visitor Failure case: empty email → red "Please enter your email" shown, no success message ✔ Sender check: SPF/DKIM pass in headers ✔ Result: PASS · evidence: screenshots in /maintenance/2026-09/ Next check: 2026-10-15
Completion criteria
The checklist below is the same list; tick it there to record your completion in My Projects. Ticking it records what you observed — the site does not check it, and the record says so.
- A test submission with a unique marker was sent from a phone, not only from a desktop.
- The marked message arrived where a human reads it, and the time between send and arrival was recorded.
- The confirmation the visitor sees was checked against what actually happened.
- The failure case was tried: an empty required field produced a visible error, not a success message.
- The result, the evidence and the date are recorded somewhere you will find next month.
Common mistakes
- Testing from the office. Office networks and logged-in browsers hide what a stranger on a phone experiences: cached scripts, allow-listed IPs, remembered form data.
- Testing only the happy path. “I filled it in and it worked” proves one state. The empty-field state is where false success lives.
- Trusting the confirmation. The page can only know that it sent a request. It cannot know the message arrived. Only the inbox knows.
- Fixing before recording. If it fails, write down what failed first. The fix is a separate change, and you will want to know whether the form was broken before you touched it.
- Deleting the test. Keep the marked message. It is the evidence, and next month you will compare against it.
Go further
- The Conversion Functionality Lab shows a form that says “Thanks!” without an email address, and the browser test that catches it.
- Playwright testing with Claude Code builds the test that keeps this from regressing — including why a mocked submission proves the page posted and nothing more.
- The maintenance guide's weekly checklist puts this check on a schedule.