Christmas Light Trail Ticketing

The vertical decides the vocabulary, the questions asked at checkout, the inventory model, the door, the payout terms and the theme. This page says "entry" and "night" because that is what a trail says; a config whose primary call to action is generic ticketing wording fails validation rather than shipping.

Everyone wants to arrive at half past five

Families come when the children have finished tea, so an undifferentiated night ticket puts four hundred people through your gate inside forty minutes. The car park backs out onto the road, the first quarter mile is a shuffling crowd rather than a walk through lights, and the last hour runs at a third of capacity while the same staff stand in the same cold. The complaints are never about the lights.

What bindro does: A night is generated as a grid of timed arrival slots and each slot carries its own inventory pool, so the shape of the evening is something you set in advance rather than something you discover on the twenty-third. A slot that fills says sold out and stops selling, and the pool is locked inside the same transaction that takes the money — the last entry in the 17:30 slot cannot be sold to two families in the same second, because the database refuses it rather than because the page reloaded fast enough. While the night runs, the day-of screen shows what is left in each slot as it moves.

A Saturday in December and a Tuesday in November cost the same money

One price across a six-week season is two mistakes at once: the peak nights sell out in October at a price that left money on the table, and the midweek nights in the third week of November never fill at all. A trail with forty operating nights and one price is running a business where a third of its capacity is priced for a demand curve nobody has looked at, and the correction — a discount code posted on social media at four o'clock — trains everybody to wait for it.

What bindro does: A price ladder is successive tiers with their own on-sale windows and their own stock, and the rung is resolved on the server at the moment the money moves, not read off the page the visitor is looking at. That means an early-bird rung that has sold out or closed cannot be bought by a stale tab, and a peak tier that opened at midnight is the price from midnight without anybody republishing anything. Promo codes exist for the cases a ladder is the wrong instrument — a local-radio code, a partner code — and they are codes, never amounts the client is trusted to name.

The season is paid for in October and paid out after Christmas

Lights, generators, fencing, marshals, marketing and the field itself are all bought before a single visitor arrives, and the trade that repays them lands in a six-week window. A trail that cannot see its own cash position until the season is over is making its December staffing decisions on a hunch.

What bindro does: Payouts are scheduled per event and released after that event's last session has ended, which makes the structure of your season a cash-flow decision rather than an administrative one — a season published as one long event pays once, at the end; published as one event a week it pays weekly. Nothing is paid before delivery in any vertical on this platform, and "paid" means a real transfer with a reference attached rather than a status somebody set. In the meantime the console reports gross, fees and refunds per event off the same ledger the payout reconciles against, so what you are owed is visible long before it moves.

A field, two entrances, and one bar of signal

The gate of a light trail is a trestle table in a field in December: a queue of cold families, a marshal holding a phone in a glove, and whatever coverage the site happens to have — which on the busiest night, with four hundred phones on one mast, is usually none. A door that needs a network is a door that stops, and one that stops on the twenty-second of December is the whole night.

What bindro does: The door is designed offline-first rather than patched for it. Each gate device downloads a manifest for the night before it goes out, admits from that manifest with no connection at all, and replays its scans when it next reaches signal; scans that disagree between two entrances are recorded and flagged for you to read afterwards rather than resolved by whichever device happened to sync second. A wristband or a printed code both admit, and a marshal can find a visitor by name in the console and admit them by hand when a family arrives with a dead phone.

Half the night's takings never touch the ticketing system

Entry is the headline and rarely the margin. Parking, mulled wine, hot chocolate, marshmallows, hats and the photograph with the reindeer are where a light trail actually makes its money, and on most sites they run on a separate card reader, a cash tin and a paper tally. Nobody knows the attach rate until somebody reconciles a shoebox in January, by which point the season it describes is over.

What bindro does: Add-ons are sold beside the entry with their own finite stock, so a car park with three hundred spaces sells three hundred and then stops, and a photo package can be capped at what your photographer can actually shoot. On the night, the gate till takes walk-up card sales and the food and merchandise tills record what goes over the counter, so the night's numbers are complete in one place. Money you take on site is already yours and is recorded rather than settled — bindro never holds it, so it is never paid out to you a second time.

Four entries bought as a present, and three people nobody has named

The single most common purchase of a light trail season is somebody buying entries for a family they are not part of, in November, as a present. The buyer is not on the trail, the people who are have never seen the confirmation email, and the booking exists under a name nobody at the gate will hear that night.

What bindro does: A booking for more than one entry creates a place per entry and emails the booker a link to name them, and those names are what the door admits. Read the next sentence twice, because it is the one that catches trails out: a place nobody has named is refused at the gate, on the offline manifest and the online scan alike. That is deliberate — an unnamed place is an entry with no holder — but it means the roster email is part of your operation rather than a nicety, and it belongs in your confirmation wording, your reminder and your signage. Your staff can name a place from the console and admit by hand if a family arrives without having done it.

Nobody is sure who is on which gate on the twenty-third

A trail runs on seasonal staff and volunteers who work four nights each across six weeks, on a rota that lives in a group chat. The people on the gate on the busiest night of the year are frequently the people who have done it least, and handing them the login that can also issue refunds is a decision made at five o'clock in the dark because there was no other login to hand them.

What bindro does: Staff and their shifts are held against the nights they are working, and what somebody can do is decided by their role rather than by which buttons you remembered to hide. A marshal on the gate sees a name and whether the code admits — not what anybody paid, not the night's takings, and not the refund control — and that is checked in the handler on every request rather than in the interface. It means a new volunteer can be given a login for one night without that being a decision about your money.

A season generated as a grid, not built one night at a time

You give bindro a date range, the arrival times you want to run each night and how long an arrival window lasts, and it creates a session for every time on every night with its own inventory pool per ticket type. A six-week season at eight arrival times a night is not eight nights of data entry; it is a few generations, because two hundred sessions is the ceiling on one pass. Capacity is per slot, so the wide 17:30 and the narrow 20:30 are different numbers rather than the same number divided.

• Timed arrival slots per night, each holding its own stock, generated from a pattern.
• Per-slot capacity, so the shape of the evening is a decision rather than an average.
• Two hundred sessions per generation — a long season is a handful of passes, not one.
• Nights you are not opening are best not generated at all — calling one off afterwards works, but it is a settlement decision rather than a tidy-up.

A price ladder the money path enforces

Tiers carry their own price, their own on-sale window and their own stock, and the unit price is resolved on the server inside the transaction that charges the card. A visitor sitting on a page that was correct twenty minutes ago cannot buy at a closed rung, and a client that tries to name a price is rejected by field name rather than quietly trusted. Flat, tiered and early-bird pricing are what this vertical can actually take money with, and they are the three the page offers.

• Early-bird rungs with real stock, so "first 500 entries" means five hundred.
• Peak and off-peak tiers priced per ticket type across the season.
• Promo codes for partner and radio offers — codes carry value, the client never names an amount.

Parking, hot chocolate and photographs as finite stock

Add-ons sit beside the entry in the same basket with their own inventory, which is the difference between selling parking and overselling it. Anything you can count can be sold this way — a space, a photo slot, a bag of marshmallows, a pre-ordered hot chocolate collected at the halfway hut. What is honest to say plainly: stock is held across the whole event rather than per arrival slot, so an add-on capped at three hundred is three hundred for the night, not thirty per slot.

• Any add-on can carry its own finite stock, sold in the same transaction as the entry.
• Vehicle registration is collected as a question on the booking, stored and shown to you — it reserves nothing and nothing reads a number plate.
• Accessibility requirements are asked and carried through to the night without anybody having to ring you.

A door that works with no signal, on more than one entrance

Offline is designed in rather than bolted on. A gate device pulls the night's manifest before it goes out, admits from it with no network, and replays afterwards; a second scan of the same credential is recorded and flagged as a conflict for you to read, whichever entrance makes it — the one that admitted them or another. What that means in practice is worth being blunt about: the platform records and reports double entry, it does not refuse it. Keeping people from walking the trail twice is a rope-and-staff problem, and always was.

• Offline manifest, offline admit, replay and a conflicts view when signal returns.
• Wristbands or printed codes; both admit, and the gate scans a credential rather than checking an identity.
• Multiple entrances scanning at once, with disagreements surfaced rather than silently resolved.
• A searchable visitor list in the console with tap-to-admit, for the dead phone and the lost email.
• There is no bindro scanner app: the door is an API plus the console. Binding a wristband is an API call, so plan for somebody technical before opening night.

Walk-ups at the gate and the tills on site

Not everybody books. A gate till takes a walk-up by card against whatever stock the slot has left, so a family who drove out on the off-chance is a sale rather than a disappointment, and the entry they get is the same entry with the same code. The food and merchandise tills record what goes over the counter so a night's trading is one number rather than three. Cash-recorded entry sales are deliberately not implemented: crediting your balance for money bindro never held would pay you for the same sale twice.

• Card walk-ups at the gate, drawing on the same inventory pool as an online booking.
• Food, drink and merchandise tills recorded against the night.
• On-site takings are yours already — recorded for your numbers, never settled and never paid out again.
• Back-office orders for the phone booking, the coach party and the correction somebody has to make by hand.

Gift cards, which are the present that survives a change of plan

An entry bought as a present is fixed to a night and a time and cannot be handed on or moved, because this vertical resolves neither transfers nor deferrals. A gift card is the shape that works: stored value the recipient redeems against whatever night suits them, at whatever the price is when they book. It is carried as a liability rather than counted as revenue until it is spent, which is the correct accounting and also the reason unredeemed value cannot be paid out to you.

• Gift cards sold like anything else and redeemed as real tender against an entry.
• Value is a liability on the ledger until redemption, not income on the day it sells.
• A refund against a gift-card payment returns the value to the card.
• Sell them from the same page as the booking button — November is when people look.

Sales tax, refunds, chargebacks and comps

The unglamorous half, which is the half that goes wrong in public. US sales tax is applied server-side, held as a liability rather than mixed into your balance, and kept out of both the fee base and the payout figure — so the number you are paid is proceeds rather than a number you still have subtraction to do on. Refunds reverse in a fixed order: your proceeds first, then tax, then the platform fee.

• Visitors can refund themselves in full from their own confirmation link right up until their arrival slot starts; after that the decision is yours, from the console.
• A refund you choose to give is one order at a time; the one bulk refund there is rides on calling a night off, and settles every booking on that night at once.
• Chargebacks debit the organiser in full and are handled idempotently by provider reference, so the same dispute cannot land twice.
• Comp entries for the sponsor, the local paper and the volunteer's family consume real inventory and scan normally, but write no revenue lines.

Your own site, our page, or both

Most trails already have a website that took a designer a fortnight, and asking visitors to leave it is where bookings are lost. Bindro gives you a hosted page per event that works on a phone in a cold hand, and an embeddable checkout for the site you already have, and they sell the same inventory — there is no second stock to reconcile. Who pays the booking fee is a setting per event: the visitor, you, or split, with the fee itself unchanged either way.

• A hosted page per event with the slot picker, priced tiers and add-ons.
• Embedded checkout on your own domain, selling the same pools.
• Fee borne by the visitor by default, so a trail is never out of pocket before a sale happens.
• One inventory behind every surface, including the gate till.

What you still hold in January

A season's worth of trading is a season's worth of information, and it should not be trapped behind whoever you sold through. Financial reports per event come off the ledger the payouts reconcile against; orders and visitors export as CSV whenever you want them, behind a fresh one-time code, with no export fee and no notice period. The visitor record persists across seasons, so the family who came in 2025 is somebody you can recognise in 2026.

• Gross, fees and refunds per event, from the same rows the payout is built on.
• Entries sold against visitors scanned, with a no-show percentage per session.
• Orders and visitors as CSV, on demand, at no charge and with no notice period.
• A post-event follow-up to visitors who opted in, sent once the whole event has finished — a marketing sweep, not a broadcast you can trigger.

Who pays the booking fee?

The visitor, unless you say otherwise. Every night carries its own setting — the visitor pays, you absorb it, or you split it — and the fee itself does not change with the choice, only which side of the sale it comes from. On a ten-entry $25.00 night that is $16.20 either added to what visitors pay or taken out of what you keep.

Because the default is the visitor, a trail can go from signing up to a sold-out night without paying bindro anything up front, at any point, ever. We are paid out of sales that happened or we are not paid.

The word "event" is load-bearing and worth reading twice. The scheduler groups by night, admits one only once its LAST session has ended, and pays it once. A night sold as a run of dates therefore pays after the final date, not after each one — a season's float is not something an operator should discover halfway through the season.

Bindro never pays before delivery, in any vertical. A pre-event advance is a configuration violation platform-wide rather than a policy someone can be talked out of, because paying out on nights that have not happened is exactly how a cancellation becomes visitors with no refund. "Paid" also means the money moved: a payout only reaches its paid state with a real transfer reference attached, enforced by the database rather than by a status field someone can set.

• One payout per night, after its last session ends, one in flight at a time.
• T+2 for this vertical (low risk tier), no reserve.
• Refunds reverse in a fixed order — your proceeds first, then tax, then our fee — so a refund never leaves you charged for a sale that was undone.
• Sales tax, where it applies, is held as a liability rather than mixed into your balance, so the payout figure is proceeds rather than a number you still have to do subtraction on.

A season published as one long event gives you one revenue figure for the whole six weeks and one payout at the end of it. The same season published weekly gives you six revenue figures, six payouts and a per-night picture you can act on while there are still nights left to act on. Attendance is per session either way; it is the money side that follows the structure you chose in October.

The three measures this vertical is designed around are the slot utilisation curve, the weather-refund rate and the parking attach rate, and each deserves an honest account of where its numbers actually come from. The utilisation curve is the one bindro serves best: every arrival slot is a session with its own pool, so sold against capacity per slot is a report rather than a project, and the shape of your evening — the 17:30 spike, the dead 20:30 — is visible from the first weekend.

The weather-refund rate is arithmetic you can do from exported rows but not a figure the console produces, because nothing in bindro knows why a refund happened. Refunds are counted per event and appear in the financial report; attributing them to fog means knowing which nights you lost and filtering the export by arrival time. It is twenty minutes in a spreadsheet, not a dashboard tile, and pretending otherwise would be the exact defect this site is built to avoid.

The parking attach rate sits between the two. Add-on lines are on the order and in the CSV export, so parking sold against entries sold is a division you can do per event with no integration — but no screen shows it as a percentage, and no chart trends it across the season. Take the export, one column against another. The rows are complete and they are yours; the ratio is yours to take.

The funnel below has a step most ticketing has never heard of — a slot is selected after a date is — and that is why the reports are shaped this way: a trail whose Tuesdays and Saturdays are averaged together has a number describing nothing it can change.

What the console shows today, without an integration or a spreadsheet:

• Gross, platform fees and refunds per night, read from the ledger the payouts reconcile against.
• Entries sold against visitors checked in, with a no-show percentage per session.
• Live remaining capacity while the night is running, per pool, on the day-of screen.
• This trail's own funnel — view → date selected → slot selected → checkout → paid → scanned — stage by stage with the drop-off between them, and any step the platform cannot see said so rather than shown as a zero.
• Refunds, transfers, turnout, no-shows, add-on attach and repeat buyers, each printed with the two numbers it was divided from.
• Orders and visitors as CSV, so anything not on the screen is one export away.

Two more that are worth stating plainly. Sensitive answers are classified on the field rather than by convention, and health data is excluded from analytics exports and from AI context absolutely, with no override in any vertical. And a trail's own people see only what their role allows — a door login sees a name and whether the code admits, not what anyone paid — which is checked in the handler rather than by hiding a button.

• bindro will not decide the weather for you. Calling a night off is one control on the night itself — it comes off sale, you choose refund, credit or keep-their-booking, and every entry on that night is settled that way in one action — but nothing watches a forecast and nothing calls it for you. There is no weather provider anywhere in the product, so the decision, and its timing, are yours.
• There is no general message tool. The only mail bindro sends to a night's visitors is the one that goes with calling that night off, and only if you tick the box asking for it: one mail per person, after the money has actually moved, saying what happened to it. There is no "message this night" control for anything else — a change of parking, a late opening — so that still goes out from your own mail tool, off the visitor CSV.
• A part-refund is not a part-cancellation. The bulk settlement applies one policy to the whole night; a goodwill gesture to the family who queued in the rain is still one refund at a time, from the console.
• No season pass. This vertical's configuration lists a season pass among its pricing models, but the capability behind it is not enabled here, so the checkout refuses one and no page offers it. Unlimited-entry passes, resident passes and "come as often as you like" products are not something a trail can sell on bindro this season — a price ladder rung or a gift card is the nearest real thing.
• No transfers and no date changes. A visitor who cannot come on the Friday cannot hand their entry to a neighbour and cannot move it to the Saturday: this vertical resolves neither ticket transfer nor deferral, no name on an entry can be changed after payment, and there is no credit note to issue. The only lever is money out — a refund, and then they book again at whatever price is on sale.
• No donation box and no charity receipts. Many trails raise money for a hospice or an air ambulance; bindro does not resolve the donation add-on for this vertical, so there is no "add a donation" control at checkout, nothing totals gifts separately from entry income, and nothing issues a receipt for one. Charitable giving has to run alongside bindro, not inside it.
• No waiting list. When an arrival slot is full the page says sold out and stops. Nobody joins a list, nobody is emailed when an entry is refunded, and a refunded entry does not return to sale on its own. If you want to resell it, raise that slot's capacity by one.
• bindro does not stop a wristband being used twice. Trails are configured for single entry, but nothing in the engine refuses a second scan: it is recorded and flagged as a conflict for you to read afterwards, whichever gate makes it, and that gate is told the band has already been used to get in. Two devices in a field with no signal cannot agree in real time, so keeping people from walking the trail twice is a rope-and-staff problem.
• There is no bindro scanner app. The door is an API: an offline manifest your gate device downloads before the night, a replay call that reconciles its scans afterwards, a conflicts page to read what disagreed, and an online scan route for a gate that has signal. In the console itself you get a searchable visitor list with a tap-to-admit button and a day-of dashboard. Binding a wristband to a visitor is an API call with no console screen at all, so plan for someone technical before your first night.
• Every place on a multi-entry booking has to be named before the gate will admit it. Buying four entries creates a booking with four places and no names — this vertical asks nothing about each visitor at checkout — and the engine refuses a place nobody has named, on the offline door list and the online scan alike. The booker is emailed a link to fill the names in. A family that ignores that email arrives with entries that do not work.
• Parking is a question, not a controlled product. The vehicle registration box is stored and shown to you; it does not reserve a space, does not price anything and is not checked at the gate. You can sell parking as a paid add-on with its own stock, which is a real limit on how many are sold in total, but nothing caps parking per arrival slot and nothing reads a number plate.
• Money taken on site never enters the platform ledger and is never paid out to you — it is already yours. Mulled wine at the F&B till, hats at the merch till and walk-up card sales at the gate are recorded so your numbers are complete, and cash-recorded entry sales are deliberately not implemented at all: crediting your balance for money bindro never held would pay you for it twice.
• bindro does not pay out mid-season and you cannot choose the schedule. One event gets exactly one payout, scheduled only once its last night has ended and released two days later. A whole season published as a single event therefore pays once, in January. Publish shorter events if you need the money sooner — the pricing guide explains how — because there is no weekly payout option to turn on.
• bindro cannot enforce your refund policy. Every visitor can refund themselves in full from the link in their confirmation email, right up to the moment their arrival slot starts — there is no notice window to configure and no fee to withhold. After the slot has started the decision is yours alone, from the console.

If one of those is the thing you need, say so — the answer is a capability declared, built and gated properly, or a straight no. It is never a feature flag that collects the request and does nothing.

The mechanism is worth understanding rather than taking on trust. The payout scheduler groups by event, admits an event only once its last session has ended, and skips any event that already has a payout row. There is no weekly payout option, no schedule to configure and no mid-season advance — a pre-delivery payout is a platform-wide configuration violation rather than a policy anyone can be talked out of, because paying out on nights that have not happened is precisely how a cancelled season becomes visitors with no refund.

So the shape of your season in the console is the shape of your cash flow. Weekly or fortnightly events cost you a little more setup — each one is its own generation of arrival slots, its own tiers, its own page — and buy you money arriving through the season rather than after it. Some trails split the difference: November as one event, December in weekly ones, on the reasoning that November is the quiet half and December is the half whose cash they actually need.

There is a real cost to splitting, and it is not the setup. Reporting groups by event too, so six events means six financial reports rather than one season figure, and a visitor browsing sees several pages rather than one long calendar. Neither is fatal and both are arithmetic and navigation rather than lost capability — whereas discovering in December that the whole season pays in January is a problem no amount of arithmetic fixes.

• One event = one payout, released after that event's last night. No exceptions, no schedule setting, no advance.
• Weekly events: money through the season, six reports, several public pages.
• One season-long event: one report, one page, one payout in January.
• Whichever you choose, arrival slots, tiers, add-ons and the gate work identically.
• You cannot merge or split events after they have sold, so decide in October.

The sequence is short. Decide; pick refund, credit or keep-their-booking, none of which is preselected; tick the box if you want every visitor written to. The mail goes out after the money has actually moved and tells each person which of the three happened to theirs — one mail per person, not one per booking. If you are not ready to decide the money, "nothing for now" takes the night off sale and leaves the settlement for later.

Timing still matters more than most trails expect. Until an arrival slot has started, every visitor can refund themselves in full from the link in their own confirmation email, with no notice window to configure and no fee you can withhold. Making the call early means a good share of the refunds have already happened by the time you settle the rest.

Two things to plan around. Refunding or crediting in bulk is an owner or finance action — a manager can close the night and rearrange it, but not move the money — so make sure somebody with that authority is reachable in December. And a cancelled night leaves the payout schedule: cancel every night of an event and there is no delivered date left, so nothing is paid out until you settle it.

One last note for the same plan: a weather policy on your own site is worth more than a policy in bindro, because bindro cannot enforce yours — it will let a visitor refund themselves up to their slot whatever your terms say, and it is your published policy that decides between a refund and a credit.

• One control on the night, stating the bookings and the money at stake before you press.
• Refund, credit or keep-their-booking, applied to the whole night; nothing is default.
• Tick to email everyone booked — sent after the money moves, one mail per person.
• Announce early: before their slot starts, visitors can refund themselves.
• Refund and credit need owner or finance authority; closing the night does not.

Wristbands first. Binding a wristband to a booking is an API call and there is no console screen for it, so if your season runs on wristbands rather than printed codes, somebody has to do that integration before the first night. Codes need none of this — a code in a confirmation email scans fine — so a first season on codes with wristbands in year two is a perfectly reasonable plan, and cheaper.

The door next. The manifest is downloaded, not streamed — which is what makes the gate work with no signal, and also means a device that never downloaded one has nothing to admit from. Build pulling it into the same routine as charging the handsets, and give each entrance its own device so the conflict report is readable.

Then the roster. Any booking of more than one entry mints a place per entry with no name on it, and the gate refuses an unnamed place. The booker gets a link; whether they use it is a matter of how loudly you ask. Trails that put the request in the confirmation subject line and again in a reminder have far fewer arguments at the gate than trails that leave it to the default email, and your staff can always name a place from the console and admit by hand.

Finally, a dress rehearsal. Comp yourself four entries across two arrival slots, walk them through the real gate on the real device with the network turned off, and let the replay run when you get back to the office. Comps consume real inventory and scan exactly like a sale while writing no revenue lines, which makes them the right instrument for this — you are testing the door, not polluting the accounts.

• Wristband binding is an API call with no console screen. Codes need no integration.
• Each gate device pulls its manifest while it still has signal.
• One device per entrance, so conflicts are readable rather than mysterious.
• Ask for roster names in the confirmation subject and again in a reminder.
• Rehearse with comp entries through the real door with the network off.

The season-pass gap catches trails out because a trail reading its own configuration will see the model listed and assume it is available. It is not: this site refuses to publish a pricing model the checkout will not honour, which is why the fee table and the structured data here name flat, tiered and early-bird pricing and nothing else. Unlimited-entry and resident passes are not something you can sell this season.

The nearest real things are a price-ladder rung and a gift card. A rung priced for locals with its own stock and its own window does much of what a resident pass does commercially, without pretending to be unlimited. A gift card does what a transferable entry does: the recipient picks their own night at the price on sale when they book, which is also more forgiving than a fixed entry when somebody is ill on the day.

On transfers, be straight with buyers rather than letting them find out. The gate scans a credential and not a name, so forwarding a confirmation email to the people actually going works perfectly well for a single entry — that covers most of the "can I give this to my sister" cases. What genuinely does not work is changing the date, and a refund before their slot starts is something the visitor can do themselves in under a minute.

• No season pass: the model is listed in the config, unresolved in the engine, and refused at checkout.
• No transfers, no renaming after payment, no date changes, no deferrals, no credit notes.
• No waiting list: a full slot says sold out, and a refunded entry does not return to sale on its own.
• Nearest real instruments: a priced ladder rung, a gift card, or a refund and rebook.
• Forwarding the confirmation email works — the door reads a credential, not an identity.

This matters more in a seasonal trade than a year-round one: a light trail makes a platform decision roughly once and then lives with it under maximum pressure for six weeks, so the sane time to check what leaving looks like is before you arrive.

A few things are deliberately not exportable, and the reason is the same in each case. Anything classified as sensitive on the field — accessibility requirements are the one that applies to this vertical — is excluded from analytics exports and from AI context absolutely, with no override in any vertical and no setting to turn it off. It is visible to you where you need it, on the booking, and it does not travel into a spreadsheet somebody emails around.