A contact form on a website collects an enquiry, writes it to a database, and emails you to say one arrived. Three steps. Most owners think of this as one thing that either works or does not.
It is three things, and they fail independently.
What actually happened
On one of our own properties, the email provider had a security setting enabled called authorised IP addresses. The idea is reasonable: only let the account send from known machines. The website runs on serverless infrastructure, which means the machine sending the email is a different one each time, with a different address.
So every notification was rejected. The provider returned an error saying it had detected an unrecognised IP address.
The form kept working. The database kept accepting rows. The page showed a success message. The only broken step was the one that tells a human being that any of it happened — and that step is invisible from the outside, because its whole job is to produce something you were not otherwise expecting.
A system that reports success proves the runner ran. It never proves the work happened.
The part that makes it expensive
Nothing alerts you. An email that was never sent leaves no gap you can see. You do not notice an absence of notifications, because the absence looks exactly like a quiet week.
We have seen the same shape elsewhere: a survey form belonging to a contact, live for weeks, with several people who had filled it in asking to be contacted. The submissions were all there. Nobody had looked, because nothing had ever arrived to make them look. The oldest one had been waiting a month.
That is not a technology problem. Every individual component did its job. It is a design problem: a chain was built where the last link is the only one a human ever observes, and nobody tested that link separately.
What to do about it, without becoming technical
- Submit your own form, today, with a real address. If nothing arrives within five minutes, you have found the bug that was going to cost you a customer.
- Then check whether the submission is stored, even though the email failed. Those two failures have completely different consequences — one loses a notification, the other loses the enquiry.
- Put a recurring reminder in your calendar to do that test monthly. It takes ninety seconds and it is the cheapest insurance in the business.
- Ask for failures to be loud. A system that cannot send a notification should be able to tell you it cannot, through a different channel than the one that is broken.
- Never let a success message be the proof. It usually only means the button was pressed.
The general rule
Anything automated in your business should be assumed to be doing nothing until you have seen its output with your own eyes, recently. Not a dashboard that says it is healthy — the actual thing it was supposed to produce.
That rule sounds cynical. It is the opposite: it is what makes automation safe to rely on. You can hand a job to a machine and stop thinking about it, as long as you have decided in advance how you would find out if it stopped.