OCTO standards in sightseeing – the case for and against

Niche topic, perhaps only of interest to technologists, however…. lets summarise the case for and against OCTO standards.

What are the OCTO standards?

When you connect a rez tech with an OTA, you have to make the product data continually align between the two platforms.

This is tricky, e.g. on booking cancellation terms, how are they commercially set, what rules do we all want to support? Or when a tour operator changes a price, how is this news updated to the OTA retailer, is it instant, is there a delay, is the accurate price checked prior to the retailer taking a booking at the correct new price? What happens if they retail at the former price?

To save endless conversations per connection, these are standardised over the sightseeing industry. The end objective is that enabling system to system connectivity is just as simple as throwing a switch, rather than a commercial connection requiring discussion, development, testing and ongoing maintenance.

Details on the OCTO standards – https://www.octo.travel/ and the actual standards – https://docs.octo.travel/docs/octo/r6gduoa5ah5ne-octo-api

What is my interest in this area?

My background in connectivity is as one of the early sector leaders, but less hands on in recent years:

• Rez tech (TourCMS) to OTA – did the first rez tech integration – Expedia, Veltra, HotelBeds, TourRadar (mutltiday), GetYourGuide (v1 of their connectivity when they connected to rez tech)
• Rez tech (TourCMS) > downstream (TourCMS can check availability of downstream services prior to saying to an upstream OTA distributor that a product is available, i.e. TourCMS acting as a channel manager)
• Travel agent (Autoura) to channel manager distributor, as the top level recipient of all product data, in my current biz

i.e. I have done integrations from all 3 possible perspectives. And when I said did them, I lead the commercial discussions, designed the interfaces and wrote the code. Can anyone else say they have done this from all 3×3 primary perspectives? 😉

I know first hand that this stuff is fiddly and requires serious expertise, but its not too lengthy (with the small number of connections there are in the sector), think 3-5 days per connection.

(This depends upon what needs to be connected with any integration – dates, prices, availability, descriptions & images, bookings, cancellation – not everything needs to be supported by each connection on day one or ever)

Case for OCTO

• Perhaps we can reduce the 3-5 day connection development time to a 2 hour basic integration test
• Minimises ongoing maintenance burden – much easier having 10 connections on 1 format, than 10 connections on 10 formats
• Any cross industry collaboration is good
• Brings the laggards on connectivity upto modern standards, but perhaps not cutting edge standards where the leaders are at
• Perhaps some areas we used to innovate on (e.g. dates / prices / availability / bookability), we are now all agreed that we are tapped out, there is no more significant innovation to do, so lets just agree some basic standards, and get back to competing on innovation on the other areas such as customer profiles, discovery & personalisation
• Begins the long-term process to merge the OTA layer and the rez tech layer into a single cohesive unit – a process that will become necessary for every OTA over the coming decade as they evolve to become Digital Experience Platforms (DXP)

Case against OCTO

• Reduced friction will likely evolve the sector to winner takes all over time – a supplier can leave one rez tech, join another, and reconnect their upstream OTA connectivity quickly. When any sector becomes winner takes all, commercially this enables the winners to lock in their position, counter to the original objective that standards makes it more of an open playing field. Perhaps the currently fragmented state is preferable for startups who have new ideas on how things should be done within the existing accepted industry framework for dates, prices, availability & booking
• It’s inward facing, instead perhaps we should be looking outward, e.g. DIF standards, where its all about connectivity with hotels & airline sectors. DIF is not mutually exclusive with OCTO, indeed very little overlap at all, however its certainly competing for the same executive time
• Do you want OTAs and rez tech to wrap up into a single cohesive unit? If you don’t, then this is a strong point against OCTO.

Where do I stand?

Personally I think the merge between OTAs and rez tech, although not welcome by everyone, is now inevitable. There are hundreds of billions of automotive sector USD going into the Brand>Digital Experience Platform>Attraction/tour guide industry model, vs hundreds of millions USD of sightseeing sector VC going into the OTA>Rez tech>Attraction/tour operator model.

The existing industry model just won’t be able to hold back that pressure, and OTAs, attractions, activities & tour guides don’t care (enough), as for them its pretty much business as usual. Only the rez tech and (urban) tour operators are seriously impacted.

Would I standardise ahead of that imminent transition?

Probably not. With the new industry model, the OTA>rez tech interface is subsumed as an internal standard within Digital Experience Platforms so doesn’t need cross industry discussion and collaboration. It will just be one engineer talking to another engineer, from within the same company. Or it may just be a singular database, so no connectivity required at all (!)

However OCTO is a good toe-in-the-water test for cross industry collaboration in the short term. Maybe later OCTO becomes the neutral group that enables discussion and implementation around medium term issues such as the collective transition to Digital Experience Platforms (DXP).

Image: Stable Diffusion AI