System
Value-Based Pricing.
Personalized real-time pricing at a Fortune 500 hospitality operator.
Per-customer pricing that uses reservation history, gaming spend, propensities, and offers to set rates at the moment the booking flow asks for one, at twenty thousand rates a second, in production.
Problem
An RMS optimizes the room. It does not see the customer.
A traditional Revenue Management System maximizes room yield using room and market data, including historical demand, current inventory, and demand calendars. What it leaves out is the customer.
A regular casino guest with a $300/night ceiling and $200/night in average gaming spend should see a different room rate during a high-demand fight night than a price-insensitive walk-in, not as a markdown, but because the system can mathematically value the customer’s full trip and choose a rate that wins the booking while preserving overall margin. Doing this in real time, at the moment a customer requests a rate, would require pricing decisions that incorporate customer context inside the transactional plane, not in a nightly batch.
Architectural Constraint
Per-customer pricing does not fit in batch.
Per-customer × per-property × per-room × per-day rates do not fit in batch. For a chain with 10 properties, 500 room types, a 365-day booking window, and an active base of 10 million customers, that is 18.25 trillion rates per pricing run, neither computable nor storable.
The only feasible alternative is to compute the personalized rate at request time, against rack rates and customer data, inside the millisecond latency budget that modern booking UIs demand. That is a data-and-compute architecture, not just a faster pricing service.
Rumi solution
Pricing logic and customer data in the same node.
Rack rates produced by the RMS (~1.8 million records) and the customer base (~10 million records) live co-located with the value-based-pricing logic inside a Rumi node. When a booking channel requests a rate, the system identifies the customer, the property, the room, and the dates, retrieves the relevant rack rate and customer record in memory, and runs the personalization logic to produce the final rate, all inside the request’s response budget.
Over time, channel-specific data was added on the same architecture, unlocking dynamic offer selection, OTA transactional pricing, product-bundle pricing, and consistent pricing across all channels.
Operational Outcomes
25× loyalty revenue, 20,000 rates a second, one architecture.
- 25×increase in loyalty-driven revenue within the first 9 months
- 20,000personalized rates per second, in production
- 1 mspricing budget including customer and channel data
- 1.8M / 10Mrack rates and customer records, co-located in node
- All channelsOTA, Loyalty, Property, Contact Center, Front Desk
- New CRSsame architecture extended to the in-house CRS