Three processes were dead in the field. Nobody had reported it.
On a multi-country retail network, I put three simple systems in place. A customer satisfaction form to be filled in. A daily photograph of each outlet. A training session for the shop teams. All three died, and nobody told me.
The form: one manager never sent a single one. The photographs: stopped by all three outlets concerned, without explanation. The training: chased twice, never run.
None of those three deaths produced an alert, a message, or a report. They surfaced when I went looking for the results, several weeks later.
The common factor is not the one you assume
The reflex is to conclude there is a discipline problem, or a workload problem. Both exist, and neither explains the pattern.
The real common factor is this: none of the three processes required a proof of completion. They described a gesture to perform, not an object to produce. A process with no object to produce has no way of failing visibly, so it fails silently.
The fix, in one line
Proof becomes the object of the task, not the process.
The task is no longer « get the satisfaction form filled in », it is « this week's completed forms are filed ». It is no longer « photograph the outlet », it is « today's photograph is in the shared folder ». What is asked for becomes verifiable without having to ask.
The difference looks cosmetic. It is not: in the first case, the absence of a result is established by questioning someone, which is socially expensive and therefore postponed. In the second, it is established by opening a folder.
A field report that said something else
Digging further, an outlet manager explained a problem that was not reluctance. Five product lines came back at every stocktake despite cancellations having been made, one of them for several months. His point, in substance: the cancellations they perform leave no trace in the tool, only in the conversation.
That was not a data entry mistake on their side, it was the absence of a cancellation record in the system. They were doing the work, the tool did not show it, and nobody at head office believed them.
A team you ask three times for something they have already done stops replying fairly quickly. What I had read as an execution failure was in part a recording failure.
What the clean-up showed
I went back through every open operation, ninety lines. The ones carried by the two marketing managers went from forty-three to twenty-one in a single working session: ten closures, fourteen reassignments, nine creations.
The number that matters is the reassignments. A third of the lines declared blocked were not blocked. They were addressed to the wrong person, and had been waiting for weeks in front of someone with neither the mandate nor the information to act on them.
A task list that is never re-read becomes a list of accusations. Every old line weighs on the person it is assigned to, including when it should never have been assigned to them.
The four questions I now ask before deploying a process
What object does this task produce, and where does it land. If the answer is « nothing » or « you can see it in the field », the process is already dead.
Who notices the absence, and how fast. A lapse discovered after six weeks is not a lapse, it is lost data.
Does the system record what the person actually does, including cancellations, reversals and exceptions. Otherwise you will be measuring the tool and not the work.
And the last one, the most useful: who is this line assigned to, and does that person have the power to do it.
Going further: the method, and the case study one group budget, nine country budgets, one rule.
Do your processes produce proof? Request a Growth Audit