It's a busy Saturday, and your fleet has eight confirmed bookings but only six vehicles free. The usual choice is to turn down the two extra jobs and lose that revenue, or hand them off to a trusted operator in exchange for a finder's commission. The second option only works well if, before that Saturday arrives, you've already agreed in writing who's accountable to the passenger if something goes wrong.
What a dispatch pool actually is
A dispatch pool is a mechanism where an operator who can't cover a job offers it to a network of partner operators, and whoever accepts it first takes the ride in exchange for paying a finder's commission to the original operator. It's the exact same pattern a fleet already uses internally to assign jobs among its own drivers (closest driver first, widen the search if nobody accepts), just applied across separate companies instead of across your own drivers.
The finder's commission
The typical commission runs between 10% and 20% of the job's value, and it varies based on three factors:
- How much lead time there is before the job: the less room to maneuver the accepting operator has, the higher the commission they'll usually ask for taking on last-minute risk.
- How detailed the information is that gets shared (exact route, vehicle type required, passenger specifics) versus a generic job that requires figuring things out on the fly.
- Whether it's an ongoing relationship between the two operators or a one-off handoff: a stable relationship with volume flowing both ways tends to bring the commission down compared to an isolated handoff.
Who's accountable to the passenger
This is the question that has to be settled before the first handoff, not after the first incident. There are two models:
Model A: the original operator stays the visible party
The passenger booked with you, gets the confirmation under your brand, and if anything goes wrong, they complain to you. You, in turn, hold the accepting operator accountable. This model protects your customer relationship better, but leaves you exposed if the operator who took the job drops the ball and the passenger has no idea who they actually are.
Model B: the accepting operator becomes directly responsible
The passenger is told the ride is being handled by a different operator, with that operator's own contact details for the day of the ride. It's more transparent and spreads the risk better, but it dilutes your relationship with that customer for future bookings.
Most dispatch pools that work well use a version of Model A for one-off jobs (the customer is yours, the execution is outsourced but under your oversight) and only move to Model B once the relationship with the partner operator is mature enough to trust them as the visible party to the customer.
What happens if the other operator drops the ball
This has to be agreed on beforehand, not improvised on the day of the incident:
- Minimum notice window: if the operator who accepted the job can't cover it after all, how much minimum notice do they owe you so you can react, reassign internally or put it back in the pool?
- Who absorbs the cost of an emergency reassignment, if you end up having to pay more to secure a vehicle at the last minute.
- A penalty for repeated failures: an operator who drops the ball once is a mishap; one who does it repeatedly is a partner to stop working with, and that line has to be defined with a concrete number, not a vague "we'll see."
What data gets shared, and what doesn't
| Data | Shared | Not shared |
|---|---|---|
| Route, time, vehicle type | Yes, always | |
| Passenger name and phone | Only if Model B applies, or to run that day's ride | Your full customer database |
| Price agreed with the passenger | The value of the handed-off job, yes | Your general pricing structure or margins |
| The passenger's history of other rides | No | Always kept out |
The most important boundary is the last one: handing off a ride doesn't mean handing off your customer base. Share what's needed for the partner operator to run that specific job, and nothing more.
When it's worth formalizing a pool instead of relying on one-off favors
A single phone call works fine for an occasional handoff, but it stops holding up once the cross-volume between two operators grows past a few jobs a month. Three signals suggest it's time to formalize:
- The same operator keeps showing up on the other side of the handoff: if they're already a regular partner, a standing agreement with fixed terms saves you renegotiating the commission every time.
- Demand spikes are predictable: holidays or peak season, where it pays to have already agreed who can absorb the overflow instead of scrambling for an available operator at the last minute.
- Jobs flow both ways: when the volume runs in both directions, it makes more sense to net the commission out monthly than to invoice every single handoff separately.
A formal pool with several partner operators, each ranked by a priority level based on their track record, is the mature version of what starts out as a favor between two people who trust each other.
What to do next
If you're already handing off jobs informally to other operators (a phone call, a favor, "I'll return it another day"), formalize three things in writing before your next demand spike: the finder's commission tied to lead time, who's accountable to the passenger, and the minimum notice window if a partner operator fails to deliver. A dispatch system with a cascading pool, like the one described in when a fleet outgrows WhatsApp and spreadsheets, applies this exact same logic inside your own fleet first, before you ever reach out to other operators. TransfersManager includes a dispatch pool with cascading levels, for your own fleet and for outside partner operators alike, with a record of who accepted each handoff.
