Hotel onboarding flow (PMS/booking-system agnostic)

Hotel onboarding flow (PMS/booking-system agnostic)

1) What we’re delivering (high level)

Inlet connects booking data → access control, so guests automatically receive working access (codes/links) and the hotel gets a smoother, more reliable operation. It works the same way for almost any PMS/booking system—only the adapter settings and lock setup guide change.

2) Who does what (other parties)

Hotel (SPOC / PM)

• Owns decisions + sign-off, coordinates testing, keeps stakeholders aligned.

Locksmith / installer

• Installs & commissions locks and prepares them for integration (varies by lock system). Use the relevant setup guide.

IT / Network

• Enables secure connectivity (firewall/ports/IP allowlist/certs where needed).

Booking system owner / integrator

• Ensures reservation data quality (updates, cancellations, room moves) and required fields are present.

Inlet

• Connects via an adapter (if available), configures rules, maps rooms/doors, supports testing + go-live.

3) The standard A–Z flow (same for every hotel)

1. Kickoff workshop

   • Define guest journey (which doors, when access starts/ends) + operational journey (exceptions, backups).

2. Hardware lane (locks)

   • Locksmith completes lock-system setup (per setup guide) and shares required integration details.

3. Network lane

   • IT completes network prerequisites for the lock system (per setup guide).

4. Booking/PMS lane — adapter configuration (most important/complex)

   • Decide how reservations should drive access:

     • when to start processing arrivals,

     • what gates access activation (time/status/payment rules if applicable),

     • how room moves behave,

     • what to do when contact data is missing/invalid,

     • sync/polling expectations.

5. Inlet configuration

   • Inlet connects systems, maps rooms ↔ doors, configures rules and groups, validates end-to-end.

6. Guest communications (keep it simple + redundant by default)

   • Set up SMS + Email by default (redundancy), and tell the hotel to mention this in their booking confirmation (incl. “check spam”).

   • Don’t overcomplicate templates: focus on code + validity + updates (PMS already sends confirmations).

   • Note: Inlet does not support guest Name as a smart field, so avoid “Hi [Name]”.

   • Timing is controlled with Firetime.

7. Testing → Go-live

   • Run a structured test period (commonly ~14 days): new booking, update, cancellation, room move, shared doors, and backup procedure.

4) Minimal deliverables (what the PM should ensure exists)

• ✅ Door list + mapping + “who gets access to what”

• ✅ Adapter decision sheet (reservation → access rules)

• ✅ SMS and Email texts + templates + send timing

• ✅ Backup access plan documented

• ✅ Test plan + sign-off

Relevant KB links (only the essentials)

• Responsibilities for the project manager: https://kb.inlet.tech/kb/the-project-manager/

• Implementation roles/steps: https://kb.inlet.tech/kb/implementation-roles-responsibilities-and-steps/

• Setup guides (lock specific): https://kb.inlet.tech/setup-guides/

• Customer comms (SMS + email): https://kb.inlet.tech/kb/customer-communication-sms-and-email/

• Smart fields list: https://kb.inlet.tech/kb/sms-and-email-smart-fields-to-insert-data/

• Firetime timing: https://kb.inlet.tech/kb/understanding-firetime-in-inlet/

• Backup access best practice: https://kb.inlet.tech/kb/best-practices-access-backup-solution/

If you want, I can also turn this into a one-page checklist (inputs per party + go/no-go gates) that fits nicely into a project plan.