Delivery · Driver Experience
Every missed pickup is an invisible cost. The driver sits, the order ages, the next delivery slips. The app knew nothing. This case study is about making the app know.
— The Problem
The customer was in a meeting. Or in the shower. Or just forgot their phone in the other room. The driver stood outside with a bag going cold, with no way to reach anyone and no system acknowledgment that any of this was happening.
The existing app had one state for this: nothing. No waiting indicator, no escalation path, no record of lost time. The driver either rang the bell and hoped, or cancelled and took the penalty hit for someone else's unavailability.
The driver, the one who did everything right, had zero recourse.
That was the only signal I needed.
— The Thesis
Drivers can handle a two-minute wait. What they cannot handle is a two-minute wait with no information, no feedback, and no way to act. The app treated arrival as the end of the driver's job. It isn't. It's the start of the riskiest minute in the delivery chain.
I wasn't trying to punish unavailable customers. I was trying to give drivers a voice inside a system that had only ever built features for the person placing the order.
— The Model
The fix wasn't a single button. It was a sequence. Each state hands off to the next, and every handoff is designed so the driver never has to decide what to do without guidance.
The driver marks arrival. A timer starts on-screen, visible and counting. After 90 seconds of no customer contact, the app surfaces the next action automatically. The driver doesn't have to hunt for it.
In plain terms: the app watches the clock so the driver doesn't have to.
One tap sends a push notification to the customer: "Your order arrives in 6 min, be ready." Sent proactively, before the driver even reaches the door. Most unavailability problems are solved before the driver parks.
In plain terms: warn the customer before the problem happens.
If the customer confirms they're coming down, the driver gets a Hold Order option with a visible countdown. If there's no response past the grace window, the driver can escalate to support with one tap, with the wait time already logged and timestamped.
In plain terms: the driver never takes the blame for a customer's no-show.
— The Guardrail
A driver who waits 4 minutes and cancels should not look identical in the system to a driver who never showed up. The wait time is evidence. The app has to collect it.
Cancelled delivery, driver flagged, no context attached. Support had no way to tell a genuine no-show from a customer who was 30 seconds late. The driver carried the risk either way.
Every wait is timestamped from arrival. Every ping sent is logged. By the time a driver escalates, the case is already built. Support opens the ticket with the evidence in front of them, not behind a form.
— Designed Against
An early direction was a manual reporting flow: driver fills out a form, selects a reason, attaches a note. It took 11 taps to complete on a budget Android device while standing outside someone's door.
Discarded.
The driver is not a data entry operator. Every piece of evidence the system needs, it should collect passively: GPS confirming arrival, timer running automatically, ping logged on send. The escalation tap is the only thing the driver should have to do.
— The Outcome
Drivers get a pre-arrival ping that prevents most no-shows before they happen, a timestamped wait record that protects them when it does, and an escalation path that doesn't require them to argue their case from memory.
The platform gets cleaner cancellation data, a reduction in fraudulent no-show claims from both sides, and a driver cohort that isn't quietly absorbing costs the system was supposed to share.
The customer got a push notification. That's it. One tap to confirm, and the problem mostly disappears upstream.
