Hospitality systems fail at the decision, not the software.

Why do hospitality technology projects disappoint so consistently? Because the selection starts at the demo rather than at the decision. A system improves performance only when a named person uses its output to make a specific commercial decision on a defined rhythm. Where that person, decision and rhythm do not exist, the software will be implemented correctly, adopted partially, and change nothing — and the post-mortem will blame the vendor. Before any shortlist, write down the decision each layer is meant to improve and who owns making it. Most stacks fail that test in two or three places, and those are the places to fix first.

The pattern

An RMS, a rate shopper, a CRM, a channel manager, a reporting layer, a chatbot. Each was justified at the time. Each is adopted at perhaps sixty percent. And the commercial questions underneath — who owns the channel mix, who challenges the parity exceptions, which meeting actually changes a price — sit exactly where they sat before any of it was bought.

This is not an argument against systems. It is an argument about sequence. Tools amplify a commercial operating system; they cannot substitute for one, and a tool bought to paper over an unowned decision reliably makes the ambiguity more expensive rather than less.

Decision-first selection

Before a shortlist exists, five questions have to have answers. They take an afternoon and they eliminate most candidate purchases.

| # | Question | Why it eliminates | |---|---|---| | 1 | Which decision does this improve? | A tool that improves no specific decision is a reporting habit with a licence fee | | 2 | Who owns that decision? | If nobody owns it, the tool will produce output nobody acts on | | 3 | On what rhythm is it made? | Daily, weekly, per-booking or annual — this determines what the system must produce and how fast | | 4 | What is the decision made from today? | If the current input is adequate, the gain is convenience, which is a smaller business case | | 5 | What changes in behaviour if we buy it? | If the honest answer is "we'd have better visibility", nothing changes |

Only after those five does platform comparison mean anything — and the comparison is then against a specification rather than a feature list.

The layers that need owners

Every layer below appears in most hospitality operations. What varies is whether the decision it serves has a named owner and a rhythm.

• PMS — the operational record. The decision is rarely commercial; the constraint it creates for everything downstream usually is.
• CRS and booking engine — what is sellable, at what rate, through which path. Owner: whoever is accountable for rate integrity.
• RMS — pricing and restriction decisions. Owner: revenue. The most common failure is a system whose recommendations are routinely overridden without the overrides being reviewed.
• Channel manager and distribution — mix, parity discipline, commission load. Owner: commercial. Frequently the least owned layer relative to its cost.
• Market and rate intelligence — the comparative view. Only useful where somebody is accountable for acting on a movement within a defined window.
• CRM and loyalty — the guest relationship and repeat behaviour. Owner: marketing or commercial, with a service-side dependency that is usually underestimated.
• Reservations, table and short-stay platforms — the conversion surface for F&B and short-stay demand.
• Analytics and reporting — the layer most likely to exist in triplicate, with three versions of the same number and no agreement on which is authoritative.
• Automation and AI workflows — the layer where unclear ownership compounds fastest, because an automated bad decision runs without anyone noticing.

Nine layers, four or five owners at most in a typical operation. The overlap is not a problem; the unassigned gaps are.

Migration, integration and the parts nobody budgets

Licence cost is the visible number and rarely the largest.

Migration is where projects actually fail. Historical data quality is almost always worse than assumed, and the discovery happens after the contract is signed. Decide in advance what is migrating, what is archived, and what is deliberately left behind — that third category is a legitimate answer and it is very rarely used.

Integration determines whether a stack behaves as a system or a collection. Ask specifically what the integration does and does not carry, and how failures surface. "It integrates" is not an answer; "it syncs rates one way every fifteen minutes and does not carry restrictions" is.

Adoption is where the value actually lands or does not. A system at sixty percent adoption produces sixty percent of its data and close to none of its benefit, because the reporting is now unreliable and the team knows it. Adoption is a management problem, not a training problem, and it belongs to whoever owns the decision the system serves.

Duplicated tools accumulate quietly — two systems that both hold guest data, three that report channel performance. The cost is not only licence; it is the reconciliation time and the standing argument about which number is right.

Vendor incentives, read honestly

Vendors are not adversaries, but their incentives are legible and worth reading.

A vendor is optimising for contract value, term length and switching cost. That produces genuinely useful roadmaps and also produces feature breadth that is easier to sell than to adopt, integration depth that is thinner than the diagram, and pricing structures that make leaving expensive.

Two questions cut through most of it: what happens to our data if we leave, and what does year three cost including the modules we will inevitably need. Both have precise answers, and reluctance to give them is itself informative.

What happens when a system disappears

A useful test, and quick. For each system, ask: if this vanished on Monday, what would stop working, who would notice first, and what would we do instead?

Three answers, and each is actionable:

• "Everything would stop" — a genuine dependency. Check the exit terms and the data-portability position now rather than at renewal.
• "We would go back to a spreadsheet" — the tool is a convenience. That may be fine, but it should be priced as a convenience.
• "Honestly, not much" — you have found something to cancel.

AI and automation

The layer with the best current return in hospitality is not guest-facing. It is the internal work of assembling, reconciling and summarising information that a person then decides on: commercial reporting, owner statements, content operations, enquiry triage, and the small reconciliations between systems that quietly consume hours every week.

Two disciplines keep it honest. The output must be checkable — an automated summary nobody can trace back to source is a rumour with formatting. And a person must remain accountable for the decision, because automating the production of an answer does not transfer responsibility for acting on it.

Katalyst's capability here is stated as it is: AI-assisted research, commercial reporting, content operations, workflow automation and agent orchestration. Not a model, not a product, and not a claim that automation substitutes for the ownership this article is about.

How Katalyst separates advice from compensation

Katalyst currently holds no technology partnerships, reseller agreements or referral arrangements. No vendor pays for placement, and no recommendation made today carries compensation of any kind.

If that changes, the relationship is disclosed on the recommendation that relies on it, not only if asked. The full position — requirements before products, realistic alternatives, software cost separated from implementation cost, and the disclosure text itself — is published at the technology recommendation policy.

The systems named under Selected Systems Experience are products the team has operated, configured, implemented, migrated or evaluated in current and prior roles. That is experience evidence. None of those vendors is a Katalyst partner, and this article deliberately recommends no platform universally — because the right answer depends on the decision, the rhythm and the owner, which are different in every operation.

What this article can and cannot establish

It can: provide a decision-first selection method, name the layers that require owners, and give two tests — the five questions and the disappearance test — that can be run against a current stack this week.

It cannot: compare named platforms, recommend a stack, or quantify the cost of poor system ownership. No adoption or failure-rate statistic is quoted, because the credible ones are vendor-published with undisclosed samples and the rest are folklore. Where a figure would have been useful, its absence is deliberate.

This article is method and operating experience. It contains no external statistic and no client result.

Where this goes next

The adjacent argument — that adding tools before fixing ownership is the more common failure — is in more hotel tech has not produced better performance. The stack-selection version for hotels specifically is how to choose a CRS, booking engine, CRM and chatbot. For short-stay portfolios, the systems layer sits on top of unresolved portfolio economics more often than not — see a holiday-home portfolio is not a collection of listings.

The capability is Technology & Automation, and the systems the team has actually worked in are listed under Selected Systems Experience.

Next action: list your current systems, and against each write the decision it improves and the person who owns that decision. The rows you cannot complete are the project.