Five vendors. One outage. Zero owners.

Chapter 01

And every seam is where incidents, costs and risks live.

Hotel IT rarely fragments by design. A WiFi party here, a PMS integrator there, a security tool from a third, telephony from a fourth. Each choice made sense at the time. The result is an environment where nobody sees the whole picture, where incidents bounce between help desks and where you, the client, do the coordination. That coordination is unpaid work, and during an incident it is the most expensive work in the hotel.

Watch it play out in a 90-room city hotel on a Friday evening. Check in stops. The PMS vendor says the network is fine on their side. The network party sees no alarms. The payment provider blames the internet line. Forty minutes in, nobody has started fixing anything, because everyone is busy proving the fault is not theirs. The duty manager is running the bridge call instead of the lobby. That is the seam at work.

Note what the left column does not say. It does not say the individual vendors are bad. Most are competent within their own boundary. The failure lives between the boundaries, in the handovers no contract covers and no help desk is paid to watch. Adding a sixth specialist does not close a seam. It adds two more.

The right question during any vendor review is therefore not whether each party performs, but who owns the outcome when the failure sits between them. If the answer is a diagram with arrows and no name on it, the answer is you. That is the heart of hotel IT vendor management: ownership of the whole, not performance per part. Ask the question in the low season, not during a sold out weekend.

Chapter 02

The invoices are spread out. The damage is not.

Every project and every incident needs you in the middle: aligning vendors, translating between help desks, chasing updates. That is management time no invoice ever shows. It is hotel IT vendor management done by the hotel, unpaid. It peaks exactly when the operation does: event days, migrations, holiday weekends.

Count the hours your GM or operations manager spent on vendor calls last quarter. At most properties it is a part time job that nobody ever decided to create. Then look at what those hours displaced: duty rounds, time on the floor, decisions that waited. That displaced attention is the real cost.

When something breaks between two vendors, both are right and nothing gets fixed. Mean time to resolution grows with every party involved, and guests feel every extra hour. An hour of broken check in at 11pm is not a metric. It is a queue at the desk, a comped room, a review about the wait.

The pattern is always the same: each help desk tests its own component, declares it healthy and closes the ticket. The outage survives every one of those closures. Breaking the loop takes one party mandated to test the chain end to end, from terminal to PMS. Without that mandate, every closed ticket is correct and useless.

Attackers love seams: the firewall one party manages, the switches another, the endpoints a third. Nobody watches the handovers. Under NIS2 those gaps are your board’s problem. A hotel network carries payment data, guest identities and door lock traffic across those same seams. Ask who reviewed a handover last month; the honest answer is often nobody.

A patch schedule that stops at a contract boundary is an open door. So is a firewall rule nobody dares to touch because the party that wrote it left two contracts ago. Disciplined security is boring by design: every device on a maintenance calendar, every rule with an owner and a review date. Fragmentation makes that discipline structurally hard to sustain.

Five vendors each optimise their own slice. Nobody plans your IT as one estate, so lifecycle, budget and innovation happen per silo, or not at all. Switches get replaced in one budget year, access points in another, servers whenever they fail. Then the renovation starts, and the cabling turns out to be on nobody’s roadmap.

Ask five vendors for a three year plan and you get five renewal quotes. None of them will propose removing their own product, however much the estate would benefit. A plan for the whole estate has to come from a party accountable for the whole estate. Anything else is procurement paperwork, not strategy.

None of these costs appear on an invoice, which is why fragmentation survives budget reviews. The line items look reasonable in isolation. The damage shows up in management time, resolution times and audit findings, and those are booked somewhere else. Put a number on the coordination hours and the extended outages for one quarter, and the case for consolidation usually writes itself.

Consolidation is also the pattern our clients follow: start with one domain, then bring the next one under the same roof. Support usually moves first, because that is where the daily friction lives. The next wave starts once the first has proven itself.

Chapter 03

Fewer parties, faster fixes, one truth.

Consolidation is not about buying everything from one shop for convenience. It is about moving the seams inside one organisation, where they are covered by one SLA and one management team instead of a bridge call. Three things change, and each one is visible in daily operation within months.

Every incident starts with a single call, whatever layer is failing. No triage across help desks, no debate about whose ticket it is. On a bad night this changes the duty manager’s job from coordinator back to host. The front desk calls one number and goes back to its guests.

When one team manages the network, the servers and the workplace, diagnosis follows the fault instead of forwarding it. An engineer who can see every layer does not need another vendor’s permission to look further. Cross domain incidents, the ones that used to bounce for days, become ordinary tickets, because there is no boundary left to bounce off.

One monitoring view, one asset register, one roadmap. When you ask what your IT costs, what is at end of life and where the risks sit, there is a single answer instead of five partial ones. Budget conversations get shorter. Audits get calmer. Under NIS2, being able to show one accountable picture of your estate is not a luxury.

There is a fourth change that is harder to put in a table: the relationship inverts. With five vendors, you chase. With one owner, you get chased: a renewal proposal before the contract expires, a warning about capacity before it runs out, a plan for the next refurbishment before you ask for one. That is what accountability for the whole estate looks like in a calendar.

Chapter 04

You don’t switch everything at once. You bring layers under one roof.

Consolidation follows our standard ownership model: we assess the estate, design the target, onboard domain by domain and operate it as one environment. Contracts with incumbent vendors end on their natural dates; every migration is planned outside your peaks. See how this looks per layer in Managed Infrastructure and Managed IT Support.

Map every vendor, contract, SLA and seam in the current estate. Including the informal ones: the camera system technical services ordered, the booking widget marketing signed for. Most estates are larger than their contract folder. The assessment also ranks each seam by what it costs during a peak: stopped check ins, stopped payments, or mere annoyance. That ranking sets the order of work.

Define the target model: what consolidates, what stays, who owns what. Not everything should move. A PMS relationship that works can stay; we take responsibility for how it connects to everything else. The design is agreed on paper before anything migrates. Ownership of every layer, including the ones that stay with others, is named in writing.

Take over domain by domain, aligned with contract end dates and occupancy. A takeover in the low season is a project. A takeover in high summer is a gamble, so we schedule around your calendar, not our pipeline. Each takeover has a rollback plan and a quiet window agreed with your team. The front desk should notice the change in fewer calls, not in disruption.

One SLA, one escalation line, one roadmap for the whole estate. From that point on, hotel IT vendor management is our job. The specialist parties that remain report to us, not to your front office. When one of them misses a deadline, we chase and we escalate. The ticket can move between parties. The accountability cannot.

Most groups consolidate in waves: support first, then infrastructure, then security and guest technology. Each wave has to prove itself before the next begins. That keeps the risk small and gives you an exit at every stage, which is exactly the discipline you should demand from any partner proposing to own more of your estate.

Chapter 05

Fragmentation feels safe because no single party is critical. In practice it means no single party is responsible.

The test is simple and worth running today. Imagine your check in down at 2am: no keys being cut, no payments going through. Write down the first phone number your night team would call, and what that party actually owns. If the honest answer is that the call starts a chain of other calls, the outage has no owner yet, and you will be the one who inherits it, live, with guests at the desk.

Single ownership is not about size, and not about loyalty to one logo. It is about where accountability lands when things break. One partner who owns every layer cannot point anywhere. That changes behaviour long before the incident: monitoring is built to cover the seams, documentation stays current because the same team will need it at 3am, and prevention gets funded because the owner of the outage is also the owner of the fix.

Fragmentation feels safe because no single party is critical. In practice it means no single party is responsible. Hotels run better with one accountable owner for the whole stack. Read how that role differs from a standard supplier in why hotels need a hospitality MSP, and what downtime really costs in the true cost of hotel IT downtime.