Ferry Booking System — Built for the Way Ferries Actually Run
Above the fold: Run your entire ferry operation on one platform. Vehicles and passengers, peak season and walk-up, channel control and POS — built by operators who got tired of running their systems instead of running their business.
The real problem with most ferry booking systems
Peak season hits and the operation has more moving parts than the system can hold. Cars and trucks staged across two terminals. The 9:30 sailing oversold because the kiosk and the website weren't in sync. A row of vehicles backed up because the deck supervisor is on a clipboard counting lane metres by hand. The phone keeps ringing — weather has cancelled the 14:00, and refunds need to go out before the next departure.
The booking system was supposed to make this easier. Instead it became another thing to manage. Capacity locked up in OTA channels you can't see in real time. A reservations team manually keying in walk-up sales after the fact. A vehicle category that doesn't exist in the system because the operator who set it up three years ago has moved on.
Ferries are not activity bookings. A ferry has a vehicle deck with lane-metre constraints and height limits. A passenger lounge with multiple seating tiers. Trucks measured by tonnage. Trailers booked separately from the vehicles towing them. Sailings cancelled on a tide that doesn't care about your customer service window.
A ferry booking system that doesn't model that is just a payment form with a calendar attached. It works until peak season — and then it doesn't. (The hidden economics of ferry operations →)
Two modes on one platform — pick what you need
JetSetGo handles two modes of ferry operation on the same platform.
The first is sophisticated advance booking with capacity rules, channel control, and dynamic pricing — for operators who want to take advance reservations and shape how their inventory gets sold.
The second is high-efficiency ticketed POS — fast kiosk and onboard sales, QR scanning at the gangway, live manifest visible to crew and office, customer database that builds itself — for operators who run walk-up, first-come-first-served, or co-op rotation models and want to keep that model.
Most operators end up running both. The kiosk takes walk-ups; the website takes advance bookings; both draw from one shared inventory pool. You choose which capabilities to enable, and you can turn advance booking on or off without changing how the rest of the operation runs.
Operational tooling — for any operating model
These capabilities work regardless of whether you take advance bookings. They are the day-to-day tools that make the ferry run smoothly.
Mobile POS for the kiosk, the gate, and the wheelhouse. Card payments via Stripe Terminal. Card-not-present sales for phone bookings. Ticket issuance in seconds. The customer pays, the manifest updates, the ticket prints or lands on their phone. No double-entry. No "let me find that booking" while a queue builds behind them.
QR ticket scanning at boarding, with cryptographic validation so a screenshot of yesterday's ticket can't be reused. Boarding-state tracking: Expected → Checked-in → Boarded. The crew knows who's on the vessel, who's still in the terminal, and who hasn't shown up — without anyone counting heads twice.
Live manifest that the wheelhouse, the deck supervisor, and the office all see at the same time. A walk-up sale at the kiosk appears on the crew's tablet the moment the card clears. A no-show triggers a re-allocation. A vehicle change-of-class at the gate updates the lane-metre count on the deck immediately. The manifest doesn't have to be reconciled at end of shift — it's already accurate.
Customer database that builds itself with every transaction. Every walk-up sale captures a contact. The operator owns the list — it's not held inside a third-party platform that controls who you can market to. For ferries that have never had a first-party customer list, this alone changes what's possible: weather comms, return-trip marketing, season-ticket renewals, freight-customer follow-ups.
Weather cancellation comms automatically. When a sailing is cancelled, SMS and email go out to every customer holding a ticket for it, with a refund-or-rebook link in the same message. The office stops being the call centre.
Audit-grade reporting. Every ticket, every payment, every modification, every refund, every boarding scan logged with timestamp, vessel, skipper, and payment trail. Useful when the maritime authority asks for a manifest. Useful when a council ferry contract requires probity-audit-grade records. Useful when an insurance claim depends on showing exactly who was on board.
Sophisticated inventory — when you want to take advance bookings
For ferries running advance booking, the inventory model goes deeper than a flat seat count.
Capacity is hierarchical. An entire vessel breaks down into a passenger lounge — with premium seats, standard seats, and standing — and a vehicle deck — with under-cover car spaces, an open area for trucks, and overflow lanes. Each level has its own constraints. The under-cover deck has a height limit (no 4-metre vans). The open deck has lane-metre capacity (a 12-metre truck takes 12 lane metres, not "one truck space"). The passenger lounge has premium-vs-standard pricing. All of it modelled, all of it bookable, all of it allocatable to the right place when a booking comes in.
Vehicle classification and inventory control are multi-dimensional and operator-defined — there is no fixed list of vehicle types and no ceiling on the number of attributes you can track. Length, tonnage, height, hazardous-goods class, EV-charging requirement, axle count, towed-trailer relationships: whatever your operation cares about, the platform tracks. All of it sits inside a hierarchical model of the physical vessel — passenger lounges, under-cover deck, open deck, overflow lanes — where each area carries its own restrictions. The under-cover deck enforces a height limit. The open deck takes oversize vehicles and dangerous goods. EV-equipped berths are tracked separately from general car spaces. Allocations respect the rules automatically when a booking comes in, so the system never places a vehicle somewhere it physically cannot go.
Channel control at the architecture level. Operators set rules like: "OTAs get a maximum of 40% of passenger capacity on this sailing." "Reserve 10% of vehicle deck for corporate accounts; release 24 hours before departure if unsold." "Premium-tier inventory stays direct-only; OTAs sell the standard tier." All of it synchronised in real time across every sales channel. No double-booking is physically possible.
Real-time availability across website, mobile POS, agent portal, and OTA connectors. If a walk-up customer buys the last spot at the kiosk, the website's "two seats left" indicator updates in the same second.
Pricing and business rules
Pricing is highly configurable and applies per service or per route. A car can be a flat rate, or it can be priced by the lane metres it actually consumes, or by a combination — whatever the operation needs. The same flexibility extends to passengers, freight, and any other bookable entity: fixed rates, consumption-based rates, attribute-based rates, or hybrids of all three.
Flat pricing — a fixed rate per fare type and per vehicle type. "Adult $35, child $18, car $85, motorbike $35."
Consumption-based pricing — priced by what is actually consumed. A car billed by lane metres rather than a flat fare. A truck billed by lane metres and tonnage together. A cabin billed by berth count. Operators pick which dimensions matter and the platform meters them.
Versioned price lists that switch automatically by date — summer rates, winter rates, school-holiday rates, weekday vs weekend. Set them once; the system applies the right one on the right day.
Business rules engine with a visual rule builder for the operator-defined rules that don't fit a flat tariff:
- "10% off when booking more than 30 days ahead" (early bird)
- "Weekend surcharge when capacity is above 80%"
- "Loyalty discount for repeat customers — third sailing of the year free"
- "Resident concession on production of an Island Resident card at the kiosk"
- "Promo code SUMMER25 for 15% off January sailings"
The rules apply automatically at the point of sale or the point of booking. Operators see the price recommendation before the customer does.
One inventory, every channel
Website. Mobile POS. Agent portal. API integrations with downstream systems. OTA connectors for Viator, GetYourGuide, Expedia. Phone bookings logged by the reservations team.
All of them drawing from one inventory pool. All of them respecting the channel rules the operator sets. All of them updated in the same second when a sale closes anywhere.
This is the part that "just a booking widget" can't do. Capacity is one thing, but capacity managed across six different channels with different rules and different price tiers — that's what makes peak season survivable.
What this looks like for real ferry operators
A small-island co-op of independent skippers selling through one shared kiosk. Each transaction tagged to the skipper who took the run. Revenue share calculated automatically at end of day. No advance booking needed; the same-day kiosk + QR scanning + live manifest is the whole product. The customer database builds itself for the first time in decades of operation.
A council-contracted vehicle ferry running a 4-lane dual-loading vessel with concession recognition for resident card holders. Audit-grade reporting that satisfies the council's probity requirements. Vehicle deck inventory modelled by lane metres, tonnage, and height — so the under-cover deck doesn't accidentally accept a 4-metre van. SMS comms go out automatically when tide changes shift the timetable.
A multi-vessel passenger ferry with peak-season weekend overflow. Channel rules cap OTA capacity at 40% so direct bookings always have premium-tier seats available. Dynamic pricing tier-up happens automatically when capacity crosses 80%. Walk-ups still served at the kiosk for last-minute customers; the kiosk and the website draw from one inventory pool, so nobody oversells. (Peak season capacity management: mathematical models that actually work →)
Frequently asked
Do I have to take advance bookings to use this? No. The operational tooling — POS, QR scanning, manifest, customer database, weather comms, audit reporting — works regardless of your booking model. If you run walk-up or first-come-first-served, those are the capabilities you turn on. Advance booking is a separate capability you can enable later if you want to, or never enable at all.
Can I keep selling on Viator and GetYourGuide? Yes. The platform connects to the major OTAs. The difference is that you set the rules — cap how much capacity OTAs can sell, reserve seats for direct bookings, decide which price tiers each channel sees. Most operators keep OTAs as a marketing channel and use the channel rules to shift more revenue toward direct bookings over time.
What happens if the system goes offline at the terminal? The kiosk and the boarding scanner work offline. Sales process locally; data syncs when the connection returns. Tickets issued offline are valid the moment they're issued — no waiting for the cloud to confirm. This matters in places where the wharf has a mobile signal that drops every other minute.
How long does implementation take? Onboarding included. Most operators are live within weeks, not months — the configuration model is operator-driven, not consultant-driven. You don't need a 6-month project to switch.
What if I outgrow you? Your data is yours — exportable at any time, in full, no lockout.
What about freight and cargo? Tonnage tracking is built in. Cargo manifests, dangerous-goods classifications, lane-metre allocation for heavy-vehicle loads all work the same way passenger inventory works. Common across cargo-passenger hybrid operations.
Run your ferry the way it actually runs
The vessel, the deck, the manifest, the walk-up, the advance booking, the OTA channel, the kiosk, the weather call — all on one platform. With one inventory pool. With pricing rules that respect what your operation actually does.
Cancel anytime. You own your data.
See also: vehicle ferry software (the deeper sub-pillar on lane-metres, tonnage, and vehicle-class modelling) — multi-modal booking platform (when you run ferry + tour + accommodation as one operation) — tour operator software (the sister pillar for the touring side of your business).
