Almost every team has a spreadsheet that is not supposed to exist.
It lives on one person's desktop, it has a name like `tracker_v4_FINAL`, and it holds the cases the real system would not accept. Sometimes it is full of clever macros. Sometimes it is a WhatsApp group instead, or a notebook by the desk, or a folder of photos on someone's personal phone. Whatever shape it takes, it is where the work goes when the software says no.
When one of these surfaces, the reflex in a lot of organisations is to treat it as a discipline problem: people are going around the process, so the process should be tightened. It rarely works, because the spreadsheet is not a sign that people are avoiding the system, it is a list of every case the system would not carry.
If you can name a team with no tracker spreadsheet, congrats!
The procedure was written for the normal day
An SOP is usually a good thing. Someone who understands the work sat down and wrote out how it should be done, and most of the time they got it right. It exists because in operations a sloppy handover has physical consequences, and because someone has to be able to answer for what happened.
What changes is what happens when that procedure gets encoded into software. A written procedure is read by a person, and a person can tell when it does not apply. The same procedure turned into required fields and a fixed sequence becomes a shape, cut to the ordinary job, and every case now has to pass through that one shape to be recorded.
And the shape was cut for the normal day. Maybe that covers eighty percent of the work, maybe more. I do not have a real number, and I doubt anyone does. But the remaining slice is not noise. It is where the cost and the risk sit, and where most of the real judgment in the job gets used. It is also, almost always, the part the software has least to say about.
Hold it too tight and the work leaves the system
At VersaFleet, we once made proof of delivery required before a driver could close a task: a photo and a signature. For the ordinary delivery that was the right call, and it worked. Then the deliveries that did not fit the shape started to arrive. The recipient was not in, so a neighbour took the parcel. The site did not allow phones past the gate. The goods were left at a guard post, because that was the standing arrangement with that customer, and everyone involved knew it except the system.
The driver still had to close the task anyway, because an open task is its own kind of problem. So they captured whatever the fields would accept. Something got photographed, someone signed. The record then said a clean delivery had happened, when something else had, and operations found out later, by phone, from a customer, which is the most expensive way for that information to arrive.
Nobody in that story was cutting corners. They were working the way the job actually runs, which is not always the way it is written down, with a tool that only accepted the tidy version of it. Forcing the tidy version did not make reality tidy. It produced a record that looked right while the real delivery went undocumented, so the one case you most needed to see was the one that stayed hidden.
I have run into similar patterns across transport, marine logistics, and heavier industrial operations. The exception is just the case the shape was not cut for: the delivery with no one home, the goods left at the guard post. It does not go away when the software refuses it. It moves to where the rules cannot reach it, into the pile beside the system rather than inside it. Make the system stricter and you do not remove those cases, you only lose sight of them.
Carrying the exception instead of shutting it out
The alternative is not a loose system with no rules in it. It is being deliberate about which rules are worth stopping someone for, and giving the rest somewhere to go.
A few things tend to help, and none of them are clever.
Let people flag an exception in their own words. A short free-text line beats forcing a pick from a list built for the normal day, and it is often the most useful data in the product, because it is the only place the work describes itself.
Put the stop where someone can actually decide. A hard stop at the point of work lands on a person with a job to finish and no power to change anything. Let them proceed and flag it, and send the decision to whoever can make it.
Save the hard stops for what cannot be undone. Usually that means the safety cases, where the consequence is physical. Everything else can be a prompt or a warning, something that asks rather than refuses.
Leave a way back. Amend, undo, a record of who changed what and when. People stay honest with a system that lets them fix a mistake, and work around one that does not.
A system that holds its rules a little more loosely often ends up with a more truthful record, and an easier audit, than one that holds every rule tight. Not because the rules matter less, but because the odd case stays inside the system, in view, instead of in the pile beside it.
The squeeze in the middle
There is an organisational reason this keeps happening, and it is nobody's fault exactly.
The procedure often gets written a few levels up from the floor, by someone accountable for outcomes, audits, and the number that gets reported upward. Making the software hold the line looks like the responsible move from where they sit, and in fairness it often is. The person doing the work is accountable for something narrower and more immediate, finishing the job in front of them today. Both of those are legitimate, they pull in opposite directions, and the software is where they meet.
Design sits right in that gap, which is uncomfortable, and also the reason the work is interesting.
Sometimes the most honest requirements document in the building is the spreadsheet. Every row in it is a real case that mattered enough for someone to track by hand, on their own time, with no credit for it.