GSK Driver
"Verified drivers. Trackable trips. Faster dispatch."
Delivery drivers had no way to see or accept jobs on the move, and the business had no consistent way to verify a driver's license before letting them onto the road.
What it looked like.
How to read this case study: what I owned, what shipped and the verified outcome (My Role, What Shipped and Impact below) are factual. The surrounding strategy, vision, alternatives and metrics framework are interview-ready framing built on those facts, how I'd talk through the product thinking, not a claim that every metric or GTM motion was formally run at the time.
Challenges & baseline.
Challenges
Matching an available driver to a fuel delivery request used to depend on who someone happened to reach by phone, and there was no consistent process for checking a driver's license was real and current before they got a job. This is a two-sided logistics problem: GSK Admin solves demand-side operations, this product solves the supply side, and a marketplace like this fails if either side breaks.
Baseline
Driver verification before this product: manual, no consistent record of who had been checked.
What the customer actually needed.
Insight
Admin technology alone can't fix dispatch if drivers still operate through informal calls, and supply-side verification is only real if it's enforced at the point that matters. A written policy about checking licenses doesn't change behaviour, requiring both sides of the license before a driver's status can move to Verified does, because the constraint lives in the software, not just the process.
Job to be done
As a driver, when I'm available, let me see and accept a real job from my phone. As an admin, when a new driver signs up, let me verify their license quickly and confidently before they're allowed to take a job.
Vision, mission & the bets we made.
Every driver on the road has been seen, verified and rated, every trip is trackable from request to completion.
Turn driver onboarding and dispatch into a system, not a phone tree.
Let a driver go online and receive a real request with pickup, destination and distance; let an admin verify a license in minutes with both sides of the document visible.
Ship the online/offline driver state with live stats (distance, trips, time); ship request accept/reject with map and live trip tracking; ship the admin driver-verification queue with clear status states.
Strategic bets
- Put trip history and stats (distance, trips, time) on the driver's home screen so status feels earned, not just logged
- Require both sides of the license before a driver can be marked Verified, put the constraint in the software, not just the process
- Keep the accept flow to one tap, with the fee and route already visible
- Build the supply side (this product) and the demand side (GSK Admin) as a connected marketplace, not two independent tools
Alternatives considered
The faster path would have been a lighter self-declaration flow for drivers, list your license number, get approved, ship it sooner. That was rejected because it doesn't actually close the verification gap, a policy without a hard checkpoint. The chosen direction required both sides of the physical license document before a driver's status could move to Verified, slower to onboard each driver, but it's the version that's actually enforced rather than merely stated.
What I owned.
Product Manager, owned the driver app (online status, trip flow, ratings) and the admin verification queue end to end.
What shipped.
A driver can toggle online, see total distance and trips at a glance, accept a request with pickup and destination on a map, and end the trip; an admin can pull up any driver's license front and back and move them from Pending to Verified or Declined.
How it got built.
Mapped the existing phone-based dispatch process to find where it broke down
Designed the online/offline driver state and the request-accept flow with live map tracking
Built the admin verification queue, license front and back, license number, expiry, status change
Added post-trip rating so service quality has a record, not just a memory
How this reaches customers.
Launched alongside GSK Admin by design, admin-only adoption creates a broken network since there's no supply to dispatch against. The sequence: onboard the operational customer, recruit or import the existing driver network, verify drivers, activate them, digitise dispatch, then track delivery performance and expand supply as demand grows.
North star metric.
Supporting metrics
- Recommended North Star going forward: successful completed deliveries per verified active driver, not raw distance or trip totals
- Verification completion rate and time-to-verification
- Job acceptance rate and time-to-match
- Delivery completion rate and driver utilisation
Guardrails
- Licence validity and safety incidents
- Fraud and poor-rating rates
- Location accuracy
The verified bottom line.
Replaced ad hoc phone dispatch with a driver app and a verification queue that both leave a record, who's online, who accepted what, and whose license was actually checked before they got a job.
What I'd do differently.
Verification only works if it's enforced at the point that matters, requiring both sides of the license before a driver's status could move to Verified closed a gap that a policy document alone never would have. The broader lesson that carried into later work: put the constraint in the software, not just the process. This is also a marketplace-health problem, not just a feature problem, more customers without drivers creates bad service, more drivers without orders produces idle supply and churn, supply-demand balance matters as much as feature adoption.
More proof, more products.
See every product shipped and business built.