If you are checking a website before launch, or investigating missing inquiries, start with one question: what evidence supports the message shown after the button is pressed? Opening an email draft, accepting a web request, saving a submission and notifying someone are different outcomes. Give each one its own name and check.
Follow the inquiry beyond the button
A website can prepare an email without sending it. The mailto standard describes a way to compose a message; it does not provide immediate interaction with a mail server. A visitor may still need to choose an email app, review the draft and send it. Opening that draft is not proof of delivery. RFC 6068, sections 1 and 3.
A form with a server has a different boundary. The server might accept work for later processing. HTTP's 202 Accepted specifically means processing is incomplete; it does not guarantee the eventual outcome. Even a successful response needs to be interpreted against what the application actually agreed to do. RFC 9110, sections 15.3.1–15.3.3.
Then there is the notification. In SMTP, a receiving server's acceptance means responsibility for delivery or relay. It does not establish that a person has read the message. Later failure is possible, and some filtering cases permit silent dropping. RFC 5321, sections 6.1–6.2.
For a buyer, the practical implication is simple: ask your developer to show the record and the next action, rather than only the success screen.
A state table you can put in the brief
This is an original planning example, not a description of a deployed system. The suggested messages depend on the evidence in the middle column.
| State | Evidence needed | Suggested wording or next action |
|---|---|---|
| Brief prepared locally | Browser has generated the text | “Brief prepared. Review it before sharing.” |
| Email draft requested | Website invoked an email link; app opening is not confirmed | “Continue in your email app. You still need to send your message.” |
| Request accepted | Server acknowledged work, but storage is not confirmed | “Request accepted for processing. Saving is not yet confirmed.” |
| Inquiry stored | Application confirmed a recoverable record with a reference | “Inquiry saved. Your reference is DEMO-104.” |
| Stored; notification failed | Record exists, notification attempt failed | Keep the saved confirmation; flag the notification failure to the responsible operator |
| Outcome unknown | Connection ended without a conclusive response | “We could not confirm whether your inquiry was saved.” Offer an approved recovery route |
| Rejected before storage | Validation or storage failure is known | Explain the fix or retry route; do not show a saved confirmation |
“Stored” should have a concrete meaning in your brief. For this example, it means an authorised operator can retrieve the inquiry after the request has ended. A temporary value in the page is not enough. A reference is useful for matching records, but a reference alone is not proof that the content was saved.
Keep sensitive implementation details out of visitor messages. The operator may need the notification error; the visitor needs an accurate account of whether the inquiry was retained and what they can do next.
Try one deliberately awkward example
Imagine an internal demonstration inquiry with reference DEMO-104 and the text “Please clarify the proposed website scope.” It contains no real customer details.
The application saves it, then the notification service becomes unavailable. Two things are now true: the inquiry exists, and the usual alert has failed. Reporting “nothing was submitted” would encourage an unnecessary second submission. Reporting “the team has read your inquiry” would claim something the system cannot know.
A useful acceptance condition is: the saved confirmation remains accurate, the operator can find DEMO-104, and a visible exception identifies the failed notification and its owner. If notification is retried, it should refer to the existing inquiry rather than create another one.
Now change the example: storage completes, but the response never reaches the browser. The visitor sees an uncertain outcome. Decide with the developer how to reconcile that uncertainty before encouraging repeated clicks. The browser's timeout alone cannot settle whether a record exists.
A local logic demonstration can check these evidence distinctions with synthetic records. It does not establish a working contact backend or successful delivery.
Check the path before accepting the work
Ask for a controlled test environment with dummy records and outbound delivery disabled or isolated. Agree these checks in the project brief:
- Prepare an email draft and cancel it. The website must not count that as a captured inquiry.
- Accept a request without confirming storage. The page must not claim the inquiry was saved.
- Save a record and suppress its notification. Confirm the record remains retrievable and the failure has an operator action.
- Reject an invalid submission. Keep the explanation specific and help the visitor correct it.
- Interrupt the response after saving. Check the uncertain-outcome message and the agreed recovery method.
- Check the status with a keyboard and assistive technology. A changing message should be available to people who cannot see the visual confirmation.
WCAG's status-message criterion covers programmatically exposing relevant updates without requiring focus. That supports the last check, but it does not make a particular implementation accessible by itself. W3C, Understanding SC 4.1.3.
Record the expected message, actual record state, notification state and responsible person for each case. Exclude these synthetic records from real inquiry totals. Agree access, retention and cleanup before using actual personal information.
Write the next step into the scope
A clear requirement might read: “Confirm an inquiry only after the agreed storage check succeeds. Track staff notification separately. Give uncertain outcomes a recovery route and assign notification failures to an operator.” The team still needs to choose the implementation and approve its handling of personal data.
Once capture is clear, plan what happens during follow-up. That is a separate workflow with its own decisions.
To describe your own inquiry-path problem, prepare a project brief. The current helper prepares text locally and lets you request an email draft; you still review and send it in your email app. Preparing the brief does not submit an inquiry.