{"id":34854,"date":"2026-08-18T23:34:29","date_gmt":"2026-08-18T23:34:29","guid":{"rendered":"https:\/\/dr-business.com\/?p=34854"},"modified":"2026-11-13T07:37:41","modified_gmt":"2026-11-13T07:37:41","slug":"a-missing-step-raises-no-error","status":"publish","type":"post","link":"https:\/\/dr-business.com\/en\/a-missing-step-raises-no-error\/","title":{"rendered":"The enquiries you never knew you had"},"content":{"rendered":"

Nothing failed, and that was the problem<\/em><\/p>\n

The enquiries were all there. One hundred and twenty-nine of them, sitting in the database exactly where they were supposed to be. The oldest had arrived in February 2024. A hundred and twenty-six had never been opened by anyone.<\/p>\n

This was our own site, not a client’s, which is the only reason I can write about it in this much detail.<\/p>\n

Nothing was broken, in the literal sense. There was no error, no bounce, no failed delivery, no alert, no incident of any kind. Every submission had been captured correctly and stored correctly, and the form, the website and the database all worked. Someone filling in that form got the confirmation message they expected, and they were right to expect it, because their enquiry really had been received.<\/p>\n

It just never reached a person.<\/p>\n

The first explanation was wrong, and it was a reasonable explanation<\/h2>\n

Our first instinct, like anyone’s, was that this was a delivery problem. Notifications were going out and landing in spam. Or the mail server was rejecting them. Or something in the chain was dropping them on the floor.<\/p>\n

That theory was more plausible than it sounds, because this system did have a genuine mail-authentication fault (an SPF record pointing at a hostname that did not exist), which we found separately a couple of weeks later and which had been damaging deliverability, unnoticed, for months.<\/p>\n

It had nothing to do with this.<\/p>\n

What the empty log told us<\/h2>\n

The thing that settled it was the send log, and specifically the fact that there was nothing in it.<\/p>\n

If notifications had been sent and lost, the log would show sends: successful ones, failed ones, retries, bounces, something. A delivery failure is an event. Events leave traces, and that is exactly what makes them fixable: you can see the attempt, see where it went wrong, and act on it.<\/p>\n

The log had zero rows. There had not been a single attempt, successful or otherwise.<\/p>\n

No email had ever been tried. When we looked at the form’s configuration, there was no notification set up at all, not even a broken or misdirected one, or one pointing at an old address. There was no step. Nothing in the system had ever been asked to tell anybody that an enquiry had arrived, and nothing else was picking them up either: no integration, no webhook, no connected tool. The path ran from the visitor to the database and stopped there.<\/p>\n

Two problems that look identical from the outside<\/h2>\n

Which of the two you have decides where you should look.<\/p>\n

A delivery failure<\/strong> means the step exists and is going wrong. Monitoring can catch it. Alerts fire. Retries happen. Someone eventually notices that a thing which used to work has stopped working.<\/p>\n

A step that was never created<\/strong> produces none of that. There is no failed send, because nothing sent. There is no error, because nothing ran. There is no alert, because alerts are built on events and there are no events. There is nothing to retry and no incident to investigate.<\/p>\n

Failure monitoring is very good at telling you when a step you already have breaks. It cannot tell you that the step was never there, because it works by watching for events and an absence produces none. Finding that requires deliberately testing the path end to end.<\/p>\n

Why the silence was so convincing<\/h2>\n

One detail stuck with me: three other forms on the same site did<\/em> have notifications configured, and switched off. That state is visible. Open the settings and you can see, plainly, that a notification exists and is disabled. Someone reviewing the setup would spot it in seconds.<\/p>\n

The two forms that mattered had no notification at all. In the interface, that looks like nothing, which is exactly what a healthy system at rest looks like.<\/p>\n

Everything downstream reinforced it. No complaints, because nobody outside knew what was supposed to happen. No unread badge, because nothing generated one. The quiet was not evidence that the enquiry path was fine. The quiet was the symptom, and it is a symptom nobody is trained to notice, because we all learned to treat noise as bad news and silence as good news.<\/p>\n

What it was really worth<\/h2>\n

Writing this up as a hundred and twenty-nine lost sales would be dishonest.<\/p>\n

When we sorted the backlog properly, most of it was not business at all. Seventy-eight of the hundred and twenty-nine were inbound marketing spam: SEO pitches, traffic offers, one selling dog harnesses. Fifty-one were genuine enquiries. Of those, thirty-three had arrived within the previous two weeks.<\/p>\n

So the backlog was mostly noise, and thirty-three real people had recently asked us something and heard nothing back, which is reason enough. The case for fixing it never rested on the archaeology; it rested on the thirty-three that were still live, and on every enquiry that would arrive after.<\/p>\n

The commercial principle is simpler than a revenue estimate, and more defensible: an enquiry that enters your software but never reaches a human is operationally identical to an enquiry you never received.<\/strong> The visitor did their part. The system did its part. The business still did not respond, and from the outside that is indistinguishable from not caring.<\/p>\n

The test worth running this week<\/h2>\n

The diagnostic is simple. Take a single enquiry path, the one you would least like to be broken.<\/p>\n

Submit a real enquiry through it yourself, as a stranger would. Then follow it all the way, and require proof at each handoff instead of assuming it: it was stored, it was routed somewhere, a named person was notified, and that person can act on it without asking anyone where it went.<\/p>\n

The test is not “does the form work.” Ours worked perfectly the entire time, and that is part of what kept the problem hidden. The test is whether the path ends at a human<\/a>.<\/p>\n

You will know it worked when something happens that has not happened before. When we fixed ours, the test submission produced the first row that log had ever contained: the first time in the system’s life that it had even tried to tell somebody.<\/p>\n

Before spending more on generating enquiries<\/a>, it is worth proving that the ones you already get reach someone.<\/p>\n

It is a cheaper experiment than any campaign, and occasionally it is the whole problem. Silence from a system is not a status report: nothing has been reported at all.<\/p>\n

\n

Related:<\/strong> Would Your SOP Survive a Full Inbox and a Missing Manager?<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"

Nothing failed, and that was the problem The enquiries were all there. One hundred and twenty-nine of them, sitting in the database exactly where they were supposed to be. The oldest had arrived in February 2024. A hundred and twenty-six had never been opened by anyone. This was our own site, not a client’s, which is the only reason I can write about it in this much detail. Nothing was broken, in the literal sense. There was no error, no bounce, no failed delivery, no alert, no incident of any kind. Every submission had been captured correctly and stored correctly, and the form, the website and the database all worked. Someone filling in that form got the confirmation message they expected, and they were right to expect it, because their enquiry really had been received. It just never reached a person. The first explanation was wrong, and it was a reasonable explanation Our first instinct, like anyone’s, was that this was a delivery problem. Notifications were going out and landing in spam. Or the mail server was rejecting them. Or something in the chain was dropping them on the floor. That theory was more plausible than it sounds, because this system did have a genuine mail-authentication fault (an SPF record pointing at a hostname that did not exist), which we found separately a couple of weeks later and which had been damaging deliverability, unnoticed, for months. It had nothing to do with this. What the empty log told us The thing that settled it was the send log, and specifically the fact that there was nothing in it. If notifications had been sent and lost, the log would show sends: successful ones, failed ones, retries, bounces, something. A delivery failure is an event. Events leave traces, and that is exactly what makes them fixable: you can see the attempt, see where it went wrong, and act on it. The log had zero rows. There had not been a single attempt, successful or otherwise. No email had ever been tried. When we looked at the form’s configuration, there was no notification set up at all, not even a broken or misdirected one, or one pointing at an old address. There was no step. Nothing in the system had ever been asked to tell anybody that an enquiry had arrived, and nothing else was picking them up either: no integration, no webhook, no connected tool. The path ran from the visitor to the database and stopped there. Two problems that look identical from the outside Which of the two you have decides where you should look. A delivery failure means the step exists and is going wrong. Monitoring can catch it. Alerts fire. Retries happen. Someone eventually notices that a thing which used to work has stopped working. A step that was never created produces none of that. There is no failed send, because nothing sent. There is no error, because nothing ran. There is no alert, because alerts are built on events and there are no events. There is nothing to retry and no incident to investigate. Failure monitoring is very good at telling you when a step you already have breaks. It cannot tell you that the step was never there, because it works by watching for events and an absence produces none. Finding that requires deliberately testing the path end to end. Why the silence was so convincing One detail stuck with me: three other forms on the same site did have notifications configured, and switched off. That state is visible. Open the settings and you can see, plainly, that a notification exists and is disabled. Someone reviewing the setup would spot it in seconds. The two forms that mattered had no notification at all. In the interface, that looks like nothing, which is exactly what a healthy system at rest looks like. Everything downstream reinforced it. No complaints, because nobody outside knew what was supposed to happen. No unread badge, because nothing generated one. The quiet was not evidence that the enquiry path was fine. The quiet was the symptom, and it is a symptom nobody is trained to notice, because we all learned to treat noise as bad news and silence as good news. What it was really worth Writing this up as a hundred and twenty-nine lost sales would be dishonest. When we sorted the backlog properly, most of it was not business at all. Seventy-eight of the hundred and twenty-nine were inbound marketing spam: SEO pitches, traffic offers, one selling dog harnesses. Fifty-one were genuine enquiries. Of those, thirty-three had arrived within the previous two weeks. So the backlog was mostly noise, and thirty-three real people had recently asked us something and heard nothing back, which is reason enough. The case for fixing it never rested on the archaeology; it rested on the thirty-three that were still live, and on every enquiry that would arrive after. The commercial principle is simpler than a revenue estimate, and more defensible: an enquiry that enters your software but never reaches a human is operationally identical to an enquiry you never received. The visitor did their part. The system did its part. The business still did not respond, and from the outside that is indistinguishable from not caring. The test worth running this week The diagnostic is simple. Take a single enquiry path, the one you would least like to be broken. Submit a real enquiry through it yourself, as a stranger would. Then follow it all the way, and require proof at each handoff instead of assuming it: it was stored, it was routed somewhere, a named person was notified, and that person can act on it without asking anyone where it went. The test is not “does the form work.” Ours worked perfectly the entire time, and that is part of what kept the problem hidden. The test is whether the path ends at a human. You will know it worked when something happens that has not happened before. When we fixed ours, the test submission produced the first row that log had ever contained: the first time in the system’s life that it had even tried to tell somebody. Before spending more on generating enquiries, it is worth proving that the ones you already get reach someone. It is a cheaper experiment than any campaign, and occasionally it is the whole problem. Silence from a system is not a status report: nothing has been reported at all. Related: Would Your SOP Survive a Full Inbox and a Missing Manager?<\/p>\n","protected":false},"author":113,"featured_media":34896,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"drb_seo_title":"The Enquiries That Never Reached a Human","drb_seo_desc":"129 enquiries sat in our database and no notification was ever attempted. A missing step raises no error, so silence is not proof the path works.","footnotes":""},"categories":[1629],"tags":[],"class_list":["post-34854","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-systems-operations"],"_links":{"self":[{"href":"https:\/\/dr-business.com\/en\/wp-json\/wp\/v2\/posts\/34854","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/dr-business.com\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/dr-business.com\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/dr-business.com\/en\/wp-json\/wp\/v2\/users\/113"}],"replies":[{"embeddable":true,"href":"https:\/\/dr-business.com\/en\/wp-json\/wp\/v2\/comments?post=34854"}],"version-history":[{"count":1,"href":"https:\/\/dr-business.com\/en\/wp-json\/wp\/v2\/posts\/34854\/revisions"}],"predecessor-version":[{"id":34855,"href":"https:\/\/dr-business.com\/en\/wp-json\/wp\/v2\/posts\/34854\/revisions\/34855"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/dr-business.com\/en\/wp-json\/wp\/v2\/media\/34896"}],"wp:attachment":[{"href":"https:\/\/dr-business.com\/en\/wp-json\/wp\/v2\/media?parent=34854"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/dr-business.com\/en\/wp-json\/wp\/v2\/categories?post=34854"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/dr-business.com\/en\/wp-json\/wp\/v2\/tags?post=34854"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}