Car rental software showing a driver you removed
Eighteen trips showed a driver who had been taken off, and on seven the removed driver could no longer be identified. The record kept for safety caused it.
You take a driver off a booking in the rental office. The booking still shows a driver. Or it shows a driver’s slot with nobody named in it, and nobody can say who was there before.
In a car rental business’s system this happened on eighteen trips: bookings that appeared to have a driver when they did not. On seven others, the person who had been removed could no longer be identified at all. That matters the day a customer, a driver or an insurer asks who was supposed to have that car.
What was actually going on
Removing a driver used to blank the driver’s name on the assignment record and leave the record in place. The reasoning sounds responsible: never destroy data, keep the record in case you want it later.
What it produced was an empty shell. A record that still belongs to a trip and names nobody. Nine places in the system read assignments without being told to ignore those shells, and each one was a separate chance to show a driver who was not there. And the shell destroyed the very thing it was meant to keep. Blanking the name in place is exactly how seven records lost the identity of the person who had been removed.
The owner’s own description of how it should work was simpler than what had been built: one record per leg of a trip, holding the current driver, with every change written to a log. Removal deletes the record, and the log entry is the history. He was right. A record kept “just in case” is a second, weaker copy of the truth sitting in the same table as the first, and every screen has to remember to ignore it. A log has no such problem, because nothing reads it by accident.
What we changed
Removing a driver now deletes the assignment and writes the change to the audit log. A leg with no driver on it means exactly that and nothing else.
I had started building the opposite: a fallback that would show past drivers on every office screen with a “historical” marker. The owner’s clarification made that the wrong design, so it was reverted the same afternoon rather than shipped.
Deleting a record that has other records hanging off it is risky, so it was tested by driving the real office screen against the real system. The first run failed: deleting an assignment that has handover photos returned an error. That was the database refusing to let the change go through. Had it been set to delete the photos along with the assignment, the removal would have succeeded and destroyed every photograph the driver took at handover, and the record of who took them. Removal is now refused outright when photos exist. The reason is a business one: photos mean the driver already did the job, and changing who did a job that is finished is a reassignment, not a removal. Reassignment still works.
One more safeguard: the driver’s phone sends a bare status update when a handover finishes. The system distinguishes “no driver mentioned” from “driver explicitly set to nothing”, so completing a handover can never delete the assignment of the driver who just completed it.
What it did not fix
Two other faults turned up during the work and were written down rather than fixed.
Two fields on the assignment record have the same name but point at different vehicle numbers. On one test booking they read 43 and 92. A careless comparison suggested all 5,193 assignments disagreed with their booking’s vehicle; the real figure was 103.
And a delete function the office screen never calls looks a record up with no check of which leg it belongs to, so it could delete the pick-up when the caller meant the drop-off. It was left alone, because changing it would alter something other systems rely on, and flagged instead.
The pattern, for anyone running bookings or assignments
Ask how your system shows “removed”. If the answer is “the record stays but blank”, every report and screen must remember to skip it, and some will not. A separate history, written at the moment of change, keeps the current picture clean and the past intact.
Also ask whether your testing does what a user does. A check that sets things up behind the scenes and only looks at the result can pass while the screen people use is broken.
Where this ends up
Driver assignments in Sazinga Rentals are removed outright and the removal is logged, which is what makes a leg with no driver on it mean exactly that and nothing else.