Multi-base taxi fleet dispatch — running two or more depots as one operation

A single-base fleet has one answer to almost every operational question: one licensing authority, one driver pool, one set of reports, one dispatcher team that knows every regular customer and every regular driver by name. A second base breaks that simplicity in ways that aren't obvious until they cause a problem — a driver licensed under one authority picking up a job that technically belongs to another base's coverage area, a corporate account that gets billed twice because two bases both logged the same job, a licensing-authority audit request that the operator can't answer cleanly because the reporting was never split by base in the first place.

None of this means multi-base operation is a bad idea — geographic expansion and consolidation are both legitimate, often necessary, growth paths. It does mean the operator needs to treat the second base as a structural change to how the business runs, not an administrative footnote added to the existing single-base setup.

Three routes account for most cases. Organic geographic expansion is the most common — a fleet with strong demand in one town opens a depot in a neighbouring one rather than trying to serve it remotely, usually because response times from a single, more distant base were losing bookings to a local competitor. Contract-driven expansion is the second — a corporate, NHS, or local-authority contract requires a physical presence or a faster response time in an area the operator doesn't currently cover, and opening a base is the only way to win or keep the work. Acquisition is the third and often the messiest — buying a smaller operator brings their base, their driver list, their vehicle fleet, and usually their own dispatch system or none at all, none of which was built to integrate with the acquiring operator's setup.

Each route creates a different starting problem. Organic expansion usually starts clean, with the new base built on the same systems as the first. Contract-driven expansion is often rushed, with the new base standing up faster than the reporting and licensing groundwork can properly follow. Acquisition is the hardest, because it usually means migrating an entirely separate driver pool, vehicle fleet, and booking history onto one platform while keeping both bases operational through the transition.

UK and Ireland taxi and PHV licensing is issued by area, not nationally, and that creates a real constraint the moment a fleet operates across more than one licensing authority's boundary. Private hire vehicles, drivers, and operator licences generally need to come from the same licensing authority for a given booking chain to be compliant — a structure sometimes summarised as the 'triple licence' requirement — though the Deregulation Act 2015 gave PHV operators more flexibility to sub-contract bookings to an operator licensed in a different area when they can't fulfil a job themselves. Hackney carriages are more restrictive again: they're generally licensed to ply for hire (be hailed on the street or wait at a rank) only within their own licensing district, even though pre-booked work and drop-offs outside it are usually permitted.

The practical effect for a multi-base fleet: a driver and vehicle licensed under Base A's authority can't simply be dispatched to cover Base B's area as if the two were one licensing zone, unless the specific cross-border and sub-contracting rules that authority applies actually permit it. Rules genuinely differ by council and by whether the vehicles involved are PHV or Hackney, so this isn't something to assume either way — it needs checking with each specific licensing authority a multi-base fleet operates under, ideally before the second base opens rather than after a booking gets flagged.

The console-architecture decision shapes almost everything downstream. Running two entirely separate dispatch systems per base is the default for fleets that grew into multi-base through acquisition and never consolidated — it's the simplest thing to leave in place, but it means no operator-wide visibility, no shared reporting, and no ability to route an overflow job from a busy base to an idle driver at the other one. Running one console across both bases, with base as a first-class field on every driver, vehicle, and booking record, gives an operator whole-operation visibility while still letting each base see only its own working queue day to day.

The middle ground most multi-base fleets actually want is permission-scoped, not system-scoped: one platform, one data model, but dispatcher accounts and reporting views that default to their own base and only surface the other base's detail to roles that need whole-operation visibility (typically ownership, area managers, and finance). That avoids both failure modes — the fragmentation of fully separate systems and the confusion of every dispatcher seeing every base's live queue by default.

Every driver needs a home base as a structural record — the base whose licensing authority, settlement cycle, and local dispatcher relationship the driver primarily sits under. The operational question on top of that is whether drivers can pick up jobs assigned to the other base, and under what conditions. Some fleets run a hard boundary — a driver only ever sees jobs from their home base's queue, full stop, which is the simplest to reason about and the safest against the licensing-geography issue above, but it means idle capacity at one base can't help an overloaded queue at the other.

Other fleets run controlled cross-base overflow — a job that's aged past a threshold in one base's queue becomes visible to eligible drivers at a neighbouring base, provided the licensing and eligibility check passes for that specific driver-vehicle-job combination. This recovers real capacity during uneven demand (one base slammed on a Friday night while the other is quiet), but it only works if the eligibility check is enforced automatically at the point of offer, not left to a driver's own judgement about whether they're allowed to take a job outside their usual area.

Each base is usually separately licensed, which means each base needs its own clean report for its own licensing authority — driver and vehicle credential status, incident logs, complaint records, all scoped to that base's jurisdiction rather than blended with the other base's figures. An operator that only has a single consolidated report for both bases combined will struggle to answer a licensing-authority audit request cleanly, because the authority only wants to see the vehicles and drivers under its own remit.

At the same time, ownership needs the consolidated view — total fleet utilisation, total revenue, driver retention trends, and corporate-account performance across the whole operation, not two disconnected spreadsheets that someone manually merges before a board meeting. The reporting layer needs to support both: base-scoped exports for compliance, and roll-up views for whole-operation management, generated from the same underlying booking and driver records rather than two separate systems that can drift out of sync with each other.

Smaller multi-base fleets often can't justify a dedicated dispatcher team at each depot around the clock, which raises the staffing question directly: shared dispatchers covering both bases from one location, or a dedicated dispatcher per base with a shared on-call arrangement for off-peak overflow. A shared team costs less in headcount but needs a console built to switch context between bases quickly — a dispatcher jumping from Base A's queue to Base B's queue mid-shift needs the same clarity on which vehicles, drivers, and local knowledge apply to each, not a generic view that doesn't distinguish them.

Peak-time coordination is the sharpest edge case: a Friday-night surge that hits both bases simultaneously stretches a shared dispatcher team thinner than either base would tolerate on its own. Fleets that grow past roughly two or three bases on a shared dispatcher model typically find they need either a dedicated team per base at peak times or AI-assisted triage that surfaces the highest-priority jobs across both queues so a stretched dispatcher team isn't manually toggling between two live boards under pressure.

TaxiCloud's Pro Max and Pro Ultra plans carry base as a first-class field across the driver, vehicle, and booking record, with dispatcher accounts scoped to their own base by default and whole-operation visibility available to the roles that need it — ownership, area managers, and finance don't have to stitch two systems together to see the full picture. Cross-base overflow, where an operator enables it, runs through the same licensing-eligibility check that governs any job offer, so a driver never gets shown a job their licence and base combination isn't actually eligible for.

Reporting generates both base-scoped exports for each licensing authority's audit or renewal requirements and consolidated roll-up views for whole-operation management, from one underlying dataset rather than two that can drift apart. None of this replaces the licensing advice a multi-base fleet needs from its own solicitor or each licensing authority directly — TaxiCloud doesn't set licensing policy — but it gives an operator the dispatch and reporting infrastructure to run two or more bases as one coherent operation rather than two loosely connected ones.