Cloud PMS Support Boundary — Who Owns What
Quick answer
In a cloud PMS, the vendor owns the application environment; the property owns the network, printers, terminals and procedures. Interfaces have named owners. The contract should state who coordinates an incident that crosses the boundary.
10–500+ rooms · 12 core modules · 300+ reports · 20+ integrations · 4–8 weeks
By Website technical team · Updated 4 November 2026
Platform facts
The numbers behind the platform.
The platform runs 10–500+ room properties on 12 core modules, with 300+ report templates and 20+ integration points across 8 interface categories. Deployment comes in 3 models; a typical single-property implementation takes 4–8 weeks. Four product lines cover PMS, POS, membership and procurement; 5 property types are configured; the site is published in 10 languages with 6 knowledge hubs and 24 guides. One guest record and one ledger run the property, with 1 database, 1 folio and 1 audit trail. Reports are available in 2 languages; 4 role groups are supported; quotes reply within 1 business day. A quote has 3 room-count tiers, 5 preparation inputs and 3 implementation phases; cutover is planned in 3 phases. Use these figures to size the evaluation; the quote confirms rooms, modules, interfaces and deployment for your property.
| Fact | Figure |
|---|---|
| Property range | 10–500+ rooms |
| Core modules | 12 |
| Report templates | 300+ |
| Integration points | 20+ |
| Integration categories | 8 |
| Deployment models | 3 — cloud, on-premise, hybrid |
| Typical implementation | 4–8 weeks |
| Product lines | 4 — PMS, POS, membership, procurement |
| Property types | 5 |
| Site languages | 10 |
| Knowledge hubs | 6 |
| Published guides | 24 |
| Guest record | 1 |
| Ledger | 1 |
| Report languages | 2 — English and Chinese |
| Quote response | 1 business day |
| Role groups | 4 — front office, housekeeping, F&B, finance |
At a glance
Support ownership by layer
| Layer | Vendor | Property | Shared |
|---|---|---|---|
| Application | Owns | Uses | Configuration |
| Database | Owns | Data | Access |
| Hosting | Owns | Connectivity | Monitoring |
| Network | Advises | Owns | Escalation |
| Printers | No | Owns | Driver support |
| Payment terminals | Interface | Owns hardware | Provider |
| Door locks | Interface | Owns hardware | Lock vendor |
| Channel manager | Interface | Owns mapping | Provider |
| Identity readers | Interface | Owns devices | Device vendor |
| Telephony | Interface | Owns PBX | PBX vendor |
| Backups | Owns | Reviews evidence | Recovery test |
| Security patching | Owns | Access policy | Review |
| Incident coordination | First line | Local response | Joint |
| Training | Delivers | Attends | Refresher |
| Procedures | Advises | Owns | Review |
Why define the boundary?
Because an incident at 23:00 does not care about the contract. If the boundary is unclear, the desk is passed between the PMS vendor, the network provider and the lock vendor while the guest waits.
What does the vendor own?
The application, the database environment, hosting, backups and patching. It also owns the interfaces it delivers and the support path for its side.
What does the property own?
The network, the printers, the terminals, the locks, the local procedures and the people. The property also owns the data quality and the operating decisions.
Who owns an interface?
The vendor that delivers the interface owns its side; the third-party vendor owns its system. The contract should name the coordinator for a cross-vendor failure.
How should an incident be coordinated?
One named coordinator, a single incident channel and a written escalation path. The property should not have to decide which vendor to call while the queue grows.
What should the contract say?
The layers, the owners, the response targets, the escalation path and the fallback procedures. A support matrix with names is more useful than a paragraph of goodwill.
How does the boundary work across a group?
A group adds a second layer: the property, the central IT team and the vendor. The property owns the local network and devices; the centre owns the standard, the identity provider and the reporting definition; the vendor owns the application environment and the interface it delivers.
Write the matrix once and reuse it at every property. The names change; the layers and escalation path should not. A group should also decide whether first-line support sits at the property, the centre or the vendor, because that decision drives the response time the guest experiences. The goal is a single path the desk can follow at 23:00, even when the first contact is unsure who owns the layer.
Test the matrix with a drill that crosses layers: a network outage during arrivals, a payment terminal failure at checkout and a lock failure at 23:00. Record who coordinates, how long each handoff takes, which fallback procedure was used and what the guest was told. The drill is more useful than a paragraph in the contract because it exposes the gaps between vendors.
- Name one incident coordinator per property and one at the centre.
- Publish the escalation path with roles, not just phone numbers.
- Keep a local fallback procedure for arrivals, payments and keys.
- Review the matrix after every cross-vendor incident.
Frequently asked questions
Frequently asked questions
Who fixes a network outage?
Who fixes a payment terminal?
Who owns a channel failure?
Does the vendor support printers?
What is a support matrix?
How do we test the boundary?
What is the biggest boundary risk?
Next step
See the platform on your own workflows.
A 30-minute walkthrough, built around your property type and the systems you already run. No slide deck — we work through arrivals, folios, night audit and reporting live.
Typical reply within one business day.