Method and sources. We based this analysis on publicly available material: hotel job postings, hospitality-technology press, vendor documentation for comparable systems, and staff accounts shared in public forums. FSPMS is proprietary. We have not seen its internals, so we describe its characteristics as they are publicly reported and hedge accordingly. Hospitally is not affiliated with Marriott International.
1 · Summary
FSPMS (Full Service Property Management System) is the brand-proprietary system that full-service hotels in a large global portfolio have long used for their core property work: reservations at property level, guest profiles, room inventory and status, check-in and check-out, folios and billing, group blocks and night audit. It is reliable and deeply wired into brand systems. By modern standards it is also terminal-first, desk-bound and siloed: housekeeping, inventory, guest messaging and mobile work often live in separate tools, and the PMS is the slowest link between them.
Hospitally keeps what FSPMS gets right: the audit trail, group and billing depth, and brand connectivity. It rebuilds the rest around one live operational picture of the hotel day. That picture is shared by the GM on an iPad, the front desk on the web, and housekeeping and engineering on iPhone. An event-driven API connects it to the brand's guest-chat app, so a guest request becomes a booking change with one approval.
- Web app for front desk, reservations, groups, revenue and back office.
- iOS app for iPhone (floor teams), iPad (managers, mobile check-in) and foldables (supervisors who need board + detail side by side).
- Hospitally Connect: a documented REST + webhook API, including a guest-chat connector (reference).
- Migration by parallel run: shadow first, then department by department, then the ledger. We never do a big-bang cut-over at a 400-room hotel.
2 · What FSPMS is, and where it sits
In a branded full-service hotel the PMS sits in the middle of a stack of brand and property systems. Public job postings for front-office and night-audit roles often list FSPMS next to the brand's central reservation system, loyalty platform, revenue tools and point-of-sale. The typical layout:
| Layer | Typical role | Relationship to the PMS |
|---|---|---|
| Central reservations (CRS) | Brand-wide availability, rates and bookings from web, app, call centers and GDS | Pushes bookings down to the property; receives inventory and status back |
| Loyalty platform | Member tiers, points, benefits, preferences | Profile and tier data flows to the PMS; stays and spend flow back for crediting |
| Property PMS (FSPMS) | Rooms, arrivals and departures, folios, groups, night audit | The system of record for what happens inside the building |
| Revenue management | Forecasts, pricing and restrictions | Consumes PMS history; sends rates and controls |
| Point-of-sale, spa, parking | Outlet charges | Posts charges to guest folios |
| Housekeeping and service tools | Room boards, requests, engineering | Often a separate system reading and writing room status |
| Guest messaging / chat | Two-way messaging with guests | Usually a separate app: staff re-key requests into the PMS by hand |
| Door locks and mobile key | Key encoding | Triggered by check-in and room moves |
Staff accounts commonly describe a character-based, keyboard-and-function-key interface reached through terminal emulation. It is fast for experts and hard for new hires, and it is mostly tied to a workstation. Public reporting also shows the parent company modernizing its core platforms. This is consistent with a planned move away from legacy property systems, which opens a window for a better replacement.
3 · Strengths worth keeping
- Reliability and determinism. Mature systems rarely surprise the night auditor. Hospitally has to match this, so night audit is a verified, idempotent job and each step has a report.
- Deep brand integration. CRS, loyalty crediting and brand standards are built in, not bolted on. Hospitally gets the same depth through certified connectors and keeps the brand as the source of truth for profiles and rates.
- Accounting depth. Split folios, routing, master accounts, city ledger, deposits and group billing all work. None of it can regress.
- Speed for experts. Power users fly through keyboard flows. Hospitally ships a command bar and full keyboard coverage on the web app for them.
- Audit trail. Every change is attributable. Hospitally makes this stronger, with an immutable event log per reservation, room and folio.
4 · Pain by role
| Role | Legacy experience (as publicly described) | What Hospitally changes |
|---|---|---|
| General manager | Morning picture pieced together from printed reports and several systems. Little visibility away from a workstation. | A live brief on iPad or phone: occupancy, arrivals, rush rooms, stock, group pickup and elite arrivals, with a "needs you now" feed. |
| Front desk agent | Memorized codes and screens, long training ramp. Room readiness only as fresh as the last status sync. | A guided web UI plus a command bar. Room readiness updates the moment an attendant taps "done". Check-in auto-assigns a room that matches the guest's preferences. |
| Housekeeping | Paper boards or a separate app. Status handed off by phone or radio. Rush rooms decided by shouting. | iPhone boards balanced by floor and credits. Rush rooms are driven by arrivals actually waiting. Supervisors inspect in-app with photos. |
| Rooms division / revenue | House-full nights spotted late. Stop-sells and walk plans handled by email and phone. | A forecast strip that flags house-full nights days ahead, one-tap stop-sell of third-party channels, and a walk-plan builder. |
| Sales & events | Rooming lists re-keyed. Pickup vs block tracked in spreadsheets. | Rooming-list import with fuzzy name matching, live pickup against cutoff, and release of unsold rooms in one action. |
| Loyalty / guest relations | Elite arrivals printed each morning. Recognition depends on who is on shift. | An elite arrival list with a recognition checklist (note, amenity, upgrade) and suite inventory in view. |
| Night auditor | Long sequential audit. Exceptions discovered late. | Continuous audit through the day, so night close is a checklist of exceptions and not a batch job. |
| IT / ownership | On-premises hardware, terminal clients, costly change requests. | Cloud SaaS, SSO, role-based access, an open API, and zero client installs beyond the App Store. |
5 · Capability scorecard
This is our assessment of the typical legacy experience against Hospitally's design targets, on a 1–10 scale. It is illustrative, not a benchmark.
Clay = legacy, brass = Hospitally target. We deliberately scored accounting depth as parity: matching it is the bar, not the pitch.
6 · Competitive landscape
Any brand replacing FSPMS will also look at modern cloud PMS vendors. Here is where they are strong, and where Hospitally wins for a branded full-service operation.
| Product | Strength | Gap for branded full-service | Hospitally's angle |
|---|---|---|---|
| Oracle OPERA Cloud | Industry standard for full-service chains, deep functionality, large partner ecosystem | Complex to configure. The UX carries decades of desktop heritage, and mobile is secondary. | Same depth goals with an ops-first UX; mobile and iPad are primary surfaces, not add-ons |
| Mews | Beautiful, automated guest journey, strong open API and marketplace | Its roots are in independent and select-service hotels. Brand-chain integrations are shallower. | Brand-grade connectors (CRS, loyalty, chat) and group/house-full tooling for 400+ keys |
| Cloudbeds | All-in-one suite with channel manager and booking engine | Tuned for small and mid-size independents. Full-service billing and group depth is limited. | Full-service folio, master account and group handling |
| Stayntouch | Mobile-first front desk and kiosk, fast check-in | Narrower back-of-house (inventory, groups) coverage. | One platform for front and back of house, including stock and par levels |
| Apaleo | API-first, headless, great for builders | Needs an ecosystem of apps to become a complete operational tool | Complete product out of the box and an open API |
7 · The Hospitally solution
Web app modules
| Module | Replaces / adds | Key capabilities |
|---|---|---|
| Today | Morning reports | Live brief, 7-night forecast, house-full flags, a "needs you now" queue |
| Front desk | Arrivals, in-house, departures screens | Smart room assignment, express check-out, command bar, ID scan and mobile key |
| Reservations | Property booking screens | Availability, rate plans from CRS, modifications, deposits and guarantees |
| Rooms | Room status grid | A 412-room live board with filters for due-outs, rush, out of order and inspection |
| Housekeeping | Separate HK tool / paper | Auto-balanced boards, rush logic tied to waiting arrivals, inspection with photos, lost & found |
| Inventory | Spreadsheets | Par levels driven by forecast occupancy, reorder to purchase order, deliveries |
| Groups | Block screens + spreadsheets | Pickup vs block, cutoffs, rooming-list import, release, master billing |
| Loyalty | Printed elite lists | Elite arrivals, recognition checklist, upgrade engine using suite inventory |
| Guest chat | Separate messaging app | Intent detection with suggested booking actions, one-tap approve, API log |
| Billing & audit | Folios, night audit | Split and routed folios, city ledger, continuous audit, exceptions-only night close |
Every module above runs in the live demo.
8 · iOS: iPhone, iPad, foldable
- iPhone, for floor teams. Attendant boards, "start / done" per room, photo inspection, guest requests with SLA timers, engineering work orders, push for rush rooms. Works offline and syncs when back on Wi-Fi.
- iPad, for managers and the lobby. The GM brief, mobile check-in with ID scan and key encoding, group pickup, elite arrivals. Split View pairs the room board with guest chat.
- Foldable, for supervisors. Closed, the cover screen shows the next rush room. Open, the board and room detail sit side by side across the crease, and the layout adapts as the device unfolds.
- Platform features: Live Activities for rush rooms, widgets for occupancy, Sign in with SSO, and role-based screens so an attendant never sees a folio.
9 · Integration architecture
Hospitally is event-driven. Every state change (room status, check-in, folio post, chat intent) is written to an append-only event log and fanned out to subscribers over webhooks. Connectors translate between those events and brand systems.
Guest chat app ──webhook──▶ Hospitally Connect ──▶ intent + suggested action
│ │ staff approves (1 tap)
▼ ▼
Brand CRS ◀──── reservations sync ─── Hospitally core ──▶ rooms / HK / folio events
Loyalty ◀──── stay + spend credit ── │
Door locks ◀──── key encode / revoke ── ▼
POS ───── charge posts ───────▶ Event log (immutable, per property)Guest-chat connector: how it works
- The chat platform sends
chat.message.createdto Hospitally with an HMAC signature. - Hospitally matches the thread to a reservation (confirmation, loyalty number or verified phone) and classifies the intent: late check-out, extension, early check-in, room move or amenity.
- It checks feasibility against live data (tomorrow's forecast, ready rooms, housekeeping sequence) and drafts both the change and the reply.
- A staff member approves. Hospitally calls its own API (for example
POST /v1/reservations/{id}/extend), syncs the change to the CRS, and posts the reply back to the thread. - Policy rules can auto-approve low-risk requests, such as a 1 pm check-out for elite members on a light day.
The chat connector is a proposed design. A production integration with any brand's chat platform would need that brand's partnership, certification and data-processing agreements.
10 · Migration plan
| Phase | Duration | What happens | Exit criteria |
|---|---|---|---|
| 0 · Discover | 4 weeks | Map configuration (room types, rate codes, routing rules, reports) and interview every role | Signed configuration and a report parity list |
| 1 · Shadow | 6 weeks | Hospitally runs read-only beside the legacy PMS via interface feeds. Managers use the Today brief and forecasts. | 99.9% match on room status and in-house counts for 14 straight days |
| 2 · Operations | 6 weeks | Housekeeping, inventory, loyalty recognition and guest chat move to Hospitally. Room status is written back to the legacy system. | Room-ready time and request SLAs beat baseline |
| 3 · Front desk | 4 weeks | Check-in, check-out and room moves in Hospitally; folios still mirrored | Zero unbalanced audits across two weekend peaks |
| 4 · Ledger cut-over | 1 night | Balances, AR and future reservations migrate at a scheduled low-occupancy night close. The legacy system goes read-only. | Trial balance ties out, and future bookings reconcile against the CRS |
| 5 · Scale | Ongoing | Playbook reused across the portfolio in waves by region | Each hotel is live in 10 weeks or less from signature |
11 · Business case & KPIs
These are design targets that we would validate in a pilot. They are not measured results.
| Metric | Target | Why it moves |
|---|---|---|
| Front-desk training time | −60% | Guided UI replaces memorized codes |
| Room-ready latency (attendant done → desk sees it) | From minutes to under 5 seconds | Single system; no status relay |
| Guest-chat request handling time | −70% | Intent plus a pre-checked action instead of re-keying |
| Elite recognition rate | >95% of arrivals | Checklist in the workflow, not on paper |
| Stock-outs on house-full nights | Near zero | Par tied to forecast occupancy |
| On-premises hardware | Eliminated | Cloud SaaS plus standard iOS devices |
12 · Risks & mitigations
- Brand certification. Brand CRS and loyalty interfaces are gated. Mitigation: start with brand-agnostic independents and soft brands, then pursue certification with a design-partner hotel.
- Accounting regressions. Mitigation: run a parity test suite built from real (anonymized) audit packs; do not cut over the ledger until the trial balance ties out for two cycles.
- Change fatigue. Mitigation: go department by department, keep keyboard shortcuts for experts, and set up in-app coaching.
- Connectivity. Mitigation: an offline-capable iOS app, a local cache at the desk, and a documented downtime procedure with printable arrival lists.
- Data protection. Guest PII and payment data. Mitigation: PCI-scoped tokenization, regional data residency, SSO/SCIM and a full audit log.
13 · Roadmap
| When | Milestone |
|---|---|
| Q4 2026 | Design-partner pilot: operations modules (housekeeping, inventory, loyalty, chat) in shadow mode |
| Q1 2027 | Front desk and folios GA; iPad check-in with mobile key |
| Q2 2027 | Groups and sales-and-catering sync; foldable layouts; public Connect API v1 |
| H2 2027 | Brand-connector certification program; portfolio roll-out playbook |