Pricing a light trail season so November pays for December

Why does the number of events decide when I get paid?

Payouts are scheduled per event, not per night. The scheduler admits an event only once its last session has ended, releases the money two days later, and never pays the same event twice. A trail that publishes mid-November to New Year as one event with two hundred arrival slots is therefore paid once, two days after closing night — even if the opening weekend sold out in October.

Six weeks of float is a serious working-capital fact for a business whose costs are all front-loaded: lights, installation, staff and marketing are all paid before the first visitor arrives.

The counter-move is to publish shorter events — one per week, or one per fortnight — so each closes and pays while the season is still running. The cost is that visitors see several listings rather than one, and your reporting is per event. There is no setting that changes payout frequency; the structure of your events is the setting.

How does a price ladder actually work here?

A ladder is successive tiers with successive on-sale windows, and each rung keeps its own stock. An early-bird rung with two thousand entries at a lower price, opening in September and closing in October, is a real tier with a real pool — not a discount applied to a shared inventory.

The rung is enforced where the money moves rather than in the page. A visitor holding a stale link to a closed early-bird rung is refused when they try to buy, which is the behaviour you want on the night a price steps up and half the internet still has the old page open.

The price someone paid stays readable on their order after the ladder has moved on, so a January reconciliation tells you what each rung actually earned rather than what the current price would have earned.

How should I shape peak and off-peak nights?

Peak pricing is separate ticket types plus pool control, because price lives on the ticket type and not on the night. Create a standard entry and a peak entry, then close the wrong one on each night by setting its pool to zero.

Since that is one edit per pool, design a pattern with as few boundaries as you can live with. Two types and a weekend rule is ten minutes of work; four types and a bespoke price per night is an evening, every time you change your mind.

The quiet-night problem is usually better solved with a promo code than a fourth ticket type: a code is created once, applied inside the money transaction so it cannot be spent twice by two simultaneous checkouts, and disabled the moment the Tuesdays start filling.

• Two or three ticket types, not eight. Every extra type is another pool on every slot.
• Use the ladder for time-based movement (early bird → standard → late) and ticket types for night-based movement (off-peak → peak).
• Promo codes for tactical demand shifting mid-season; disable rather than delete when the night fills.
• Remember that a comp takes real stock from a slot, so sponsor entries need to be in your capacity plan, not on top of it.

Where do gift cards and sales tax fit into the plan?

Gift cards are the one product on this vertical that takes money now for a night chosen later, and for a Christmas trail that is worth building into the plan deliberately — there is no season pass available here, so a gift card is the only buy-now-choose-later shape you have. It behaves as tender rather than a discount: you are credited the whole sale when it is redeemed and the platform charges its fee on the sale as it would for a card.

The cashflow subtlety is that the money sits as a liability from purchase until redemption and cannot be paid out while it is unredeemed. Cards sold in November and redeemed in December are fine; cards sold as presents and never used are not money you can plan around.

Sales tax is price-exclusive and applied server-side, held on its own account, never credited to your balance and never part of what the platform fee is charged on. It is calculated and reported, not filed — remitting it is still yours.