Let's talk
operations

The documents were in, and the booking still said pending

Half of recent car hire bookings showed documents missing in the driver app when the office had them. One rule lived in three places, and they disagreed.

·

A driver in a car park checking a booking card in Sazinga Rentals on a phone.

A driver meets a customer, opens the booking on his phone, and the phone says the customer’s documents have not been uploaded. The office has them. The driver either turns away a customer whose paperwork is in order, or learns that the warning is wrong and stops reading it. Both outcomes are bad on a hire business, where the paperwork is the control.

For GOI Car & Taxi, a self-drive and taxi hire business in Goa, this was not an occasional slip. We measured it: 150 of the 300 most recent reservations, about half, were shown as documents missing in the driver app. Six bookings on the live system sat in Document Pending while documents were on file, and the office could not close one of them without filling a dropdown that controlled nothing.

What was actually going on

One rule, “are this customer’s documents complete?”, existed in three separate copies, and they had drifted apart.

The driver app read an old set of customer fields the office no longer used. The server required an identity type on top of the uploaded documents, and uploading a document never triggered a fresh check of the booking’s status, so a booking stayed Pending after the documents arrived. The office portal held a third copy that disagreed with the server. A booking with four customer-uploaded documents and an empty identity-type box was complete to the server and incomplete to the screen. The screen then offered a button that opened a form demanding the box be filled, a loop that could only be escaped by filling a field that gated nothing.

We measured before acting. Of the six stuck bookings, only two were blocked by the identity-type check alone, so removing it would have fixed a third of the problem. The field was blank on 14,554 bookings, against 333 Aadhaar and 6 passport.

What we changed

One rule now: documents on a booking complete it. The driver app reads the booking’s own fields, and that change shipped in app version 1.0.7. Uploading or deleting a document re-derives the status immediately. The office portal mirrors the server’s rule exactly, using the same inputs, so a booking cannot be complete to one and incomplete to the other. The identity type became optional. The server change reached production on 5 August.

What it did not fix

Complete does not mean checked. While measuring, we found that all 261 customer-uploaded documents had no reviewer recorded. There were 112 across 39 bookings still untagged, and 18 bookings whose documents were entirely customer-uploaded and entirely untagged, with no trace that anyone had looked. Two of those were already past pickup. And 13 bookings had reached On Rent or beyond with no documents at all.

A second gap is in the rule itself: any single upload counts as complete, so one identity card stops the chase and the customer can arrive without a licence. Whether to add a verification step was left with the owner.

The pattern, for anyone with a checklist

Count the places your business rule lives. A rule in the app, the server and the office screen is three rules. The test is to find one record the office calls complete and ask each screen what it thinks.

Then ask the harder question: who looked? A field that says a document was received is not evidence that somebody read it.

Where this ends up

Keeping one rule for what makes a booking ready is how Sazinga Rentals keeps the driver’s phone and the office screen telling the same story.

This came out of building Sazinga Rentals

Bookings, availability and the fleet standing behind them. The problem above is one we met while building it, and what we did about it is in the product.

If you run something like this, there is one thing you can do without a call: send one week's booking sheet.