Our drivers could not see the customer's phone number

Your driver is on his way to a pickup and wants to tell the customer he is ten minutes out. He opens the job on his phone and the number shown is your office landline. On the next job there is no number at all, just a name. So he rings the office, the office looks up the customer and reads the number out, and this happens on every job, for every driver, all day.

This was a self-drive car rental operator in Goa in August, and the first report was simply “the app shows the support number instead of the customer’s”. When we measured it on the live system, 0 of the 290 bookings taken in July and 0 of the 147 taken in August carried the link the app used to find the customer, and of the 16 jobs in one driver’s live window at that moment, 16 had no number to show.

What was actually going on

Two faults were stacked, and the first look found only one of them.

The first was a rule, not a bug. The app was built to hide the customer’s number until six hours before the job and show the office number instead, as a privacy measure. Most of the time a booking sits on a driver’s phone it is more than six hours away: 5,273 of the 5,650 live assignments were. So the “wrong number” the drivers were seeing was the rule working as designed. The first answer given to the owner said so, put the remaining gap at about 12 percent of jobs, and left the six-hour window as a policy question for him.

Two days later the report was that drivers were seeing no number at all, and the second fault came into view. The app found the customer’s number by following a link from the booking to a customer record. Since the end of June the nightly copy from the public booking site had stopped making that link and had been writing the number into a different column on the booking instead. So inside the six-hour window, where the rule stepped aside, the app followed the link, found nothing, and hid the call button. Outside the window it showed the office number. There was no state in which the driver got the customer.

One more report came in after the fix: the number showed, but tapping the call icon did nothing. That one was the phone itself. A screen-lock app on that model intercepts the dialler, and past it the number dials fine.

What we changed

The server now finds the customer’s name and number by looking at the booking’s own columns first, then the copy of the record from the booking site, then the linked customer, and hands the app the shape it already reads. No app release was needed. Bookings whose columns were empty were filled from the copy each row already held: 1,212 of them, 850 numbers and 1,207 names and emails, added without overwriting anything, with a backup taken first. The driver search, which had matched only the linked customer’s name and so found nothing for these bookings, now searches the booking’s own name and number too.

Then, on the owner’s decision, the six-hour rule was removed. The customer’s number now reaches the driver on every assignment at every stage. The office number survives only on the 6 of 469 live assignments that have no customer number anywhere, where the alternative is a call button that dials nothing.

For the phones that swallow the dial request, the number is also printed as text beside the customer’s name, so the driver can dial it by hand. Verified live across eight assignments of one driver.

What it did not fix

389 older bookings have no customer number in any of the three places and keep the office number. There is no source to fill them from.

The screen-lock behaviour on the drivers’ phones is not something the server can change. Printing the number is a workaround for it, not a fix.

And the first diagnosis was incomplete. It found the rule and stopped, because the rule explained the report as given. The second fault was only found because the drivers kept reporting, with a different symptom, and somebody measured the live window rather than the codebase.

The mechanism, briefly

The sync’s builder hard-coded the customer link to null and wrote the number to a separate column; the driver endpoint resolved through the link. Resolution is now a three-step fallback chain, backfilled from each row’s stored upstream JSON. The masking branch was dropped along with a “handover” branch that turned out to be dead, since both driver endpoints filter to assigned status.

Where this ends up

A driver who has to ring the office to reach a customer is a driver doing the office’s job, which is why the assignment a driver sees in Sazinga Rentals carries the customer’s number from the booking itself, not from a link that a sync might one day stop making.