Hotel Phone Systems: How PMS Integration Actually Works

Most hotel phone system projects fail at the interface between the property management system and the PBX, not inside the phone system itself. The calls work, the room phones light up, and then the wake-up call a guest requested at the front desk never arrives, or the guest's charges land on the wrong folio, and nobody can say which side of the interface dropped the message.

Definition: A hotel PBX system is the voice platform for a property — room phones, front desk extensions, departmental lines and outside calling. A hotel VoIP PMS integration is the layer that carries guest and service data between that platform and the property management system (PMS) that owns room status, guest profiles and the folio.

What a PMS Integration Actually Does

The PMS is the system of record for the hotel: which rooms are occupied, who is in them, what has been charged. The phone system is a separate platform with its own idea of extensions, permissions, routing and call records. On its own it knows nothing about a guest arriving or a call that should be billed to a room rather than to the front desk.

An integration closes that gap in both directions. Data flowing one way only produces a phone system that is confident and a PMS that is blind.

The two-way data exchange

New Rock's PMSI hotel middleware is described on the product page as middleware for interfacing OM IP-PBX with a third-party hotel management system, achieving information interaction between OM and the PMS. The described mechanics define what the integration can and cannot do for you.

• When PMSI receives configuration instructions from the hotel PMS, it converts the information and sends it to the OM API interface for voice function setting, including wake-up call service, extension permission, do-not-disturb mode and display caller name on extension. After the configuration it sends the setting results back to the PMS.
• It receives call billing information from the OM API interface and sends it to the PMS.
• Multiple OM IP-PBX can be connected to one set of PMS.

Two observations follow. The integration is API-driven in both directions, so the PMS pushes service changes and pulls results back rather than the PBX polling a database. And the supported voice functions are enumerated, which means anything outside that list is work you scope separately.

Middleware sits between two systems and translates, which is also where it fails. The interesting failures are not crashes; they are partial states. The PMS believes a do-not-disturb flag is set on a guest room and the PBX has no record of it, because a configuration instruction was converted incorrectly or the result confirmation was lost.

Treat the result path as part of the design. If the PMS cannot see confirmation that a setting was applied, reconciliation has to be manual, and the person doing it is usually the front desk manager. Ask the PMS vendor what they do with an unacknowledged message.

On the PBX side, the platform needs to be willing to be driven. The OM20G IP-PBX provides an XML/HTTP-based RESTful API for third-party applications and lists add-on middleware for hospitality applications among its features, which is what lets a middleware sit alongside voice features rather than in front of them.

Room Phone Design: Numbers, Services and Billing

Room phones are the part of the system a guest touches, and they are also where the numbering and billing decisions become visible. Guest-facing behaviour changes with the property's service model and with the PMS.

Room numbers and extension mapping

The first structural decision is whether a room is one extension or a set of them, and it follows the billing model rather than the phone model. A room that can place a call needs a number the carrier can present and the PMS can attribute. A room that only receives may not need one.

• Map every room to an extension that the PMS can hold as a guest record, so that a billable call has a room attached to it before the call ends rather than being reconstructed afterwards.
• Keep the guest-visible number tied to the room, so that when the extension is reprogrammed for a maintenance state the caller-facing identity does not change with it.
• Make sure the room extension can be enabled or disabled by the PMS. Extension permission is explicitly handled by PMSI, and in practice this is the control that stops a room phone from being used after checkout and before the next arrival.
• Decide who owns calls placed from a room when the guest is not in it. A call billed to a folio that has already been closed creates a dispute that costs more to resolve than the call did.

Guest services sit on top of this. The MA50-LS local survivability branch exchange is a branch unit, but its feature list is a useful reference for what a guest-facing platform is expected to carry: auto attendant, call forwarding, call transfer, high-speed fax, emergency call and three-way calling.

Billing is the part that cannot be approximated. The PBX records the call, reports the billing information through the API, the middleware forwards it, and the PMS posts it to the folio. The last step belongs to the PMS, which is also where the tax treatment and service charge rules live.

Test this path end to end before the property opens, with calls in each category you bill differently: local, long distance, international, and service calls that should be absorbed rather than charged. The failures that matter are rarely the obvious ones. A call that crosses midnight, a call placed from a room phone momentarily associated with the wrong room record, or a service number that appears twice on the folio are the errors that show up in a guest complaint weeks later.

Record retention has a separate path from billing. The RMS recording management system collects, stores, queries and manages recordings from OM series IP-PBX and MX series gateways, and properties that need them for disputes usually index them against the same guest or room reference the billing uses.

Wake-up, Do-Not-Disturb and Room Status

Wake-up calls are the classic PMS integration feature because the request arrives at the front desk, where staff have no reason to know the PBX's internals, and the outcome has to be reliable enough to defend in a complaint. The request has to reach the room phone, and the guest has to be woken up.

The PMS sends the instruction; PMSI converts it and pushes it to the OM API as a wake-up call service setting; the PBX applies it to the extension; the result is reported back to the PMS. Two things should be checked. First, that a guest who asks for a wake-up call from a phone in the room, rather than from the front desk, produces the same result in the PMS. Second, that a cancelled wake-up call actually replaces the earlier one rather than leaving two requests armed on the same extension.

Do-not-disturb mode is in the same group, and it is a privacy control rather than a convenience feature. It needs to work in both directions: a guest pressing DND on the room phone expects the PMS to know, and a staff member setting DND at the front desk expects the room phone to be unreachable. If only one direction works, the discrepancy shows up as a missed call to a guest who was visibly unavailable, which is the kind of failure that ends with a compensation request.

Caller name display on extension matters here too. PMSI supports display caller name on extension as one of the configured voice functions, which lets a guest phone identify who is calling instead of presenting a number they cannot interpret.

Room status is the reverse flow. The PMS knows whether a room is occupied, vacant, dirty or in service, and that state has to reach the phone system if the phone system is going to reflect it. Ask specifically whether the status change is pushed on every transition or polled on a cycle, and what the property does when a room phone is found with a state that disagrees with the PMS. In a busy hotel, the housekeeping team's own device is often the authoritative source for the room's service state, and the phone system may be the one that has to be told.

Front Desk, Housekeeping and Maintenance Workflows

The PMS integration is only one part of the operational picture at a property, and the workflows around it decide whether the interface is useful or just present.

• Front desk. The desk console needs to see calls to a room, see whether the room phone is enabled, and place calls to a room extension without knowing the internal numbering pattern. When a guest is not in and the call needs to be transferred, the room status determines whether it goes to voicemail or to a staff extension.
• Housekeeping. The room phone is often the only device in the room that the cleaner interacts with, so the state shown on it has to be trustworthy. A room whose extension was disabled at checkout but re-enabled by a late arrival is a classic source of a phone that rings for an empty room.
• Maintenance. Engineers need to be able to take a room extension out of service and put it back without a ticket that routes through the front desk. If the PBX side of the property management is only writable by the front desk, the engineering workflow will route around the system, and the record of what happened will not match the phone state.

Recording fits into these workflows as well. New Rock's RMS recording management system gives the property a central place to store and search recordings produced by the OM series IP-PBX and MX series gateways, and SoftConsole provides PC-side click-to-dial, call history and recording access for staff who are not at a desk.

Scaling PMS Integration Across Properties

Groups running several properties hit a specific question: does one PMS serve several sites, or does each site run its own?

One PMS serving multiple PBXs

PMSI explicitly supports multiple OM IP-PBX connected to one set of PMS, which suits a group running a single central reservation and billing system across several properties. The benefit is one place where rates, templates and service rules are maintained. The cost is that the interface becomes shared infrastructure: a problem with the middleware or the API affects every property at once.

Single-PMS deployments should be built with per-property isolation in mind: separate API credentials, separate configuration objects, and a documented answer for what happens to a property's room phones when the shared system is unavailable. That last question decides whether a property can still check guests in or answer a guest line when the interface is down.

Sizing hardware per property

Once the PMS picture is clear, the PBX choice becomes a capacity lookup against the room count and the departmental extensions, using published model figures.

Built-in FXS/FXO ports decide how much of the property's existing cabling can stay in place, which matters in a hotel where rooms already have analog phones on the wall and the budget does not stretch to replacing every handset. New Rock's solution library maps these models to hotel scenarios, including the OM8000 for a 4-star chain hotel and the OM200G for an upscale hotel, with the larger models positioned for properties where the room count is high enough to make per-room extension and trunk planning the dominant design exercise.

Two operational requirements should be settled before the model is chosen. A property with a second building or an offsite annex needs a decision about what happens to those calls if the main site is unreachable, and the local survivability device is the option designed for that case. And any group running several properties should settle management early: the New Rock unified management system handles unified management and remote operations for OM series IP-PBX and MX series VoIP gateways, which is what makes a multi-property estate maintainable without a site visit per change.

Where PMS Integration Projects Stall

Three failure patterns account for most of the trouble, and all three are visible before go-live.

1. Partial support for a service. The integration covers wake-up calls, extension permission, do-not-disturb and caller name display, but a property may also want guest message light, room-to-room calling rules or automated wake-up retries. Anything outside the enumerated list needs its own design and test.
2. The PMS was the only side built. Interfaces written so that the PBX pulls from the PMS, with no path for the PBX to report back, produce a system where results cannot be confirmed and reconciliation happens by hand at the desk.
3. Room state owned by two systems. If the housekeeping application and the PMS both maintain room status and neither is authoritative, the phone system will eventually display a state that matches neither. Pick one source of truth and have the other subscribe to it.

A fourth issue is procedural: PMSI's product page lists supported docking with third-party PMS including Oracle among others. If your property runs a specific PMS, confirm compatibility with that vendor before committing to the design.

Hotel Phone System and PMS Integration FAQ

What does the PMS integration actually do for the phone system?

It carries data both ways: instructions from the PMS become voice function settings on the OM IP-PBX through the OM API, and the setting results go back to the PMS. Call billing information travels the other way, from the OM API to the PMS for posting to the folio.

Which hotel PMS systems are supported?

New Rock's PMSI product page names Oracle among the supported third-party PMS systems. For any specific property, confirm compatibility with that PMS vendor directly, since the interface depends on what the PMS exposes through its own API.

Do room phones have to be replaced when the PBX changes?

Not necessarily. The OM series has built-in analog gateway modules, and models such as the OM80E, OM200G and OM200G-A carry 48 to 96 built-in FXS/FXO ports, which lets existing analog handsets stay on the wall. Whether that is the right call depends on the condition of the handsets and on the guest-facing services the property wants to add.

Can one PMS manage more than one IP-PBX?

Yes. PMSI supports connecting multiple OM IP-PBX to one set of PMS, which suits a group running several properties on one reservation and billing system. Each property still needs its own API credentials and configuration separation so that one site's problem does not become every site's problem.

What happens to guest services if the PMS interface fails?

The phone system keeps running, but the functions that depend on pushed data stop updating: wake-up requests taken at the desk, extension permissions tied to arrival and departure, and room status changes. Decide in advance which of these the property will handle manually while the interface is down, and who is responsible.

Does the integration cover call recording?

Recording is a separate concern from PMS billing. The RMS recording management system collects, stores and manages recordings produced by OM series IP-PBX and MX series gateways, and properties typically index those recordings against the same guest or room reference used for billing.

Conclusion

A hotel phone system is a voice platform, and the PMS integration is where it becomes a hotel system. The specification that matters is short: wake-up call service, extension permission, do-not-disturb mode, display caller name on extension, and call billing pushed to the PMS, with results confirmed back. Write that list down, confirm it against what your PMS exposes, and test each item on the actual property platform — including the failure case where the interface drops mid-service, which decides whether your front desk can still run the hotel.