Everything is connected except the booking software

October 7, 2026 · Last updated October 12, 2026

We’re evaluating booking software for Adventure Idaho against the operation we’ve built. I’m talking with outfitters and other service businesses about similar integration and manual-entry problems. I want to test a workable connection in our operation and share what I learn. See our requirements below. For broader checks across a service business, see Agent-Ready Operations.

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.

I wrote up what it took to get off the whiteboard, including the operating rules and connections underneath it.

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.

It isn’t data entry. It’s keeping a second model of the business in sync. Our office is three people. One is usually out driving shuttles or on a supply run. One handles sales and customer service, which AI has made faster, and we want a person in that seat. Mine should go to decisions. But a crew of 44 means 44 sets of certifications for specific river sections, changing through training season as guides qualify for new water. Boats and vans move between bases. Trips change shape. Every one of those changes already lands in our system. Keeping a booking platform’s copy of the same facts current means doing all of it twice, and the copy is always a little behind.

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

Here’s the shift. With AI, we keep the whole business current in one place, fast. A sentence updates who’s working, what a trip includes, what it costs and what we can actually run. What we don’t need anymore is a second set of manual workflows inside the booking software to type the same changes in again: staff, resources, seats, trips, descriptions and prices.

That isn’t bad news for booking platforms. It’s the opposite. The platform keeps doing what it does best, checkout, payments, distribution and support, and becomes the easiest one to run, because nobody has to babysit its admin screens. The platforms that accept updates from an operator’s own system will be the ones operators can actually keep current.

Another GM told me he’s in the middle of switching platforms and dreading weeks of the same manual entry all over again. Switching vendors doesn’t fix that. Letting the operator’s system update the platform does.

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.

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.

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.

Why seats don’t fit

Booking software usually counts seats. Ours aren’t fixed. A raft holds a different number on a multi-day than on a day trip, and a different number for a family than for a youth group. Every boat carries a different load. Every vehicle seats a different number, and which trailer it can pull changes by river section. A guide can come off a multi-day and run a half day the same afternoon, and one van can cover five different runs in a day. A seat count can’t hold any of that, so we built our own rules into our own system, and it works. We’re looking for a platform that can take what that system works out, not one that pins us back to seats. Selling the seat is the part this industry already standardized. Delivering it is the part that isn’t.

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.

What we do want to buy

The booking platform still has a job beyond checkout. A guest should be able to open one link, add names, sign the waiver and answer the questions tied to it, see the balance, and pay, or share the link with someone else who will. The same link should carry the trip details we choose, like the packing list, FAQs and how to reach us, so everyone who shows up has signed and comes prepared. Our office should see where every guest stands and be able to manage it. If they want to add two people, the platform should check the capacity our system calculates, update the same reservation and reprice it, or bring the request to our office when a rule needs a person.

In the office, we still need a fast way to see who’s going, add a note, change a price, apply a discount, add gear or a rental, edit a line item, check guests in and issue a refund. Those are workflows worth buying. What we don’t want to maintain twice are the trip rules, prices, resources and guest-facing content that already live in our system. And we don’t need the platform’s guide or staff scheduling. Our crew already runs on our own tools, which work far better than the whiteboard ever did and update much faster.

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, a guest link that handles group payments, waivers with the required questions tied to them, headcount changes and the trip details we set, so everyone signs and arrives prepared, 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, selling tools like waitlists, add-ons and self-rescheduling, 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.
• Deposit rules we can set per trip: amount, due date and refundability can differ for day trips and multi-day trips.
• Cards kept on file and charged automatically when deposits and balances come due, with retries, and a flag on 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.

Guests and the reservation desk

• One reservation link several guests can complete and pay toward, with separate cards and partial payments, and one accurate balance.
• Trip details on that link we can customize per trip: packing list, FAQs, meeting details and how to reach us.
• Guests can add people when our capacity allows: the same reservation, repriced, with the balance and roster updated, or sent to the office when a rule needs a person.
• A fast staff screen for discounts, custom prices, add-ons, rentals, line items, notes and refunds, all recorded in the change record.
• Waivers and their required questions completed through that link, with per-person status the office can see, targeted reminders to anyone who hasn’t signed, and quick check-in.

Selling more, with less office work

• Guests can reschedule themselves within our rules, which matters when weather or water changes plans.
• Waitlists that fill automatically from cancellations on full departures.
• Follow-ups to guests who started a booking and didn’t finish.
• Add-ons at checkout, like wetsuits, photos, shuttle seats and lunch upgrades.
• Gift cards and promo codes, sold online and in person, with unredeemed balances visible.
• Point of sale for walk-ups, same-day bookings and retail at our bases.

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.
• Follow-ups for open quotes, unpaid balances, incomplete forms and unsigned waivers. The platform can send them, or we can trigger them from our own system just as easily, as long as it all stays one conversation with the guest.
• 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.

For Adventure Idaho, a good answer means clear record ownership, updates between systems we can verify, and rules the team can maintain. That’s the work I’m taking into other businesses: learn how each operation runs, turn its rules into a connected data model, and build tools the team can use. I’m interested in working with platforms bringing those capabilities to more complex operators. If you’re building booking software for outfitters and tour operators, tell me what’s possible and what isn’t, including what I’ve got wrong. Get in touch.