Case 08of 08
Parcelle One app, one thumb, a whole shift of battery
A hundred and forty same-day couriers running their working lives through a consumer maps app and a WhatsApp group, photographing parcels into a chat and hoping. Nine per cent of jobs ended in a dispute, and every phone was dead by two in the afternoon.
Offer and proof of delivery — designed to be used without stoppingFig. 01
The problem
A Parcelle rider ran three things at once: a maps app for navigation, a WhatsApp group for dispatch, and a camera roll as the permanent record of every delivery they had ever made.
Nine per cent of jobs ended in a dispute, and almost all of those disputes came down to a photograph that had scrolled out of a group chat. Meanwhile the combination of continuous navigation and a chat app flattened a phone in about four hours of a ten-hour shift.
- 9% of jobs disputed, nearly all over missing proof of delivery
- Phones dead after ~4 hours; riders carrying battery packs at their own cost
- 42 second median to accept a job, because accepting meant reading a chat
- Dispatch reconstructed each day by hand from three sources
- No record that survived a rider leaving the company
Before and after
The rider’s phoneBattery life across a shift, after we stopped doing the thing that made our own dispatch map look impressive.
No chat, on purpose
The obvious build is an app with messaging in it. We argued against it and it was the most contested decision of the project.
A rider reading a chat message is a rider reading a phone in traffic. Free text also cannot be reported on, disputed or audited. We replaced the entire conversation with three structured states — collected, delayed, delivered — plus a call button for the genuine exceptions. Dispatch lost nuance and gained a record; riders stopped typing at junctions.
- Three structured states replacing an open chat channel
- One call button for real exceptions, logged against the job
- 96px accept target, reachable one-handed from a bar mount
- Offer shows fee and distance only — the two things the decision needs
- Proof of delivery bundles photo, recipient state and GPS accuracy together
Accepting a job
Forty-two seconds became nineMedian across 140 riders on their own handsets, which range from a four-year-old budget Android to a current iPhone — we did not normalise for device, because riders do not get to. The continuous-tracking figures are from our own first build, not from the previous setup, so this compares our mistake with our fix.
The battery problem
Our first build tracked location continuously at one hertz, because that is what made the dispatch map look impressive. It was also the single worst thing we could have done to a rider’s day.
Riders told us in week seven. We had not measured it, which is the failure. Adaptive sampling — every 40 seconds while moving, every 5 minutes while stationary, suspended entirely between jobs — took a shift from 4 hours to 11 and made no measurable difference to dispatch.
- Adaptive location sampling replacing continuous 1 Hz tracking
- Tracking suspended entirely between jobs, not merely reduced
- Battery drain per shift now a tracked metric in every release
- Dispatch accuracy unchanged, which we measured before shipping the change
- Dark interface by default, because it is cheaper on OLED and easier in sun
A shift
Five moments that had to work without stoppingResults
Each with its methodThey took the chat out and the riders thanked us. I did not expect that, and I argued against it for a month.
LogWeek by week
The build log
Eleven weeks, including the week we spent undoing something we were proud of.
Paid discovery. Two days riding pillion and one evening in the dispatch room. Every dispute from the previous quarter read and categorised.
Offer and accept flow. Tested on a stationary bike with a bar mount and gloves before it went near a road.
Proof of delivery. Photo, recipient state and GPS accuracy bundled as one artefact, because separately they settle nothing.
Structured states replacing chat. Dispatch hated it for a fortnight, then stopped mentioning it, which is how that usually goes.
Riders reported dead phones. Our continuous tracking was the cause. Feature work stopped; battery became a measured metric that day.
Adaptive sampling built and validated against dispatch accuracy before shipping, so we were not trading one problem for another.
Rollout city by city, forty riders at a time, each with a week of overlap where the old group chat still worked.
Battery drain is now on the release checklist for every field app we build, which is the only good thing to come out of week seven.
What shipped
Six deliverablesWhat we would do differently
We shipped continuous location tracking because it made our own dispatch map look good in a demo, and we did not measure what it cost the people holding the phones. Riders told us in week seven; we should have known in week two. Battery drain per shift is now measured from the first build of any field app, alongside crash rate, and we would rather have a less impressive map. The fix was a week. Not noticing for six is the part that still bothers us.
Who did it
CreditsProduct design, React Native, proof-of-delivery model, rollout. One person, ten weeks.
Native location modules for iOS and Android, including the adaptive sampling that saved the project. Three weeks.
Head of operations who argued against removing chat and then defended it publicly; eleven riders who tested every build on real shifts and were paid for the time.
Two build slots openNext start: March