Selling Seats on Scheduled Sessions

Publish a booked session — a tour, a class, a guided trip — and sell seats to the public, then hand whoever runs it a printed roster with every name, class, and payment status.

Updated 3 hours ago 6 views scheduling payments reports portal bookings

Selling seats on scheduled sessions

Sometimes the person who books your resource isn't the person who shows up.

A tour operator books a dock for a ten o'clock departure. Forty-eight passengers buy seats for that departure. The operator pays you a landing fee based on how many actually sailed; the passengers pay for their seats; and the captain needs a piece of paper with everyone's name on it before the lines come off.

That's what public sessions do. It builds on booking shared resources by time slot — the session is a booking, and everything else hangs off it.

When you'd use this

  • Boat tours and charters where you handle ticketing and hand a roster to the vessel.
  • Guided trips — kayak, fishing, hiking, diving.
  • Classes and clinics with a headcount limit.
  • Events on a bookable space — a talk in the pavilion, a demo in the yard.

The common thread: a fixed time, a capacity, and a list of individual people who need to be accounted for on the day.

How it fits together

The session is a booking. Someone — usually an operator, sometimes you — books the resource for a window of time. Most bookings stop there and sell nothing.

A program is what gets sold. "Sunset Harbor Cruise", 48 seats, Adult/Child/Senior. You set it up once, under Session Programs, and attach it to as many departures as you like. That's the piece that makes a standing weekly tour practical — nobody re-types the seat classes every Saturday.

A program belongs to one operator and (normally) one vessel, because capacity is a property of the two together: a dinner charter on a hull seats fewer than a sightseeing run on the same hull. So one operator can have several programs, on several boats, at different capacities and prices, and each departure picks the one it's running.

You own programs; the operator owns the schedule. Programs live behind an admin permission, so an operator can't invent a product or set their own seat prices. When they book a landing they simply choose from the programs you've already set up for that vessel — or choose nothing, and it's just a landing.

Seat classes are what the public buys. Adult, Child, Senior, Member — name them whatever fits. Each one points at a real price list item, so seat revenue lands in your reporting alongside everything else. Each can carry its own capacity and a per-order limit. They live on the program, not on the individual session.

Registrations are orders. One person buys three seats; that's one registration with three attendees.

Attendees are the individual people. This is the roster. Each attendee gets their own ticket with a scannable code.

Two separate money flows

Worth being clear about, because they're easy to conflate:

  • Passengers pay you for seats. Each order becomes its own invoice, paid through the portal.
  • The operator pays you the session fee. That's the fee rules on the session type — typically a per-attendee charge, plus any add-ons.

The operator's per-attendee fee counts confirmed attendees only — seats that were actually paid for. Unpaid holds appear on the roster but are never billed to the operator. That's why sessions with a headcount fee should be set to bill after the session runs: at booking time the number doesn't exist yet.

Setting it up — the typical workflow

  1. Allow public sessions on the session type. In Session Types, set Sell seats to the public to yes.

  2. Set the operator's fee to bill after the session runs, if it depends on headcount. This is the step people miss.

  3. Build the program under Administration ▸ Scheduled Resources ▸ Session Programs. Name it something customers will recognise — "Sunset Harbor Tour", not "Booking 4471". Pick the operator and their vessel, set the seat capacity, and add the seat classes.

  4. Attach it to a departure. On the Booking Schedule, book the slot and pick the program from Selling seats?. The operator can do this themselves from their portal when they book their own landing.

  5. Approve it — if your session type asks you to. Set the session type's approval to Automatic and the listing goes on sale by itself; that setting means no staff step, so there isn't one. Set it to Staff must approve and the session waits as a Draft, and nobody can buy a seat until somebody says yes. Hit Approve on the row in Public Sessions, or Approve & put on sale on the session itself. Anything waiting shows as a red count on the Scheduled Resources menu, so a session an operator set up overnight doesn't sit unnoticed. If the button is greyed out, hover it — it tells you why (already departed, cancelled, or no seat classes to sell).

    Changed your mind? Take off sale pulls the listing back. Seats already sold are untouched — those passengers keep their tickets and stay on the roster. Cancelling the session is the action that cancels orders.

Published sessions appear in two places: the portal for existing customers, and a public sessions page anyone can browse without an account.

How the public buys

Someone browsing your public sessions page clicks Get seats. If they don't have an account yet, they go through the normal portal sign-up — enter an email, get a code, fill in their details — and land back on the booking page with a real account.

That's a deliberate choice. It's one more step than an anonymous checkout, and it buys a lot: buyers can find their own tickets later, re-print them, see what they paid, and buy again without re-entering anything. Anonymous buyers who lose the confirmation email become your phone call.

Existing customers go through the portal's Tickets tab instead, which is built for a season with hundreds of departures rather than a handful. Their own tickets are at the top, because the thing people come back for is showing a ticket at the dock, not buying another one. Below that they pick a tour, then a date from a calendar that greys out and disables every day with no departure, then a time. Each step replaces the last rather than stacking underneath it, so the page never turns into a scroll.

They then add one row per person — a name for each attendee, because that name goes on the roster — pick each person's seat class, and pay. Seats are held from the moment the order is created, so a slow card entry doesn't lose the seat to someone else mid-checkout.

The roster

Public Sessions ▸ Roster, or the Roster button on the session.

The roster is built to be printed. Hit print and the screen furniture drops away, leaving a sheet with every attendee's name, seat class, contact details, any notes they left, a check box, and a signature column. It survives a clipboard in the wind, which is the actual design constraint.

Unpaid seats are shown, not hidden — flagged in amber and labelled Payment outstanding. The person at the gangway needs to know that someone is on the list but hasn't paid. A filtered-out row can't tell them anything.

The header carries the counts that matter: how many are on the list, how many have paid, how many seats the session holds.

Checking people in

Two ways, and you can mix them freely on the same session.

On paper — tick the boxes. Fine for a small group, and it works when the dock has no signal.

By scanning — Scheduled Resources ▸ Check In opens a scanner. Point the camera at an attendee's ticket, or upload a photo of it, or type the short reference printed on the pass. If you opened Check In from a particular session, a pass belonging to a different departure is refused rather than accepted — scanning next week's ticket at today's gangway tells you so instead of quietly boarding them. Each scan shows who it is, any notes on their record, and a running count of how many are aboard. The scanner refuses a canceled order and warns on an unpaid one rather than quietly admitting them.

Attendees find their ticket in the portal under Tickets, where each person on the order has a Show Ticket button. It's a plain page with a large QR code that works from a phone screen.

Common mistakes

Billing the operator at booking time on a headcount fee. At booking, zero seats are sold, so the fee resolves to zero and the operator is invoiced nothing. Set the session type to bill after the session runs.

Forgetting to approve the session. A session sitting in Draft is invisible to everyone. If an operator says their tour isn't showing up, check this first — it's the usual answer, and the red count on the Scheduled Resources menu is there to stop it happening.

Leaving seat capacity at zero. Zero means uncapped. That's a legitimate choice for an open event, but it is not what you want on a vessel with a licensed passenger limit. Set the number.

Selling seat classes with no price list item. A class with no item attached is free. Sometimes intentional — a comped guide seat — but check it's what you meant, because a whole class priced at zero is a quiet way to lose a day's revenue.

Expecting a price change to reach sessions already on sale. When you attach a program, its seat prices are copied onto that session and frozen. That's deliberate — a price change in October must not restate what someone paid in June. Edit the program and future departures pick up the new price; departures already published keep theirs.

Trying to change the program after seats have sold. The system refuses, on both the session page and the booking screen. If the tour genuinely changed, cancel the session (which cancels the seat orders, so you can refund them deliberately) and book it again.

Renaming or deleting a seat class mid-sale. Removing a class from a program deactivates it rather than destroying it, so sold seats keep their history. Don't repurpose an existing class into something different — add a new one.

Assuming the roster is final the moment you print it. Seats can sell right up to departure. Print it as late as you reasonably can, and if you're billing the operator on headcount, the system waits an hour past the end time before invoicing so a walk-up sale still lands on the same invoice.

Related articles