PMS Modules — What Each One Does and Where It Stops

How to use this guide

Use the boundary table before the demo. Ask each vendor which module owns the guest, the folio and the rate, and how the handoff works.

If two modules both claim to own the guest, ask which one is the master.

Common mistakes

Buying a booking engine and a channel manager that do not share rates, adding a CRM that creates a second guest record, and buying an RMS before the PMS data is clean.

• Duplicate guest records
• Two rate structures
• No master data owner
• No interface test
• No sequence plan

What to read next

Read the booking engine, channel manager and CRM pages for the boundaries in practice.

• Booking engine
• Channel manager
• Hotel CRM
• Revenue management

How this guide is maintained

The boundary table is reviewed when a module changes ownership of guest, rate or folio data.

Reference rollout

A 100-room hotel starts with the PMS core, adds the channel manager, then the booking engine, then the POS and later the CRM.

Each phase has a success test and a data master, so the next module does not create a duplicate record.

• Core first
• Channel manager second
• Booking engine third
• POS fourth
• CRM and RMS later

Before you commit

Name the data master for guest, rate, reservation and folio. Then test the handoff, not just the module.

• Guest master
• Rate master
• Folio owner
• Handoff test
• Module sequence