Managing multiple NewBook accounts across a hotel group

Hotel groups running two or more properties on separate NewBook accounts hit a recurring problem: NewBook manages each account independently. There is no native NewBook feature for consolidated group-level reporting or bulk operations across multiple properties. This article covers the workarounds available within NewBook and how third-party group-management modules close the gap.

The multi-property challenge in NewBook

NewBook is architected around one account per property. Each hotel has its own NewBook account, its own credentials, its own rate plans, its own channel configuration and its own reporting. For a single-site operator this is a good fit. For a group running 3, 5 or 10 properties, it creates real operational friction.

A group revenue manager typically needs to: compare occupancy and ADR across every property at once; spot rate parity gaps between properties; apply the same rate change to several properties in one operation; track booking pace at group level; and produce consolidated reports for management. None of these tasks is available natively in NewBook for multi-account groups.

The usual workaround is opening several browser tabs — one NewBook account per tab — and comparing the data manually. For 2- to 3-property groups this remains manageable. Above 3 properties it becomes time-consuming and error-prone.

Approach 1: export NewBook reports and aggregate manually

Each NewBook account can export reports to CSV. A group revenue manager can download the same report from every account and consolidate them in Excel or Google Sheets. This works but requires: (a) signing in to each NewBook account separately; (b) running the same report against every account; (c) downloading CSVs from each; (d) merging and formatting them in a spreadsheet. For a weekly review, this process typically takes 30 to 90 minutes depending on group size and reporting complexity.

Approach 2: use the NewBook API to build a custom integration

For groups with a technical resource, the NewBook API lets custom scripts pull data from several NewBook accounts simultaneously, using a distinct API key for each property. This is the approach taken by large hotel groups with an in-house technology team. Group data is aggregated into a central database or a BI tool (Power BI, Tableau, Looker) and the consolidated dashboard is built inside the BI tool.

This approach offers maximum flexibility at the cost of a significant upfront development effort and ongoing maintenance, especially when the NewBook API evolves.

Approach 3: use a dedicated multi-property module

For groups that cannot justify custom development but need more than a manual spreadsheet process, dedicated multi-property modules offer a middle path. The CloudBookMod Multi-Site setup connects to each NewBook property account using its own API credentials and aggregates the KPI data into a unified group dashboard.

Key capabilities of a multi-property setup: (a) group-level KPI view — occupancy, ADR, RevPAR, pickup — for every connected NewBook property, refreshed in real time; (b) rate parity monitoring across properties — alerts when the same room type sells at materially different rates between properties without a deliberate pricing rationale; (c) bulk rate operations — apply a rate change to every property or a selection in one go, with a confirmation step before pushing to NewBook; (d) group pickup report — visualise booking pace across every property in a single view; and (e) consolidated billing and support, rather than managing a separate vendor per property.

Managing rate parity across NewBook accounts

Rate parity is a specific pain point for groups with varied accommodation offers across properties. If your group includes a luxury hotel and an economy hotel that share similar room categories, accidental rate parity between the two can undermine the positioning of the upmarket asset. Conversely, if the same standard room type sells at very different rates across properties in the same market, you may breach the parity clauses OTAs enforce.

Monitoring this manually across several NewBook accounts means pulling rate plan reports from each account and comparing them side by side. Automated multi-property management monitors this comparison in real time and alerts the revenue manager the moment a parity flag is triggered.

Organisational recommendations for multi-property NewBook groups

Groups that operate effectively across several NewBook accounts typically share these practices: a single group revenue manager with access to every NewBook property account; a weekly consolidated KPI review meeting using cross-property data; standardised rate-plan naming conventions across every NewBook account (which simplifies comparisons); and a documented escalation process when a property's performance drifts materially from the group's targets.

The most effective multi-property operators treat their NewBook accounts as a portfolio rather than as independent assets. A portfolio-level pricing strategy — deciding when properties should position differently from each other and why — requires the consolidated visibility that NewBook's native multi-account interface does not provide.