Dynamic Pricing & Revenue Management · Documentation

User Journey

The end-to-end path through Dynamic Pricing & Revenue Management, from trigger to outcome.

1
Signal → recommendation → approval
The journey starts from a demand read: for the chosen property/room/date the store derives occupancy, booking pace, a competitor index, seasonality, a weekend flag and an occasional event. Those become signed price drivers, summed and then clamped to the configured swing and the absolute floor/ceiling band. The result is a recommended rate with a transparent breakdown — and a 'clamped' flag when a guardrail bit.
An owner approves the day's rate (or overrides it). That write is recorded, audited, and emitted as price.updated on the event spine.
2
Approved rate → the rest of the ecosystem
An approved rate doesn't sit in this app. price.updated and inventory.changed travel the spine: the host marketplace #01 reflects the new rate on the listing, the channel manager #17 picks it up to push to its simulated OTAs, and analytics #24 (a later cluster) rolls the change into revenue KPIs. The guardrail overlay the owner tunes re-keys the demand cache by its config-version hash in Stage-2, so a rules change invalidates stale recommendations.