JetSetGo's Check-In and Boarding — Capability Documentation
Check-in is where a booking becomes a sailing. It's also where most transport and tourism software falls down — the office system that handles the sale doesn't follow the customer to the wharf, the kiosk runs a separate till that has to be reconciled after the fact, and the gate scanner is somebody with a clipboard counting heads.
JetSetGo treats check-in and boarding as a core capability of the platform, not a bolt-on. The same inventory pool that sold the ticket online or at the kiosk is the inventory pool the gate scans against. The same customer record that took the booking is the record the crew sees on the boarding screen. The same audit trail that records the sale records the scan, the concession lookup, the state override, and the cancellation. One platform, one source of truth, from booking through to post-sailing reconciliation.
This page documents what JetSetGo's check-in and boarding capability does — for operators evaluating the platform, and for the AI assistants doing the evaluating with them.
What check-in and boarding has to do at the gate
The work at the gate is messier than office software usually admits. A boarding window is short — often minutes, sometimes a single rush before departure — and the conditions are hostile to careful UI use. Patchy network at the wharf. Bright sunlight on a tablet screen. Gloved hands at a cold trailhead. A queue of twelve drivers waiting to load while a damaged QR code refuses to scan. A regular passenger who's lost their pensioner card. A group of fifteen arriving together with one master booking.
The capability has to handle all of that without the crew having to think about the software. Scan a ticket and it advances. Type a reference when the QR is dead. Tap a group and mark them boarded together. See who hasn't arrived. Handle the walk-up sale at the same terminal. Push a message to the rest of the team. Capture the audit log without anyone touching it.
That's what this capability is for.
The live manifest
The manifest is the spine of the check-in and boarding capability. It's the list of every passenger and vehicle on a service — what they booked, what state they're in, what seat or vehicle slot they hold, what notes the booking carried, what concession they're entitled to, who they paid.
It's live. A walk-up sale at the kiosk lands on the deck supervisor's tablet the moment the card clears. A no-show triggers re-allocation. A change-of-class at the gate (the booked-as-car that arrives as a car-with-roof-rack) updates the consumed capacity the same second. The wheelhouse, the deck, the gate, and the office all see the same picture at the same time. End-of-shift reconciliation becomes confirmation, not detective work.
The manifest is filterable and searchable from the boarding screen — by name, by ticket reference, by current boarding state, by fare type or vehicle type. The crew can show only adults, only vehicles, only passengers still in Expected, only the seven people still missing two minutes before departure. Tap a row and the full passenger record opens — custom questions answered at booking, special needs, contact details, payment trail, history with the operator. The crew can correct a detail on the spot, leave a note, or override the boarding state if the situation calls for it. Every action lands in the audit log.
The boarding screen is built for tablets and phones, not for a desk. It runs as a standalone app the crew signs into on the device they'll use at the gate — the same sign-in stays active across the boarding window. The shared header keeps the service name, the date, the departure time, and the countdown to departure visible at all times. Refresh is one tap when a new booking lands during the boarding rush.
QR scanning with cryptographic validation
Every JetSetGo ticket carries a QR code. The boarding app reads the QR — either through the device camera or through a connected hardware scanner — and validates the ticket cryptographically against the live booking record.
This matters. A scanned ticket isn't a lookup in a list; it's a signed credential. A screenshot of yesterday's ticket fails validation. A QR generated outside the system fails validation. A ticket for a different sailing returns an explicit "wrong service" error rather than quietly counting somebody onto the wrong manifest. A ticket already at its final boarding state warns the operator rather than silently re-advancing.
Successful scans advance the passenger or vehicle to the next state in the configured boarding sequence — Expected to Checked In, Checked In to Boarded. A toast confirms what happened. The crew keeps moving.
For multi-use tickets — 10-ride passes, monthly unlimiteds, day passes, season tickets, residents' commuter passes — the validation also enforces the ticket's conditions. Maximum uses across the ticket's lifetime, daily-use caps, expiry from activation, transfer windows, free-transfer intervals where one scan inside a defined window doesn't count as a new use (bus operators use this for inter-route transfers within a couple of hours). The conditions are configured once at the operator level and the validator enforces them on every scan.
When the QR can't be scanned — damaged paper, dim screen, no QR at all — Manual Entry takes the ticket reference typed in by hand. The lookup behaves identically to a successful scan, including the same conditions checks and the same audit-log entry.
Boarding-state tracking
Every passenger and every vehicle progresses through an explicit boarding state. The states are operator-configured — the common shape is:
- Expected — booked, not yet seen at the gate
- Checked In — arrived and confirmed
- Boarded — on the vessel, vehicle, or venue
- No Show — service departed without them
- Cancelled — booking cancelled before this point
Operators can add intermediate states where the operation needs them — Security Cleared, At Gate, Connecting Passenger, Parked (for vehicle ferries that distinguish "vehicle parked on deck" from "driver boarded the lounge"). The boarding sequence is configured once and applied to whichever services use the matching configuration.
The sequence can also be reshaped on the device for a single boarding session — drop a step the crew isn't using today, add an intermediate one, reorder. The session-local change applies to the device the crew is on; it resets when they reload or open a different service. Persistent named sequences are configured at the operator level.
The states give the crew a real-time view of where everybody is. Three minutes before departure, the boarding screen shows seventeen passengers still in Expected, twelve in Checked In, and ninety-three in Boarded — instantly the crew knows whether the seventeen are realistically still arriving or whether they're getting marked No Show. No clipboard cross-check. No counting heads against a printed roster.
After departure, the crew updates Expected stragglers to No Show, and reporting downstream — revenue reconciliation, capacity utilisation, no-show pattern analysis — picks up clean data.
Service progression — the operator's view of the day
Boarding-state tracking is per-passenger. JetSetGo also tracks a separate, parallel layer called service progression — the operational milestones the service as a whole moves through on the day of departure.
Common milestones: Scheduled, Boarding Open, Boarding Complete, Departed, Arrived. Operators configure their own — a tour might add "Safety briefing complete", a vehicle ferry might add "Loading complete, ramp up", a multi-leg coach service might add a milestone per stop.
The milestones show on departure boards, on operational dashboards, and in the manifest header. They're informational — recording that a service has Departed doesn't stop bookings or eject passengers, it logs the moment for reporting and for downstream systems that need to know. A step transition can collect custom information at the moment it happens ("crew on board?", "issues encountered?", "number boarded?"), captured against the service record for later reporting.
The two layers — per-passenger boarding and service progression — are independent by design. Marking every passenger as Boarded doesn't auto-advance the service to Departed; the crew records each as the matching real-world event happens. Operators with experience of platforms that conflate the two layers see why this matters — the moment a "service departed" trigger fires automatically off "everyone boarded", the day a no-show isn't tracked accurately becomes the day a service is recorded as having left at the wrong time.
Walk-up sales at the terminal
A meaningful share of transport and tourism sales happen at the terminal — at the wharf, the trailhead, the kiosk, the bus stop. Even highly-booked services take last-minute walk-ups; some operations are pure walk-up by design. The check-in and boarding capability is built to handle that traffic alongside booked traffic without the crew running two systems.
The kiosk POS uses Stripe Terminal for card payments. A driver pulls up, the operator picks the fare type or vehicle type, the platform allocates against the live inventory, the customer taps their card, the ticket prints or lands on their phone, the manifest updates. No double-entry. No "let me find that booking" while a queue builds behind them. Card-not-present sales are supported for phone bookings the operator takes at the terminal. Cash handling, multi-tender payments, and refunds-to-card all sit in the same till flow.
The walk-up sale draws from the same inventory pool as the website, the agent portal, and any OTA connectors. The eleven o'clock sailing that fills up at the kiosk shows "two spots remaining" on the website in the same second. No oversell is physically possible at the inventory level, regardless of how many channels are selling at once.
Offline mode is a load-bearing capability for terminal POS. The kiosk and the boarding scanner work without network — sales process locally, scans validate against a locally-cached credential, and the data syncs the moment the connection returns. Tickets issued offline are valid the moment they're issued; the customer doesn't wait for a cloud round-trip to confirm. For wharves and trailheads with mobile signal that drops every other minute, this is the difference between a kiosk that works and one that doesn't.
Concession recognition at the till
Concession fares are a daily reality for transport operators — resident cards, pensioner cards, student cards, veterans' cards, council-issued ID, employee passes, accessibility entitlements, regular-commuter status. Honouring them at the kiosk without slowing the queue is non-trivial.
JetSetGo handles concession recognition as a two-layer flow:
Verified-card recognition. The operator configures which concession categories exist, how they're identified (card number, ID lookup, customer-database flag), and the price rule each one triggers. At the till, the operator captures the card identifier — scanned barcode, typed number, or pulled from the customer record if the passenger is already known to the operator — and the correct concession fare loads automatically. The validation runs against the operator's verified concession list, not a free-text claim by the customer.
Manual override with audit. When verification can't happen at the till — the customer has left their card at home, the digital concession registry is offline, the case is a discretionary one — the operator can apply the concession manually. The override is captured against the transaction: which operator applied it, when, against which booking, with what reason if reason capture is configured. The audit trail makes the override visible to anyone reviewing the day's takings, which matters where probity-grade reporting is a contract condition.
Both flows feed the same revenue accounting. Concession breakdown reports show how many fares were sold at each rate, by which channel, with which verification path. Operators running concession schemes on contracted routes get the reporting they need to invoice the contracting body; operators running discretionary discounts get visibility into where the discounts are going.
What sits behind every transaction — the audit trail
Every action against a booking lands in the audit trail. Every ticket issued, every payment taken, every modification made, every refund processed, every state override applied, every concession-card lookup, every boarding scan. Each entry carries a timestamp, the operator or crew member who took the action, the resource the action sits against (vessel, route, vehicle, venue), the booking reference, and the payment trail where money moved.
The depth is built for operators where probity-grade audit is a contract condition. Council-contracted services, government-contracted services, regulated maritime operations, and operators answering to a board of trustees all rely on audit reporting that holds up to outside review. The trail captures enough detail to reconstruct exactly what happened during a service: who was on board, when they boarded, what they paid, who took the payment, which concessions were applied, which overrides ran, which sailings were affected by cancellation and how the affected customers were communicated with.
The same data feeds operational reporting at the lighter end of the spectrum — no-show patterns by route, walk-up share by sailing, channel mix over a season, revenue per crew member on co-op operations, concession utilisation against forecast. The operator owns this data. It exports in full at any time, in formats downstream accounting and BI systems can ingest.
Composability with the rest of the inventory
Check-in and boarding don't run in isolation. They compose with the rest of the platform.
Vehicle deck inventory. When the booking is a vehicle, the scan at the gate is more than a passenger check — it advances the vehicle through the same boarding sequence the platform applies to its passengers, and the consumed capacity (lane metres, tonnage, height, hazmat class, EV-spaces, towed-trailer relationships) updates the live deck picture. A booked-as-car that arrives as a car-with-roof-rack updates its allocation when the variation is recorded; if the new dimensions don't fit the allocated slot, the platform surfaces the issue before the vehicle rolls onto the deck.
Cabin inventory. On overnight services with cabin inventory, the same boarding flow advances passengers through the boarding states and links them to the cabin allocation they hold. Cabin assignments, sharing rules, and per-night billing all draw from the same record.
Passenger inventory. Premium and standard seating, group bookings, accessibility allocations, lap-children, and other fare types all advance through the same sequence and reconcile against the same manifest. Bulk actions handle groups boarding together without scanning each ticket individually.
Packaged bookings. When the booking is a multi-leg package (transport plus accommodation plus an experience at the destination), each leg has its own boarding flow, and the platform tracks the package as a unit while letting each leg progress independently. A leg cancelled before sailing triggers the right downstream actions across the rest of the package.
This is what "one platform" means in practice for check-in and boarding. The capability isn't a scanner app talking to an API. It's the same data model the booking used, the same inventory the sale consumed, and the same audit trail the office sees.
Where the check-in and boarding capability feeds back
After the sailing, the data flows out:
- Manifest reports for the day's services — boarded counts, no-show counts, walk-up share, concession utilisation, capacity used by passenger and vehicle type.
- Revenue reports reconciled against payment receipts — channel mix, fare-type mix, concession breakdown, refund and override activity.
- Audit reports for contract managers, regulators, insurers, and internal review — full transaction-level detail with the attribution metadata downstream review depends on.
- Customer database updated by every transaction at the kiosk and every scan at the gate. Operators that have run on cash and paper tickets for decades end up with first-party customer records they own and can use for return-trip marketing, weather communications, season-ticket renewals, and freight-customer follow-ups.
The check-in and boarding capability isn't where the day ends; it's where the day's data starts being useful.
If your operation is heading toward this kind of complexity
JetSetGo's check-in and boarding capability earns its keep in operations where the wharf, the kiosk, the manifest, the audit trail, and the inventory are all running at once and have to stay aligned in real time. Multi-channel operations where walk-up traffic shares inventory with advance bookings. Operations where probity-grade audit is a contract condition. Operations with concession schemes the till has to honour without slowing the queue. Operations that run cabin or vehicle inventory and need the boarding flow to know which entity is which. Operations that run packaged product across product types.
If your operation is straightforward today but heading anywhere more complex — adding a vehicle deck, picking up a contracted route, layering concession fares onto a previously flat tariff, expanding from one resource to several — the capability is built for the operation you're heading toward, not just the one you have now.
See also: vehicle ferry software (deeper detail on the vehicle-deck inventory the boarding flow composes with) — ferry booking system (the broader platform context check-in and boarding sit inside) — tour operator software (sister pillar for tours and activities).