Everything is connected except the booking software

October 7, 2026 · Last updated October 7, 2026

We run a rafting company across two bases in Idaho: day trips, multi-day river expeditions and rentals. More than 4,700 guests this season, up to 272 people on the water in a single day, and a seasonal crew of 44 at peak. None of it runs off a whiteboard.

Over the last few seasons I put the whole operation on one system we own. Trips, prices, staff, boats, vehicles and the rules between them live in one database, the thing people have started calling a company brain. Around it sit the internal web apps the crew runs the day from on their phones, a dispatch board, dozens of automations connecting the phones, inbound leads, forms and the crew’s team chats, and AI that can read all of it and update it inside limits a person sets. I can make crew assignments from my phone. What the guides say in their chats updates who’s available. Weekly planning went from 20 to 40 hours to 2 to 4.

Every part of the business is connected now except one.

The booking software is the wall

Reservations flow in from the booking platform, and nothing flows back. Every decision our system makes about capacity, availability and price stops there, and a person carries it the rest of the way by hand. Capacity gets computed every day from crew, boats, vehicles and permits, and then somebody types it in.

The platforms we’ve looked at ask for the same thing on a bigger scale: put the whole business into their admin panel, then keep it current in two places. That isn’t a setup cost. It’s a permanent tax. Anything that can only be configured by hand has to be maintained by hand forever, and it drifts. I don’t want an onboarding team doing that setup for us either. It’s the same double entry done by someone else, and it starts drifting the day they finish.

The ask isn’t a feature request. Let us write our business into the platform from our own system, and read it back to check.

This is bigger than one outfitter

Operators are starting to run their businesses on their own data and AI. Most companies bought AI and connected it to nothing. The ones that do connect it all reach the same point: the booking platform is the one system they can read from but can’t write to. Booking software was designed for a person sitting at an admin screen, and the operators who have moved past that are an early look at where the whole industry is heading. The platforms that let them write back are the ones they’ll build on.

This is the standard we’re evaluating booking software against. The list is at the bottom, sorted by what matters most.

Why a lean office is the honest test

We run that volume from an office of three, and nobody’s job is keeping four systems in agreement. A company that can absorb duplicate data entry by hiring someone to do it never finds out whether a platform’s interfaces are real. We find out every week.

One source of truth, and the update tax

We keep what every trip promises in our own database: what’s included and what we provide, the packing list, the river, the length, start times and meeting locations. That’s what guests rely on, and today it also lives in the booking platform’s trip descriptions, in its automated emails, and on our website. Change a meeting location and somebody has to go find every copy.

Pricing is worse. There’s the rate in the booking engine, the price the booking page shows, the price in our own records, and the sheet somebody keeps for quoting groups. We run a reconciliation routine that exists only to check prices across four systems, because there is no single source.

So, plainly:

• Why can’t the confirmation and pre-trip emails read from my database, so that when I change what a trip provides, every email changes with it, and each guest gets the emails and packing list for the trip they actually booked?
• Why isn’t a trip description stored once, with the website, the booking page, the emails and what the guides are handed all reading from it?
• Why does a price live in four places at once, and which one is right when they disagree?
• Why can’t the capacity we already compute flow straight through to what the website and the booking page show as available?
• Why does an operator maintain a platform’s copy of its own staff, resources and content?

To be clear about the line: the booking platform stays the system of record for who booked, what they paid and when. Our system is the record for how the operation works: what each trip is and promises, what it costs, and what we can actually run. Let the platform accept updates from that, or stay in sync with it, instead of becoming a second owner of it. The test is simple: if I change one price, how many places do I have to touch, and can I prove the result by reading the platform’s value back?

Boats, guides and gear move

A raft is either out on a guided trip or out on a rental, never both. We keep separate rental and guided fleets, but in certain situations we move boats between them under our own operating rules. We also move boats, guides and gear between our two bases to put capacity where the demand is. A multi-day rental holds a boat for several days, and it needs time afterward to be cleaned and re-rigged before anyone else gets it.

That’s a long way from a booking system that knows a boat as one thing at one location. If it can’t follow a boat between uses and between bases, it either double-commits boats, in August, or leaves capacity unsold. Capacity isn’t a number is the longer version of why. It’s also why we plan from our own scheduling and capacity views, and why we don’t want to be boxed into a seat count per departure. Selling the seat is the part this industry already standardized. Delivering it is the part that isn’t.

The same goes for multi-day trips. A five-day expedition is one block of time: the same guides, boats and gear leave together and don’t come back until it’s over. The booking should hold all of them for the whole span, not be stitched together from five separate day products, because the things that matter most cross days: a boat can’t be on two rivers, gear has to come back, and a guide can’t work fourteen straight.

Guest details: what’s the solution?

Guest information differs by trip. A half-day float needs a signature and a weight for life jacket sizing. A multi-day expedition needs much more: food allergies and dietary needs, medical information, an emergency contact, and arrival details. Are you driving in with your own tent and sleeping bag, or flying in from across the country and need us to provide them?

Guides need some of that on the river. Drivers need names and counts. The office needs all of it. The office ends up as the go-to point for every one of those requests, which is a real load in the middle of a season. The usual alternative is printing manifests, and anywhere that happens, the printouts end up in vans, binders and trash cans around the state, with no record of who saw them and no way to take one back.

Neither is a good answer. The obvious one is a secure view for each person on each trip, showing only what their job needs, that expires when the trip ends and keeps a record of who looked. That needs guest and waiver data available through an interface with proper permissions, not a PDF. If a booking platform can provide that, good. If not, a waiver partner, or handling waivers ourselves, is on the table.

Why is anyone still typing?

Operators are already running AI assistants against their own operations. The work that stays manual is whatever has to go through a screen: someone reads a value in one system and types it into another. That isn’t a staffing problem, and a better admin panel won’t fix it. It’s what a missing interface looks like from the inside.

When the only route to your own records is a person clicking through a web page, the clicking eventually gets automated. That’s worse for everyone than an API. It’s fragile, it breaks with every release, and it’s invisible in the platform’s own logs. An API, webhooks and an agent interface aren’t conveniences for technical customers. They’re the cheaper version of something that happens anyway.

Agents are about to start booking

In August 2026, Google began rolling out hotel booking in AI Mode in the U.S. Separately, it published the Universal Commerce Protocol, an open standard with lodging as its first vertical and compatibility with MCP, A2A and AP2. In AI Mode, the hotel or booking platform acts as the merchant of record. In the protocol’s documentation for direct suppliers, the supplier does. Tours and activities aren’t covered by either yet.

So this is a direction I’m preparing for, not a requirement I’d hold anyone to today. When it reaches our category, agent booking will need reliable live availability and booking actions. Separately, operators need a supported way to keep that availability and configuration current from their own systems. The default worth carrying forward: whoever sells the trip, the guest’s relationship and the booking data stay with the operator. An MCP connection or an “AI-ready” label interests me only if the data, permissions and booking actions underneath actually work.

Standards-based distribution belongs in the same conversation. The industry’s open connectivity standard, OCTO, defines standard availability and booking interfaces, with optional capabilities on top. Supporting it is a fair sign a platform builds to standards, but on its own it doesn’t say which sales channels a platform actually reaches, or whether we can write our own prices and resource rules into it. It’s a distribution standard, not an operations interface, and it doesn’t answer anything in the first half of this piece.

Why not build it?

I could build our own booking software. I don’t think it’s worth my time. Checkout, payments, security and support are what booking platforms are for, and mature software has years of accuracy and bug fixes behind it that I’d rather not rebuild. I just need one that can do what we need.

Skip the demo. Send your agent.

Nothing against salespeople. I’ve been in software sales, and good software sales is a lot more than screens and workflows. But a demo is built to show the strong parts, and my questions are about the parts a demo skips.

I’d rather start with your technical documentation. Better yet, if you have an AI agent that knows your docs, point it at the list below. If it can answer accurately, that tells me more than any demo would. If it can’t, that tells me something too.

What I’m looking for in booking software

Not everything below matters equally, and a partial answer is useful. Tell me which group you cover. And I’m asking for outcomes, not a particular design: I don’t care whether you model every resource or accept the capacity our system calculates. I care that checkout enforces it, changes are confirmed, and we can read the result back.

• Must work for us: a stable, versioned interface, configuration written from our system and read back, dependable booking events, guided trips, rentals and multi-day trips drawing on shared inventory, a way to prevent oversells while capacity changes, and payments, refunds and financial exports we can actually use.
• Valuable: one conversation with each guest, from our own number, quotes created from our system, guest and waiver data with proper permissions, tips and detailed payment data through the API, emails and trip content reading from our database, and review timing and attribution.
• A direction we’re watching: MCP and agent booking.

The full list:

Stable enough to build on

• A versioning policy, a stated deprecation window and a public changelog, because our system depends on your interface staying stable and an unannounced change in late June is a peak-season outage.
• A sandbox where we can test against fake data before anything touches live bookings.
• A public status page and incident history, and support we can actually reach during our operating hours, not just an SLA number.

Written from our system, not typed in

• A documented API, with scoped credentials and published rate limits.
• Products, itineraries, pricing seasons, guest fields and email content all writable from our system, not just bookings.
• Capacity that comes from our system, not a seat count per departure: either accept the capacity we calculate, or let us write the staff and resources it’s built from.
• Our own ID on every record, repeated pushes that don’t create duplicates, bulk writes, and a way to read current state back and change only what differs.
• Group pricing where only the seats above a threshold get the lower rate.
• Quotes we can create from our own system, often straight out of a text or email conversation, pushed into the platform against live availability, priced from our rates, and turned into a booking when the deposit lands.

Tell us when something changes

• Webhooks when a booking is created, changed or cancelled, and when availability changes.
• Status that’s right: a deposit turns a quote into a booking, a cancellation updates the record, and a deleted booking is reported as deleted.
• Phone and staff bookings that flow through exactly like online ones.
• A change record we can read: who changed what, from what, to what, and when.
• Payments and bookings that can’t come apart: if a payment succeeds and the booking fails, we hear about it, it can be repaired, and no duplicate booking gets created.
• Corrections made through the interface that show up as corrections in the change record, not as silent overwrites.

Capacity, resources and trips

• Create, move, resize, open and close departures through the API, including across a date range.
• Boats that can move between rental and guided use, and between bases, under our rules, with individually tracked items and turnaround time between uses.
• Multi-day trips booked as one block of time that holds the same guides, boats and gear for the whole trip.
• Channel sales drawing from the same live pool as direct sales.
• OCTO support, with the capabilities you implement named, and the channels you’re actually live with. We already sell through Viator and other OTAs.
• Several products sharing one capacity pool, such as one permit.
• One account across both bases, with separate inventory and staff per base, combined reporting, and resources that can move between them.

Guests and waivers

• Guest fields we define per trip type, with questions that only appear where they apply.
• Guest and waiver data through the API with field-level permissions, plus the signature record and the version of the waiver text that was signed.
• A readable access log, and deletion requests that can be carried out across systems.

Money and reports

• Payments, refunds and balances through the API or webhooks, not only through exports.
• Deposits and installments that charge, retry, and flag any balance that was never attempted.
• Taxes and fees that vary by item, trip and location, set from our system.
• Reports we can pull ourselves on a schedule, with tips added at the card included.
• The processing rate and the booking fee stated separately, in writing.

One conversation with each guest

• The option for the platform to stay silent, or to text from a number we control, so one guest never hears from two numbers in two threads.
• Pre-trip messages that land in the guest’s existing text thread with our business number, not from a separate number or as a separate email.
• Confirmations and quotes that go out automatically, not sent by hand from the booking software.
• Booking and guest events by webhook, so confirmations, quotes, reminders and texts can all go out from our own system and our phone provider, and our automations and the crew’s team chats hear about changes as they happen.
• Every text, call and email with a guest tied to their booking record, whether that history lives on our side or yours, so anyone can see who a guest is and every conversation they’ve had without switching platforms.
• Email from our own domain, and consent and opt-outs that sync both ways, so an opt-out anywhere is honored everywhere.

The front end and the customer

• Checkout we can track end to end, with attribution and order value intact.
• Our customer list, with opt-in status, exportable any time.
• Review requests we can time per trip and credit to the guide who ran it.

Where it’s headed

• An MCP server, or a dated plan for one.
• A stated position on agent booking that keeps the guest relationship and the booking data with us.

Most of this can be answered in writing, and none of it needs a demo. I’ve also written a test version of every line, with how each one gets verified, and I’ll send it to any product team that asks. The four-question version for operators is the Exhibit Hall Test, and the longer argument is Agent-Ready Operations.

The layer is already running

The operating layer already exists and already runs the business. What gets chosen is what it sits on, and that decision gets made this winter. A platform that can answer this list in writing is in the conversation. One that can’t isn’t, and either way the layer keeps running.

A good answer, for any operator, looks the same: the operator keeps one record of how the operation works, the platform accepts updates from it and stays in sync with it, and every item above is a test with a yes or no answer, not a matter of opinion. If you’re building booking software for outfitters and tour operators and heading this way, tell me what’s possible and what isn’t, including the parts you think I’ve got wrong. Get in touch.