Selling the seat is standardized. Delivering it is not.
The tours and activities industry now has an open connectivity standard. It is called OCTO, it is a non-profit specification, and more than 130 resellers and technology providers are using it. If you have spent any time waiting on a custom integration, that is genuinely good news.
It is also the clearest evidence I have found for something I have been arguing from the inside of one operation.
Here is the entire capability list, core and optional:
Supplier. Products. Availability. Bookings. Pricing. Notifications. Content. Pickups. Dropoffs. Promotions.
Read it twice. Every one of those is about selling a seat and telling somebody where to stand.
Now here is what is not in it. Crew. Guides. Qualifications. Vehicles. Equipment. Maintenance. Permits. Worker scheduling. Resource assignment. Not deprioritized, not in draft. Absent.
That is not a criticism
Distribution was the right first problem. It was the expensive one, the one with an obvious buyer on both sides, and the one where a standard pays off immediately because every reseller connection you do not have to hand-build is a reseller connection you get for free. A standard exists because enough people had the same painful integration.
So the industry standardized the answer to how do I sell this seat.
It has barely started on how do I actually deliver what was sold.
I do not think anyone decided that. It is just where the money was pointing.
The market underneath this is enormous and still mostly offline
Arival and Phocuswright put global travel experiences at $271 billion in gross bookings in 2025, growing toward $342 billion by 2029, an 8 percent annual clip against 5 percent for travel overall.
And only 33 percent of those bookings happened online, against 64 percent for travel as a whole. Online was 17 percent in 2019 and is projected at 42 percent by 2029.
So: a very large, very fragmented sector with most of its digitization still ahead of it. That is the setup for an architectural change, not an incremental one.
The ground is less settled than it looks
Arival surveyed about 7,000 operators for its 2025 booking technology study. The finding that stopped me: 40 percent of them run the business with no booking system at all.
Not an old system. None.
Among the ones who do have something, the market is so fragmented that when respondents were handed a list of the 50 leading systems, 15 percent still chose “other” and wrote in about 300 more names.
On satisfaction, Arival’s own section heading is “Are Operators Happy with Their Tech? Sort of,” which is about the politest way to put it. For software with this much switching friction, landing on “sort of” is remarkable. People do not casually migrate a reservation system. Leaving means moving the payments, the history, the website and the distribution at once, so operators stay through a great deal of irritation.
That is not a settled category. That is a category where nobody has won yet, in a sector where two thirds of the money still does not book online.
What changed is the comparison
Booking software originally won because the alternative was a phone, a paper calendar, a spreadsheet and a card terminal. Against that, a reservation system is so obviously better that operators accepted a lot of dependence to get it. I have written before that the software genuinely earned its place, and I still think that.
But that is no longer the comparison.
The comparison is becoming a closed system you have to sit inside, against a system of record that anything you own can read from and write to.
That is a much harder argument for a closed product to win, and it does not depend on the closed product being worse at bookings. It can be better at bookings and still lose, because bookings stopped being the part the operator spends their day on.
Where I think this splits
Three postures, and I am describing them generically on purpose, because I am a customer in this category and I would rather argue with the architecture than with anyone’s roadmap.
The closed suite. We have everything you need, and here is our assistant. This will keep working for operators who want one throat to choke, and it will get steadily more frustrating for anyone whose operation does not look like the average.
The open system of record. We handle reservations, inventory, payments and transactions extremely well, and you connect whatever you want to it. I think the strongest products end up here, and some are visibly moving.
Agent-native. Object models, permissions, events and actions designed from the start for software to operate, not just for a person to click. Nobody is finished, but the direction is legible.
The tension is that posture one protects switching costs and posture two erodes them. A system of record with clean exports and full write access is easier to leave. That is a real business reason to keep the doors narrow, and it is worth naming rather than pretending vendors are being lazy.
You can already see the incentive showing up in pricing: fees on API bookings have become increasingly common across the category. Charging for the connection is a rational response to a world where the connection is the product. It is also a tax on exactly the architecture operators are moving toward.
MCP is not the revolution
I want to correct my own emphasis here.
I have written about agents needing somewhere to stand and cited MCP as the emerging way software exposes itself to them. That is true, and it is also too narrow. MCP is one interface. Tomorrow it is MCP plus OpenAPI plus event streams plus whatever settles.
The revolution is not the protocol. It is that software is becoming something other software operates, and the operator interface stops being a screen a human logs into.
The old product was: log into our software and run your business here.
The emerging product is: your software is the authoritative record, and people and their agents operate across it from wherever they already work.
That changes what a booking system competes on. If my own layer can reach twelve systems, I do not want twelve proprietary assistants. I want one that can use all twelve. Which means building a more elaborate assistant inside the dashboard is, strategically, the wrong direction. It is defending the screen at exactly the moment the screen stops being the moat.
What I would actually evaluate
If I were choosing a system today, I would spend very little time on the next twenty-five dashboard features and almost all of it on five things:
API coverage. Can I read every object that matters, or only the ones the vendor considered interesting?
Write access. Can something other than a person change what needs changing, and how much of the model does that reach?
Events. Does the system tell me when something changed, or do I poll it and hope?
Permissions I control. Can I say this agent reads manifests and never issues refunds, that one assigns crew and never touches pricing? Permissions have to live where the data lives or they are theatre.
Portability. Can I take my history, my customers and my operational data out without asking nicely?
Those five decide whether a system can participate in the next architecture or becomes the thing you eventually have to replace. None of them show up in a feature comparison.
The sharpened version
I have been saying booking software needs a write path. That is right but small.
The better version: reservation software is becoming infrastructure, and the next control point in vertical service software is the agent-accessible operations layer that turns reservations into executed work.
Tours are just an unusually clean demonstration, because one booking detonates into a dependency graph. A customer books. Now produce a guide, a boat, a vehicle, a driver, a permit, food, waivers, medical information, camping equipment, a shuttle, a timing plan, communications, payroll consequences, capacity, and a backup plan for the weather.
The booking system sees the transaction.
The operation sees the world.
What changed is that reasoning over that world finally got cheap enough to be worth doing. The standard the industry built tells you where the attention went. The gap it leaves is the same one I ran into with a whiteboard, and it is still the interesting part.