Ask three vendors whether a hotel should move its phone system to the cloud and all three will say yes, and all three will show you a slide claiming it cuts the total cost by somewhere between a third and a half. Then run the numbers on an actual hotel and something odd happens: the two options land within a few percent of each other. Not because anybody is lying, but because a hotel is a strange shape for the way cloud telephony is priced, and the savings that are real in an office mostly are not real in a building where every bedroom has an extension. This is a practical look at the decision underneath: hosted or on-premise, what each genuinely costs, what stops working when the line drops, and how the link to your property management system is affected.
Worth saying at the outset what this decision is not. It is not a technology choice, or at least not mainly. Both models do the same job and a guest cannot tell them apart. It is a question about who carries the operational risk, who holds the capital, and what you are willing to depend on. Which makes it a finance question wearing a technology costume, and one that belongs as much to whoever owns the capital and operating budgets as to whoever owns the network.
What Cloud Actually Means Here
Strip away the branding and one thing has moved: the switch.
In a traditional setup the box that routes calls sits in your building, usually in a plant room or a comms cupboard, and everything registers to it locally. In a cloud setup that box sits in a provider's data centre, shared with hundreds of other customers, and your handsets reach out across the internet to register with it. The phones on the desk look identical. The wiring is often identical. What changed is where the intelligence lives and who is responsible for keeping it running.
You will meet several names for this and they are close enough to treat as one for buying purposes. Hosted PBX usually means the same platform you would have run yourself, operated for you in somebody's data centre. Cloud PBX tends to mean a multi-tenant platform built for the purpose. UCaaS, unified communications as a service, means the same thing with messaging, video and presence bundled in, most of which a hotel will never use. The differences matter to engineers and rarely change the decision in front of an owner.
This is not an emerging option, incidentally, which is worth knowing if your integrator talks about it as though it were novel. Hospitality-specific cloud telephony platforms are deployed across hundreds of thousands of hotel rooms worldwide. The question is not whether it works. It is whether it suits your particular building, your balance sheet and your tolerance for depending on a connection you do not own.
Hosted, On-Premise, and the Hybrid Between Them
Three shapes, and almost every proposal you receive is one of them wearing a different name.
On-premise. You buy the switch, it lives in your building, you own it. Someone maintains it under a support contract. Calls between two extensions in the building never leave the building. You carry the capital cost, the hardware risk and the obligation to replace it eventually, and in exchange you carry very little dependency on anything outside your walls.
Cloud, or hosted. You rent the capability monthly. There is no switch to buy, no server to power and cool, no maintenance contract, and no hardware that becomes unsupported in six years. Every call, including a call from one room to another, travels to the provider and back. You carry a monthly cost that never ends and a dependency on your internet connection that is total unless you spend money to soften it.
Hybrid. The platform is in the cloud but a piece of equipment stays on site, handling local call control when the connection is healthy or taking over when it is not, and connecting whatever analogue equipment you kept. This is the shape a lot of hotels arrive at, usually after starting the conversation assuming they had to pick one of the other two.
Keep those three in mind through the cost section, because the hybrid is frequently priced as cloud while carrying an equipment line that gets discussed late.
What You Stop Being Responsible For
Before the arithmetic, the honest case for cloud, because it is a real case and it has nothing to do with the monthly figure.
You stop patching things. Security updates, firmware, platform upgrades and the whole business of keeping software current become somebody else's problem, and they happen whether or not anybody at your property remembers. Hotels are not software companies and this genuinely disappears.
You stop owning hardware that dies. A switch has a service life, parts become scarce, and eventually a vendor stops supporting the model you own. On a subscription that entire category of anxiety belongs to the provider, along with the replacement cost when it arrives.
You stop needing somebody who understands the platform. This is the one that decides it for small independents. If nobody on site is comfortable with telephony and the nearest engineer who has configured your model is a long drive away, then a system you own is only as reliable as a relationship you may not have. A platform managed by the people who built it removes that dependency entirely.
You stop making capital decisions on a five-to-seven year cycle. Whether that is good depends on your balance sheet, which is the next section.
None of that is small. If the article ended here the answer would be obvious. It does not end here because the pricing model was designed for a different kind of building.
Why a Hotel Fits Cloud Pricing Badly
Cloud telephony is priced per user. That model was built for offices, where a company with fifty staff buys fifty extensions and all fifty are used by people who make calls all day. The subscription tracks the size of the workforce, the workforce is the thing generating the revenue, and the arithmetic feels fair to everyone.
A hotel does not work like that. A 150-room property might have twenty staff who use a telephone as part of their job, and 150 extensions sitting on nightstands that are used, at most, a handful of times per stay. Very often not at all. The extension count is decoupled from the staff count and tracks the building instead, and the building is large.
So the pricing model asks you to pay a monthly fee, for ever, for an extension in room 214 that a guest might pick up twice a year to ask for extra towels. Multiply by 150. That is not a defect in anybody's product, it is a mismatch between how the service is sold and how a hotel is shaped, and it is why the generic savings figures do not survive contact with a hotel.
Per User, Per Room, Per Extension
Vendors serving hospitality know this, which is why the good ones quote differently.
Generic business cloud telephony runs roughly 15 to 35 dollars per user per month for a standard tier. Apply that to a 150-room hotel and the answer is absurd, somewhere between 27,000 and 63,000 dollars a year, which is more than the entire capital cost of owning a system outright.
Hospitality-specific providers price per room instead, typically 5 to 15 dollars per room per month, with the understanding that a guest room extension is a fundamentally different product from a knowledge worker's phone. That is the number you should be negotiating, and the first thing to establish about any quote is which of the two models it uses.
Three things to pin down in writing while you are there. Whether staff extensions are counted separately from rooms, and at which rate. Whether the rate applies to rooms you have taken out of service, or to a wing you close for the season, because a property that shuts a floor every winter is paying for it unless somebody agreed otherwise. And what happens to the per-room rate at renewal, which is the subject of the section on lock-in.
What Each Model Actually Costs
Currency figures move and vary by region, so treat what follows as structure and orders of magnitude rather than a quotation. The shape is what transfers.
Owning it. A small property of 40 to 80 rooms is looking at roughly 15,000 to 30,000 dollars for the switch, the installation, the room phones and the initial programming. Larger and more complex properties run from 50,000 well into six figures. A useful rule of thumb at the equipment level is 500 to 1,000 dollars per extension for hardware plus licensing. After that, a support contract at somewhere between 10 and 20 percent of the system cost per year, call-out charges starting around 150 dollars an hour when something breaks outside it, and a replacement cycle of five to seven years.
Renting it. Little or nothing upfront beyond handsets and configuration, then the monthly per-room or per-user fee, which includes maintenance, updates and support. No replacement cycle, because replacement is the provider's problem.
Now put actual numbers on a real building.
Working Out Your Own Crossover
Take a 150-room hotel and run both models over seven years, which is a fair life for a switch.
Cloud at ten dollars per room per month is 1,500 a month, so 18,000 a year, so 126,000 dollars over seven years.
Owning it at 60,000 dollars of capital, with a support contract at 9,000 a year, is 60,000 plus 63,000, so 123,000 dollars over the same seven years.
Within about three percent of each other. Which is the whole point of this article: at a typical mid-market rate the two models cost the same, so anyone telling you that moving to the cloud halves your telephony bill is describing an office, not a hotel.
What that arithmetic does show is where the sensitivity lives, and it is not where people look. Change the per-room rate and everything moves. At six dollars a room the cloud costs 75,600 over seven years and wins comfortably. At fifteen dollars it costs 189,000 and loses badly to owning. The single most consequential number in the entire decision is the per-room monthly rate, and it is negotiable, which is worth more attention than the feature comparison most tenders obsess over.
Two adjustments to that picture before you use it.
The first is cash flow, and for many properties it settles the matter regardless of the total. Sixty thousand dollars on day one is a different proposition from 1,500 a month, and a property that cannot raise capital, or that would rather spend it on rooms guests can see, will take the subscription even knowing the seven-year total is identical. That is a perfectly rational decision and nobody should apologise for it.
The second cuts the other way. Capital cost is fixed the day you sign. A subscription renews, and it gets repriced. Seven years is two or three renewal cycles, and the totals above quietly assume the rate never rises, which nobody believes. Ask for the renewal mechanism in writing and treat any answer softer than a capped percentage as an open-ended number in your model.
The Line Items That Are Not in the Monthly Price
The subscription is not the whole cost of the cloud option, and the gap tends to appear after the decision has been taken.
The connection is first. Cloud telephony puts your phone system on the far side of your internet link, so the resilience of that link stops being an IT preference and becomes the phone system's reliability. A second circuit from a different carrier, or a mobile data failover, is a recurring cost that a like-for-like comparison against an on-premise system does not carry, because an on-premise system does not need it to keep the building talking to itself.
Survivability equipment is second, and it has its own section below because it is the most consequential omission.
Then the smaller ones. Handsets, which are usually bought or rented separately and provisioned to the provider. Configuration and onboarding, sometimes waived in a competitive tender and sometimes not. Call recording storage, which is generally metered. Anything described as a premium or AI feature. Emergency calling service fees, which are levied per room per month in some markets. And the PMS integration, which is very often a separate paid item and is discussed below.
The useful discipline is to ask for a fully loaded monthly figure, per room, with every line named, and then compare that against a fully loaded on-premise figure that includes the support contract and an honest amortisation of the capital. Comparing a subscription against a purchase price alone will mislead you in whichever direction the salesperson prefers.
What Happens When the Line Drops
Here is where a hotel differs from an office badly enough that generic advice becomes actively misleading.
On a cloud-only system, when your internet connection fails, the handsets lose their registration with the platform and go silent. Calls in progress drop. Nothing on the desk rings. Anything living in the platform, which is the auto-attendant, the call queues and the voicemail, becomes unreachable from your building.
One part of that is better than people assume and worth understanding, because it changes what you should plan for. The platform itself does not go down. Your main number stays live in the provider's data centre, and inbound calls still arrive there. What has broken is the last leg, between the platform and your handsets. Which means calls to the hotel can be diverted, to mobiles, to another property, to voicemail delivered by email, provided somebody configured that in advance and tested it. Set up beforehand, an outage becomes an inconvenience rather than a silence. Not set up beforehand, callers hear ringing that nobody will ever answer.
The Call From Room 412 to Reception
Now the part that generic comparisons miss entirely.
In a cloud-only design, a call from a guest room to the front desk does not travel across the building. It travels out of the building, across the internet, to a data centre that may be hundreds of miles away, and back again to a telephone twenty metres from where it started. That is invisible and harmless while the connection is healthy.
When the connection fails, two telephones in the same building cannot reach each other. A guest in room 412 picks up the handset and gets nothing. They cannot call reception, they cannot call for help, and if they have no mobile signal, which is the reason many of them still use the room phone at all, they have no way to reach a member of staff except by walking. At three in the morning, that is not a service inconvenience.
An on-premise switch, or any design with local call control, keeps internal calling alive through an internet outage, because the switch is in the building and the call never needed to leave. Extension to extension keeps working as long as the local network and the power hold, which is a materially different risk profile.
This is the honest argument against cloud-only telephony in hospitality, and it is not an argument against cloud. It is an argument for making sure somebody has answered the question before you sign, because the answer is buyable.
Buying Your Way Back Out of It
The component that fixes this has several names, and you should learn one of them because it will not be on the first quote.
A survivable branch appliance, sometimes a local survivable branch or a session border controller with local survivability, is a small device that stays in your building. In normal operation it registers with the cloud platform and does very little. The moment it detects the platform is unreachable, it takes over local call control, so phones inside the building can still call each other. Paired with a local trunk or a mobile data connection, it keeps external calls working too, including emergency calls, which is the capability that matters most and the one to test rather than assume.
Underneath that, the connection itself can be made more resilient: two circuits from genuinely different carriers, mobile failover, and equipment that switches between them automatically before anybody notices. Survivability is only ever as good as the connectivity beneath it, and a backup circuit that shares a duct with the primary is not a backup.
The practical instruction is short. Ask every cloud provider what happens to internal calling during an internet outage. If the answer is a survivability appliance, ask whether it is in the quote, what it costs, and whether emergency dialling works through it. If the answer is a diversion to mobiles, note that this handles inbound calls from outside and does nothing whatsoever for a guest trying to reach reception from a room.
Groups, Estates and Acquisitions
Everything above is written from the perspective of a single building. Run more than one and the balance shifts, genuinely and substantially, toward the cloud.
A group with eight properties each running its own switch has eight capital cycles falling due at different times, eight support contracts with different suppliers on different terms, eight sets of local knowledge that leave when a maintenance engineer retires, and no consolidated view of what any of it costs. Nobody planned that. It accumulated, one property at a time.
One platform across the estate changes the operating model rather than just the invoice. Dial plans become consistent, so an extension number means the same thing everywhere and staff who move between properties do not relearn the phones. Administration becomes central and role-based, with corporate setting policy while a general manager still controls their own greetings, schedules and routing. Reporting consolidates, so telephony spend becomes one number somebody can actually interrogate. And the commercial relationship consolidates too, which is the part finance notices, because fragmented carrier contracts across regions are where unexplained line items live.
Acquisitions are the clearest case. Buying a hotel means inheriting whatever telephony it happens to have, and on a per-property model that means inheriting another contract, another vendor and another end-of-life date. On a group platform it means connecting a building. That difference compounds with every deal.
Seasonal capacity works better this way too. A resort that runs at a fraction of its rooms for four months a year has a case for negotiating something other than a flat per-room fee across the estate, and a group is large enough to be listened to when it asks.
So the rule of thumb: the more properties you run and the more distributed they are, the stronger the cloud case gets, and it is strong on operations rather than on the seven-year total.
The Shape Most Hotels Actually End Up With
Very few properties end up at either pure extreme, and it is worth knowing that before you frame the decision as binary, because a tender written as an either-or invites answers that ignore the sensible middle.
The common landing point looks like this. The platform is hosted, so patching, upgrades and hardware risk sit with the provider. A survivability appliance stays on site so the building keeps talking to itself when the connection fails. Gateways stay in the risers so the existing analogue handsets keep working without rewiring bedrooms, which is the same equipment that lets a hotel move its phones to VoIP without replacing the estate. And the connection has a second path.
That configuration takes most of what is genuinely good about the cloud and buys back the specific weakness that matters in a building full of sleeping guests. It costs more per month than the headline cloud figure, which is the reason it is not what appears on the first proposal, and it is usually the honest answer.
The corollary is a warning about comparing quotes. A pure cloud proposal and a hybrid proposal are not the same product, and the pure one will always look cheaper because it has less in it. Make every bidder price the same survivability position, or you are comparing a system that keeps working against one that does not.
The PMS Link, and Who Owns It Now
The interface between the phone system and the property management system is what separates hotel telephony from office telephony, and moving the switch off site changes who is responsible for it without changing what it has to do. How a hotel PBX system talks to the PMS, including the protocols and the heartbeat that keeps the link honest, is covered in full separately.
What changes in a hosted model is the shape of the problem. The link now runs between a data centre and your building rather than between two rooms in your basement, which means it depends on the same connection everything else does, and when it drops the failure is the quiet kind: the phones keep working, the PMS keeps working, and the switch simply stops learning who is in which room. Departed guests keep dialling out. New arrivals find a barred extension. Nobody notices until a guest complains.
So ask three things. Whether the integration is included or licensed separately, since it is very often a separate paid item and is the line most often missing from a first quote. Who monitors the link and who receives the alert when the heartbeat stops, because in a hosted model that is now genuinely ambiguous between two companies. And whether the provider has integrated with your specific PMS and version, rather than with your category of PMS.
If your PMS is Prostay, this is straightforward. Prostay integrates with the hotel phone platforms in common use, hosted and on-premise alike, and where a property runs something less usual, custom integrations are built around what the building actually has rather than around a fixed connector list. Scope that work with both vendors at the same time rather than after the platform is live.
Lock-In, and What It Costs to Leave
An owned switch has an obvious form of lock-in: you paid for it, so you will keep it until it is worn out. That is visible, it is finite, and it ends.
Subscription lock-in is less visible and does not end by itself, which is why it deserves reading properly at the point where you still have something the vendor wants, meaning before you sign.
Published provider terms are consistent about the mechanics. Contracts commonly renew automatically. Leaving requires written notice, usually 30 to 90 days, delivered through a specified channel rather than mentioned to your account manager. Outstanding charges accelerate on termination. And handsets are frequently provisioned to that provider, so a set of phones you paid for may not work on the next platform without being re-flashed, if they can be at all.
Getting Your Numbers Back
Your main number is the asset in this relationship, and the terms around it are worth quoting almost verbatim because they surprise people.
Providers will support a port-out, and they will also tell you plainly, in the contract, that they accept no responsibility for delays in the process and will issue no credit for one. Meanwhile you remain liable for all monthly and usage charges until the port actually completes. Read those two clauses together and the shape is clear: a slow port costs you money and costs them nothing.
There is a practical trap in the sequencing too. You must have the new service installed and active before the switch date, so for a period you are paying two providers, and if the new equipment is not ready the port fails and reschedules. Providers also reserve the right to refuse to import a number they cannot support.
None of that is unreasonable, and all of it is normal. But it means an exit takes months rather than weeks, and it means the moment to negotiate exit terms is at signature, when they want your business, and never afterwards. Ask for the port-out process and its timescale in writing, and ask what happens to your numbers if the provider fails commercially, which is the scenario nobody puts in a proposal.
What an Uptime Promise Is Actually Worth
Every hosted provider will quote a number with a lot of nines in it, commonly 99.99 percent and sometimes 99.999. Those are real engineering commitments about geographically redundant infrastructure and they are not marketing inventions. They are also worth less to you than they appear, for two reasons.
The first is that they describe the platform, not your service. The most likely thing to fail is the link between your building and that data centre, which is nothing to do with their uptime figure and everything to do with your circuit. A provider can be at five nines while your hotel has no phones.
The second is the remedy. Where an agreement offers compensation, it is normally a service credit calculated pro rata against your monthly fee, it is usually expressed as the sole remedy, and it must be claimed within a stated window with supporting evidence. A day of outage buys back roughly a day of subscription. On a 150-room property at ten dollars a room that is about fifty dollars, against a day of guests unable to call reception. The credit is not compensation and was never designed to be.
So read the agreement for what it tells you about the provider's confidence rather than as insurance. What you actually want is a right to terminate without penalty if service falls below a threshold repeatedly, which is worth considerably more than credits and is much less commonly offered. Ask for it anyway.
Which Model Suits Your Property
Sorting by property type gets you further than any feature matrix, because at the category level every vendor ticks every box.
A small independent with no technical staff should probably go hosted, and the reason has little to do with cost. It is that owning a system means depending on a local engineer who may or may not exist, and a platform run by the people who built it removes that dependency. Add a survivability appliance and accept the monthly cost as the price of not having to think about it.
A mid-size single property with competent support nearby is the genuine toss-up, and the one where the arithmetic above matters most. Get a real per-room quote, run your own seven-year comparison, and then decide on the things money does not settle: whether you would rather hold capital or spread it, and how much you care about internal calling surviving an outage.
A large single property tilts toward owning, because the per-room subscription scales with a building that is already large while the capital cost of a switch does not scale nearly as fast. Above a few hundred rooms the subscription arithmetic gets steadily harder to defend on a seven-year view.
A group of any size tilts hard toward a single hosted platform, for the operational reasons above rather than the financial ones. Standardisation, central administration, consolidated reporting and easier acquisitions are worth more than the per-room delta.
A property with an unusually poor or single-path internet connection should either fix that first or stay on premise. Moving telephony onto a connection you already do not trust converts an IT problem into a guest safety problem, and no amount of feature comparison changes that.
A property mid-refurbishment has a genuine reason to reconsider everything at once, since the walls are open and the marginal cost of cabling is at its lowest point in a decade.
Questions to Ask Before You Sign
Take these into the room and make somebody answer them aloud.
Is this priced per room or per user, which extensions count, and what happens to rooms that are out of service or to a wing we close seasonally? What is the renewal mechanism, and is there a cap on increases? What is the fully loaded monthly figure with every line named, including handsets, onboarding, recording storage and any per-room service fees?
What happens to internal calling when our internet connection fails? Is a survivability appliance included, what does it cost, and does emergency dialling work through it? Does this price assume a second circuit, and if so whose cost is that? What have you measured on our connection rather than assumed?
Is the PMS integration included or licensed separately, have you integrated with our specific system and version, and who receives the alert when that link stops? Who is accountable when the phones fail and the answer is ambiguous between you and our internet provider?
What notice is required to leave, through what channel, and does this renew automatically? What is the port-out process and how long does it take? Are the handsets locked to your platform? What is the uptime commitment, what is the remedy, and can we terminate without penalty for repeated failure? What happens to our numbers if you cease trading?
As always, the hedging is the information.
The Decision Is About Who Carries the Risk
If the seven-year totals land within a few percent of each other, and at a typical mid-market rate they do, then price has quietly stopped being the deciding factor and something else has to decide it instead.
What you are actually choosing is where the risk sits. Own the switch and you carry the capital, the hardware, the obsolescence and the need to know somebody who can fix it, and in return the building keeps talking to itself no matter what happens outside. Rent it and you hand all of that to a provider who does it better than you would, and in return you accept that a cut cable somewhere else can silence every telephone in the building unless you have spent money to prevent it.
Neither is the wrong answer. What is wrong is choosing between them on a slide claiming half your costs will disappear, because in a hotel they will not, and the number that would have told you so was the per-room rate nobody negotiated. Get a real quote per room. Run seven years. Ask what happens to the call from room 412 to reception when the line goes down. Those three things will tell you more than any comparison table, and they are the ones a vendor will not volunteer.
