A destination is more than a room.

The day starts with breakfast across one or more outlets, often from 07:00, and with the activity desk confirming the day’s departures. Housekeeping covers rooms, villas and public areas across a dispersed site, so the room board has to reflect buildings and travel time, not just floors. Arrivals may come in waves with transfers, and departures are spread across the morning. Outlets run separate windows, the pool bar follows the weather, and evening dining may require bookings. The night close still happens after the last outlet, but the day’s revenue is spread across rooms, F&B, activities and transport. Seasonal hours change the whole pattern, and the system has to hold the current season’s rules.

The PMS holds the package and the guest ledger; the POS holds outlet charging; procurement holds stock and recipe costing across stores. At the desk, the package components are visible on the folio, so an included dinner is flagged and an extra beverage is not. Activities and transfers post to the folio or to a package component, depending on the rule. Housekeeping works across buildings and room types, and the board must show which units are ready to sell. Finance uses the same postings to allocate package revenue across rooms, F&B and activities at month-end. Reporting follows the same allocation, so the package can be read as a product rather than a room rate with extras.

Scale and season change the operating pattern more than any other factor. A 500-key resort may run several restaurants, a spa, a pool bar and an activities desk, each with its own hours and revenue centre. Seasonality changes rates, minimum stays, closed-to-arrival dates and day-of-week pricing, and it changes outlet hours and staffing. Groups and long stays add blocks, rooming lists and multi-room billing. A dispersed site adds another condition: the desk may need to keep working when the network link to the centre drops. The system should hold the season’s rules centrally and let each delivery point post against them without a separate rate sheet or a manual override at the desk.

Configure seasons and rate plans first, then packages and their revenue allocation. Agree how each component posts, what is included, what is an allowance and what is chargeable, and test a multi-night package from arrival to settlement. Map outlets, activities and transport to revenue centres before the first live posting. Set the housekeeping board by building and room type, and decide how offline operation will reconcile when the link returns. Boundary conditions include closed-to-arrival dates, minimum-stay rules, package changes mid-stay, and the treatment of no-shows and deposits. Interfaces for activity systems, locks and payment terminals should be assessed in the same scope, with a clear statement of what is native and what needs integration work.