Support and uptime terms in hotel software contracts: SLA, response time, RTO and RPO
Understand SLA terms like uptime, response time, RTO and RPO in hotel software contracts. Learn how to measure downtime and what service credits actually cover.
Contents
Key takeaways
- An SLA is a measurement rule before it is a promise: a percentage with no stated period, no exclusions and no evidence is a sentence, not a commitment.
- Response time and resolution time answer different questions: how fast someone picks the problem up, and how fast the hotel is working normally again.
- RTO is the longest the hotel accepts to be without the service after a failure; RPO is how much data it accepts losing, written as an amount of time.
- Service credits return part of the fee; they do not pay for a lost booking, a queue at the front desk or a guest's compensation.
- A percentage only becomes useful when you convert it into hours of downtime in your busiest month, then check what the contract removes from the count.
An SLA (service level agreement) is the part of a software contract that states which service levels the vendor promises, how each one is measured, and what the hotel gets when one is missed. Uptime, response time, resolution time, RTO and RPO are the vocabulary inside it, and each is only as strong as its measurement rule. These SLA terms explained plainly are what follows.
The service annex arrives as three pages of percentages, and the renewal date is next week. The words that decide what happens on a Saturday night in August are all in there, and most of them are never defined. After reading this, you will be able to open the annex, find each term, and know the one question that tests it.
What does an SLA actually promise a hotel?
An SLA, a service level agreement, is the annex that states which service levels the vendor promises, how each one is measured, and what the hotel gets when one is missed. It is a measurement contract, not a description of effort. If a level is not measured, it is a hope.
Before reading, separate three documents. The main contract covers term, fee and liability. The service annex covers levels, support hours and credits. The support procedure covers how to open a ticket and who to call. A term can sit in any of them, but the annex is where it is usually defined, so read the annex with the other two beside it.
Every entry in the annex needs four things: what is measured, how it is measured, over what period, and the consequence of missing it. Remove any one and the entry stops being usable. A "99.9% availability" line with no period and no consequence is decoration.
Ask who produces the evidence. It may be the vendor's own dashboard, an outside monitor, or nothing at all. A level nobody records cannot be enforced or credited, so the evidence rule matters as much as the number.
The hotel has duties too. The annex usually expects a named contact, one route for reporting a fault, and a rule that staff report before they restart anything. If your staff habitually reboot first and call later, the vendor can argue the clock started late.
Key pointFour questions for every line in the annex
What exactly is measured, how and by whom, over what period, and what happens when the level is missed. Write these four beside every entry; any entry that cannot answer all four is not a commitment.
Treat this glossary as a reading order, not a legal opinion. Wording that decides money should be confirmed with your own adviser, and the same applies to the contract clauses to read before you sign, which this article complements. The question that tests the whole annex is simple: show me last month's report against each level.
Uptime, availability and planned maintenance: what counts as downtime?
Availability is the share of a stated period during which the system answers requests, and an uptime percentage is that share written as a number. The argument is almost never about the percentage. It is about what the contract removes from the count.
The measurement period comes first: a month, a quarter or a year. The same percentage over a year hides a bad week; over a month it does not. For a seasonal property, an annual figure can absorb a disastrous August without ever showing it.
Exclusions shrink the denominator. Typical ones are planned maintenance windows, the hotel's own internet or power, the guest's device, third-party services the vendor does not control, and events outside anyone's control. Each exclusion is defensible in principle; the question is how much of it was used last year.
Planned maintenance deserves its own three questions: does it sit inside or outside the number, how much notice is given, and can the window be moved out of the hotel's peak hours? A maintenance window at 22:00 is a different product from one at 12:00 on a checkout Sunday.
Partial failure is the quiet gap. The system is up but the booking engine is not, or it is up but slow. Ask whether a separate performance measure exists and what "slow" means in it, in seconds, not adjectives.
| Term | Plain meaning | Question to ask |
|---|---|---|
| Availability | Share of a period the system answers requests | Over which period? |
| Uptime percentage | The same share as a number | What does it exclude? |
| Measurement period | Month, quarter or year | Is a bad month visible? |
| Planned maintenance | Scheduled work | Inside or outside the count, with how much notice? |
| Excluded downtime | Causes the vendor does not count | Full list, and last year's usage? |
| Partial outage | System up, one function down or slow | Is there a separate measure? |
Where the measurement is taken also matters. A monitor inside the vendor's own network can stay green while the front desk sees nothing. Ask where the probe sits, and ask which hours were excluded last year and how many of them were used.
Response time or resolution time: which one is the promise?
Response time is how quickly the vendor acknowledges a reported fault and starts work; resolution time is how quickly the hotel can work normally again. Contracts often promise the first and let the reader assume the second. Read the two words separately.
Severity levels classify a fault, usually by impact: the whole property down, one outlet, one user, or a question. Ask who assigns the severity, the vendor's support desk or the hotel. If the vendor grades its own homework, a "critical" outage can quietly become a "medium" one.
The clock has its own rules. Ask whether it runs on calendar hours or business hours, whether it pauses while the vendor waits for information from the hotel, and whether it restarts on every reply. A clock that pauses for every question can run for days without ever being late.
Escalation is a path with roles and contact points, not a phone number. Ask what happens at each step and who at the hotel is called. Support hours matter just as much: around the clock, extended hours, or business hours in a named time zone. A seasonal property may need cover only in season, which is a negotiation, not a default.
First-line support is the desk that takes the first call. Ask what it can actually do and whether it can reach someone who can change the system. A first line that can only take messages turns a stated response time into an acknowledgement, not help.
Finally, resolution versus workaround. A workaround gets the front desk moving while the fault stays open. Ask which of the two stops the clock. If only a full fix does, a month of "resolved" tickets may still contain a month of limping.
Checklist
- Who sets the severity of a fault?
- Is the clock calendar hours or business hours?
- Does the clock pause while we answer questions?
- What is the escalation path, and who is called at the hotel?
- What are the support hours, and in which time zone?
- Does a workaround stop the clock, or only a full fix?
When the fault is on your side of the boundary, a prepared front desk checklist for when the internet goes down keeps the desk moving while the vendor's clock is not even running.
RTO and RPO: what do the recovery terms mean?
RTO, recovery time objective, is the longest the hotel accepts to be without the service after a failure. RPO, recovery point objective, is how much data the hotel accepts losing, written as an amount of time. The two letters answer different questions, and neither is a promise until a procedure sits behind it.
RPO is set by the copy interval. A nightly copy means up to a day of reservations can disappear; more frequent copies shrink the gap. RTO is set by the restore procedure, not by the promise: who performs it, from where, with which access, and how long the transfer and the check take.
A backup that has never been restored is a hope. Ask for the date and result of the last restore test, and whether it was run on a copy of the hotel's own data. Where the copy lives and who can reach it matters most when the vendor's own platform is the thing that failed.
| Term | Plain meaning | Question to ask |
|---|---|---|
| Backup | A copy kept elsewhere | How often, and where? |
| Restore | Putting the copy back into use | Who does it, and how long does it take? |
| RTO | Longest accepted time without the service | What is the procedure, and who runs it? |
| RPO | Data the hotel accepts losing, as time | What is the copy interval? |
| Restore test | A rehearsal on real data | Date and result of the last one? |
| Data export | A usable copy the hotel can take away | Which format, and how often? |
The hotel's own fallback keeps the desk working while RTO runs: an exported or printed arrival list, today's rate sheet, and a way to record a booking on paper. The deeper version of this, what to back up in a hotel and how to test it, is worth reading before you negotiate these clauses. Then ask the vendor the concrete question: what happens if the system is gone at 20:00 on a Saturday, in what order, by whom, and how the hotel is told.
What do service credits actually pay for?
Service credits return part of the fee when a stated level is missed. They are a price adjustment, not compensation for what the outage cost the hotel. The gap between those two sentences is where most disappointment lives.
Ask how credits are calculated: usually a percentage of the monthly or annual fee, tied to how far the level was missed. Ask for the table itself, not a summary. Then ask whether they are claimed or automatic: many contracts require the hotel to claim within a window, with evidence, and a credit nobody claims is a clause nobody uses.
Caps come next: a total limit per month or per year, often small next to the fee. Then the sentence that matters most, "exclusive remedy" wording, which can make the credit the only thing the hotel receives for a missed level. Read that sentence with your adviser before renewal.
What sits outside the annex entirely: bookings lost, guests sent elsewhere, staff overtime, guest compensation, reputation. None of these appear in a credit calculation, and no credit table will ever price a queue of guests at midnight.
Watch outA service credit is not a refund of the damage
Before renewal, establish what the credit is a percentage of, who has to claim it and by when, what the cap is, and whether the contract says the credit is the only remedy.
The remedy that matters more is the right to take the data out in a usable format and end the agreement on stated notice. Test the export before you need it. For context on what the fee itself buys, see how hotel software is priced and what the costs around it are.
From a percentage to hours: how much downtime is 99.9%?
Multiply the hours in the measurement period by one minus the stated percentage. For example, a 30-day month has 720 hours, so 99.9% allows about 43 minutes of downtime and 99.5% allows about 3.6 hours.
The arithmetic, once, so it can be repeated: 720 hours times 0.001 is 0.72 hours, about 43 minutes; times 0.005 is 3.6 hours; times 0.01 is 7.2 hours. These figures are illustrative arithmetic, not a standard and not a recommendation. No uptime level is an industry standard; the contract sets the number and the hotel accepts it.
| Stated level (for example) | Downtime in a 720-hour month | What it can mean at the desk |
|---|---|---|
| 99.9% | about 43 minutes | a short queue if it lands at 15:00 |
| 99.5% | about 3.6 hours | a lunch service without the restaurant screen |
| 99.0% | about 7.2 hours | a full afternoon recorded on paper |
Then apply the exclusions. If planned maintenance is excluded and the vendor uses several hours a month, the real allowance is larger than the headline suggests. Then apply the season: the same 43 minutes costs far more on a sold-out Saturday in August than on a quiet Tuesday in February. That makes the maintenance window and the measurement period commercial questions, not technical ones.
Check the period again before signing: a quarterly or annual figure can hide a bad month inside a good year. Ask which month, which hours are excluded, and what the actual figure was last August.
What to do before the renewal conversation
Print the service annex you have now and mark every term in this glossary against it. Where a term is missing or undefined, write the question beside it and send the list to the vendor before the renewal conversation, not after. The percentage is the easy part; the measurement rule, the exclusions and the recovery procedure are what the hotel is actually buying.
Frequently asked questions
Is 99.9% uptime good?
There is no industry standard to compare against, so the number alone says nothing. Convert it into hours of downtime in your busiest month, check the measurement period, and list what the contract excludes. Then judge whether the front desk can absorb that much interruption in season.
Does the SLA cover our internet or power going down?
Usually not: hotel-side connectivity, power and devices are normally excluded, because the vendor does not control them. The useful work is drawing the boundary in writing, so both sides know who is called first, and keeping a paper fallback for the desk while the connection is out.
What is the difference between a backup and a recovery plan?
A backup is the copy; RTO and RPO are the targets for how fast it comes back and how much data may be lost; the recovery plan is who does what, in which order, with which access. The restore test is the only proof that the three fit together.
Can we get a copy of our data if we leave?
That depends on the export clause, not on goodwill. Ask for the format, how often it can be requested, whether there is a cost, and how long after the end of the agreement it stays available. Request one export during the contract and open it, so the first attempt is not made under pressure.
Do we need 24/7 support as a seasonal hotel?
Match support hours to the months you actually operate, and write the season into the annex. A property open from April to October may negotiate around-the-clock cover for those months and business hours outside them, provided the clock definition and the escalation path are clear in both cases.