Zeelo. Turning a compliance process held together by email and goodwill into something that works at scale.
Intro
I knew nothing about bus operator compliance when this landed on my plate. Operator licences, OCRS records, insurance certificates — the paperwork stack that sits between a vehicle and a paying passenger. I learned it the way you learn most things in an ambiguous problem space: by talking to everyone who'd let me, building a picture from the edges inward, and slowly working out who actually owned what.
What
0→1 internal compliance platform connecting operator onboarding directly to Zeelo's Mission Control ops system.
Why
Operators were tracked across four fragmented systems — Pipefy, spreadsheets, email, Google Drive — with no source of truth.
Stage
0→1. Internal platform. Shipped to 230+ operators over 12–18 months following launch.
My role
Product design lead. Sole designer. End-to-end: discovery, systems thinking, IA, UI, testing.
The problem wasn't the paperwork. It was that nobody could see it.
The problem
What research actually showed.
I ran discovery sessions with Melissa Parnaby (Operations Specialist), Alice Lane (Senior Operations Manager South), and Tom Kinsey (Senior Operations Manager North). The brief started as 'improve onboarding.' The sessions sharpened it fast.
Melissa described tracking operator information across four parallel systems simultaneously — Pipefy forms, spreadsheets, emails, and Google Drive — none of them complete. Ops specialists had no reliable way to know where any operator stood at any point in time. The default was chasing: emails, calls, more emails. Sometimes operators started running trips before their compliance was confirmed.
Visibility, not speed.
Nobody knew operator status without manually chasing. Speed wasn't the problem — clarity was.
Four parallel systems.
Pipefy, spreadsheets, email, and Google Drive. None of them the source of truth. All of them in use simultaneously.
No audit trail.
When something went wrong, there was nothing to refer back to. No record of who approved what, or when.
Real liability.
In the US, if a driver is in an incident, it's on Zeelo directly — not the operator's insurer. Compliance wasn't administrative. It was legal exposure.
We just need one place where everything lives instead of chasing emails.
Melissa Parnaby, Operations Specialist
Context
One system, not two.
Zeelo runs corporate transport without owning a single bus. Operators bring the vehicles and drivers. Zeelo brings the routes, the clients, the coordination. The operator portal connects directly into Mission Control — Zeelo's internal ops platform. The two systems are one system.
Which meant this wasn't a standalone onboarding tool. It was the entry point to the entire operational relationship between Zeelo and the operators it depends on. My manager's opening question wasn't 'fix the onboarding.' It was: what does this product look like in three years? That vision shaped every scoping decision that followed. None of it works without a clean foundation. The first thing to design was the ground floor.
Onboarding isn't a signup flow. It's the first chapter of an ongoing compliance relationship.
The reframe
Designing it as a system, not a form.
The brief had framed it as a form to fill in. Research made clear it needed to be a pipeline with state, visibility, and a feedback loop — one that served both the operator completing it and the ops team reviewing it.
Before touching screens, I mapped the system: what an operator profile must carry, how compliance state flows between the portal and Mission Control, what Zeelo ops needs to see without opening a single record, what happens when a document is rejected and why that rejection has to carry a reason.
Design decisions
Three decisions where something real was in tension.
Collect everything upfront, or stage it?
The first prototype asked operators to provide full compliance data during onboarding — insurance details, coverage amounts, expiry dates, vehicle documentation. Usability testing killed it fast. Operators hesitated, got stuck, dropped off. Too much to have ready in one session. We moved to progressive disclosure: onboarding collected only what was needed to vet and activate. Compliance documents moved to a dedicated portal phase after the operator was in the system.
Self-serve or ops-assisted?
Keeping ops in the loop at every stage felt safe. It was also exactly the bottleneck producing the problem. We went self-serve with guardrails: a gated three-stage flow, progress saving throughout, a notification centre surfacing outstanding tasks with deadline countdowns. Ops kept document validation — removed from the chasing, not from the process. The work they'd been doing in email moved into Mission Control, where it was trackable.
The rejection note
When a document failed validation, the original design marked it rejected and stopped. I pushed for a mandatory written note from ops explaining why. Engineering pushed back — close to the edge of what could ship in the first release. I held on it. Without a reason, operators re-upload the wrong version. Another review cycle. Another round of emails. The note was the thing that made the loop close without a phone call. It stayed.
UK and US flows
Two countries. Two flows. One shared foundation.
UK and US compliance requirements differ enough that a single generalised form would have required operators to self-identify applicable fields mid-flow. We built two distinct flows — shared components, different requirements. The US liability difference made getting this right non-negotiable.
In the US, if a driver is in an incident, it's on Zeelo directly — not the operator's insurer. The US flow includes a Certificate of Insurance section with Zeelo's address pre-filled as certificate holder, so operators know exactly what to upload and why.
Getting the onboarding right
Tested with real operators before anything was built to stay.
I ran sessions with four UK operators — Landflight, Centrebus, Wheelers, and Charlise — from a corner of the open office. No meeting rooms available, which kept things scrappy. But the insights were real.
The structure validated in testing. The specific labels didn't.
The MPOC field caused confusion.
Nobody immediately understood the distinction between Main Point of Contact and Main Point of Contact for Quotes. Fix: progressive labelling. First instance showed the full term with the abbreviation in brackets. Subsequent uses showed MPOC with an info tooltip on hover. Operators learned the term once, and the shorthand worked from there.
Fleet size terminology needed work.
Operators weren't sure whether 'coach' and 'bus' referred to the same vehicle type. Labels were clarified with plain descriptions. Both changes confirmed in testing before anything shipped.
Mission Control
A pipeline view without opening a single record.
For Zeelo Ops inside Mission Control, I added an onboarding status pipeline to the operator list: Invited → Details required → Docs required → Compliant. Filterable by stage. A full pipeline view across every operator without opening a single record.
These four states came out of working sessions with ops — we explored more granular options and simplified to what was actually actionable under real workload. After onboarding, operators land in the portal. The notification centre surfaces outstanding compliance tasks with deadline countdowns — they know what's missing, when it's due, what to do next. Every document carries a timestamped record of who approved or rejected it and why.
What I learned
The gap the data made visible.
Responsibilities for compliance were split across ops, customer success, and account management in ways nobody had written down. A chunk of discovery time went into mapping that before anything could be designed — figuring out who owned what, who needed to sign off what, where the handoffs actually happened. That should have been the first conversation, not something uncovered gradually.
The operator portal shipped without usability testing. The onboarding flow was tested and iterated — four operators, real sessions, specific changes made as a result. The portal itself, where operators manage compliance documents after onboarding, didn't get the same pass. It worked. But I don't know how much better it could have been.
That's the honest gap: I designed a system for an ongoing relationship but only tested the entry point. Everything from document upload onwards was built on research inference rather than direct observation. That's the part I'd go back to first.
What's next
Two honest bets, both measurable against specific behaviours.
Driver-level compliance.
Hypothesis: giving operators visibility into driver document status inside the portal will reduce the ops touchpoints currently required to chase individual driver DBS checks and licence renewals. Measure: reduction in ops-initiated driver compliance contacts per week.
Portal usability testing.
The compliance portal shipped without a usability pass. Before any new features are added, the right next step is running the same testing rigour on the post-onboarding experience that shaped the onboarding flow. Measure: task completion rate and error frequency on compliance document upload flow.
