A frozen transfer is evidence that an exception deserves investigation before automation. When I became the user trapped in my own WhatsApp off-ramp, the important question was whether the block was needless friction or the last useful pause before money moved.
On 26 September 1983, Stanislav Petrov was on duty at Serpukhov-15 near Moscow when a Soviet early-warning system reported an incoming American missile. The system then indicated more launches. Petrov had to decide whether to pass the warning up the chain as a genuine attack.
He did not trust the alert.
The BBC’s account of the incident describes how Petrov judged the warning inconsistent with the kind of large first strike he expected. The ground radar had not confirmed it. He reported a false alarm. The satellites had misread sunlight reflected from high-altitude clouds.
That story involves stakes far beyond a founder’s transfer. The useful parallel is narrower: a system produced a confident signal, but a human noticed that the surrounding evidence did not fit. Removing that human decision would have made the process faster and less safe.
The block looked different from the user side
I had built the off-ramp to move a customer from WhatsApp into a process where the right checks could happen. From the builder’s side, a stopped transfer looked like the system doing its job.
Then my own transfer stopped.
I knew why the controls existed. I knew which parts of the flow were deliberate. None of that made the wait easier. I was now asking the same questions a customer would ask: Did the request fail? Was someone reviewing it? Should I try again? Would a second attempt create a duplicate?
That shift matters. Founders often evaluate safeguards from the diagram: input, rule, decision, next step. Users experience them as missing money, uncertain status and a clock they cannot control.
The temptation was immediate. I could identify the condition that had caught me and write a rule to let the next matching transfer pass. The next user would avoid the pause. Support would receive fewer messages. The flow would feel better.
It would also convert one uncomfortable case into a permanent policy.
An exception needs a reason, not a shortcut
Before automating an exception, I need to know what the existing stop is protecting against.
A blocked case can mean several things. The rule may be correct and the user may need a clearer explanation. The rule may be too broad. The underlying data may be incomplete. Two systems may disagree about the transfer’s state. A manual reviewer may be compensating for a risk the product does not yet represent in code.
Those causes demand different changes.
If the problem is communication, changing the decision rule creates new exposure without fixing the actual experience. If the problem is missing data, automatic approval hides the gap. If the reviewer is making a repeatable decision from reliable evidence, automation may be appropriate, but only after that reasoning becomes explicit.
This is the part product demos usually skip. A clean happy path proves that software can complete a transfer under expected conditions. It says little about whether the software can distinguish a safe exception from an unusual warning.
That distinction also shaped the compliance testing behind a WhatsApp off-ramp. The valuable test is often the one that confirms the process can stop, preserve its state and explain what must happen next.
I separated the decision from the delay
The frozen transfer created two problems, and combining them would have produced a careless fix.
The first problem was operational: the transfer had stopped.
The second was informational: the user did not have enough certainty about what the stop meant.
Automation could reduce the delay. It could also make the decision less visible. A better first move was to document the exact inputs available at the stopping point, the evidence needed to continue and the result of each possible action.
Could the same transfer be submitted twice? Could its state change while a reviewer was looking at it? Would an automated retry preserve a clear record? Could a future operator explain why the system released this case?
If those answers are unclear, the exception is not ready to become code.
This resembles the boundary I examined in what happens when a chatbot hands a customer into a regulated process. The conversational layer can make entry easier. It cannot remove the need for an accountable decision once the process carries financial or regulatory consequences.
The next version must preserve doubt
Petrov’s value in 1983 came from his ability to treat the system’s output as evidence rather than truth. The lesson for a small product team is not to place a person behind every automated decision. Limited runway makes that impossible.
The lesson is to identify where uncertainty still exists before removing the pause.
I would automate the exception only when the deciding evidence is available to the system, the rule has been tested against cases beyond my own, duplicate actions are controlled and the outcome remains explainable afterward. Until then, the manual step is carrying information the product has not learned to handle.
My transfer freezing on a Tuesday was frustrating. That frustration was useful because it exposed both sides of the decision: the customer needed a clearer path, and the system still needed a reason before it could safely let the next case through.
The next task was concrete. Write down why the transfer stopped, what evidence resolved it and which fact would have changed the decision. If I could not express that rule without referring to my own judgment, I had no business automating it yet.
Comments
No comments yet.