Before anybody gets splashed going through a wave, a surprising amount of work has to happen. I’m Justin Smith, General Manager at Adventure Idaho. I’m preparing to speak at the Idaho Outfitters and Guides Association conference about that work: what I built to help run it, what took longer than I expected, and what another operator can use even if their business looks very different from ours. These are the ideas I’m bringing to the talk. The dispatch case study shows the tools. This is about the decisions behind them. A reservation is the beginning of the plan A group wants to move its trip to tomorrow. Another group grows enough that the vans no longer work. Now we need a bus, which means checking for an available CDL driver. A multi-day crew gets back that afternoon, but those guides need time to unload, clean and rig before their next assignment. Rentals draw on some of the same equipment. Each decision changes another decision. A name in a guide field doesn’t tell me whether that guide is available, qualified, rested, already promised somewhere else or able to reach the next assignment on time. Booking software is crucial. Taking reservations and payments well is a substantial job. Broadly useful software also has to serve many kinds of businesses. Trying to fit a particular operation into its scheduling fields can feel like pushing a round peg into a square hole. Our whiteboard worked because it was fast. I could erase something, move a name and see the whole day. The problem was how much knowledge had to stay beside it. The booking software held the reservations. The whiteboard held the assignments. I held the connections between them. Then I had to translate the board into dispatch messages: which group, what time, which vehicle, which trailer, where to go next. Updating the plan meant updating the explanation too. A guide looking at the board and a guide reading yesterday’s message could be looking at different plans. The part AI could not guess During the summer of 2025, I tried giving ChatGPT a photograph of the whiteboard and asking it to help untangle the schedule. One suggestion was to take guides partway through a Main Salmon trip, have them cover a day trip, then finish their multi-day trip. It could read names. It didn’t understand what those assignments meant in the real world. That experience is still useful to me. A convincing answer can be impossible. The missing work was to make the operation understandable: the people, equipment, trips, locations, timing and rules connecting them. I’ve written more about that first attempt and getting off the whiteboard. I started building the connected records and tools around those relationships. That became what I call the company brain. Someone still has to decide what a record means, which source to trust, how changes arrive and what happens when the information is wrong. AI can write the code. You still have to engineer the system. One board is only the visible part The crew board is the easiest thing to show. Behind it are guide availability and qualifications, assignments, vehicles, trailers, equipment, food planning, issue tracking and reporting. The crew can see assignments and trip details on their phones. The office can check conflicts against connected records rather than reconstruct the whole operation from memory. The same information supports food preparation, maintenance tracking and payroll preparation. Permit and usage reports are another reason to keep the underlying trip records useful. redactedThe old whiteboard and the connected crew board show different planning periods. The improvement came from the records, rules and workflows behind the screen. My estimate is that weekly planning dropped from roughly 20–40 hours to 2–4. That’s an estimate of planning work, not my entire job or an audited productivity study. It gave me more room for guide training, driving, photography and improving other parts of the operation. The useful result was breathing room to manage the business better. Voice gets interesting when something is connected Dictation alone saves typing. A connected assistant can work with the records and tools behind the words, within the access it has been given. I can describe a change, ask what it affects and review a proposed response. That is a very different workflow from opening several apps, finding the same information in each and typing it again. My spoken production-fix example shows one way I use that speed. For the talk, I’m considering a simple demonstration: dictate a thank-you email, inspect the draft and stop before sending. The point is how quickly an idea becomes something I can review. It doesn’t need to be a risky live scheduling change to make that clear. Buying an AI subscription for everyone doesn’t create this workflow by itself. The useful work is deciding what connects, who can change it, what needs approval and how the team knows a change actually happened. Speed needs checks A database can be wrong. A sync can stop. An assistant can misunderstand. A person can miss an assignment that was correctly recorded. I want the system to make those problems visible. Hard conflicts block an assignment that breaks a rule. Soft conflicts flag something that needs judgment or confirmation. An override needs an explanation. A change log tells us what happened. Important changes need a person to review them, and important assignments need acknowledgment from the person doing the work. A good system still needs management and leadership. Before giving an assistant another permission, I ask what could happen if it gets the task wrong. Reading a schedule, proposing a change and changing a customer’s booking are different levels of responsibility. External booking records remain read-only in the operating system described here; that is different from letting an agent change reservations or payments. The benefit of tracking an issue is also practical. Someone reports it, someone owns the next step, and someone verifies the work is complete. A longer task list on its own doesn’t make an operation safer. Some things should stay simple I could try to model propane use from trip length, group size, stove type and weather. I could build a dashboard to track every paddle. But the model is only useful if the inputs stay reliable and the result changes a decision. A straightforward equipment check, spare supply and clear restocking responsibility may solve the propane problem better. A paddle count that nobody can maintain is another thing to fix. Build the system people can keep accurate. The same judgment applies to AI itself. Fixed calculations belong in code. Routine transfers between tools can often run through ordinary automation. AI is useful for interpreting an unclear request, drafting or investigating, with review appropriate to the risk. I don’t need a fresh model call to do arithmetic every time the headcount changes. That is the distinction behind using AI to build the system. It still takes maintenance, hosting, testing and attention. It also has environmental costs. I don’t have a defensible water-use figure for this project, and I won’t turn it into a shower comparison. I want useful tools that reduce repeated work, not more processing for its own sake. A smaller outfitter can start much smaller You don’t need our database to get something useful from this. Talk through a trip you run often. Explain what changes, what people forget and what you check before departure. Ask an assistant what information is missing. Have it turn that conversation into a checklist, a guide handoff or a draft SOP. Check it against your actual procedures and field experience before anyone relies on it. Start with a task where you can recognize a good answer. Use approved tools, keep private information out unless the setup is appropriate, and review the result. Then decide whether a connection to another tool would remove a real repeated step. When evaluating software, I also want to know whether I can access the underlying records, receive change notifications and use supported write actions where appropriate. My Exhibit Hall Test is a starting point for those conversations. Access still needs permissions, checks and someone responsible for maintaining it. What I think comes next I expect more business work to start with a conversation instead of a sequence of clicks. That’s a prediction, not a timetable. It won’t remove the need for good records or for people who understand the operation. In my experience it makes that knowledge more valuable. For a high-trust business, I still want a capable person talking with customers. I’m more interested in taking repetitive coordination off that person’s plate than putting a robot between them and a guest. I love Idaho’s rivers and the people who work on them. Better preparation, fewer avoidable trips back for something forgotten, clearer responsibilities and more time for training are worth working toward. That’s why I want to share what I’ve learned with other outfitters. If you’re coming to IOGA, I’d enjoy comparing notes. Bring a process that keeps pulling you away from the work you actually want to do. We may not need to build very much to make it better.