The Shadow Infrastructure of the Experiences Industry

The 2023 Arival Guide to Channel Management reports a single load-bearing number. The average experiences operator works with fourteen distributors. The average large operator works with forty-seven. The average attraction works with more than forty, and many larger attractions report working with hundreds of distribution partners.^¹ Each of those relationships, in its raw form, is a one-to-one connection that must be built and maintained on both sides.

Per-operator, fourteen is a large number. At industry scale, it is larger still. The Global Operator Landscape 4th Edition puts the global operator count at approximately 600,000.^² The Technology & Connectivity survey, on a 3,500-plus operator response base, reports that roughly half of operators run some form of booking system: 44% use vendor res-tech and 9% run an in-house system, with the remainder on no formal system at all.^³ The arithmetic of distribution connectivity therefore runs against a denominator on the order of hundreds of thousands of operators and a numerator on the order of the tens of thousands of resellers that collectively sell their product. The position of this essay is that the aggregate engineering labour devoted to building, maintaining and replacing those one-to-one connections is the experiences industry’s shadow infrastructure. Shadow, because it never appears on any single balance sheet. Infrastructure, because the industry does not function without it. The framing has its theoretical home in Star and Ruhleder’s account of infrastructure as a layer that becomes visible only on breakdown, embedded inside the working systems that depend on it.^⁴ The breakdown surface in this industry is the part operators see daily: manual extranets, stale availability, mapping errors, failed API calls, reconciliation work between calendars and manifests, the same integration written twice on either side of the same connection.

The mesh is conserved, not eliminated

The structural logic of channel management is straightforward. Without a channel manager, an operator’s booking system fans out to each reseller individually: one operator multiplied by N resellers equals N connections to build and maintain. With a channel manager, the operator, or more precisely the operator’s reservation system, connects once to the channel manager, and the channel manager holds the mesh of reseller integrations on behalf of many suppliers and many reservation systems at once. Arival’s 2023 channel-management guide visualises this distinction directly.^⁵

A channel manager, in the precise sense of the term, is not itself a reservation system. Many reservation systems route bookings and availability to third-party channels as one feature among many; that functional overlap is not what a channel manager is. A channel manager is a tool whose singular purpose is to route content, availability, bookings and cancellations between suppliers and distribution channels. What it offers in exchange for its position in the stack is twofold. It consolidates access to resellers that would otherwise have to be integrated one by one; and it lets suppliers and reservation-technology vendors share the cost of building and maintaining those reseller integrations as requirements change. The value proposition is not a new sales channel, nor a new booking engine. It is shared infrastructure for a task that would otherwise be paid for many times over.

The important move is to notice what the second picture does not do. It does not eliminate the mesh. It shifts the mesh’s locus. The reseller-side integrations still exist; they have been moved one layer up, into the channel manager’s own engineering backlog. The operator has been spared a per-reseller integration; the channel manager has not. At industry scale, the mesh is conserved. The cost has moved. It has not disappeared.

The cost the industry under-reports

Per-integration engineering cost, in the publicly available Arival data, is expressed indirectly. The Technology & Connectivity survey records how operators actually manage distributor bookings: extranet (47% of tour operators, 41% of activities, 31% of attractions); email (37%, 39%, 27%); booking-system API (33%, 46%, 27%); channel manager (8%, 18%, 27%). Extranet and email are, by any definition, manual. Arival’s own characterisation of the finding reads: “distribution connectivity remains fragmented and in many cases manual, despite significant efforts by booking systems and distributors to advance direct API connectivity with operators.”^⁶

The implication of those shares is not that API connectivity is impossible. It is that, for most operators below a certain size, the per-connection engineering cost exceeds the per-connection operational value. At the scales at which most operators trade (Essay 1 established the benchmarks: 86% under $250,000 in annual revenue, 50% with fewer than five years of operating history), direct API connectivity is not affordable. The cheaper substitutes, hand-managed extranets and email, take its place. API penetration correlates strongly with operator size: the same Arival survey reports 59% of large operators (above 10,000 annual guests) using an API, against 29% of small operators.^⁷ The integration tax is not evenly distributed. It is concentrated in the upper tail.

Integration is rent, not capex

Integrations are not permanent. APIs version. Authentication schemes evolve. Rate limits change. Endpoints deprecate. Every integration is a live relationship, subject to re-work on a multi-year cadence on both sides. The familiar operator-side mental model, that the integration is a capital expenditure to be made once and amortised over the life of the distribution relationship, is wrong. The integration is not capex. It is rent. The framing is consistent with the long-established finding from Brooks and the software-engineering literature that maintenance and evolution dominate the lifecycle cost of any non-trivial software system, often by an order of magnitude over initial build.^⁸ Integrations are not exempt from this; if anything, they are a sharper case of it, because both sides of the connection are evolving in parallel.

The rent is paid on both sides of every connection: the operator-side cost (or, more commonly, the booking-system vendor’s cost, internalised into the vendor’s SaaS fee), and the reseller-side cost (or the channel-manager provider’s cost, internalised into distributor-side fees and platform-level engineering budgets). The aggregate is genuinely large. The reason no research firm has published an industry-wide total is not that the total does not exist; it is that the cost is distributed across thousands of engineering backlogs, none of which is labelled “integration tax.” That atomised incidence is the distinguishing feature of shadow infrastructure. It is not absent from the industry’s economics. It is invisible in the industry’s accounting.

A conservative order-of-magnitude construction, clearly labelled as construction rather than a sourced total, makes the scale legible. Take the 600,000-operator base from the latest Global Operator Landscape; apply the roughly 54% booking-system-adoption rate; apply the 14-average-distributors-per-operator figure (which likely understates, because larger operators pull the mean sharply upward); assume a mix of direct-API, extranet, and channel-manager-mediated connections; apply multiple engineering-weeks per full integration on each side; apply a multi-year half-life for maintenance, version churn, and replacement. The arithmetic produces a figure in the low-to-mid hundreds of millions of US dollars per year at industry level, and that range is best read as a lower bound. The construction does not capture the reseller-side and aggregator-side engineering labour in full, nor the opportunity cost of the engineering time itself. A more complete accounting would land higher. This is not a sourced number; it is an order-of-magnitude argument built from per-operator data points that are. The point is not the specific figure. The point is that the figure is material at industry scale, and that the industry has never formally added it up.

Why standardisation has not settled it

In airlines, a standard settled the distribution-connectivity problem in the 1970s through the GDS architecture and IATA’s settlement infrastructure. In hotels, partial standardisation through the property-management-system-to-switch-to-distributor pathway reached sufficient adoption to contain the problem over the 1990s and 2000s. In experiences, standardisation has been attempted twice, and a neutral specification exists today.

The first attempt came from outside the category. The OpenTravel Alliance was founded in 1999 by a consortium of airlines, hotels, car-rental companies and travel-software vendors, with the stated purpose of building an XML-based messaging specification for electronic communication between disparate travel systems.^⁹ Its first release appeared in 2000; its object-model 2.0 release, adding JSON support, followed in 2016. OpenTravel progressively expanded its coverage into rail, cruise, golf and, from 2008, tours and activities, with the tour-operator messaging built into a live implementer’s system in 2009 and described at the time as a first-of-its-kind standards-based connection integrating tour operators into the broader online travel market.^¹⁰ The commentary surrounding that release explicitly identified the tour-and-activity segment as the long tail of online travel, most of which had little or no ability to connect online with other suppliers or distributors.^¹¹

Tens of thousands of OpenTravel messaging structures remain in use in the upstream segments (airline, hotel, car rental) the specification was built for. In tours and activities, adoption never crossed the threshold that would eliminate the bespoke integration layer. The reasons reward close attention. OpenTravel’s governance and technical agenda reflected its founding constituencies, whose own distribution problems were already substantially solved; tours and activities were an addition to the agenda, not its centre of gravity. And the supply side of the experiences segment, then as now, was too atomised for the OpenTravel membership to sustain a coordinated push into it.

The second attempt originated inside the category. OCTO (Open Connectivity for Tours, Activities and Attractions) was formally established as an industry association in October 2022.^¹² Its first specification (OCTO 1.0) was published in mid-2023; its next major version (OCTO 2.0, with enhanced pricing models and improved booking flow) has been in community review through early 2026.^¹³ OCTO is a 501(c)(3) non-profit, governed by an industry-led board drawn from across the category, and the specification and its documentation are free. It does not operate an API, a channel manager, or connectivity infrastructure itself.^¹⁴ Its technical coverage is comprehensive for the category, spanning products, availability, bookings, pricing, supplier management, pickup and drop-off, and authentication.

OCTO is, by any reasonable standard, a credible standardisation effort. By a figure OCTO itself reported in 2023, 114 trading partners worldwide were working through the specification within its first year.^¹⁵ And yet, four years after its formal launch, most of the industry is not yet connected through it. The specification exists; adoption has not reached the threshold that would eliminate the bespoke integration layer.

This is not a criticism of OCTO, which is doing everything a standards body can do. It is an observation about the structural conditions that produce industry-wide standardisation in adjacent categories, and the extent to which those conditions hold in this one. Historically, industry-wide standardisation has required at least one of three forces: a dominant player whose scale compels compliance (the airline-GDS case); a regulator with standing over the interchange (the banking ISO 20022 case); or a cooperative adoption threshold, at which a critical mass of major participants converges simultaneously and the remaining holdouts are forced to adopt or be excluded.^¹⁶ Experiences has none of the three in the shape the adjacent industries had. The supply side is too fragmented for any single participant to force compliance, for the reasons Essay 2 established. No regulator has standing over industry-wide distribution APIs. And the cooperative-threshold condition has not been met, because the individual incentive for each participant to maintain its own integration relationships has so far been stronger than the collective incentive to converge.

There is a sharper version of that last observation worth making directly. The category’s largest online travel agents and attraction-side platforms have, over the past decade, invested substantially in proprietary connectivity stacks of their own. Those stacks are, from the platform’s own vantage, competitive assets rather than neutral pipes: the engineering investment is sunk, the reseller-side and supplier-side integration portfolio is extensive, and in several cases the connectivity layer is actively positioned as a source of advantage over smaller distributors. In that frame, a neutral specification is not merely redundant; it is strategically undesirable, because it lowers the distribution-integration cost for competitors who have not made the same investment. The participants whose adoption would most plausibly trigger convergence are, on their own unit economics, the participants with the strongest individual incentive not to converge. This is incentive analysis, not a charge of bad faith: rational actors with sunk investment in proprietary stacks face a different convergence calculus from actors without it. Until that calculus changes, mass adoption of a neutral specification will lag, whatever the technical merits of the specification itself.

That is the structural reason the integration tax persists. A neutral specification exists and is available. The forces that would otherwise produce industry-wide adoption are weaker in this industry than in the adjacent industries a reader might assume comparable, and the actors with the most leverage to move the market toward convergence have the clearest reason not to.

The two counter-arguments

Two counter-arguments deserve to be named directly.

The first is that every industry has integration overhead, and that this is simply the experiences-industry version of a normal cost of doing business. The response is a question of order of magnitude. The average experiences operator maintains an order of magnitude more distribution relationships than a typical hotel; it does so without the convergent standard that hotels reached over two decades; and the median operator sits so far below the scale at which conventional integration economics work that the cheaper substitutes (email, extranet, manual posting) remain in broad daily use. The problem is not that experiences have integration overhead. The problem is that the scale, churn rate, and distribution of that overhead are non-normal.

The second counter-argument is that integration is just the normal IT cost of running a software business, absorbed into a SaaS vendor’s P&L like any other engineering expense. This is partially true for the individual vendor. What it misses is that the cost is not contained inside one vendor’s P&L. It is spread across operator-side vendors, reseller-side vendors, channel-manager intermediaries, aggregator engineers, in-house operator teams, and distributor-side IT departments. The atomised incidence is the distinguishing feature. Atomised incidence is not the same thing as small cost.

What comes next

The useful question, accepting the shadow-infrastructure frame, is no longer how any individual operator can reduce its integration overhead. That question is bounded by the per-connection engineering cost, which is itself determined by a standardisation environment the operator does not control. The useful question is what the industry stack looks like if the shadow infrastructure is priced honestly, engineered once, and maintained at scale by actors whose economics do not depend on capturing the adjacent distribution flow. What the shape of such a layer would be, and whether it is emerging, is the question the essays that follow take up.

Before that question can be addressed well, the reader needs a concrete picture of what actually happens in a single booking: the systems it touches, the API calls it generates, the data-format translations it requires, the latency budget it operates within. The next essay traces one. The shadow infrastructure becomes legible when you watch it work.

The industry has been paying for this plumbing out of thousands of separate engineering budgets, for more than a decade, without ever adding up the bill.