Using Dynamic Pricing Effectively
About This Course
A single flat price either overcharges during slow periods, losing bookings you could have won, or undercharges during peak demand, leaving revenue on the table — and there's no way to prove what a guest will actually be charged before it happens. TripWorks' dynamic pricing layers prioritized rate sheets on top of one always-present base rate: each rule targets a date range, day of week, group size, or channel — including giving resellers a wholesale net rate distinct from what website or walk-up guests pay.
The highest-priority match wins when more than one could apply, and staff can test any day's price before it goes live and audit exactly which rule applied to any real booking afterward.
Transcript
Why demand-based pricing matters
Weekends draw more guests than a Tuesday in February. A group of ten costs you differently than one couple. A reseller sending you volume bookings needs different economics than a guest who found you on your own website. Charge everyone the same price, and you're either overcharging the slow periods and losing bookings you could have won, or undercharging the peak ones and leaving real revenue on the table — with no record of why any one guest paid what they paid.
What dynamic pricing actually is
Your base rate never goes away — it's always sitting underneath as the fallback. On top of it, you layer rate sheets: prioritized rules that charge differently by date or season, by day of the week, by group size, or by channel — website, direct walk-up, or reseller. When more than one rule could apply to the same booking, the highest-priority one wins. Nothing is hidden or automatic in a way you can't see — you're always looking at one ordered list.
Seasons — the reusable library behind “by date or season”
A season isn't something you type into one rate sheet and forget — it's a reusable library. Under Setup → Seasons & Schedules, you define a named season once — Summer, Black Friday, Fall — with its own recurring date ranges, and any rate sheet can reference it by name. Set it up once, and it's there next year too.
Why channel matters
That channel piece is easy to overlook, but it's real money. A website guest is paying retail. A reseller sending you a block of bookings usually needs a wholesale net rate — not because you're discounting your product, but because that's the economics of the relationship. TripWorks lets you set that as its own rule: a rate sheet scoped to the reseller channel, distinct from what a walk-up or website guest pays for the exact same activity. A built-in channel-coverage check flags any channel you've left completely unpriced, so you're not finding out about a gap from a confused reseller.
Building your first rate sheet
Adding a rate sheet takes seconds. Name it, set your price per ticket type — say a hundred dollars for an adult, fifty for a child — decide what it applies to, and set it live. That's the whole rule.
Layering a second rule
Now layer a second one on top. Weekends can charge more — two hundred for an adult, a hundred for a child — without touching the first rate sheet at all. Every rule you add stacks independently.
Priority is a real decision, not an afterthought
Stacking rules means you have to decide what wins when more than one could match the same booking. That's priority — a simple ordered list, nearest the top wins. Drag Weekends above Standard, and now every Saturday and Sunday charges the weekend rate instead of the base — deliberately, not by accident.
Proving it before it's live, and auditing it after
Before you ever go live, Test a Price lets you pick any day and see exactly which rule would win, and why every other one lost — a guest never sees a price you haven't already checked yourself. And after the fact, every real booking keeps a record of exactly which rate sheet applied, right there in the pricing breakdown next to the ticket price.
The common mistake: pricing isn't retroactive
Adding a new rate sheet doesn't reach back and reprice bookings that already happened. A trip reserved before your Weekends rule existed keeps its original price — it only gets re-priced if that booking is actually rescheduled, which forces the pricing engine to run again. That's not a bug to work around; it's what makes a guest's price stable once they've booked.
If a price ever looks surprising
You don't have to trace the rule chain by hand. Just ask Beacon. It'll tell you, in plain language, exactly which rate sheet won and why.
FAQ
What happens if two rate sheets could both apply to the same booking?
The highest-priority rule — the one nearest the top of the list — wins. Lower-priority matches are evaluated and shown as “would have applied” in Test a Price, but only the top match is actually charged.
If I add a new rate sheet, does it change prices on bookings that already happened?
No. Pricing is calculated at the moment a booking is made (or re-priced), not retroactively — a booking made before a rate sheet existed keeps its original price unless it's rescheduled, which forces the pricing engine to re-run and pick up any rule that now applies.
Can I see what price a booking will get before a guest actually books it?
Yes — Test a Price lets staff pick any day and see exactly which rate sheet would win and why every other one lost, before any guest ever sees that price.
How do I know which rate sheet applied to a booking that already happened?
Open that booking's pricing breakdown — a tag next to the ticket price names the exact rate sheet that won. Or just ask Beacon to explain the price in plain language.
Can I charge resellers a different rate than website guests?
Yes — set a rate sheet's channel to reseller (or set a reseller-specific base rate). The “Channel or reseller net rate” preset is a ready-made starting point, and a channel-coverage check flags any channel you've left unpriced.