When the booking goes to someone else's driver

Passing an overflow booking to a subcontractor or partner fleet solves the capacity problem. It creates a tracking problem: who actually drove it, at what rate, and whether the payout ever got reconciled.

The problem

Demand does not stop at the edge of the fleet. A hotel sends more guests than there are free cars, a corporate account needs three pickups at once, or a partner agency's programme simply exceeds what the operator owns outright. The booking still has to be covered, so it goes to a subcontractor: another company's driver and vehicle, working under the original operator's commitment to the client.

Once the ride leaves the owned fleet, the record-keeping usually leaves with it. The subcontractor's rate was agreed by phone or a WhatsApp message, not written against the booking. Nobody logs which bookings actually went out versus which ones a driver on the roster covered. At month end, reconciling who gets paid what means reading through a chat history instead of a ledger, and a rate agreed once in September quietly becomes the rate for every booking after it, correct or not.

How 8Move handles it

A booking that goes to a subcontractor carries that fact from the moment it is assigned, not as a note added afterward: which partner fleet took it, at the rate agreed for that partner, distinct from the rate quoted to the client. The margin on a subcontracted ride is visible immediately, because the cost side and the revenue side sit on the same booking record instead of living in two different places. This is Transfer Booking's affiliate operations layer: partner routing, GPS visibility on the affiliate's vehicle, and settlement that posts at trip completion rather than at month-end reconciliation.

Partner rates are recorded once against the partner, not re-typed per booking. At the end of the period, each subcontractor gets their own payout statement, built the same way consolidated partner invoicing builds a statement for the partners sending bookings in, just running in the other direction: money going out to the fleets that covered the overflow, instead of money coming in from the agencies that sent it.

What this looks like by industry

The same problem reads differently depending on the work. These are the segments it hits hardest.

Airport Transfer Dispatch SoftwareA gateway city partner takes the overflow from a delayed wave of arrivals the local fleet cannot reach in time. The subcontracted rides are flagged the moment they are assigned, so the partner payout at month end does not depend on anyone remembering which pickups were not the operator's own cars.Event and MICE TransportA conference needs forty pickups in a two-hour window and the owned fleet covers twenty-five of them. The other fifteen go to two partner fleets, each at its own agreed rate, and the event invoice and the two payout statements both build from the same set of bookings.B2B Transfer Booking PortalA travel agency's programme books more volume for one week than the roster can cover. The extra bookings route to a subcontractor fleet at its own rate, and the client-facing booking and confirmation stay the same regardless of which fleet actually drove it.

Questions operators ask

The booking carries a flag for which fleet is covering it, and a separate payout rate for that fleet, distinct from the rate quoted to the client. Otherwise the booking and tracking the client sees are identical.

Yes. Each partner in the directory carries its own commercial terms (by city, airport, or vehicle class) rather than one flat rate for every subcontracted ride.

Not unless the operator chooses to say so. The booking and pickup the client sees stay the same regardless of which fleet actually covered the ride.

Each subcontractor fleet gets its own statement covering every ride assigned to it in that period, built from the same booking records as the client-facing invoice, not from a separate manual tally.

It runs the other direction. Consolidated partner invoicing bills the agencies and hotels that send bookings in. This is money going out to the fleets that cover the overflow, using the same per-period statement logic.
Request a demoAll solutions