An hour of downtime never costs an hour.

Chapter 01

In an office, an hour of downtime is an hour of lost productivity. In a hotel it lands in the middle of check in, dinner service or the night audit. Guests are standing in front of you while systems are down, and every minute is visible.

Picture a 120 room property at seven on a Friday evening. Two coaches arrive at once, the PMS freezes, and the queue reaches the door within ten minutes. Nobody in that lobby cares that the incident will be resolved inside the SLA. They care that they have been travelling all day and cannot get a key. Office downtime is measured in productivity. Hotel downtime is measured in people standing in front of you, and in the story they tell about it afterwards.

That is why the ticket cost of an incident, the number that ends up on the IT report, is only a small part of what actually happened. The real cost of a hotel outage is not in the ticket. It is in the guest moments that failed while the ticket was open.

Neither invoice is wrong. But only one of them is on the finance team’s desk the next morning. The other one shows up in RevPAR three months later, and nobody connects it back to a Tuesday afternoon PMS failure. By then the review scores have moved, the rate has followed, and the meeting is about pricing instead of infrastructure. That gap between cause and cost is where hotel downtime hides its real price.

This is not an argument for softer reporting. It is an argument for honest accounting. If the only number your management team ever sees is the ticket cost, prevention will always look expensive and downtime will always look cheap. Put both invoices on the same table and the question changes. It stops being what does support cost, and becomes what does the next incident cost, and who is carrying that risk today.

Chapter 02

Most of the damage from a hotel IT outage never reaches the IT report, because it lands in places the IT team does not track. Four categories, in the order they show up. Each one runs on its own clock. Some start counting in the first minute, others take a quarter to surface. Walk through them with your own property in mind, and with a full house on the calendar.

Failed payments, abandoned direct bookings, missed upsells and vouchers handed out to keep guests calm. Revenue losses start in the first minutes and are rarely booked as IT costs. They just show up as a bad day in the F&B numbers. A payment terminal that cannot reach its provider does not delay one transaction. It stalls the whole queue behind it, and the guests in that queue quietly drop the second drink, the late checkout and the breakfast add on.

Manual workarounds, double entry once systems return, overtime and a night audit that takes until morning. Your team pays for downtime long after the systems are back. Staff who spent Tuesday night doing paper check ins are less patient with the tenth guest on Wednesday. There is a quieter cost too. Workarounds invented under pressure become habits, and habits built during outages keep producing errors for weeks after the systems are back.

Guests do not see a server. They see a hotel that could not check them in. One visible failure can outweigh an otherwise flawless stay, and reviews translate that directly into rate pressure. Booking sites reward consistency. An outage on the wrong day breaks the streak. And the guest who waited forty minutes for a key does not write a review about your infrastructure. They write a review about your hotel.

Downtime often has a security dimension: failed backups, missed alerts or an incident that should have been reported. Under NIS2 that adds regulatory exposure to the operational damage. The 24 hour reporting clock does not pause because reception was busy comping rooms. The moment your systems fail is exactly the moment your evidence and reporting discipline matter most, and the moment they are hardest to improvise.

Chapter 03

Prevention costs a fixed amount per month. Downtime picks its own price, and its own moment. The maths favours prevention almost every time, but only if you count all four categories from Chapter 02, not just the IT invoice. Hotel IT downtime also has a habit of arriving under load: full occupancy, event days, peak season weekends. An outage on your busiest night costs a multiple of the same outage on a quiet one.

Three concrete outcomes define the difference between reactive and prevented.

Managed support turns IT from a risk line into a budget line. You know what next month costs. You know what next year costs. Finance can plan against it. IT is no longer the reason for a variance conversation with the CFO. It also changes the quality of investment decisions. When the baseline is stable, new IT spend goes to improvement instead of firefighting. Reactive hotels spend the same money twice: once on the incident, once on repairing the trust it broke.

Most incidents that would have hit the guest never do, because monitoring catches the degradation first. The team notices something is being fixed. The guest notices nothing at all. That is what “no incidents” actually looks like from the desk. Think of the near misses a monitored environment quietly absorbs. A disk filling up, a switch running hot, a certificate about to expire. Each one is either caught on a dashboard on a quiet morning or discovered by a receptionist on a full Friday night. The difference is not luck.

Prevention does not mean zero failures. It means a shorter path from failure to fix, with an escalation line that is already open when the issue lands. One escalation, one number, one owner. The guarantee matters less for the hour itself than for the behaviour it forces. A partner that commits to it has to know your environment before the incident, keep documentation current and rehearse the path back. Those habits are the real product.

Chapter 04

Every managed support conversation eventually comes down to the same question: what changes on Monday morning? Five things, in order. None of them are exotic. All of them require an owner.

Detect degradation before guests do, across network, PMS, workplace and access. The alert threshold is set to catch problems while they are still boring, not once they are already dramatic. A watched environment produces fewer surprises, and the surprises it does produce arrive smaller. That includes the layers guests touch without ever naming them: Wi-Fi at the door, key encoding at the desk, payment traffic at the bar. If any of those degrades unseen, reception finds out first, and at the worst possible moment.

Patch, maintain and replace on schedule instead of on failure. The unglamorous work that means the incident never happens in the first place. It is also the work that always gets deferred when nobody owns it, which is exactly why fragmented IT environments break. A patch window on a quiet Tuesday morning is an inconvenience. The same component failing during Saturday arrivals is an incident with a lobby audience. Scheduled work lets you choose the timing instead of letting the failure choose it.

When something does break, there is one number to call, one team on the other end, and a one hour recovery guarantee against the SLA. No handoffs between vendors. No debates about whose problem it is. Your receptionist should not have to guess whether a frozen screen is a network fault, a software fault or a licence issue. They call, describe what the guest sees, and hand the problem over. Working out where the fault sits is our job, not theirs.

Every incident gets a root cause and a fix, so it does not return. The temptation after any restoration is to move on. The discipline is to write down why it happened and close the door behind it. One incident that returns every quarter does more damage than three one offs, because the team stops trusting the system and builds shadow workarounds around it.

Fixed scope, fixed monthly costs, no surprises. That is what turns IT from a risk line into a budget line, and what makes prevention economically comparable to the alternative. It also removes the quiet incentive problem in reactive contracts, where the supplier earns more when things break. Under a fixed fee the economics point the same way for both sides: fewer incidents, shorter recoveries, calmer nights.

Chapter 05

Every hotel decides its downtime tolerance before the incident, in the contracts it signs and the monitoring it runs. Once the incident is under way, the choice has already been made. What is left is executing whatever plan was in place, or improvising in front of guests.

If you want to test where your hotel stands, three questions are enough. Who is watching your systems tonight, and would they see a degradation before reception does? If the PMS failed at seven this evening, who would you call, and how many vendors would that call have to cross? And when the last incident closed, did anyone write down why it happened, or only that it was fixed?

Honest answers tell you your real downtime tolerance, whatever the contracts say. If those answers make you uncomfortable, the discomfort is useful. It arrived before the incident did, and it costs nothing to act on. Most hotels that walk through this exercise find the same thing: not one dramatic gap, but a series of small assumptions nobody ever tested.

Choosing prevention means choosing a partner that owns the outcome. Not the ticket. The outcome. That distinction is what separates a managed service from an IT invoice. It is also what your team feels on the next difficult night. Somebody is already watching, somebody already knows the environment, and reception can stay with the guests in front of them.