Guide 01 · Property Management · Operational architecture
Your PMS knows there is a booking. Operations need to know what happens next.
A practical architecture for connecting bookings, tasks, cleaning, payments and reporting without making one tool the judge of everything.
Direct answer
You do not need to start by replacing the PMS.
You need to decide which system is authoritative for each data point, separate the states that are currently being merged and define what should happen when a booking changes. Then you can connect the layers and automate only the steps with a reliable source, an explicit rule and an owner for exceptions.
The problem is rarely a lack of software. Each tool answers a different question.
The channel confirms that a booking exists. The calendar shows occupancy. Operations need to know whether the arrival can be prepared. Finance needs to distinguish expected money from received money. The owner needs a clear, approved output.
When those answers are stored in the same field, the system appears simple until a modification, partial payment, incident or late departure occurs. An update that is correct for one team can then be wrong for another.
Centralising does not mean forcing one tool to be the source of everything. It means every data point has an authority and the connections respect that contract.
Five layers. Five responsibilities that should not be merged.
The specific tool may change. The separation of responsibilities should survive that change.
Channels and PMS
Originate or consolidate bookings, dates, availability and external references. They are authoritative only for the data they actually control.
Operations
Turns a booking into work: preparation, cleaning, check-in, maintenance, incidents, owners and deadlines.
Data and documents
Keeps canonical records, permissions, versions and controlled documents away from public outputs.
Finance
Separates expected amounts, obligations, confirmed receipts, adjustments and settlements. An arrival date is not proof of payment.
Outputs
Creates internal reporting, owner views and public data from validated information at the right level of detail.
A booking does not have one status. It has several families of states.
Separating them prevents ‘confirmed’ from ending up with five different meanings.
| Family | Question | Examples |
|---|---|---|
| Booking | Does it exist, did it change or was it cancelled? | enquiry · option · confirmed · modified · cancelled |
| Operations | Which work is ready or blocked? | pending · assigned · in progress · completed · incident |
| Payment | What was expected and what has evidence? | expected · due · received · reconciled · adjusted |
| Document | Which evidence exists and is approved? | requested · received · reviewed · rejected · archived |
| Exception | What prevents the normal flow? | open · assigned · resolved · escalated |
A booking change can create operational work without creating a financial movement yet. That difference must exist in the model, not only in the team's memory.
Design the whole event before automating the first step.
Example: the departure date changes on a confirmed booking.
- The authorised system receives the change and preserves the source reference and version.
- The canonical booking is updated without overwriting its previous history.
- The operational layer recalculates cleaning, access, tasks and possible conflicts.
- Affected people receive a concrete action, not a generic notification.
- Finance reassesses what is expected but records no payment without authorised evidence.
- Reporting updates only fields validated for each audience.
- If a connection fails, the event remains visible, retryable and owned.
Useful automation is not ‘when A happens, send a message’. It is a traceable state change with idempotency, an exception path and a way back.
The minimum data contract fits on one page. Ambiguity costs far more.
Before integrating, agree at least these fields and who can modify them.
- Booking identifier
- Recognise the same event across systems without matching only by date or amount.
- Property identifier
- Avoid free-form names and keep permissions, tasks and reporting attached to the correct entity.
- Arrival and departure
- Trigger planning from dates with a defined source and timezone.
- Source and version
- Know where the data came from, when it changed and which system is authoritative.
- Separate states
- Represent booking, operations, payment, document and exception without false closure.
- Owner and next action
- Turn every exception into assignable, verifiable work.
- Last updated
- Detect stale data, retries and synchronisation conflicts.
Pilot a complete cycle. Not a polished screen.
A small implementation is valuable when it crosses real work from beginning to end.
- Map sources, decisions, owners and exceptions in the current flow.
- Assign an authority to every critical data point and document what happens when sources disagree.
- Define states and transition criteria before building automation.
- Choose one or two properties and cover booking, change, arrival, departure, task, incident and output.
- Reconcile the result against original sources and review permissions, history, export and rollback.
- Progressively automate what is stable; retain human review where evidence or impact requires it.
- Measure cycle time, exceptions, manual corrections, adoption and data quality.
A demo validates that an interface can represent an idea. A pilot validates that the operation can complete a cycle and explain every difference.
Decision
Connect or replace the PMS?
Connecting is usually the first option when the PMS reliably holds the booking and can export or integrate the necessary data.
Connect
When the current system is a reliable authority for bookings and availability, and its limits can be covered in other layers.
Configure
When the capability exists but states, permissions, rules or coherent implementation are missing.
Build
When a specific operational gap cannot be covered responsibly by an existing tool.
Replace
When limitations affect critical functions, data ownership, portability, permissions or business continuity.
FAQ
Questions to ask before connecting anything
Do I need to replace my PMS to automate operations?
Not necessarily. If the PMS reliably holds bookings and availability, it can remain the source for that data while other layers manage tasks, documents, finance or reporting.
Is an iCal calendar enough?
It is often useful for occupancy and basic coordination, but it does not contain every operational, financial or document state, nor the history needed to govern the operation.
Can cleaning be automated from each booking?
Yes, once the date source, change and cancellation rules, owners, conflicts and failure handling are defined. The task must remain visible and verifiable.
Should payments live in the same tool as bookings?
They can be displayed together, but their states and evidence should remain separate. A confirmed booking, a payment obligation and a reconciled receipt are different facts.
What should an owner see?
Only information validated for that audience: sanitised booking data, approved dates and amounts, understandable states and the last update date. Not private contacts, internal documents, bank references or operational notes.