Most late repairs are not engineering failures. They are approval failures.
We went through the overdue work orders of customers running SaharaDesk and asked their teams a simple question: what was this job waiting for? The answer was rarely a part, a technician, or a diagnosis.
When a work order runs late, the post-mortem usually looks for an engineering cause. A part that was out of stock. A technician who was on another site. A fault that turned out to be harder than it looked. Those causes exist, but in our own data they are the minority.
Analysis of overdue work orders, combined with conversations with maintenance teams, showed that up to 80% of delayed work was waiting on nothing more than a quote moving through an approval chain. The engineer had diagnosed the fault. Contractors had priced it. The job sat still because a signature had not arrived.
Why the bottleneck is invisible
An approval delay leaves almost no trace in a paper or spreadsheet process. The work order shows an open date and a close date. The two weeks in between look like execution time, so the conversation that follows is about technician productivity and contractor responsiveness — the wrong conversation entirely.
This is why the question we now ask in every demo is not "can you raise a work order?" but "can your current process tell you who delayed an urgent repair — the vendor, the engineer, or the approval chain?" Most organisations cannot answer it, which means they cannot fix it.
How we measured it
The method was deliberately unsophisticated. For every work order that missed its target completion date, we asked the responsible engineer to name the single longest wait in its life, then checked that answer against the timestamps in the system. Where the two disagreed, the timestamps won.
Two things stood out. First, engineers consistently under-reported approval delay, because waiting for a signature does not feel like an event the way a missing part does. Second, the delay was rarely one long wait; it was three or four short ones, each individually defensible, accumulating into a fortnight.
The counter-argument, and why it fails
The obvious objection is that approval delay is a people problem, not a system problem: chase harder, escalate sooner, and the queue clears. Teams that tried this told us the same thing. Chasing works, for about a month, for whoever is doing the chasing. It does not survive a holiday, a resignation, or a busy quarter, because it depends on continuous human attention applied to something that should not need attention at all.
What did survive was changing the rule rather than the effort — deciding in advance which decisions require a person and which do not.
Three ways out, not one
The instinct is to remove approvals, and that instinct is wrong. Approvals exist because maintenance spend is real money and because auditors ask questions. The organisations that solved this did not remove governance; they changed where governance sits in the sequence.
Across our customer base three distinct models emerged, and each suits a different appetite for control. We have written each one up separately.
- Engineer-Led Evaluation — the engineer runs a time-bound RFQ and evaluates on diagnosis quality before cost.
- Delegated Approval with Cost Thresholds — spend below a threshold proceeds immediately; above it escalates.
- Fixed-Price Governance — a central priced catalogue removes the quotation step for known work.
Related reading
See it against your own workflows
Book a live demo and we will start with your overdue work orders, not our feature list.