Your RMS is the Steering Wheel. Where's the Dashboard?

A note for revenue managers running IDeaS, Duetto, Atomize, or any modern RMS — about the layer their tooling is missing.

A modern RMS — IDeaS, Duetto, Atomize, all of them — is a remarkable piece of software. The pricing engine watches dozens of signals, optimizes the rate continuously, pushes to the channel manager, learns from outcomes. For pricing-heavy properties, it’s hard to imagine running revenue management without one.

But every revenue manager I’ve worked with who runs a serious RMS has the same complaint, in different words: “The pricing is great. The reporting is weak.”

This article is about why that’s not a coincidence — and what to do about it.

What an RMS is built to do

An RMS is built to act. It looks at demand signals, computes optimal rates, pushes them to your channels. The product mission is rate optimization; everything else is supporting infrastructure.

This means the data layer is built for recommending the next rate, not for answering yesterday’s question. The RMS knows what it pushed and why; it doesn’t, by design, know how that decision compared to the alternative or whether it actually worked. The optimization engine is forward-looking; the analytical layer is, at best, descriptive.

For most RM workflows, this leaves a gap. Three of them, actually.

Gap 1: Decision audit

When the RMS recommended dropping weekend rates by 8% three weeks ago, why did it recommend it? Did you accept the recommendation or override? What did you tell the team? Did the override turn out to be the right call?

In most RMS environments, none of these questions have stored answers. The pricing decision happened, the rate went out, and the reasoning lives only in the RMS’s internal model state — which isn’t human-reviewable in any practical sense.

For a revenue manager preparing for a quarterly owner’s review, this is the gap that hurts. “Why did we drop weekend rates in March” should have a one-sentence answer with a date and a name. Most RMS deployments produce a “the optimization engine recommended it” answer that’s structurally true and analytically useless.

The missing layer: a decision audit. Reasons captured at decision-time, owner attached, outcome traceable.

Gap 2: Multi-dimensional analytics

“How did our Booking.com pickup for corporate-segment room nights compare to last year’s same-week-position?”

This is a normal RM question. The answer requires stacking five filters: channel, segment, period, comparison-mode, week-position-aware YoY. On most RMS reporting layers, getting that answer requires:

• Two or three exports
• Some Excel manipulation
• A judgment call about week alignment (which the RMS doesn’t make automatically)
• About 90 minutes of work

The answer existed in the data the whole time. The reporting layer just couldn’t surface it directly. Most RM teams develop a personal Excel toolchain to bridge the gap. The toolchain ages, breaks, gets re-built by the next RM, and the time leakage compounds.

The missing layer: BI depth on the RMS’s data, with the multi-dimensional filtering modern operators expect.

Gap 3: Owner-facing reporting

The owner wants a quarterly review. The RMS dashboard answers questions in revenue-management language. Translation between the two is a manual exercise that lands on the RM’s desk every quarter.

Most RMs end up building a parallel reporting layer in PowerPoint or in a dedicated BI tool, sourcing data from the RMS but presenting it in language the owner can engage with. The work is real — but it’s the same work, every quarter, forever. The RMS doesn’t help.

The missing layer: traffic-light scorecards, plain-language summaries, executive-level dashboards. Tools like RMS think in optimization language; owners think in “are we hitting plan and what’s the trajectory.” These don’t naturally translate; the gap is structural.

The architecture pattern

The pattern across all three gaps is the same: an RMS optimizes one job (rate optimization) extremely well, and the layers around that job — audit, multi-dimensional analytics, executive reporting — are intentionally underdeveloped, because the product wasn’t built to do them.

The analogy I find useful: the RMS is the steering wheel. Where’s the dashboard?

The steering wheel does what it does. The dashboard tells you whether you’re going where you wanted to, how fast, and what’s coming up. Both are necessary. Pretending one is the other gets you in trouble.

For a hotel’s revenue stack, the equivalent of the dashboard — the layer that handles audit, analytics, and executive reporting on the same data the RMS is acting on — is structurally separate. It can live in spreadsheets (most RMs do this), in a dedicated BI tool, or in an integrated revenue intelligence platform.

Wherever it lives, the separation is the point. You don’t try to do reporting from the RMS, and you don’t try to do pricing optimization from the BI tool. The two layers serve different purposes; they should be different tools.

What “the dashboard layer” looks like

In practice, the dashboard layer answers three questions the RMS doesn’t:

“What changed and why?” — multi-dimensional pickup tracking, segment performance, channel mix shifts, with same-point-YoY comparison built in. Not as exports; as a default view.

“What did we decide and what happened?” — decision audit with reason codes, ownership, outcomes traceable to the data. Discussion threads anchored to specific data rows so conversations stay connected to the numbers.

“Where are we three months from now?” — executive-level traffic-light summaries, forecast accuracy reports, owner-language scorecards. The RMS’s optimization runs in the background; the dashboard makes the outcomes visible to non-RM stakeholders.

For most RM teams, building this layer used to mean PowerPoint and Excel. Modern integrated tools (full disclosure: we make one) cover all three jobs in one place — alongside the RMS, not replacing it.

When you don’t need a separate dashboard

Not every property needs a separate dashboard layer.

• Very small properties (under 30 rooms) can usually run revenue management without an RMS or a separate analytical tool. The volume is small enough that the GM tracks everything in a notebook.
• Properties with very simple operations — single segment, single channel, no MICE — may get enough analytical depth from the RMS’s reporting alone.
• Hotels in the brand-corporate-reporting flow may already get the executive layer from their chain’s central reporting; the RM doesn’t need to build it.

For everyone else — mid-sized independent hotels with active RMS deployments and meaningful corporate or group revenue — the dashboard layer isn’t optional. It’s the layer that makes the RMS deployable to non-RM stakeholders.

The honest cost

A proper dashboard layer (not the spreadsheet workaround) costs in the €100–500/month range for an integrated tool, less if you build it on a generic BI platform. That’s a small fraction of the RMS subscription on most deployments — and recovers most of the time-leakage from manual reporting work.

The RMS isn’t broken. It’s doing the job it was built for. What’s been missing is the recognition that the analytical and reporting layer is a separate job, structurally, that needs its own tool.

Where to go from here

If you currently run IDeaS specifically and want to see how a separate analytical layer fits, the Peaqplus vs IDeaS comparison explains the coexistence pattern — IDeaS for pricing, Peaqplus for the dashboard.

For the analytical depth side specifically, the Business Intelligence page explains the multi-dimensional analysis approach (Time Machine, Same Point YoY, multi-dim filtering).

For the decision audit and executive reporting side, the Decisions & Collaboration page covers the workflow.

Or stay on the spreadsheet workaround. Most RM teams do; it works, kind of.