The short answer
Notification by email alone is fragile. Messages get filtered, deleted or missed, and there is no record afterwards that the enquiry ever existed.
Store every submission durably first, then send the notification. The store is the record; the email is a prompt.
The order that matters
- Validate and store the submission.
- Confirm to the visitor, on the page.
- Send the notification to whoever handles it.
- Send an acknowledgement to the visitor.
- Record whether each of those succeeded.
Storing before notifying means a mail failure costs you a prompt rather than a lead. That is the whole point of the ordering.
How enquiries get lost
| Failure | Why it is invisible |
|---|---|
| Notification filtered as spam | Looks like a quiet week |
| Sent to a departed employee | Nobody notices the absence |
| Mail sending silently discarded | Server reports success |
| Handler on leave | No cover arranged |
| Script error blocking submit | No submission arrives at all |
Every row produces the same symptom: fewer enquiries, no error. That is why an explicit check is necessary.
Check that it still works
- A scheduled test submission that goes the whole way
- An alert if no genuine submissions arrive in a period you would normally see some
- A visible count of stored submissions somewhere people look
- Test any change to the form end to end, not just the page load
- More than one notification recipient
The second point is the cheapest early warning. Several days of silence on a form that normally produces enquiries is almost always a fault.
Route it to someone accountable
An enquiry that arrives in a shared mailbox everyone assumes someone else is watching is functionally lost. Name an owner and a response time.
Acknowledging quickly with a realistic timeframe matters more than answering immediately. Silence is what sends people to a competitor.