Handing a Ride to Another Operator: How a Dispatch Pool Works and What to Agree First

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 finder's commission is charged by the operator who sources a job and hands it to another one, and it is a percentage each operator sets (in TransfersManager it is editable). It is not the platform fee, which is a separate thing: each operator pays TransfersManager for online payments according to their plan. The finder's percentage usually varies based on three factors:

1. 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.
2. 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.
3. 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.

admin.transfersmanager.ai/rides/service-pool

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

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.

And if what interests you is the other side of the same table, taking on jobs from operators who are stretched instead of handing yours out, that is covered in full in how a dispatch pool works for the receiving operator. And if you want to see the criteria that decide who each job is offered to (profitability, partner reputation, your own fleet first), they are set out in the automatic dispatch pool.