TOC - Hospitality Integration

Connect your Property Management System to a modern hosted phone system — guest names on room phones, wake-up calls that just work, housekeeping updates dialed from any room, and accurate call billing. We replace your aging PBX with our hosted TOC platform; your PMS stays exactly as it is.

This page explains what TOPS TOC (TOPS Office Communicator) Hospitality can do for a hotel or hospitality property, which options are available depending on your PMS, and how the hosted platform and the on-site connector fit together. It is written for both decision-makers and the technical staff who will evaluate or implement the integration.

1. What your property gets

No proprietary handsets, no on-site PBX to maintain. TOPS TOC Hospitality comes built-in with the hosted TOC phone system — and your PMS never changes.

2. How it works at a glance

In the standard setup, we host everything: the TOC phone system (TOPS Office Communicator) and the TOPS TOC Hospitality platform both run in our data center. The only components that may live on your property are the PMS itself and, when the PMS is on-site, a small connector (see §4).

TOPS TOC is a translation and routing layer:

• It listens to your PMS (check-in, check-out, wake-up, DND, postings, room status…) and applies the matching action on your phone system (rename the extension, schedule the wake-up, clear DND…).
• It listens to your phone system (call records, feature codes dialed from room phones) and delivers those events to your other systems — billing, housekeeping, CRM, or anywhere else.
• Every event is audited and can be fanned out to multiple destinations at once. Adding a new destination later (say, a new housekeeping app) is a configuration change, not a project.

3. Capability matrix

What is available depends on the PMS protocol your property uses and, for some features, the phone system's capabilities. This matrix reflects the current shipping state honestly.

✅ Supported  ·  ◐ Partial / dependent on PBX or PMS support  ·  🗓 Roadmap

* TigerTMS iLink works today because iLink speaks the standard Mitel TCP/IP PMS protocols — we emulate those protocols and TigerTMS doesn't know the difference. What's on the roadmap is native iLink dialect support (TigerTMS-specific record extensions); you don't need it to integrate a TigerTMS property.

Two things worth calling out:

• Every event is always captured and auditable — even where a check mark is ◐. If your phone system can't apply an action natively today, the event is still logged, and can still be delivered to your other systems (e.g. a message-waiting event can still light up a dashboard or trigger a webhook).
• Unknown or newer PMS event types pass through safely. If your PMS emits a record type we don't translate natively yet, it is still audited and can be routed to your systems — no software upgrade required to start receiving it.

4. Deployment: everything hosted by us, (almost) nothing on-site

Hospitality properties mix cloud and on-premises systems. TOPS TOC is designed for exactly that. In the standard setup we host both halves of the solution in our data center: the TOC phone system (TOPS Office Communicator) and the TOPS TOC Hospitality platform. The only things that may live on your property are your PMS and, when the PMS is on-site, a small connector — nothing else. No PBX hardware to rack, no inbound firewall rules, no VPN.

The on-site connector, three ways

1. A small Docker container — we publish a ready-to-run container image. Runs on any existing on-site server, VM, or the same host as other hotel systems. This is the most common choice.
2. A tiny always-on appliance (e.g. a Raspberry Pi) — for properties without a server closet, we can supply or help you provision a small, low-power appliance that sits on your LAN next to the PMS. It runs the same connector software; there is nothing else to maintain.
3. A purpose-built option for unusual PMS interfaces — most modern PMS interfaces speak plain TCP. Some legacy PMS or PBX units only offer a serial (RS-232) port. In that case the on-site appliance bridges the serial line to the connector using standard serial-over-IP emulation, or we build a purpose-built adapter for your specific PMS interface as part of onboarding. You don't need to change the PMS itself.

In all cases the connector:

• makes outbound connections only — no inbound firewall holes, no port forwarding, no VPN required;
• encrypts everything in transit (TLS);
• queues and retries if your internet drops, and catches up when it returns;
• is configured remotely by our team — there's no day-to-day administration on your side.

Scenario A — The standard setup: hosted TOC phone system + on-site PMS

The most common setup: your phones run on our hosted TOC platform in our data center — right next to the TOPS TOC Hospitality platform — and your PMS server is in the back office.

The PMS talks to the connector over your LAN (or the connector connects to the PMS — both directions are supported, whichever your PMS prefers). The connector forwards events securely to our data center, where they are applied to your hosted phone system instantly — the two platforms sit side by side.

Scenario B — Hosted phone system + cloud PMS (nothing on-site at all)

Nothing on-site at all is possible here: the PMS vendor points their interface at an endpoint we provide (or the connector runs as a small container in our data center), and events flow PMS → TOPS TOC → hosted phone system without anything installed at the property. The exact arrangement depends on your PMS vendor's interface options — we confirm this with them during onboarding.

Scenario C — Multiple properties or estates

Hotel groups and estates spanning multiple properties are supported natively: each property gets its own configuration, one connector per site, and a single view across the estate — all running on the same hosted platform in our data center. Adding a new property is a configuration change, not a project.

What we need from your property

5. Feature walkthroughs

A guest checks in

1. Front desk checks the guest in on the PMS.
2. The PMS emits a check-in record (FIAS GI / Mitel equivalent) with the room and guest name.
3. TOPS TOC receives it, applies the property's timezone, writes an audit entry, and updates the room phone's caller-ID name to the guest's name on the phone system.
4. Any destinations you've configured also fire — e.g. a "guest checked in" note in your CRM, or an entry on a front-office dashboard.

Check-out reverses it: the extension name returns to "Room 204", DND is cleared, and the room is ready for the next guest.

A housekeeper marks a room clean

1. From the room phone, the housekeeper dials *93 (clean) — codes are remappable per property.
2. TOPS TOC identifies the room from the phone's extension, applies your room-numbering rules, and emits a room-status event.
3. Your housekeeping system (webhook) and/or PMS receives the update. The event is audited with a timestamp.

Room-numbering mismatches between PMS and phone system (e.g. extension 7204 = room 204) are handled by configurable mapping rules — the two systems don't need to agree on numbering.

A wake-up call is scheduled

1. Front desk (or the guest, via a feature code) sets a 07:30 wake-up.
2. TOPS TOC schedules it on the phone system's wake-up service.
3. Every few minutes, TOPS TOC reconciles the phone system's wake-up table against the PMS view — if anything drifted (manual edits, restarts), it's corrected. Wake-ups are "set and forget", with a safety net.

A call is billed

1. A guest makes a call from room 204.
2. The phone system emits an SMDR/CDR record. TOPS TOC parses it (duration, numbers dialed, trunk, time-to-answer, ANI/DNIS, and more), stamps it with the property's local timezone, and audits it.
3. The record is delivered to your billing system (webhook), written to an on-site audit file if you want a local copy, and/or sent anywhere else you configure.

6. Voicemail and message waiting

Voicemail behavior in hospitality is a joint responsibility of the PMS and the phone system. Since every property runs on our hosted TOC phone system, here's exactly what happens today:

• Message-waiting lamp (MWI) on the room phone: TOPS TOC receives and audits MWI on/off events from the PMS in all cases. Applying the lamp state to the room phone on the hosted TOC platform is currently a roadmap item. Even then, the events are never lost: they can drive dashboards, staff notifications, or audit trails.
• Mailbox lifecycle at check-in / check-out (mailbox setup, message purge, greeting reset): the PMS events are parsed, audited, and relayed; automated mailbox purge and greeting reset on the hosted TOC platform are on the roadmap and handled with documented workarounds in the meantime.
• FIAS properties: FIAS defines a dedicated voicemail interface type (message-waiting on/off notifications between the PMS and the voicemail system). TOPS TOC parses and tracks these events and can relay them wherever you need.
• Room moves: guest name and extension state follow the PMS room-move events automatically; voicemail message transfer between mailboxes is part of the same roadmap item as the mailbox lifecycle.

7. Security, privacy, and reliability

• Outbound-only connectivity. The on-site connector initiates every connection. No inbound firewall rules, no exposed ports on your network.
• Encrypted in transit. All connector ↔ data-center traffic runs over TLS; stored credentials are encrypted at rest.
• Per-property isolation. Every property's configuration, events, and routing are fully separate.
• Resilient to outages. If your internet drops, the connector queues events and catches up on reconnect; delivery is acknowledged end-to-end so nothing is silently lost. Your phones and PMS keep working locally throughout — integration simply pauses and resumes.
• Safety gates. Optional per-property rules restrict which extensions are allowed to trigger room-status / DND / wake-up actions, so a misdialed code from a back-office phone can't change a guest room.
• Full audit trail. Every PMS event, every call record, and every action taken on the phone system is logged with timestamps for your records.

8. What onboarding looks like

A typical property goes from kickoff to live in days, not months:

1. Discovery call. We cover the integration side together: your PMS and version, its interface type (FIAS, Mitel, …) and license status, and which capabilities you want from the matrix.
2. On-site visit. We confirm the physical side in person: the phone-system hardware and cutover plan, network, the PMS server and its interface port (TCP vs serial), room numbering, and where the connector will live. The goal is to surface every unknown before anything is configured — not after.
3. Connector deployment (≈30 minutes). We install our Docker container on an existing VM, or plug in the small appliance we provide. It connects outbound and registers itself.
4. PMS link-up. We work with your PMS vendor/reseller to point the interface at the connector and verify the handshake.
5. Configuration. Room numbering plan, feature codes, timezones, and your destinations (billing webhook, housekeeping dashboard, CRM).
6. Validation with example rooms. Together with your front desk, we check a test guest in and out of one or more dummy rooms and walk the flow end to end: name appears on the room phone at check-in, extension resets at check-out, a wake-up schedules and fires, a maid code updates room status, and a test call lands in call accounting. We confirm each step with your team before sign-off — nothing goes live on real guest rooms until you've seen it work.
7. Live. Day-2 monitoring is on us — we watch the link health, event flow, and reconciliation, and alert if anything stops moving.

9. Frequently asked questions

This page describes current shipping capabilities and roadmap items as honestly as we can; specific behavior for your PMS + phone-system combination is confirmed in writing during discovery.