Does a Channel Manager Need Another Channel Manager? Not Quite.

Something interesting occasionally happens when you build software.

You spend a long time developing a system, solving one problem after another, until eventually you reach an obstacle and discover that someone else arrived at almost exactly the same problem years before you did. And then built a company around solving it.

While developing CM Plus and CM PRO, we recently reached exactly such a point.

From a Calendar to a System CM did not begin as a business plan for a new hotel PMS. Its origins were much simpler.

We needed a better way to manage our own accommodation property. First, the calendar mattered. Then reservations. Then prices, offers, inquiries, occupancy, guest communication, arrival and departure rules.

But once we started actually using the system, new questions appeared.

• What happens to a reservation that has not yet been fully confirmed?
• When should a period be temporarily held rather than permanently occupied?
• What is the difference between a paid reservation and an occupied period?
• What happens when an offer or reservation expires?
• And, perhaps most importantly:
• Which system is the actual source of truth for availability?

Slowly, what had started as a calendar became a system.

Today, CM Plus is already performing real work in accommodation management, while CM PRO is being developed as a considerably broader evolution of the original concept.

Independent modules have also grown around the CM core. Guestbook handles guest data and legally required guest registration and reporting.

Financing connects reservations with financial records, tax reporting and, gradually, government information systems.

But there is an important architectural principle behind these modules. They were not designed as parts of one enormous monolithic application. They communicate through defined bridges and adapters.

Each module can perform its own job independently, while together they can form a much larger system.

That architectural decision became particularly important when we reached the next major problem.

A Reservation Arrives from Booking.com A Channel Manager without direct connectivity to booking platforms can still do a great deal.

But it cannot perform one of the functions that ultimately justifies the name Channel Manager.

It cannot communicate directly with the channels. When a guest makes a reservation on Booking.com, a real Channel Manager should know about it.

When that reservation is cancelled, it should know that too. And when availability, prices or restrictions change inside CM, those changes should be sent back to the booking channel. Preferably almost immediately.

In an ideal world, the architecture would be wonderfully simple:

CM → Booking.com API

Unfortunately, the world of large online travel platforms does not work quite like that.

Booking.com does not simply provide its Connectivity APIs to every application capable of sending a technically correct HTTP request. Connectivity providers must pass through partnership and technical certification processes. At the time of writing, Booking.com's Connectivity Portal also states that applications for new connectivity providers are temporarily paused.

This creates an interesting paradox for a small software project. The software can become technically capable of communicating with Booking.com.

And yet still have no direct route to the API. So Does a Channel Manager Need Another Channel Manager? At first, the idea sounds absurd.

If we are developing our own Channel Manager, why would we connect it to another Channel Manager?

The answer is that we would not.

What we need is only the part of the infrastructure that somebody else has already built and certified.

This is where we discovered Channex. Channex is interesting to us not primarily as another PMS that could replace CM.

It is interesting because it provides something different: connectivity infrastructure between PMS platforms and booking channels. Its White Label API allows an independent PMS or Channel Manager to use Channex as the connectivity layer to Booking.com, Airbnb, Expedia and other distribution channels.

The architecture therefore would not really be:

• CM → another Channel Manager → Booking.com

It would be closer to:

• CM → Connectivity Adapter → Channex → Booking.com

That distinction matters.

• CM can remain the authority over its own data.
• CM knows the reservations.
• CM knows the prices.
• CM knows the availability.
• CM knows the restrictions and business rules.

Channex simply provides the infrastructure through which those changes reach the distribution channels — and through which changes from those channels return to CM.

And Then the Story Became Slightly Amusing While researching Channex, we also looked into the story behind the company.

Its founder did not begin with the idea: "Let's build an API infrastructure company for the hospitality industry." He came from hospitality.

He built his own PMS.

And then discovered that one of the most difficult problems was connecting that system to Channel Managers and booking platforms.

The problem he encountered while building his own system eventually contributed to the creation of Channex. At that point, I had to smile.

Because the path of CM has been surprisingly similar.

We did not start with a plan to build a large software platform. We started with our own accommodation property. We built our own system.

Then we used it.

Real-world use exposed the next problem.

We solved it.

Then another problem appeared.

We solved that one too.

And eventually we arrived at the connectivity problem.

Someone else had reached a remarkably similar obstacle years before us. The difference is that he turned that obstacle into a company. Why an Adapter, Rather Than a Dependency?

None of this means CM should become dependent on Channex. Quite the opposite.

If there is one lesson that has repeatedly emerged during the development of CM, it is the value of clear boundaries between systems.

The Channex integration should therefore be implemented as an adapter.

Today, we might have:

ChannexAdapter Tomorrow:

BookingNativeAdapter

Later:

ExpediaNativeAdapter

or an adapter for another connectivity provider.

The CM core should not need to know how Booking.com expects to receive its data.

It only needs to understand operations such as:

• send availability,
• update a price,
• receive a new reservation,
• process a cancellation,
• check synchronization status.

How that request physically reaches Booking.com belongs to the connectivity layer.

This is the same principle we already use elsewhere. Guestbook does not need to understand the internal architecture of Financing.

Financing does not need intimate knowledge of every internal detail of CM. The systems agree on what they exchange.

A bridge or adapter handles the translation.

The Interesting Economics of a Small Channel Manager This introduces another interesting question.

Channex currently offers a White Label model consisting of a base platform fee followed by a relatively small additional charge for connected accommodation inventory.

For one small accommodation property, shared connectivity infrastructure obviously makes little economic sense.

But CM Plus and CM PRO are not designed around the assumption that every user should independently build a Booking.com integration. Imagine a different model.

One accommodation provider runs CM Plus with two units.

• Another provider has an independent CM installation with five units.
• A third has one.
• A fourth has ten.

Every CM installation is independent and every accommodation provider remains in control of their own data.

Only the connectivity infrastructure is shared. At that point, the base connectivity cost is no longer the cost of one apartment.

It becomes infrastructure shared across an ecosystem. And as the number of connected users grows, the infrastructure cost per individual provider becomes increasingly small.

That is very different from the traditional model of: "Pay for a large PMS package every month."

CM can remain small, locally deployed and focused on independent accommodation providers. Only the infrastructure that genuinely benefits from being shared needs to be shared.

What About a Native Booking.com Connection? That idea has not disappeared. Quite the opposite.

It remains an interesting long-term objective. If Booking.com reopens applications for new connectivity providers and CM reaches the necessary level of maturity, we can explore becoming a directly certified provider ourselves.

And the architecture would not need to be redesigned. We would simply add another adapter. Instead of:

CM → ChannexAdapter → Booking.com a particular channel could use: CM → BookingNativeAdapter → Booking.com while Channex could continue providing connectivity to other channels. That is the point of a good abstraction. Today's practical solution should never prevent tomorrow's better solution.

We Knocked on the Door So we sent Channex a somewhat unusual message.

We did not simply ask:

"How much does your API cost?"

• We described CM.
• We explained why it exists.
• We described its architecture.
• We explained how CM, Guestbook and Financing remain independent while communicating through bridges.

We described the idea of distributed, self-hosted CM installations operated by small accommodation providers.

And, importantly, we explained that we do not want Channex to become the centre of our system.

We want it to occupy a very specific place in the architecture: between CM and the booking channels.

We also asked how their pricing model applies to small accommodation providers operating several apartments or rooms, and whether one partner integration can serve many independent CM installations.

At the moment this article is being written, we have not yet received their answer.

And that is actually a good moment to publish it. Because this story does not need an artificially manufactured conclusion. It is happening now.

Software That Grows Out of Real Use CM has developed somewhat differently from many software projects. First, we need something.

Then we build it.

Then we use it.

And only real-world use tells us whether the original idea was actually good.

Guestbook emerged from dealing with real guests and real reporting obligations.

Financing emerged from real invoices, tax records and financial reporting. Connectivity is now emerging from another very real question:

How can a reservation made on Booking.com become part of our system without a human having to move the data between them? Perhaps the answer will be Channex.

Perhaps, eventually, it will be a direct Booking.com API connection. Most likely, it will be a combination of several adapters. But one thing is already clear.

When your own Channel Manager starts looking for a certified route into the infrastructure of the world's largest booking platforms, the project is no longer merely the calendar you once built for yourself. It has reached the door of a much larger system.

This time, we knocked.

Now we wait to see who opens it.