Every operator that flies crews away from base ends up running a ground-support function whether it means to or not. Someone has to book the rooms, arrange the cars, order the catering, handle the diversion at 02:14 and settle the invoices afterwards. The only question is how that function is organised.
Broadly, there are three answers. Build it in-house, with your own people, your own systems and your own supplier contracts. Buy it piecemeal, from a hotel programme here, a transport company there and a catering contract somewhere else. Or contract one lead partner that owns the platform, holds the standard and coordinates a set of specialists on your behalf.
Each of these is a legitimate choice. Each has been made well and made badly. What follows is an attempt to set out the trade-offs honestly, and to explain why the third model works when, and only when, the roles are drawn clearly.
Building it yourself
The case for building is control. The operator decides the standard, owns the data, picks every supplier and can change anything without asking permission. For a large carrier with a stable network and a long planning horizon, this can be the right answer.
The costs are less visible. An in-house function needs a 24-hour desk, which means a shift pattern, which means a team large enough to cover sickness and leave. It needs a system, which means either a build project or a licence, plus the people to maintain it. It needs supplier contracts in every city the network touches, and someone to negotiate, review and renew them.
Most of all, it needs to be good at something that is not the operator's core business. Running hotels and cars across forty cities is a discipline in itself. An airline that is excellent at flying is not automatically excellent at it, and the people who are excellent at it tend to be working for specialists.
Buying from many suppliers
The case for buying piecemeal is flexibility and price. Each category can go to the best or cheapest supplier, contracts can be short and switching is easy. There is no single large dependency, and procurement can run a clean process for each line.
The cost is coordination. When the hotel, the transport firm and the caterer are three separate contracts with three separate systems, the operations desk becomes the integration layer. Every change has to be pushed to each supplier separately, by whatever channel that supplier uses. Every failure sits in the gap between two suppliers, where each can point at the other.
Accountability is the real problem. When a crew is left on the kerb because the hotel moved the checkout time and the transport firm was not told, whose fault is it? Under the many-supplier model, the answer is usually "the operator's", because the operator was the only party that could see both halves.
Appointing a lead partner
The third model puts one party in front. The lead partner holds the master contract, runs the platform, sets the service standard and settles with everyone. Behind the lead sit the specialists: the accommodation firm with the rooms, the transport firm with the vehicles and licences, the caterer with the kitchens, the handling firm with the ramp.
The specialists keep their own names, their own staff and their own expertise. They are not absorbed into the lead; they are coordinated by it. The operator sees one contract, one system, one invoice and one phone number at 02:00.
One accountable party matters far more than one company trying to do everything.
That distinction is the heart of the argument. The value is not that a single firm owns the hotels and the cars and the kitchens. Firms that try to do all of it tend to be mediocre at most of it. The value is that a single party is answerable for the outcome, and has the platform and the contracts to make the specialists behave as one service.
The honest trade-offs
The lead-partner model is not free of cost. The operator gives up some direct control over supplier choice. There is a dependency on the lead, and it is a bigger dependency than any single supplier would be. If the lead is weak, everything behind it looks weak too.
Data is the other question. Under this model the lead's platform holds the booking history, the journey records and the settlement data. The operator must insist, in the contract, that this data is theirs, that it is exportable and that the platform exposes it through an API rather than a monthly spreadsheet.
Speed and scale are where the model earns its keep. A lead partner that already has licensed operators in a city can stand up service there in days, not months. When a network grows, or a disruption throws two hundred passengers into an unfamiliar airport at midnight, the operator is drawing on a standing arrangement rather than building one in the moment.
Making the roles clear
The model fails when the roles blur. If the lead starts competing with its own specialists, the specialists stop sharing information. If the specialists are allowed to contract directly with the operator, the lead loses the ability to hold the standard. If settlement runs through three different channels, nobody knows who has been paid.
The arrangement that works is simple to state. The lead holds four things: the contract, the platform, the service standard and the settlement. The specialists hold the physical assets and the local licences, and they are paid promptly and predictably by the lead. The operator holds the data rights and the right to audit.
Everything else can be negotiated. Those lines cannot.
Key takeaways
- Building in-house buys control but turns the operator into a 24-hour logistics company in forty cities.
- Buying from many suppliers buys flexibility but makes the operations desk the integration layer and leaves accountability in the gaps.
- A lead partner works when it holds the contract, the platform, the standard and settlement, and the specialists hold the assets.
- The goal is one accountable party, not one company that owns everything.
- Whatever the model, the operator must own its data and have it available through an API.