Alert Once Is Not a Workflow

A catering order nearly slipped away while my system did exactly what I built it to do. It alerted once, perfectly, and then trusted me to remember — and a notification is not a workflow.

A catering order almost walked out the door this week, and the system did everything I had asked it to do.

Here is the shape of it. A request came in through the website on a Monday: a corporate breakfast for thirty people, three days out. The moment it landed, my system did what I built it to do. It read the request, decided it was time-sensitive, and sent me a message. One clean notification, on time, with the details. By every measure I had written down, that was a success. The capture worked. The classification worked. The alert worked. I have spent months making sure those things work, and they did.

And then the lead sat there for two days, untouched, while two more phone calls about the same order came in and also went unanswered, until I happened to catch it by hand the morning before the event. I booked it in the end. It became, in fact, our second standing corporate catering account. But I did not save it because the system saved it. I saved it because I got lucky, and luck is not a process.

What went wrong is the kind of thing that does not look like anything went wrong. The system notified me, and then it trusted me to remember. That is the entire bug. There was no error, no failed step, no red light. There was a notification that did its job perfectly and then assumed a human being would carry it the rest of the way. And the human being, who runs a restaurant and answers to a hundred small fires a day, did not carry it. Notifications assume that. They are built on the quiet belief that you will see the message, hold it in your head, and act before it decays. They are a tap on the shoulder, and a tap on the shoulder is not a workflow. It is a hope.

I had confused the two for a long time, because they feel identical at the moment of the alert. When the message arrives, you read it, you feel informed, you feel handled. The system told me, you think. But "the system told me" and "the system handled it" are separated by the most unreliable component in the entire operation, which is my memory under load. The alert moved the work from the machine's plate to mine and called itself done. And on paper it was done. The lead was surfaced. The fact that it then died in the gap between surfaced and handled did not show up in any log, because nothing failed. A thing that needs a person had simply been set down, gently, in a place where no one was looking.

So I changed what the system is allowed to consider finished. It is no longer allowed to alert once and move on. Now, every lead that has not been dealt with comes back the next morning, and the morning after that, and it keeps coming back, getting louder as the event gets closer, until I do something that changes its state. Mark it contacted. Mark it booked. Mark it lost. The nagging only stops when the thing actually moves. The system is no longer satisfied by having told me. It is satisfied only by my having acted, and it has no way to confirm that except a status that I have to change with my own hand.

Then I went looking for the same hole everywhere else, because a failure this quiet is never in one place. The first time the new logic ran, it surfaced ten job applications and three customer messages, all sitting in exactly the same condition: noticed once, then forgotten. Same gap, three different doors. None of those had failed either. Every one of them had been politely announced and then abandoned. I had built a business that was very good at telling me things and had quietly assumed that telling was the same as doing.

The lesson is not really about software, the way these things never are. The notification is the easy ninety percent. It is satisfying to build, it gives you the feeling of coverage, and it is almost worthless, because the value of the whole thing lives in the last ten percent, the part where a human actually does the work, and that is exactly the part a notification hands off and stops watching. A real workflow does not hand off and stop watching. A real workflow assumes the human will drop it, because the human will, and it refuses to let go until the state on the board has changed. The measure of a system is not whether it can get your attention. It is whether it can survive you not paying attention.

I think every operator runs on a pile of these taps on the shoulder. The invoice you will get to. The follow-up you mean to send. The deadline you are sure you will remember because it feels too important to forget. We mistake the moment of noticing for the act of handling, and most of what slips through our businesses slips through that exact gap, silently, looking like nothing, because nothing technically failed. The fix is unglamorous and it is the same every time. Do not build a thing that tells you once. Build a thing that will not shut up until the work is actually done. Make "I will remember" something the system refuses to accept as an answer, because it is not an answer. It is the sound a dropped ball makes on its way to the floor.

The order went out at eight the next morning. The table was set. Nobody who got that breakfast will ever know how close it came to not happening. That is the part that stays with me. The near-misses do not announce themselves any more than the failures do. You only find them when you go looking for the silence, and decide that silence is not the same as nothing wrong.

/ar/