A hotel phone system touches every room, runs for fifteen or twenty years, and gets replaced roughly twice in a career. Which means almost nobody doing the buying has done it before. The vendor knows their product and the integrator knows their install, and the gap in the middle, where somebody has to judge whether the quote is sensible, is where the expensive mistakes live. This is a plain guide to what a hotel PBX actually does, how it talks to your property management system, which brands are worth shortlisting and why, and what an installation really involves.
Worth saying at the start what this is not about. Guest communication has largely moved to messaging and email, and that is not going to reverse. The phone system is no longer how you talk to guests. It is the plumbing underneath a handful of jobs that still need doing, and the useful question is what to buy for those jobs rather than whether to fight the tide.
What a Hotel PBX Actually Does
PBX stands for private branch exchange, a name left over from when telephone exchanges were public and enormous and a private one meant you had your own. Functionally it is the switch that owns every extension in the building.
It knows that extension 214 is a guest room and extension 8 is the kitchen. It decides that the guest room may dial reception and the outside world but not the plant room, and that the kitchen may not dial internationally at all. It routes an incoming call to the operator, then to a room, then to voicemail if nobody answers. It writes a record of every call that completes. And in a hotel it does one more thing that a PBX in an office block never has to do, which is stay synchronised with a database of who is currently sleeping in which room.
That last responsibility is what makes hospitality telephony a specialism rather than a configuration. An office PBX maps extensions to employees, and employees change a few times a year. A hotel PBX maps extensions to guests, and the guests change every single day, sometimes twice in a day, at a rate no human could maintain by hand. Almost everything distinctive about a hotel phone system follows from that one fact, including why a general-purpose business phone system with a hotel brochure attached will disappoint you.
Why the Phone Is Still in the Room
Guests do not make paid calls from hotel rooms. They carry a device with better call quality, cheaper international rates and their own contact list, and telephone revenue as a department is, for practical purposes, finished. Any business case built on recovering it is fiction, and vendors who lead with call revenue are quoting from a deck written in 2006.
So the phone stays for other reasons, and they are worth listing because they determine what you actually need to buy.
The front desk still receives a surprising volume of outside calls, and the switchboard function is the busiest part of the system in most properties. Internal communication between departments runs on it, particularly in buildings where mobile coverage is patchy in the basement, the plant room or the back of the kitchen. Lift phones are generally a requirement of the lift certification rather than a hospitality choice, and they usually terminate on the same system. Guests with accessibility needs may rely on a fixed handset with hearing aid coupling. Room service and housekeeping requests still arrive by phone from a meaningful share of guests, particularly older ones and particularly at properties where nobody has been offered an alternative. And guests do occasionally need to reach somebody urgently from a room where their mobile has no signal or a flat battery.
None of that generates revenue. All of it generates complaints when it is missing. The practical consequence is that you are buying a utility rather than an amenity, and the buying criteria should look like the ones you would apply to a lift or a boiler: reliability, supportability, parts availability, and a sensible answer to what happens when it fails.
What Happens When Somebody Dials the Room
It helps to follow one call end to end, because every feature in the rest of this article sits somewhere on that path.
An outside caller dials your main number. The call arrives over whatever connects your building to the outside world, which historically was a bundle of physical lines and today is more often a digital trunk delivered over your internet connection. The switch answers and decides what to do with it: ring the operator, present an automated menu, or route straight through if the caller dialled a direct number that belongs to a specific extension.
Say it rings the operator. The receptionist sees the call arrive, asks who the caller wants, and transfers to room 214. Here the switch does two things worth noticing. It checks whether 214 is currently occupied, which it only knows because the PMS told it, and it checks whether the room is set to do not disturb. If the guest does not answer within a set number of rings, the call goes to voicemail, and the message waiting lamp on the handset in the room lights up.
Now reverse it. The guest picks up and dials 9 for an outside line, or whatever your numbering plan uses, and calls a mobile abroad. The switch checks the calling class attached to that extension, decides whether an international call is permitted for this room, connects it if so, and writes a record when it ends: which extension, which number, how long, at what time. That record is what gets priced and sent to the folio.
Three systems touched, one call. The trunk that brought it in, the switch that routed it, and the PMS that told the switch who was in the room. Most of what goes wrong with hotel telephony is one of those three not knowing what the other two are doing.
The Link Between the Phone System and the PMS
The feature that separates a hospitality PBX from an ordinary one is the live link to the property management system. Without it, somebody has to tell the phone system by hand that room 312 is now occupied by a guest who should be allowed to dial out, and then tell it again tomorrow when they leave. At twenty arrivals a day that is not a workflow, it is a full-time job nobody is doing.
With the link, a check-in in the PMS reaches the switch within a second or two and does several things at once. The extension is unbarred to whatever calling class the rate or guest type allows. The guest's name is attached to the extension, so the operator sees who is calling before answering, which is the single most visible quality-of-service feature in the whole system. Voicemail is enabled and any messages left for the previous occupant are cleared, which matters more than it sounds. At checkout the whole set reverses.
This is the part of the project most likely to go wrong, and the part vendors are vaguest about in proposals. Treat it as the first question rather than the last.
Why Almost Everything Speaks Fidelio
Ask a telecoms engineer how a PBX talks to a hotel system and the answer will almost certainly be FIAS, the Fidelio Interface Application Specification. It originated with MICROS-Fidelio, passed to Oracle with the acquisition, and became the closest thing hospitality telephony has to a common tongue. Oracle publishes the specification, and it covers Oracle Hospitality Suite 8 and OPERA from version 4 onward.
It is not a modern API and does not pretend to be. FIAS runs over TCP/IP and exchanges typed records, each a short string of field codes. A check-in is a GI record. A checkout is GO. A change to guest details is GC. Room status is RS, a posted charge is PS, and a request to resynchronise the whole database after an outage is DR. Inside those records the fields are equally terse: RN for the room number, GN for the guest name, G# for the reservation number.
It looks archaic because it is, and that is also why it works. A protocol this narrow is easy to implement, easy to log and easy to debug at three in the morning with a packet capture and a printed specification. Vendors have supported it for decades and the installed base is enormous.
FIAS is not universal. Some large brands run their own protocols, and Hilton's PEP is the one most integrators will name without prompting. Mitel's platform, for instance, supports FIAS, Hilton PEP and its own native protocol, with separate arrangements again for the voicemail side. Newer vendors increasingly offer a REST API alongside FIAS for anyone who would rather not implement a specification written for serial links. The practical consequence for a buyer is singular and important: find out which protocol your PMS actually speaks, and get the vendor to confirm they have integrated with your specific system and version, not merely with your category of system.
If your PMS is Prostay, this part is straightforward. Prostay integrates with the hotel PBX platforms in common use, 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 switch is on the wall, for the reason given later about interface licences going missing on the day they are needed.
The Heartbeat That Tells You It Broke
The link maintains itself with a heartbeat, and understanding it is worth the two minutes it takes.
The two systems open the connection with a Link Start record, describe what they support, and then keep confirming they can still hear each other with Link Alive records. If the answer stops coming, the link is dead. When it comes back, one side asks for a database resync so the phone system can rebuild its picture of who is currently in the building.
Why this matters on the floor: when the link dies, nothing appears to break. The PMS carries on checking guests in. The phones carry on working exactly as they were. What has actually happened is that the switch has frozen its picture of the hotel at the moment the link dropped. Departed guests keep their extensions unbarred and their voicemail live. New arrivals find a phone that will not dial out and a mailbox with somebody else's messages in it. Nobody notices until a guest complains, which is usually the following morning.
The fix is to monitor the link rather than the phones. Whoever supports your PBX should be alerting on the heartbeat, not waiting for the front desk to report that a room cannot call reception. Ask how that alert reaches a human, and ask when it was last tested.
What Actually Crosses That Link
Beyond check-in and checkout, the interface carries a set of transactions that vary by vendor but cluster around the same list.
Wake-up calls. Set at the desk or by the guest from the room, held by the phone system, and reported back so the PMS knows whether the guest answered. The reporting half is the useful part, because an unanswered wake-up call at five in the morning before an airport transfer is an event somebody should physically check.
Room status from the handset. A housekeeper finishing a room dials a short code from the room phone and the status changes in the PMS. This predates housekeeping apps by decades and still has one advantage over them, which is that it needs no device, no login and no battery. Plenty of properties run both.
Call charges. The switch produces a record for each completed call, prices it against a tariff table, and posts it to the guest's folio. In an era when almost nobody makes chargeable calls, the main function of this path now is to make sure the occasional call that does happen reaches the bill rather than disappearing.
Minibar and other room postings. Some systems let a housekeeper post a minibar item by dialling a code, using the same channel as room status. This is common in properties that never adopted mobile housekeeping and it works well enough, although it produces charges nobody can later explain unless the codes are documented somewhere other than in one supervisor's head.
Message waiting and do not disturb. The lamp on the handset and the setting that stops the phone ringing, both of which the PMS may need to see and set.
None of that list is exotic and all of it is decades old. What varies is which items a given vendor implements, and whether they arrive included or as a licensed module. That is a question for the proposal, in writing.
The Features Worth Paying For
Strip out the marketing and a hotel phone system needs to do a shortlist of things properly.
A PMS interface in the protocol your PMS speaks, confirmed against your specific system and version. This is the first question, not the last.
Guest name display at the operator position. The receptionist should see who is calling from a room before they answer. It is a small thing that changes the tone of every internal call.
Class of service per extension, so a guest room, a meeting room, a back office and a public area phone can each be allowed a different set of destinations. This is also your main defence against toll fraud, which is not a historical curiosity. An unsecured extension that can dial internationally is still a target, and the bill arrives before anybody notices.
Call detail records you can actually read, both for billing the rare chargeable call and for answering the question of what happened during an incident.
Wake-up handling with failure reporting. The reporting matters more than the scheduling.
Survivability. What the system does when its uplink, its server or its power fails. Ask specifically what still works during an outage, because a phone system that dies with the internet is a different risk profile in a hotel than in an office.
Direct emergency dialling. A guest should reach emergency services without needing a prefix first, and the desk should be alerted when someone does. Current platforms handle this by default, but on an older system it is worth testing rather than assuming.
Auto-provisioning of handsets, because configuring two hundred phones individually is a week of somebody's life.
What You Will Be Sold and Never Use
Proposals for hospitality telephony tend to arrive padded with capability lifted from the enterprise product, and it is worth knowing what to decline.
Elaborate contact centre features, including skills-based routing and queue analytics, unless you genuinely run a reservations department of a size that needs them. Video calling on room handsets. Full unified communications licences for every guest extension, when a guest extension needs to make calls and receive them and nothing else. Voicemail-to-email for rooms, which sounds sensible until you notice guests do not read a mailbox they did not know they had. Presence and instant messaging across the whole staff estate, when your team already coordinates on something else. Analytics dashboards measuring metrics from an office context that mean nothing in a corridor.
The useful test is to ask, for each line on the quote, which member of staff will use it and on which shift. Anything that cannot be answered concretely is negotiable, and in a competitive tender it usually disappears.
The Brands That Actually Serve Hotels
What follows is a working map rather than a scorecard. Every vendor here has a genuine hospitality story rather than an enterprise product with a hotel brochure attached, and each entry says where it fits and where it does not, because a comparison in which everybody is excellent is worth nothing.
Mitel
Mitel is the name most hospitality integrators reach for first, and with reason. Its MiVoice Business platform carries the deepest hospitality feature set among the traditional vendors: it supports FIAS, Hilton PEP and its own native PMS protocol, handles the voicemail side of check-in and checkout as a distinct integration rather than an afterthought, and covers the full working vocabulary of guest name display, room status, class of service and message waiting.
It suits larger properties, groups, and anywhere a brand standard dictates the platform. The hospitality capability is mature in the sense that the awkward cases have been met before, which is worth a lot on a complex site.
The trade-offs are real. It is not the inexpensive option, and its ecosystem runs entirely through partners, so your day-to-day experience depends heavily on which integrator you get rather than on the badge. Two properties running identical Mitel platforms can have completely different support experiences. Vet the partner at least as hard as the product.
Alcatel-Lucent Enterprise
Alcatel-Lucent Enterprise has a long hospitality installed base, particularly across Europe, the Middle East and Asia. If you have bought or refurbished a European hotel in the last two decades there is a reasonable chance you already own one, which makes it a common incumbent as much as a candidate.
It suits mid-size and larger properties in those regions, where the partner network is dense and parts and expertise are easy to come by. The hospitality feature set is comparable to Mitel's for practical purposes, and where a property already has the platform, extending it is usually cheaper and less disruptive than switching.
Outside its strong regions, support depth thins noticeably. Selecting it fresh in a market where the partner network is sparse means accepting longer response times and a smaller pool of engineers who have done a hotel before. Check who would actually turn up before you shortlist it.
NEC
NEC occupies similar ground with a strong presence in Asia-Pacific and a well-earned reputation for hardware that keeps running long past the point at which anyone is still enthusiastically supporting the software.
It suits properties in its strong regions, and it suits operators who value longevity over feature velocity. NEC systems tend to be found still working in buildings where three generations of management have come and gone.
The caution is the same one that applies to any platform bought primarily for durability. Confirm the roadmap and the support horizon for the specific model being quoted, and confirm that the hospitality module and the PMS interface are covered by that horizon rather than merely the hardware.
Cisco
Cisco appears in hotels mainly where the property belongs to a larger corporate estate whose IT department has already standardised on it, and that is the context in which it makes sense.
The strength is integration with everything else that department already runs, plus a very deep bench of engineers who know the platform, because the platform is everywhere.
The weakness for hospitality specifically is that the hotel features generally arrive through a third-party middleware layer rather than natively. That adds a component to buy, a component to maintain, and a support boundary that becomes interesting when the PMS link fails and two vendors each believe the problem belongs to the other. It is a reasonable choice in the right corporate context and rarely the obvious one for an independent.
Yeastar
Yeastar is the most interesting entrant for independents and small groups, and it is the one most likely to be unfamiliar to somebody who last bought a phone system fifteen years ago.
Its P-Series carries a hotel management module inside the platform itself rather than as a bolted-on layer, so check-ins, room assignment, wake-up calls and room status are handled from the same interface as the telephony. It integrates with OPERA and other FIAS systems directly, without separate middleware, and offers open APIs for anything custom. It handles a mix of analogue and IP endpoints, which matters if you are keeping existing phones, and it auto-provisions handsets from the usual hospitality manufacturers so a large rollout does not become a week of manual configuration.
Two things to check in the quote. The hospitality PMS integration is a paid add-on subscription rather than part of the base licence, so confirm it is priced in. And the support model is partner-led, so the same caution applies as with Mitel: find out who supports it in your city.
3CX
3CX is widely deployed, inexpensive and flexible, with hospitality functionality available and a very large reseller base.
It suits smaller properties that have competent local IT support, or an owner who is comfortable enough with technology to engage with the platform. The economics are hard to argue with at the small end, and the flexibility means it can usually be made to do what you need.
It suits you considerably less if nobody on site is comfortable with the system. Flexibility cuts both ways, and a platform that can be configured many ways is a platform that can be configured badly. Where Mitel or Alcatel would arrive as an engineered solution, 3CX often arrives as a capable toolkit. Budget for the expertise rather than assuming the software replaces it.
Grandstream
Grandstream sits at the budget end of the market with capable hardware and an unusually wide gateway range, which is the detail that matters most for hotels.
It suits small independents, and it suits any property trying to keep a large analogue estate alive without replacing every handset in the building. The gateway range means there is usually a sensible way to connect what you already own.
Expect a product rather than a solution. Hospitality features are thinner than the specialists offer, documentation assumes more of you, and the PMS integration story is less mature. For a thirty-room property with a technically confident owner it can be excellent value. For a two-hundred-room hotel with a complex PMS interface it is the wrong tool.
Avaya and Panasonic, and What to Do If You Have One
Two names you will meet constantly in existing buildings but which are hard to recommend for a new installation.
Avaya has an enormous hospitality installed base and the platforms themselves are capable, but its corporate turbulence makes it a difficult thing to select fresh today. Panasonic is similarly present everywhere in older properties while having stepped back from the market.
If you already have one, the sensible posture is neither panic nor loyalty. Treat it as an asset to run down rather than extend. Establish now what spare parts you hold and what a replacement handset costs on the secondary market, because that is what determines how long you actually have. Do not sink money into significant expansion of a platform you will replace within a few years, and do fold the eventual replacement into the next refurbishment cycle rather than treating it as an emergency when something finally fails.
Which One Suits Your Property
Feature matrices are close to useless here, because every vendor ticks every box at the category level and the differences live in the detail underneath. A more useful approach is to sort by what your property actually is.
An independent under about fifty rooms wants the fewest moving parts it can get away with. A platform with the hotel module built in, rather than assembled from a PBX plus middleware plus an integration licence, will cost less and break in fewer places. Yeastar and 3CX both fit, and Grandstream fits if the estate is analogue and the budget is tight. The deciding question is usually who supports it locally, not which product wins on paper.
A mid-size independent or small group starts to care about consistency across properties and about the PMS interface being genuinely supported rather than theoretically possible. This is where paying for a proper hospitality platform begins to earn its keep, and where the integrator matters as much as the badge.
A branded property frequently has the decision made for it, either by an approved vendor list or by a protocol requirement such as Hilton PEP that narrows the field immediately. Check the brand standard before shortlisting anything, because discovering it afterwards wastes a tender.
A property inside a corporate estate should at least price the option its IT department already runs, even if the hospitality features need middleware, because shared support and shared expertise can outweigh a better-fitting product nobody in the group knows.
A property with a large analogue estate has a different question entirely, which is not which PBX but how much of the existing in-room hardware survives. Two hundred analogue handsets and the cabling behind them represent real money, and gateways that let them keep working against a modern switch are often the difference between a project that happens and one that gets deferred again.
Whatever the shortlist, ask every vendor for two reference sites of similar size and type, in your region, and actually call them. Ask those references one specific question: what broke during the cutover. The answer tells you more about the integrator than any proposal does.
What Goes on the Nightstand
The handset is where most of the money hides, and where guests form the only opinion they will ever have about your telephony.
The first fork is analogue or IP. Analogue phones are cheap, effectively unbreakable, need no configuration and keep working when the network does not. They connect through gateways that present them to a modern switch, and for a property with existing cabling this is very often the economically correct answer, whatever a vendor's roadmap suggests. IP handsets take an ethernet drop, usually powered over the same cable, and offer better audio along with features guests will not use. The main argument for IP in rooms is that you are already running data cabling to the nightstand for other reasons.
The hospitality handset market itself is narrow and specialised. Vtech is the volume leader in guest room phones, with Fanvil, Snom, Grandstream and Yealink covering much of the IP side. Hospitality models differ from office ones in ways that matter operationally: programmable one-touch keys labelled for reception, room service and housekeeping, a message waiting lamp visible from the bed, hearing aid compatibility, and a build that survives being knocked off a nightstand by somebody reaching for it half asleep.
Three practical points. Insist on auto-provisioning, for the reason given earlier. Cordless handsets in suites need a plan for charging and for batteries, which have a life measured in a couple of years and will all fail in the same season. And whatever you buy, buy spares in the same batch, because hospitality handset models are discontinued quickly and a matched replacement in three years is not guaranteed.
What the Installation Actually Involves
Telephony projects have a reputation for going badly, and it is mostly deserved, but the failures are predictable and therefore avoidable.
Survey first, and survey honestly. Somebody has to physically establish what cabling exists, what condition it is in and where it terminates. In older buildings the drawings are wrong. There will be cables nobody can identify and rooms wired through a route that made sense during a refurbishment in 1998. This survey is the single highest-value day in the project and the one most often skipped to save money, which is also why so many of these projects overrun.
Agree the numbering plan before anything is configured. Which extension corresponds to which room, what the operator is, what internal codes exist for departments, what housekeeping dials for each room status. Write it down and keep it somewhere other than the integrator's laptop.
Sort the PMS interface early. Establish which protocol, which licence, at which end, and who supplies it. The interface may need a licence on the PMS side as well as the phone system side, and this is the item most likely to be missing on the day it is needed. Get it in writing in the proposal.
Configure and test off-line. A modern platform can be built and mostly tested before it touches a live room, including the PMS link, against a test property if your vendor can provide one.
Then cut over.
The Cutover, Which Is the Only Hard Part
Everything else is preparation. The cutover is the night the old system stops and the new one starts, and it is where hotels differ fundamentally from offices, because you cannot do it at the weekend when the building is empty. The building is never empty.
Do it in the lowest-occupancy week you can find, which for most properties is a known season. Do it floor by floor rather than all at once, so a failure affects thirty rooms and not three hundred. Keep the old system alive and reversible until the new one has survived a full day including a check-in rush and a night audit. Have someone physically walk the floors testing handsets, because a phone that appears configured and does not actually work looks identical from a screen.
Test in this order: an outside call in and out, room to reception, reception to room, a check-in through the PMS with the extension unbarring, a checkout with it barring again, guest name appearing at the operator position, a wake-up call, a room status code from the handset, and a call record reaching a folio. Anything that fails goes on a list with a name against it before the next floor starts.
Brief the front desk and the night team before the night rather than during it. They are the people who will field every confused guest, and they need to know what changed and what to say.
Where the Money Goes
Currency figures for hospitality telephony are close to meaningless across regions, so what follows is structure rather than numbers, which is the part that transfers.
Platform licensing is normally priced per extension or per room, so it scales with the building rather than with usage. The hospitality or PMS integration module is very frequently a separate paid item, sometimes an ongoing subscription, and this is the line most often omitted from a first quote. Handsets are per room and, in a full replacement of an analogue estate, routinely exceed the cost of the software. Gateways are per port when you are keeping analogue phones alive, and cheaper in aggregate than replacing them. Cabling is the wild card, ranging from nothing to a genuinely large number depending on what the survey finds. Professional services cover configuration, the numbering plan, the interface and the cutover. And then there is an annual support contract, which is where the long-term cost of ownership actually lives.
The pattern worth internalising is that the switch itself is rarely the expensive part. The building is. Anyone quoting a per-room figure without having surveyed your cabling is quoting a guess, and the variance in that guess is larger than the entire software line.
When to Replace and When to Run It Down
Not every ageing phone system needs replacing, and the industry has an obvious interest in telling you otherwise. A few signals genuinely distinguish the two cases.
Replace when the PMS interface no longer works or was never installed, and the desk is maintaining room states by hand. Replace when spare handsets are no longer obtainable and you are buying used ones from the secondary market to fill gaps. Replace when the vendor has exited support entirely and nobody local will touch the platform, because at that point a failure is not a repair but an emergency procurement. Replace when a refurbishment is already opening the walls, since the marginal cost of doing the cabling then is a fraction of doing it later.
Run it down when the system does the jobs listed earlier, parts are still available, somebody local supports it, and the only complaint is that it looks dated. Handsets can be replaced without replacing the switch, which is a much cheaper way to address the appearance problem. A working platform with five years of parts availability ahead of it does not need to become this year's capital project.
The middle case, which is the common one, is a system that works but is nearing the end of its supportable life. There the right move is usually to plan the replacement into the next refurbishment cycle and start the vendor conversation early, rather than waiting for a failure to make the decision for you at the worst possible moment.
Where the Phone Bill Ends Up
Assume a guest does make a chargeable call. The switch records it, prices it against a tariff table, and passes it across the interface to be posted to the folio, where it sits alongside every other incidental until checkout.
The failure mode is timing rather than accounting. Call records are often batched rather than posted the instant a call ends, so a call made at eleven at night can reach the folio after the guest has already settled and left. At that point it cannot go back on a closed bill, and the route for a late charge is a house account, which is a folio that exists without anybody in a room and can be invoiced separately. Prostay works exactly this way: a phone bill that arrives late is posted to a house account rather than reopening a folio the guest has already agreed and paid.
Whether chasing it is worth the effort is a separate question, and for a small call it usually is not. Which is the honest reason many properties now bar chargeable outbound calling from rooms altogether, keep internal and emergency calling open, and remove an entire category of billing dispute in the process. If your call revenue is negligible, that is a defensible policy rather than a surrender, and it simplifies both the night audit and the conversation at checkout.
Questions to Ask Before You Sign
Take this list into the meeting.
Which PMS protocol does this use, and have you integrated with my specific PMS and version before? Is the hospitality module included or licensed separately, and is that a one-off or a subscription? Is an interface licence required at the PMS end, and who supplies it? How is the link monitored, who receives the alert when it drops, and how quickly?
What happens to the phones when the internet goes down, when the server fails, and when the power fails? Which handsets are supported, are they auto-provisioned, and how long will the model you are quoting remain available? What in my existing cabling and hardware survives, and have you surveyed it or estimated it?
Who performs the cutover, at what hour, and what is the rollback if the first floor goes badly? Who supports this afterwards, are they local, and what are the response times in the contract rather than in the brochure? Can I speak to two properties of my size in my region that you installed?
Any vendor who answers all of those without hedging is worth shortlisting. The hedging itself is the information.
Getting It Right Once
A hotel phone system is a utility, and the goal is a system nobody has to think about. That sounds like a low bar and it is not, because getting there means the boring parts were done properly: the cabling was surveyed rather than assumed, the numbering plan was written down, the PMS interface was tested against your actual system before the cutover night, and somebody local knows the platform well enough to fix it on a Sunday.
The choice of brand matters less than most tenders assume. Any of the specialists here will run a hotel competently. What varies far more is who installs it, who supports it, and whether the interface work was treated as the first question or discovered at commissioning. Spend your attention there, and the box on the wall will do its job quietly for the next fifteen years, which is the entire point.
