The morning
6 AM, 138 vehicles, five yards, and a backlog nobody could read.
← All work
Three Problems Were Live in the Fleet. The Old Tool Showed None of Them.
Reviver ran 138 vehicles with 149 open compliance issues and no way to rank or batch them, so clerical work grew with every truck the company added. These are the four calls I made to change the shape of that cost, and why each one beat the alternative.
RFleet is Reviver's fleet operations platform. Some product details in this case study are adapted.
The core problem
Every compliance fix cost the same three minutes per vehicle, one vehicle at a time, with nothing telling managers which vehicle mattered first. Growing the fleet meant hiring the clerical hours to match.
89 → 9 min
shift-start compliance work, same morning, 138 vehicles
Modelled
92%
flatter cost per added vehicle, 0.65 to 0.05 minutes a day
Modelled
3 of 3
real problems surfaced at shift start, against 2 of 3 in the old tool
Measured
- 01 Open on ranked problemsover the fleet table managers already knew Costthe all-rows view
- 02 Fix in bulk by defaultover a faster one-vehicle form Costmistakes scale with the batch
- 03 Keep a human on every filingover automatic renewal filing Costone-click speed
- 04 Build three modules deepover nine at surface depth Costa product that looks less finished
The weak spot: bulk actions make mistakes bigger, and wave one has per-item cancel rather than real undo. Undo is the next build, and recovery is a pass or fail task in the test plan.
Read the full story ↓
01
Three problems were live that morning, and the tool rendered them like everything else
The operation runs 138 vehicles out of five yards with 22 drivers. On a normal morning it carries 149 open compliance and hardware issues. A backlog is not unusual. What made this one expensive is that the system holding it had no opinion about which items mattered and no way to clear more than one at a time.
This is what was sitting in that backlog the morning the work started.
Two plates had gone dark
RP-70144 had stopped reporting 52 hours earlier, RP-60012 36 hours in. Both rendered identically to the 136 vehicles that were fine.
A registration had already lapsed
Truck 2210 went overdue three days before anyone looked, with nothing flagging it on the way there. That is a problem an operation learns about from a phone call.
Eleven trucks had not moved in ten days
Three sat in one yard, six also had a renewal due. No column held "has not moved", so this one was not findable even on purpose.
37%
of the fleet carrying an open theft or hardware issue, 51 vehicles of 138
149
open compliance and hardware issues, none of them ranked
71
registrations needing renewal, 23 of them inside six weeks
32
open stolen vehicle reports, none prioritised against each other
It looked like a usability problem. It was a cost problem.
A missed row turns into money along the same path every time. Nothing ranks a dark plate above a routine plate photo, so it waits for the next manual pass. The fix is one vehicle per trip through the form, so the backlog fills faster than one person clears it. A renewal goes overdue, the truck is no longer street legal, and it sits until the paperwork clears.
Every step on that path scaled with the number of vehicles. Buying a hundred more trucks meant buying the clerical hours to match. That is what moved this from a usability complaint to a company priority: it capped growth before the market did.
02
Where I aimed
The evidence, the two findings that mattered, and what I chose to leave alone.
The brief was to clean up the vehicle table. The evidence said the table wasn't the problem.
I worked alongside fleet managers and compliance staff running the old system, watching where the workflow actually stalled rather than where people said it did. Then I audited the same system against usability heuristics and severity-rated every violation, which turned a list of complaints into a build order.
Eight gaps came out of it. Two rated severity 4, meaning work stops or risk goes unseen. Neither of them lived in the table.
Severity 4
Nothing ranked urgency
A stolen vehicle and a routine plate review carried identical weight, so emergencies surfaced late. This lives in the absence of a layer above the table.
Severity 4
Nothing could be fixed in bulk
One fix per vehicle, repeated, even when the same fix applied to dozens. This lives in the absence of a selection model underneath the table.
So I reset the mandate: make compliance work stop scaling with fleet size, and make the fleet's real state visible without anyone going looking for it. I left the six severity 3 and 2 gaps for later, including navigation and the assistant, because none of them stopped work. Success was written down before the build as two things that could be checked afterwards: fewer vehicle days lost to avoidable lapses, and no link between fleet size and clerical hours.
Three constraints bounded every decision that follows.
Constraint
Filings carry legal consequence
Compliance submissions cannot be automated away casually. A wrong automatic filing is worse than a slow correct one.
Constraint
No behavioural data to tune against
Nothing in the legacy system was instrumented. Any threshold in the new product would be my judgement until real usage could correct it.
Constraint
Nine modules, one build capacity
The full operational surface is nine modules. Building all nine at shallow depth was possible. Building three properly was the other option.
See all eight gaps, severity rated
| Gap | Heuristic violated | Sev. | Cost to the user |
|---|---|---|---|
| No urgency signal | Visibility of system status | 4 | A stolen vehicle and a routine plate review carried identical weight, so emergencies surfaced late. |
| No bulk actions | Flexibility and efficiency of use | 4 | One fix per vehicle, repeated, even when the same fix applied to dozens. |
| No overview layer | Visibility of system status | 3 | Fleet health had to be reconstructed by hand from a flat table every shift. |
| No real filters | Recognition rather than recall | 3 | Isolating stolen, overdue, idle or unassigned vehicles meant scanning rather than filtering. |
| No synthesized insight | Recognition rather than recall | 3 | Correlations such as "these six idle trucks also expire this month" stayed invisible. |
| No navigation | Consistency and standards | 3 | No persistent shell, so orientation reset on every jump between areas. |
| No design system | Consistency and standards | 3 | The same status meant different things in different colours on different screens. |
| No assistant | Flexibility and efficiency of use | 2 | Every question required manual table work, even to reach an answer nobody could act on. |
Severity 4 means work stops or risk goes unseen. 3 means a major slowdown with a painful workaround. 2 means real but survivable friction.
03
Four forks in the road
Each one a choice between two reasonable paths, and what the winner cost.
Every decision below gets the same test: what I picked, what I picked it over, the proof, and the price. The pushback is the objection I would expect from someone who disagrees, with my answer.
Fork 01 · Closes: nothing ranked urgency
Open on ranked problems, not on the fleet
Path not taken
The vehicle table or a map as the landing page. The industry default, and what managers already knew.
Path taken
A ranked list of findings, written as sentences, each carrying the control that resolves it.
I chose a ranked list as the landing state, because managers open the page to act, over the table or map, and it cost the all-rows view they were used to.
- Why
- The dashboard runs the fleet data through a set of rules and writes each finding as a sentence before anyone arrives. The three problems from that morning are the first three things on the page, in severity order. The legacy table surfaced two of the three. The idle trucks had no column at all.
- Cost
- No all-rows default. The table and map are one click away and share the same filters, so the full view still exists. It just isn't the first thing anyone sees.
- Pushback
"Fleet software opens on the map. And what if your rules rank the wrong thing first?"
For a dispatch-heavy fleet the map is the right default. These managers spend their mornings on registration and compliance, which is list work. If the ranking is wrong, a guardrail catches it: insight cards dismissed with no follow up. If most of their day went to live location, I would flip it.
Fork 02 · Closes: nothing could be fixed in bulk
Fix in bulk by default, and treat one vehicle as the exception
Path not taken
A faster single-vehicle form. Better fields, same model: one trip through the form per vehicle.
Path taken
Four bulk flows covering every open issue type, with filter and selection state in the URL so a dashboard card hands the table a pre-selected batch.
I chose bulk as the default, because the cost was paid per vehicle, over a faster one-vehicle form, and it cost safety: a mistake now scales with the batch.
- Why
A faster form lowers the cost per vehicle but keeps the straight line. Batching changes the slope: one more vehicle inside an open batch takes about 12 seconds, against roughly three minutes on its own. All 149 open issues map to one of four flows: assign plate, change status, renew registration, and report or cancel a theft.
The same flows are reachable from Ask, which returns a structured card carrying the fix instead of a prose answer. One renewal flow, two entry points, and no second implementation to drift.
- Cost
Bigger mistakes, and wave one has per-item cancel rather than real undo.
Batching also helps less where the decision is genuinely per vehicle. Plate assignment drops 78%, not 97%, because every truck still needs its own plate chosen. The design does not pretend otherwise.
- Pushback
"You made it easier to make bigger mistakes, and didn't ship undo."
That is the real weakness of wave one, and I won't argue it away. Recovery is a task in the usability protocol with a 90%, no data loss target. If it fails, wave two waits.
Fork 03 · Bounded by: filings carry legal consequence
Keep a human on every filing
Path not taken
Automatic renewal filing. The rules already know which registrations are due.
Path taken
One human review per batch, with the documents checked inside the same dialog.
I chose to batch the human decision, because a wrong filing carries legal consequence, over automatic filing, and it cost the one-click speed automation would have given.
- Why
- A slow correct filing costs minutes. A fast wrong one takes a truck off the road or creates a compliance violation. Batching still took the renewal flow from 115 steps to 3, so most of the time saving landed without moving liability onto the software.
- Cost
- A person still reviews every batch. For the 23 renewals due that morning, that is about five minutes.
- Pushback
"Automation is the point of software. If a competitor auto-files, you look slow."
For low-stakes records, automation wins. What would justify automating this step is production data showing reviewed batches almost never need correcting. Until that exists, auto-filing is a bet made with the customer's liability.
Fork 04 · Bounded by: nine modules, one build capacity
Build three modules deep, not nine wide
Path not taken
All nine modules at surface depth, replacing the legacy tool everywhere at once.
Path taken
Three modules built properly, each closing a severity 4 finding. The other six visible in the navigation, but inactive.
I chose three deep modules, because only two findings were severity 4, over nine shallow ones, and it cost a product that looks less finished.
- Why
- Both severity 4 findings need depth to close: a rules layer above the data and a selection model under it. Nine shallow modules would have closed neither. The remaining six now inherit a shell and component library that already exist, so wave two starts further along.
- Cost
- Managers keep using legacy screens for the other six areas for now. I left the unbuilt modules in the navigation, inactive rather than hidden, so nobody mistakes wave one for the whole platform.
- Pushback
"Leadership asked for a platform and you shipped a third of one."
If the severity ratings had spread evenly across the modules, I would have gone wide. They didn't. Two gaps stopped work, and breadth fixes neither of them.
Two smaller calls, same test
No language model behind Ask yet
The value is the answer contract, typed cards that carry their own actions, not the parser in front of it. Keyword routing proved the contract cheaply and keeps the model swappable. It costs flexibility in how questions can be phrased. Questions that fail to match are the signal to add the model.
No configurable thresholds
With nothing instrumented, a settings screen would have handed managers my guess with extra steps. Fixed idle days and renewal windows ship a decision that real usage can correct, at the cost of fleets that run differently waiting a wave for control.
04
The same morning, replayed
Same three problems, same 138 vehicles, measured against the baseline taken before the build.
89 minutes down to 9, and all three problems found
Both tracks cover the identical morning: triage the fleet, clear the 23 renewals due inside six weeks, deal with the two dark plates. The legacy track is reconstructed from its own workflow at roughly three minutes per record edit. The RFleet track is measured by walking the built product.
Legacy system89 minutes, ends 7:29 AM
10 min
Renew 23 registrations, one at a time69 min
10 min
Scan 138 rows 10 min, renew 23 registrations one at a time 69 min, chase 2 dark plates 10 min
Never found: the 11 idle trucks. No column held "has not moved".
RFleet9 minutes, ends 6:09 AM
Renew 23 in 5 min, dark plates 2 min, idle trucks reviewed 2 min, triage 0 because it is the landing state
All three problems handled, including the one the old system could not show.
Legacy system
RFleet
Both tracks on the same 0 to 90 minute scale.
The number that matters most: cost stopped tracking fleet size
Back to the line from the start of the page. The legacy tool spent its minutes per vehicle, so cost rose in a straight line with the fleet. In RFleet the expensive part is opening a batch, not the size of it.
That changes the slope, not only the starting point. It is the difference between a faster tool and a tool that lets the company grow without hiring against it.
Cost curve slope
92%flatter
0.65 to 0.05 minutes of daily compliance work per vehicle.
At four times the fleet
5.9 hrs→30 min
Daily clerical load at 552 vehicles, projected from the same baseline.
Per vehicle inside a batch
3 min→12 sec15x
The mechanism behind the slope change.
Issue types fixable in bulk
0 of 4→4 of 4
All 149 open issues map to one of four reusable flows.
Step counts per workflow, and how every figure was derived
Renew the 23 registrations due inside six weeks
Legacy115
RFleet3
−97%
Assign plates to the 27 vehicles with none
Legacy135
RFleet30
−78%
Report 2 vehicles stolen
Legacy10
RFleet4
−60%
Identify what needs attention at shift start
Legacy138 rows
RFleet0, landing state
Eliminated
A step is one interaction: a click, a selection, a save. RFleet step counts are measured by walking the built product. Legacy counts are reconstructed from the legacy workflow.
Time figures apply roughly three minutes per manual record edit, conservative for a form based tool with no bulk actions. These are modelled figures rather than production telemetry, because the platform has no usage log yet. The ratios survive a different per edit estimate, since both sides move together.
What is measured, what is modelled, and what is still open
The step counts are measured. The time and cost curve figures are modelled from those counts plus one stated assumption. Nothing here is production telemetry yet.
The walkthrough is also mine, and I built the product, which makes me the worst available test subject. Nothing in wave one has been put in front of a fleet manager who has never seen it. That is the next thing to fix, and the protocol is written so its results compare directly against the legacy baseline.
Measured
- Step counts for all four workflows in the built product
- Issue coverage: four bulk flows against 149 open issues
- Detection: 3 of 3 morning problems surfaced, against 2 of 3 before
Modelled
- Minutes per morning, from step counts at 3 minutes per edit
- The cost curve slope and the four times fleet projection
- Backlog clearance time at roughly ten grouped batches
Not yet evidence
- Task success rate with users who did not build the product
- Whether bulk actions cause recoverable mistakes in practice
- Registration lapse rate and vehicle days recovered in production
How I'll know it worked in production
| Task | Success criterion | Target |
|---|---|---|
| "Something needs your attention this morning. Handle it." | Finds the highest severity item unprompted and takes the resolving action | 90% unassisted, under 60s |
| "Clear every registration due in the next six weeks." | Uses a bulk flow rather than per-vehicle edits | 80% choose bulk, under 2 min |
| "A truck was stolen overnight. Report it." | Completes the report without entering the wrong status first | 95%, under 45s |
| "Which vehicles in Roseville have no plate assigned?" | Reaches the answer through filters or Ask rather than scanning | 85%, under 60s |
| "You reported the wrong truck stolen. Undo it." | Recovers without help. The guardrail task for bulk actions. | 90%, no data loss |
Moderated, six to eight fleet managers, think aloud, SEQ after each task and SUS at the end against a target of 80. If the recovery task does not test clean, the batching win is not real and wave two waits.
North Star
Share of the fleet that is street legal and reporting
63 percent today, 87 vehicles of 138. It is the number the growth ceiling argument rests on, and the one that says whether compliance work is keeping trucks earning.
Leading
- Time from dashboard load to first resolving action
- Share of fixes performed through a bulk flow
- Median age of an open issue when resolved
- Ask sessions ending in an action rather than an answer
Lagging
- Registration lapse rate
- Mean time to report a stolen vehicle once known
- Vehicle days lost to preventable out of service status
- Open issue backlog size week over week
Guardrails
- Bulk actions reversed within ten minutes
- Theft reports cancelled shortly after filing
- Insight cards dismissed with no follow up
- Alert volume per manager per shift
What I would change next
Undo comes first
Bulk actions make mistakes proportionally larger, and per-item cancel is not undo. That is the next build, and it is why recovery sits in the test protocol as a task rather than an assumption.
Put it in front of managers who didn't build it
Every measured number on this page comes from my own walkthrough. The moderated test is written and ready. Until it runs, the step counts show what the product allows, not what people do with it.
The insights are rules, not learning
The dashboard cards are hand written heuristics over live data. Right for a first wave because they stay legible and debuggable, but the thresholds inside them should be tuned against real behaviour rather than my judgement.
The map is doing less work than it could
It shares filter state with the table but does not support selection. A manager looking at a cluster of problems in one yard should be able to select it and run a bulk flow without going back to the list.
RFleet, Fleet Operations Platform, wave one. I designed it and built the front end in Next.js 16, React 19, Tailwind CSS 4, shadcn/ui and react-leaflet, on the Reviver design system.