Hotel Technology Integration and Why It Keeps Failing

Hotel systems stay disconnected for structural reasons, and once you can name the five of them, you can decide which seams to fix and which to live with.

How many other systems does a hotel's core software have to talk to before a night runs cleanly? Mews, one of the larger cloud property management vendors, runs a marketplace reported to carry more than 1,000 hospitality integrations. That is the honest scale of the surface an average property is being asked to manage.

Nobody at a hotel wanted 1,000 anything. They wanted the rate the booking engine sold to match the rate the property management system charged, and the guest who stayed nine times to be greeted like it.

Hotel technology integration keeps failing, and it fails for reasons that have almost nothing to do with vendors being lazy or operators being slow. It fails because of how these systems were built, who owns the connection, and what a connection costs. The wider reason the whole stack feels borrowed is the subject of why hospitality software was built for someone else, and this chapter, the third in the series, takes apart the specific case of a hotel.

Key takeaways

Hotel technology integration is not one problem. It is five distinct mechanisms, and each one calls for a different response.
Connector counts are a measure of the gap, not a cure for it. Mews alone advertises more than 1,000 hospitality integrations.
No system in a hotel owns the guest. The PMS, the POS, the booking engine and the loyalty tool each hold a different partial record.
The property management system is the lock. Whoever holds it sets the price, the pace and the permission for every other connection.
An operator can close specific seams without replatforming, but the pick has to be made on cost of failure, not on vendor pitch.

Nine systems run a hotel and none of them owns the guest

Count what a mid-sized property actually runs, and the list gets long fast.

The property management system holds the reservation and the folio.
The central reservation system distributes inventory across the estate.
The channel manager pushes rates out to the OTAs, while a booking engine takes direct bookings.
The revenue management system decides what tonight should cost.
The point of sale runs the restaurant and the bar.
The guest CRM holds the marketing list, while door locks issue keys and a board tracks room status.

Nine systems. Nine vendors. Nine data models, each of them internally consistent and none of them agreeing with the others.

The guest exists nine times, differently

Here is the specific failure that operators feel first. In the property management system, the guest is a reservation with a folio. In the point of sale, the same person is a table and a check. In the CRM, they are an email address with an open rate. In the loyalty program, they are a number.

None of these records is wrong. None of them is complete. There is no shared guest identity because no system was ever appointed to hold one, and every vendor has a commercial reason to believe the guest lives in theirs.

So the nine-time returning guest gets greeted like a stranger by whichever screen happened to be open, and the front-desk agent gets blamed for it.

The other place it surfaces is the night audit. Somebody has to make the restaurant's takings, the room charges and the channel's reported bookings agree before the night closes. In a property with a technology department, that is a job for a system. In the vast majority of properties, it is a job for a person with a spreadsheet and an export.

That person is usually your best one, and the work produces nothing a guest will ever see. If your reconciliation runs the other way, from tables to rooms, the same seams are mapped in where a restaurant tech stack breaks.

Timeline of one hotel night from rate sold through night audit to close, showing where each separate system holds a different version of the same guest and stay

Integration fails for five reasons, and only two of them are technical

Read enough of the trade coverage on hotel operations technology and you will find the same complaint restated for twenty years. Restating it does not fix it. Naming the mechanism might.

Proprietary schemas, written before anyone had to share

Each system defines its own objects. What a PMS calls a rate plan, a revenue system calls a price point and a channel manager calls a product. The fields do not map cleanly, so somebody has to decide, in code, what happens when a two-night package with a breakfast component meets a channel that only understands a nightly rate.

That decision gets made differently in every integration, which is why two properties running the same two products can get different behavior out of them.

The PMS is a lock, and it knows it

The property management system holds the reservation, so it holds the leverage. Every other system in the building has to ask it for data, and the terms of that ask are set by the vendor. The big core vendors run entire integration platforms of their own, and those platforms exist precisely because access to the core has to be brokered, governed and certified.

Legacy on-premise systems make it worse. Migrating one means moving live reservations, rates and folios without losing a night of trading, which is a project no general manager volunteers for in a good season.

Connections have a price, and it recurs

Interfaces are rarely free. Certification programs, per-connection fees and per-property setup charges are standard in this industry, and they are charged by the party that owns the data you already paid to create.

The result is an operator who can name the integration they want, price it, and still not build it, because the sum of five small monthly fees is a line item somebody has to defend at budget. Where that recurring bill actually lands, and why it is rarely just a license fee, is the whole argument of what a restaurant integration really costs.

Certification is a gate, not a standard

Vendors run partner programs with review queues and approval tiers. That is reasonable governance and it is also a moat. A small, sharp product that solves one problem for one kind of property has to survive a certification process built for the vendors who can staff one.

Nobody agreed who holds the truth

The fifth reason sits under the other four. No convention exists that says the guest record lives here, the rate lives there, and everything else reads from it. Trade coverage of PMS and POS integration still treats each connection as a strategy an individual property has to work out for itself, which is what a missing convention looks like from the floor. Adoption is the part that never lands, because the vendor closest to the truth has the least reason to give it up.

Laid side by side, the five stop looking like one fault and start looking like five different jobs.

Mechanism	What it really is	Why more engineering does not settle it
Proprietary schemas	A modelling gap	Each vendor defines a rate its own way, so the mapping is rebuilt per property
The PMS is a lock	A control point	Whoever holds the core sets the terms for every other connection
A recurring price	A budget line	Certification and per-connection fees are charged by the owner of your data
Certification is a gate	A moat	A partner queue built for large vendors keeps small products out
No agreed source of truth	A missing convention	Nothing says where the guest record or the rate actually lives

Five mechanisms. Two of them are engineering problems. Three of them are commercial ones, which is why buying better engineering has never fixed this.

Marketplaces count connections, they do not create agreement

Every serious vendor now runs an integration catalog, and the numbers get quoted as reassurance.

Epos Now advertises a connection to over 100 apps.
Cloudbeds describes an ecosystem of more than 450 marketplace partners.
SiteMinder sells a direct booking engine that plugs into the same distribution network it already runs for the OTAs.

Those are real products doing real work, and if your operation is close to the shape they assume, they will serve you well.

But an integration is a pipe, not an agreement. A connector moves a field from one system to another. It does not decide which of the two systems is right when they disagree, and disagreement is the actual failure.

That is the difference between plumbing and a source of truth. Reference sites that map the property management system landscape are useful for the first job. Nothing on the market does the second for an independent property. Whether to buy one suite that owns the connections or assemble the best products and own the seams yourself is its own decision, argued out in all in one restaurant software versus best of breed.

Whole businesses exist to translate between hospitality systems. When an entire category of company is viable purely as a translation layer, that is not a sign the ecosystem is healthy. It is a measure of how far apart the systems were allowed to drift.

Four moves that close a seam without a replatform

None of this means an operator is stuck. It means the moves available are narrower than the vendor pitch suggests, and choosing well matters more than choosing fast.

Pick the seam by cost of failure, not by whichever fault irritates you first that week.
Appoint a source of truth in writing, so one system wins every disagreement.
Buy the API terms, not the feature list, because the contract governs your options for years.
Build the one workflow nobody sells you, the market of one that is genuinely yours.

Pick the seam by cost of failure, not by irritation

Rank your seams by what a failure actually costs. An oversell caused by a rate and inventory mismatch costs a room, a refund and a review. A guest record that does not follow the guest costs a smaller amount, repeatedly. Fix the one with the expensive failure first, even if the other one annoys you more daily.

Two by two matrix ranking hotel integration seams by cost of failure against how often they bite, placing an oversell on rate and inventory in the fix-first quadrant

Appoint a source of truth in writing

Somebody has to decide which system wins when two disagree, and the decision has to survive the person who made it. Write it down. Rate and inventory truth lives in one place. Guest identity lives in one place. Every other system reads.

This is free. It is also the single thing that separates properties whose stack degrades gracefully from properties whose stack degrades on a Friday.

Buy the API terms, not the feature list

When you next change a core system, read what the contract says about access to your own data, per-connection fees and certification. That clause will govern your options for the next seven years, and it is worth more scrutiny than the demo. The same discipline shows up in technical due diligence on any software business, and it is exactly as unglamorous there.

Build the one thing nobody sells you

There is usually one workflow specific to how your property runs that no vendor will ever ship, because your version of it is a market of one. The market is dense with capable general tools, from labor scheduling to the point of sale, and every one of them was designed for the average property rather than yours. Building the specific thing used to be indefensible on cost. It is not any more, which is the whole argument the studio was built on.

The test for whether a workflow qualifies is simple. If you can describe it to a vendor and they say it is on the roadmap, buy it. If you describe it and they say nobody else asks for that, you have just found the thing that is actually yours, and the thing worth building.

Technology in the hotel industry has spent thirty years arriving as a product somebody else specified. The one piece specified by the operation is the only piece that ever fits without an export.

What this looks like when it works

Run the same property again with the five mechanisms answered rather than abstracted away.

Rate and inventory have one owner, so an oversell becomes an event somebody investigates rather than a Tuesday.
Guest identity has one owner, so the returning guest is recognized at the door, at the table, and in the follow-up email, by the same record.
The core contract was signed on data access rather than features, so the connection you need next year costs a conversation instead of a budget fight.
The workflow you depend on exists as software, built for the way your night runs rather than bent from something built for a retailer.

That last piece is the one that used to be impossible. Trade coverage in outlets like eHotelier will tell you the money is moving into hotel technology, and coverage of what hoteliers are actually buying will tell you what they want from it. Not hype. The repetitive admin gone, and the hours it eats handed back to the people running the property. The shape of that as a category is drawn in a hospitality management platform built for the shift.

Both things are true at once. That is the opening.

Building it properly takes somebody who owns the outcome rather than the invoice, which is why we sit on the cap table under our equity model and why how we choose what to build starts with the operator and not the roadmap. Groups that try it alone usually need senior judgment before they need engineers, which is the argument for a fractional CTO over a first hire.

Nine systems will still be running. The difference is that they will finally agree about tonight.

Frequently Asked Questions

What is the difference between a POS and PMS system?

A PMS runs the accommodation side, holding reservations, room status, rates and the guest folio. A POS runs transactions in outlets such as the restaurant, bar or spa. The seam between them is where a room charge posted at the table has to reach the folio at the front desk.

What PMS system do Hilton hotels use?

Large chains typically run proprietary or heavily customized systems, and Hilton is no exception to that pattern. Scale buys the option of commissioning software that matches your operation exactly. Independent properties, who make up the bulk of the industry, buy from the same short list of vendors as everybody else.

What is the best PMS software?

No single answer survives contact with a real property. The right PMS is the one whose data access terms, integration fees and certification process fit the systems you already run and the ones you will add. Evaluate the contract and the API before you evaluate the interface.

Which software is best for hotel management?

Best depends on what your property is optimizing. A boutique with a strong direct channel needs different distribution than a resort selling through OTAs. Judge candidates on how cleanly they share rate, inventory and guest data with the rest of your stack, because that is where the cost lands.

What are 5 types of POS systems?

Common types include a fixed terminal, a tablet or mobile POS, a self-service kiosk, a cloud POS that runs from a browser, and a handheld order-taking device used at the table. In hospitality, the distinction that matters is whether the POS can post charges to the PMS folio.

What is ERP vs POS?

An ERP runs back-office functions such as finance, procurement and inventory across a whole business. A POS runs the customer-facing transaction at the counter or table. In hospitality groups, the two are often connected badly, which is why food cost reporting so often arrives a week late.

Continue Reading:

More In This Series:

More from Teleport Dynamix:

Explore the Insights Categories: