A customer fills in the form, adds a few details and presses send. The business needs to know where that information went and who will reply. Planning those steps together makes the form a useful part of the working day, with a clear way to investigate a problem.
- Validate
- Check the information and explain any correction needed.
- Save
- Create a durable record and identify the submission.
- Notify
- Tell the appropriate person about that record.
A notification can fail after a record has saved. The interface and retry behaviour need to handle that distinction.
Choose the place the enquiry belongs
Start with the record the business will use for follow-up. That might be a lead register or a customer system. Agree which details it needs, where attachments belong and which person receives the enquiry. An email notification can point to that record, giving the recipient a consistent place to find the full message.
Keep questions focused on the next conversation. Show accepted file types and size limits before an upload, and explain field corrections near the question. Agree how spam controls are checked and how uncertain submissions can be reviewed.
Make saving the record a distinct step. The website's confirmation should describe the stage actually reached. A browser receiving a response and the business retaining the enquiry are separate things to check.
Reading behind this section: MDN contributors
Plan for an uncertain connection
A slow connection can leave somebody unsure whether their message arrived. Give them useful feedback, preserve their answers where practical and make the next action clear. A generic error followed by an empty form asks them to do the work again.
Unmesh Joshi's Idempotent Receiver pattern explains why a retry needs an identity: the receiving system can recognise a request it has already processed. Applied to an enquiry workflow, this means a retry can be designed to recover the original result without creating another lead or sending another acknowledgement.
Reading behind this section: Unmesh Joshi, published on Martin Fowler's website
Check the whole path with a labelled test
Use a clearly labelled test submission to check the saved record, attachments, customer acknowledgement and business notification separately. Match them through one reference. If the email is delayed, the enquiry should still be findable in its agreed destination.
MDN's Fetch documentation shows that some server errors still produce a response the website must inspect. Ask the developer how the form distinguishes a rejected request, a connection failure and a confirmed save. A thank-you screen alone cannot answer all three.
Reading behind this section: MDN contributors
Give follow-up an owner
Decide who checks new records and what happens when the usual recipient is away. Keep test records identifiable so they stay out of enquiry reporting. Then distinguish received messages, genuine enquiries and suitable opportunities when reviewing the numbers.
Begin with one complete route and check it before adding more destinations. Once that route is understood, extra notifications or reporting views have a clear job. The useful question is whether the business can find the message and act on it.
Put it to use
A useful check for your business.
- Name the saved destination and follow-up owner.
- Match records and notifications through one reference.
- Check attachments and acknowledgements separately.
- Keep tests separate from genuine enquiries.
The thinking behind this guide
Sources & further reading.
Our practical interpretation, with the references below for the specific principles and further detail.
- Idempotent Receiver
Unique request identities let a receiver recognise a retry and return a saved response. This is a design pattern, not evidence that a particular form implements it.
- Using the Fetch API
Browser requests require explicit response-status and body handling. The documentation does not establish that an enquiry was durably saved.
