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. The connection matters beyond our operation Another GM told me he was switching platforms and dreading weeks of manual setup. In our three-person office, there is no spare role for keeping staff, resources, trips, descriptions and prices current in two places. A new vendor does not solve that by itself. Most companies bought AI and connected it to nothing. Booking platforms can keep doing checkout, payments, distribution and support. A supported connection lets an operator maintain changing operational details in one place and verify what reached the platform. That is the standard behind the requirements below. 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. Trip descriptions and pre-trip messages should use the same source. Prices, staff, resources and the capacity we compute should reach the booking page without retyping. 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 promises, what it costs and what we can run. We need supported updates between them and a way to read the platform’s values back to verify each change. 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. Without a supported API and change events, staff retype values or automate clicks through admin screens. That is fragile and hard to audit. A documented interface gives systems a safer way to exchange updates and confirm what changed. 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. Start with the documentation I have worked in software sales. A demo can show the staff and guest experience, but these questions turn on data access and update behavior. Start with the documentation. If you have an agent that knows it, point the agent at the list below; an accurate answer is more useful here than a tour of screens. 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. I’ve written verification checks for each requirement and can share them with a product team. 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.