Questions about working together

Because at small scale a whiteboard is the correct tool, not a compromise. At five guides and three trips a day you can see the whole operation at a glance, anyone can update it, and a change costs one erase and one rewrite. It stops working for a reason most operators never name out loud: the number of resources grows steadily, but the number of relationships between those resources grows exponentially. Add a second river, a bus, and multi-day trips, and nothing stays in its own lane anymore.

A live board the crew pulls from, backed by a database that models how the operation actually fits together. Ours is a no-login web board carrying assignments, shuttles, food, notes, and inventory, sitting on top of 207,000 connected data points covering guides, certifications, river sections, equipment, maintenance, dispatch history, and logistics. The important part is not the screen. It is that the team self-serves the plan instead of waiting for one person to text it out.

Because booking software solves reservations, and dispatch is a different problem. Most scheduling products assume people and rooms. A river operation schedules a dependent graph: a trip needs a crew, the crew needs qualifications specific to a river section, the trip needs boats and a vehicle and often a trailer, the vehicle needs a driver with the right license, and the whole thing has to be somewhere else the next morning. Off-the-shelf tools can express that a person is busy. The ones we tried couldn't express that a guide is qualified on one river section and not another, or cleared to lead big water and not yet cleared to lead.

Because the model was never the hard part. The obvious version is an AI that clicks through your booking software for you, and it is too slow and too brittle, because that software was built for a human to operate, not a machine at speed. The bottleneck is the data layer. So the real work was a purpose-built operational database: 44 interconnected tables and 207,000 connected data points, with the operation's rules and dependencies encoded as data an AI can read and write in real time. The AI is the interface. The operating model is the part that is hard to copy, and it gets deeper every season, because every operation and exception it survives is context no competitor or foundation model starts with.

They are getting closer, and that is a good sign the problem is real. But most of what is shipping automates workflows around the booking record: assign a guide, post an alert, fill a slot. That is useful. The harder layer is modeling the operation itself, the dependencies between people, qualifications, assets, geography, timing, and permits, and keeping that model current as reality changes underneath the bookings all day. A guide assignment is a feature. Knowing what that assignment changes two days downstream is an operational model. That deeper part is still underbuilt, and it is where I have spent the last few seasons.

Slack is a sensor, not a chat room. The crew already reports everything that matters in plain language: a guide picking up an appointment, a group running late, a boat tube that tore, a guest count that changed in passing. The system reads across the channels, works out what each message means for the operation, updates the record or stages the change, and re-checks the schedule so a collision surfaces while there is still time to fix it. One real example: a guide texts that they will take another guide's driving tomorrow, no time or trip named, and it becomes three specific movement reassignments, checked and confirmed that night. Anything touching money, compliance, or safety waits for a human.

The person holding it together. Long before the schedule breaks, whoever holds it in their head becomes the router every change passes through, and that person's memory becomes the actual production system. Being more organized does not save you, it only delays it. The tools were never the problem. The speed was, because operational reality changes faster than anyone can stop and record it.

Yes. Adventure Idaho has run the 2026 season so far on the system with the whiteboards down, through peak summer, across multiple rivers, day trips, multi-day expeditions, youth groups, rentals, and vehicles. That is the honest test of an operating system: not whether it demos well in February, but whether anyone reaches for the marker in July.

At Adventure Idaho, estimated weekly planning time went from 20 to 40 hours a week down to 2 to 4. The hours did not disappear, they moved to training, communication, and problem solving, which is the actual return. The reason the number moved that far is that planning stopped being re-entry of things people already knew and became review of what the system had already assembled.

You interview yourself, and that is harder than building the software. Most of what an experienced operator knows is held in their body rather than in a document: how long a float actually takes at this flow, with this wind, with this kind of crew. Extracting that into something precise enough for a machine to act on is the real work, and the automation on the other side is comparatively easy. That knowledge is the most valuable asset a company has and the least protected, because it walks out the door at the end of a season or the end of a career.

You model the river instead of guessing. A guide radios a launch time in, the system pulls current flows, factors in wind speed and direction and trip type, estimates downstream travel time, and tells the driver when to leave. It has been putting drivers at takeouts about five minutes before guests arrive. A river is not a road: travel time changes with flow, the relationship is not linear, and a headwind on a wide slow stretch can add half an hour to a float the gauge says should take ninety minutes.

Product quality, reputation and content built our early foundation. We shot and edited the work in house, with an organic video library past 3.6M+ views and one piece past 1.6 million. We now also use paid marketing to scale demand. Website visitors went from 4,944 in 2022 to 97,486 in the last 12 months, and direct visits, people looking for us by name, rose about ten times. Online share of bookings went from 67% in 2023 to 78% in 2025; online share of revenue went from 46% to 74% over the same period. Those results reflect the combined work, not a claim that every booking came from unpaid content.

You treat it as a marketing problem, because that is what it is. In 2026 every regional headline said drought while our actual flows ran higher through the summer than the year before. Customers book off headlines, not hydrographs, so the work was publishing the real conditions ourselves, repeatedly and early, instead of waiting for the story to correct. We were not fighting low water. We were fighting a story about low water.

Reputation first, content second, and both only after the product is consistent. A 5.0 star average across 650 Google reviews is not a marketing asset you can buy, which is exactly why it is the durable one. Driving traffic at an inconsistent product does not grow a business, it manufactures three star reviews and a worse business.

Start by making the business and its work easy to understand in factual, crawlable pages. At Adventure Idaho, recorded AI search appearances went from ~30 a month to ~1,800 a month. Publishing specific details about the operation and training helped, alongside the wider work on service, content and reputation. Appearances are not rankings or bookings, and results vary by query.

You go get demand somewhere else, fast, and you do not start by cutting. When a policy change took our largest institutional account from ~50% of revenue to under 20% in a single season, the instinct was to let every new hire go. Instead we rebuilt the front of the business over ten weeks: new pages, new funnels, new channels, and market segments we had never gone after. Records were broken by May, before the season opened, nobody was laid off, and the company came out of the year structurally less fragile than it went in.

You standardize the trip before you scale it, and you hold a standard people can see. At Adventure Idaho that means checklists for every phase of a trip, written procedures for logistics and gear, more than 50+ structured case studies drawn from real scenarios, live rescue simulations, and repetition under pressure. The piece most operators skip is the debrief: every trip gets an honest one, modeled on the way fighter pilots run them, which is where the learning compounds.

More than most operators think, and almost none of them measure it. Discounts get given one booking at a time by people trying to be helpful, so it never shows up as a line item, it shows up as a margin quietly lower than the price list says. Measuring it is the cheapest pricing work there is, because you are not raising a price, you are finding out what you actually charge.

You stop charging flat rates for products that are not flat. We split the lineup into premium, mid, and budget, made the differences obvious, and pointed each kind of traffic at the right one, because self selection does a lot of sales work if you let it. Then we repriced by trip and by day rather than raising everything at once. Rates went up and volume kept climbing, which is the clearest possible evidence a product was underpriced rather than overpriced.

You stop hiring for experience and start hiring for trajectory. The default in this industry is to look for outdoorsy people with the right certifications, which is reasonable and does not solve operational consistency. We ask a different question at the door: are they going somewhere. That brings in college athletes, future pilots and engineers and doctors, builders and operators, and it means the culture enforces the standard without anyone having to police it. Adventure Idaho now receives hundreds of applications a year for a handful of guide spots.

You accept the ceiling and work the yield underneath it. When you cannot sell more days, the levers are which trips fill those days, what they are priced at, and how tightly you load each departure, so capacity rules belong in the system as data rather than in someone's judgment. Ours live as configurable trip type rules, capacity tiers, and day caps, alongside the use reporting the agencies require.

Buy the reservations, build the operation. Booking platforms are good at what they were built for and there is no reason to rebuild that. What none of them handle is the layer underneath: fleet, driver and vehicle compliance, certification expiries, permit and use day tracking, and real crew scheduling. If that layer is where your operation hurts, no purchase order fixes it, because the rules are specific to your company even when the engine that reads them is not. And most of the connecting is automations and connectors, not new software: the real work keeps happening in the platforms the crew already uses.

It works, with a constraint doing most of the load bearing. AI is the interface, not the decision maker: updates get made by voice from a truck, questions get asked in plain language against live data, and reports that took days get generated in minutes. Anything touching money, compliance, or safety requires a human confirmation, the system reports back exactly what it changed so a person can verify it, and every change keeps a record of who asked for it and whether a person or the AI made it. That constraint is not a limitation, it is the reason the crew trusts it enough to use it.

Justin Smith is the General Manager of Adventure Idaho, a multi-site whitewater rafting company operating on federal and state permits in Riggins and Twin Falls, Idaho. He runs operations, marketing, and sales, leads a seasonal team of 44, and designed the system the company runs on: an operating model plus the automations and connectors that tie together the platforms it already uses. Guest volume grew roughly 3.6x since 2022, the year before he took over, from 1,279 to 4,709+ so far this season, while prices went up rather than down.

It means the person who runs the business is also the person who designs the system it runs on. Most operators are either a systems person or a growth person, and the work only holds together if you are both, because a demand engine pointed at an inconsistent product manufactures bad reviews, and a beautifully run operation nobody can find does not survive either. The rafting is the setting, not the product. The transferable thing is the sequence: standardize the product, build demand, price for the demand, then build the system so growth does not turn into chaos.

Less one piece of software than a system. At the center is a model of the whole operation: 44 linked tables and 207,000 connected data points covering crew, certifications, fleet, trips, food and the rules between them. Around it, dozens of automations and connectors, Zapier zaps, scheduled jobs and webhooks, tie it to the platforms where the work actually happens: reservations read from the booking system, Slack, the phone system, email and forms. On top of it sit the web apps, phone apps and dashboards the crew uses, with conflict detection that catches a double-booked guide or van before the day of. Most of it shipped mid-season while the operation was live. He is not a career software engineer: he specifies, directs, reviews, and ships using AI coding tools, which is a real distinction and worth stating plainly. The skill that mattered most was judgment: what to automate, what to leave to a person, and what was worth modeling at all. The part he is proudest of is the interface: tools the crew opens on a phone and uses without training, because a system nobody opens changes nothing.

Partly, and that is the point. The data lives in Airtable, the orchestration runs on Zapier, and the logic, a conflict engine and ~50 automations, is custom JavaScript, on top of the booking platform's API, with a real-time dispatch board the crew reads. ~20,000 lines in the current system, 696 commits in version control. I chose those tools deliberately: as one person iterating on a live operation, I needed to ship at the speed the operation changed. The architecture does not depend on them, though. The rules live in data, not tool-specific code, so the whole model ports to a production database when scale demands it, and only the connector is vendor-specific. The tool was never the moat. The operating model on top of it is.

He bought a locksmith business in Rexburg, Idaho at 22, expanded the services, fixed the pricing, built a crew that could cover calls around the clock, grew revenue about 6x over, and sold it. It was a very small local service business and he does not call it an exit, but he found it, bought it, ran it, and sold it, which taught him more about pricing and staffing than anything since. In between he guided multi-day wilderness trips on the Middle Fork of the Salmon for a different outfitter, spent about a year working on international distribution and ecommerce sales operations, and sold door to door and software. He is an FAA certificated private pilot, an Eagle Scout, and holds an Idaho guide license.

At a small operator, all of it. Operations, marketing, sales, hiring, pricing, fleet, compliance, and whatever broke that morning. The job description that matters is narrower: get the operation out of your own head and into a system the whole team can run from, so the business stops depending on one person remembering everything. A business that only works when one person remembers everything is not a business yet, it is a job with employees.

I have one, and I am not quietly shopping. I run operations, marketing, and sales for a multi-base outfitter in Idaho, and I am building toward a bigger season next year. I also take on a small number of service-business projects. Based in Twin Falls. Serving Southern Idaho, with remote projects available. See /inquiries/ and /operations/.

Putting it to work inside service businesses. I built an operating layer because my operation needed one, and it turned out to be a specific answer to a general problem: what a business has to write down before anything can safely act on it. The longer argument is at /agent-ready/. Where I am taking it is growing good service businesses: the demand, the operation and the systems underneath, built on site with the people who run them, for long enough that the improvements compound.