What to ask a booking software vendor
Four questions to ask every booking software vendor on the floor. Keep your operation in your own database, let the booking system do what it is genuinely good at, which is taking orders and money, and then ask it for exactly four things: can I get my data out, can something other than a person write to it, will you tell me when something changes, and do I have to keep my resources in your system.
What changed and why
The old seven asked a platform to become an operations system. That was the wrong ask. Their resource module will never fit your operation, their rule engine will never hold your rules, and their conflict detection will never know that Boat 7 is committed Thursday.
The new four ask a platform to get out of the way.
The question is not whether your platform does operations. It is whether your platform will let you do operations.
Three of the old seven are gone because they are your job, not theirs: conflict detection, your own rules, approval gates. Those all live in your database. Asking a vendor about them just confuses the conversation and makes you sound like you want a feature.
1. Can I get all of my data out, on my own schedule, without asking anyone?
Why it matters. Everything you build sits on top of this. If getting your data requires a support ticket, or a report somebody runs for you, you do not own your data. You are renting a view of it.
A good answer sounds like: "Yes. Here's the API, here are the endpoints, here's what each returns." Or: "Full export, on demand, documented."
A bad answer sounds like: "You can export a report." A report is not your data. A report is the part of your data somebody else decided you should see.
2. Can something other than a person write to it?
Why it matters. This is the wall. If a human has to click, the operation moves at human speed, and nothing you build can act on your behalf. Everything downstream of this question is theoretical until it is answered yes.
Ask it in the sharpest form: "Can an agent change a booking, an assignment, or availability without opening your interface? Is there an API or an MCP server for that?"
A good answer sounds like: "Yes, here's what's writable," followed by naming bookings, assignments, and availability specifically.
A bad answer sounds like: "You can bulk edit in the UI." Bulk edit is still a person, just a tired one.
3. Will you tell me when something changes, or do I have to keep asking?
Why it matters. This one gets skipped and it costs the most. Without events you have to poll. I run a scheduled script every hour that hits our booking system looking for changes. It works, and it is a lot of calls to find out that nothing happened, and it means I am always up to an hour stale. In an operation, an hour is a trip.
A good answer sounds like: "Yes. Webhooks on booking created, updated, and cancelled."
A bad answer sounds like: "You can check the API whenever you want." That is polling with extra steps, and you are paying for it in API calls on both sides.
4. Do I have to keep my resources in your system?
Why it matters. Nobody asks this one and it is the difference between a system you can live with and double entry forever. Their resource model will never fit your operation. If you are forced to maintain crew, boats, vehicles and qualifications inside their product and in the place you actually run the operation, you now have two versions of the truth and one of them is always wrong.
The right relationship is that they do not care where your resources live, as long as you can tell them what is available.
A good answer sounds like: "Keep them wherever you want. Just write availability back to us."
A bad answer sounds like: "We have a full resource module." That is them telling you that you have to use theirs.
Optional fifth, for anyone about to sign a multi-year contract
Is any of this in the contract, or is it a favor?
An API that exists but is not contractual can be deprecated, throttled, or priced later. Ask whether the access survives a change of ownership. Most of these companies have been acquired at least once.
How to use it
Walk the exhibit hall. Ask all four at every booth. Write down the answers.
You are not looking for a perfect score. Nobody scores four out of four today. You are looking for two things: which vendors know what you are asking, and which ones get defensive.
A vendor who says "not yet, but that is on the roadmap and here is roughly when" is a better partner than one who tells you their scheduling module already handles it.