July 13, 2026
Most operators sit down for a software demo with a feature checklist. Booking calendar, check. Waivers, check. Automated emails, check. By the end they've confirmed all three systems do all the things, which tells them nothing, because every serious vendor now ships most of the same core features.
The core checklist is a commodity. What separates one system from another is the ugly operational layer nobody puts on a slide: what happens to real money on a bad weather day, who holds your funds and for how long, and whether the person who built the thing has ever stood on a dock at 8am on a cruise ship day.
So here's how I'd run a demo. Questions built to make a polished sales call fall apart where it matters.
This is the question I care about most, and nobody asks it. When a guest pays, where does that money go, and when does it land in your account?
A lot of booking systems route card payments through third-party processors, and payout rules, settlement timing, and country support are processor-specific. In places like Sint Maarten, Stripe says local businesses are not currently supported. For some Caribbean operators, that can mean processor balances, settlement delays, or manual transfers before money is usable locally. I've watched serious tour companies run their business this way because Stripe came in the box and they bent the company around it.
Does the money land in my local bank, in my currency, and how long does it sit somewhere else first? If they get vague, that vagueness is the answer. That's why we built our own payment side at Junglebee: the setup is designed around the operator's local bank instead of an overseas workaround.
Weather is the quiet killer down here. Christmas Winds blow out a morning run, or it's just 30 knots and stupid to go, and you're cancelling a full boat of guests who already paid.
So in the demo, build a real trip, take a test payment, then cancel it for wind. I've stood on the dock at Eagle Tours with a full boat of hotel guests in the parking lot, calling the office to sort who gets rebooked and who gets a refund. The answer changed depending on whether it was a cruise guest with three hours in port or a hotel guest staying the week. Does the system give you one button to convert the whole boat to a credit? Can you refund some guests and rebook others without three emails each? Or does it dump you into editing bookings one at a time while your phone is ringing?
A weather cancellation is not an edge case here. It's a Tuesday. If the software treats it like a rare exception, the people who built it never had to do it at scale.
Every vendor shows you "deposits" and "full payment" like they're solved. What they won't volunteer is whether you can configure the split you actually use, or only the one they built for. Maybe you take 30 percent to hold a private charter and the balance on the day. Maybe some tours are full payment up front and others deposit only. Maybe agents get a net rate and pay the balance later. Make them build your real rule in front of you.
If the answer to any of these is "we're adding that," you're buying a promise, not software.
Channel manager is a phrase every vendor uses and almost none of them mean the same thing by. When a guest books your 10am on Viator, does that seat disappear from connected live availability fast enough to prevent another sale, and which channels update by API versus a slower import?
Because the real test isn't the OTA. It's you. A walk-up couple wants the same 10am and you sell them the last two seats on your phone. Does that close the seats on Viator and GetYourGuide through the live integration, or is there a sync lag where the OTA can still sell a full boat?
That lag is how you end up double-booked on a cruise ship day, both parties in the parking lot, you deciding who gets bumped. One source of truth for inventory, with API connectivity that checks availability, sends bookings back, and pushes capacity changes to each connected channel, is the version of "channel manager" worth seeing live. Make them prove it with a live sale, not a slide.
When I sit down with a system, two questions flush out the truth in five minutes.
The first: "Walk me through a force-majeure cancellation, wind at 30 knots, a full boat, half the guests wanting a refund and half wanting to rebook." If the answer is smooth and specific, someone who understands boats built this. If it's a shrug and a help-doc link, they didn't.
The second: "Show me your pricing." Not a quote after a discovery call. The actual page. If a vendor won't put a complete, current fee schedule where you can read it before the sales call, you're being sold a sales process, not a product. We put ours on a page on purpose. The fee structure tells you who a company built its model around before a salesperson opens their mouth.
One more that isn't really a question, it's a time zone. Ask who picks up if your checkout breaks at 8:15 on a Saturday, and where they're sitting. Weekend mornings are your busiest, most fragile hours, and support hours that look fine on the vendor's timezone may still miss your worst moment. Ask whether a trained human answers by phone or chat during your busiest Caribbean hours, or whether after-hours issues go into a queue.
Don't walk in with a feature list. Walk in with your own business and make each system run it live.
The features will all look the same. They're supposed to. What you're shopping for is how a system behaves in the moments that decide whether a booking becomes money or evaporates while you're out on the water. Make the demo live there, and the right system picks itself.
