A price calendar built one date at a time
Your attraction sets three price bands: peak for school holidays and bank holidays, standard for weekends in term time and off-peak for weekdays in term time. The online price is lower than the gate price. The marketing team decides the calendar for next year, and someone in the office enters each date into the ticketing system.
School holidays differ between local authorities around you, so the dates are argued over. A half-term week is entered at off-peak by mistake and sells well before anyone notices. The gate still charges the old price for a week because the till was not updated.
Why date-based pricing is error-prone
Ticketing systems often allow date-based prices but expect them to be set date by date, or in blocks that are awkward to change. When the calendar changes, someone repeats the job.
The gate till and the online ticketing may be separate systems with separate price lists, so every change is made twice.
Pricing decisions also lack feedback. Nobody easily sees how off-peak dates sold compared with last year, or whether the online discount moved people from gate to online.
And the calendar is hard to explain to visitors. If the website shows a single price but the checkout shows another, you get complaints and abandoned bookings.
What manual pricing costs
| Problem | Effect |
|---|---|
| Dates entered by hand | Wrong prices on some days |
| Separate till and online prices | Gate and online disagreeing |
| School holidays that vary | Arguments and late changes |
| No view of results | Pricing decisions based on opinion |
| Unclear prices on the website | Visitors surprised at checkout |
A pricing calendar with rules and checks
We build a pricing calendar that sits above your ticketing system and tills.
- You define price bands and rules: which dates are peak, standard and off-peak, the online and gate prices for each ticket type, and any special dates.
- School holiday dates can be loaded from the local authority calendars you choose, then adjusted by hand.
- The calendar is shown as a colour-coded year view for sign-off before anything changes.
- Once approved, prices are pushed into online ticketing and, where possible, the gate till through their APIs, and a check confirms that both match the calendar.
- Your website shows a simple price calendar to visitors, so they see the price for their date before checkout.
- A report shows sales by price band against the same period last year, and how the online and gate split changed.
We do not set your prices. Deciding what to charge is yours. We make sure the prices you choose are the prices visitors see and pay.
Cases we plan for
- Events on particular dates with their own pricing.
- Annual pass prices that change on a set date.
- Concession prices that follow the same bands.
- Last-minute changes, such as lowering prices on a day with a poor forecast, which follow the same approval step.
Setting next year's prices, afterwards
The marketing team builds next year's calendar in an afternoon, with school holidays already loaded. The manager signs off the year view. Prices are pushed to online and gate, and a check confirms they match. Visitors see their date's price on the website.
- Price bands set by rule, not date by date
- Online and gate prices kept in step
- A year view for sign-off
- Reports on how each band sells
Does pricing work like this for you?
- Prices are entered date by date.
- Online and gate prices are set separately.
- Wrong prices have been on sale for some dates.
- Visitors are surprised by the price at checkout.
- You cannot easily see how each price band performed.