Can the business act on what it knows?

Start here

Ten requirements for the whole system

Pick an actual change, such as a group growing after a booking, and trace it through these checks. The business needs to know which tool owns each record and who maintains the rules across them. It may use existing tools or a connected database to do that.

1. Canonical objects

   Define customers, jobs, people, qualifications, assets, places, schedules, payments and permits with stable identities. A larger rafting group should point to the same trip, boats, guides and vehicle everywhere it appears.

2. Relationships

   Show what each job needs and what else shares those resources. A guest count change may affect guide ratios, food, transport and launch timing. A single updated field does not show the full consequence.

3. State changes

   Capture created, moved, assigned, canceled, paid, dispatched and completed events, including changes first reported by a person. A crew message about taking a driving shift is a signal to verify and record, not an automatic instruction to rewrite the schedule.

4. Action contracts

   Give each supported action named inputs, preconditions, effects and a result that can be read back. "Reassign driver" must say which run changes and which conflict checks passed. An endpoint that accepts a request is only one part of this contract.

5. Permission scopes

   Separate reading, proposing and writing, with narrower authority for financial or irreversible changes. Enforce authorization on every protected action. Policy decisions can be centralized, while each action still checks the decision before executing.

6. Hard rules

   Write down constraints that cannot be waived by a confident suggestion: qualifications, capacity, time, permits and resource conflicts. Keep operating preferences distinct from those rules and put safety calls with the people responsible for them.

7. Idempotency and recovery

   Give retries a stable identity so a timeout cannot create a second booking or charge. When a change spans systems, expect partial failure: record each step, repair or compensate for what succeeded, then reconcile against the actual records.

8. Approval gates

   Attach the gate to the action and its consequence. Show the proposed change and reasons to the right person before a refund, payroll change or consequential safety decision. A broad login role alone is too coarse.

9. Audit and reconciliation

   Keep who proposed, approved and made a change, what each system accepted, and what still disagrees. Reconcile the operating model with the authoritative booking, accounting and assignment records, and give someone a clear queue for mismatches and failed connectors.

10. Evaluation

    Test historical exceptions and safe synthetic scenarios before granting authority. Include stale data, conflicting assignments, interrupted writes, overrides and a human refusal. Keep checking the system after it goes live.

For an operator comparing tools

Ask for evidence, then test the gap

For each requirement, mark supported, partial, missing or unverified. Cite the vendor documentation or a test result. Separate working capability from custom integration work, a roadmap promise and an unknown. An agent helping with this assessment should use the same labels and show its evidence, so a person can check the conclusion.

The booking category has its own test: what I am looking for in booking software. The shorter buying conversation is the Exhibit Hall Test.

A useful vendor test

Bring a real change, not a feature list

Ask a vendor to show how a group changing size, a worker calling out or a vehicle going out of service travels through its product and the other tools you use. Start with a sandbox or safe test records. Show the state before the change, the proposed action, the user or system allowed to take it, and the state afterward. If the answer requires custom work, write down what that work is and who will maintain it.

Try the failure case too. Interrupt an update after one system accepts it. Retry with the same request. Ask where a person sees the partial result and how the team avoids a duplicate. Then make a conflicting change while the first one is pending. A clean demo of the happy path says little about a busy operating day.

Read coverage carefully. Bókun's REST v2 documentation, for example, lists product components, resource pools and assignments, reallocation, and availability and daily pricing writes. Documented operations are a starting point, not proof of access or fit for a particular account. Test the exact permissions and behavior you need. API access alone does not capture a company's rules, exceptions or authority; people still have to model and validate those.

Prefer a written answer tied to the exact endpoints, events, export formats and permission scopes you can use. Ask for rate limits, event delivery and retry behavior, and how to recover if an event is missed. If the tool has no event feed, ask what polling interval is safe and how stale the resulting view can be. A label like "AI ready" does not answer any of these questions.

One framework

Six parts of an operating loop

These are capabilities the business needs across its tools and people, not six products to buy or a claim that each is equally mature. Demand creates work; AI can help interpret and propose changes. Neither supplies trustworthy state or authority by itself.

1. Records and signals. A booking or field service system records the transaction. Messages, forms and field reports tell the team when physical reality changes. Someone must verify those signals and bring them into the same current view.
2. Operating model. A maintained view of people, qualifications, assets, locations, capacity, timing and the links between them describes what the business can actually do, whether it lives in one system or across connected tools.
3. Rules and judgment. Hard constraints are enforced; patterns can inform a proposal; ambiguous or consequential decisions stay with a person. A guide's qualification is a hard rule. Who usually prefers a trip is a pattern.
4. Actions. Typed, supported writes and human workflows turn a decision into an actual change. The interface may be an API or another controlled route, but the outcome must be verified.
5. Governance. Identity, authorization, approval and an audit trail apply across the action path. A central policy service can make the decision; each protected write must enforce it. Open Policy Agent documents that separation.
6. Feedback and reconciliation. Compare expected and actual state, surface failures, record corrections, and decide whether an exception changes a reusable rule.

That loop can include booking software, accounting, an operating database, workflow tools and a person approving the important calls. A vendor does not have to own every part, but the connections between parts need to work.

Decide before automating

Three kinds of decisions need different treatment

Hard constraints are facts the system must check every time. A guide needs the right qualification for the water; a van cannot cover two runs at once. These belong in explicit rules and validation. If a source record is stale or missing, the system should stop or ask, not infer that the constraint probably passes.

Operating patterns help rank options but can change. A guide usually prefers a trip; a shuttle sequence usually works; a customer may need extra lead time. Historical examples can inform a suggestion, but they do not grant authority. Save the reason when a person overrides one, and ask whether it was a one-time exception or evidence that the pattern needs revision.

Human judgment stays visible where context and consequences matter. A safety call on the water, a refund after a bad day or a schedule change that costs someone their only day off needs a person who can weigh the circumstances. The system can assemble the relevant facts and show possible effects without pretending it made the decision.

The boundaries are operating choices, not permanent truths. Test them with the team, document who can change them and revisit them when the work changes. A false hard rule blocks good work; an unstated hard rule lets bad work through.

Follow one change

A larger group is more than an edited guest count

When a group grows, the booking system knows who booked and paid. The operating model must check guides, boats, vehicles, food, permits and timing. A proposal can show the viable options. Hard rules reject a conflict; a person decides exceptions with real consequences. Only then should the supported systems receive updates, followed by a read-back and a mismatch check.

In my operation, booking data flows in. Capacity and other operating decisions still need manual write-back to the booking system. That is a limitation of our current integration, not proof that all platforms are read-only. Some field service and booking products expose useful writes, but a write for one object is not a coordinated change across the whole business.

Multiple systems seldom share one atomic transaction. The practical design is idempotent steps, recorded progress, partial-failure recovery and reconciliation. If payment succeeds while booking fails, the system must identify the mismatch and route a safe repair. Microsoft's compensating transaction pattern explains why a distributed workflow needs an explicit way to address work already done.

Good interfaces help, but descriptions are not enforcement. OpenAPI describes HTTP operations, and MCP tools describe callable functions. The implementation still has to validate inputs, authorize actions and check business rules. OCTO helps connect tours and activities for products, availability and bookings; it does not by itself describe an operator's crew, qualifications or fleet.

Action quality

What a supported write must prove

Before a change runs, the system needs a stable request ID, current inputs and known preconditions. It checks the actor's authority and the hard rules against fresh state. A person sees the proposed consequences when approval is required. A tool description can help an agent choose a function; it cannot substitute for those checks inside the system that performs the write.

After a write, record the result and read back the affected state. A successful HTTP response may mean a request was accepted, not that every related record now agrees. If the booking changed but the crew board did not, show the disagreement to the team and retry or repair the failed step. Where a change cannot simply be reversed, the recovery plan may be a compensating action or a human decision.

Keep an audit trail useful to the person running the day: what was proposed, who or what approved it, which rules were checked, what each connected system returned and what remains unresolved. The aim is to make a mistake findable and fixable before it reaches a guest. For physical work, "rollback" has limits. A record can be restored; a missed launch or a stranded group cannot.

From a working operation

What this changed on the ground

At Adventure Idaho, where I serve as General Manager, I built a connected operating model and the dispatch tools around it while the business was running. The crew uses the board and phone tools to see assignments, report changes and surface conflicts. Dozens of automations and connectors carry information between the booking system, messages, phones and forms. Weekly planning fell from 20 to 40 hours to 2 to 4. See the operating system and the dispatch board.

The useful evidence is in the corrections too. A substitute driver can look available while lacking the qualification for that run. A boat issue can change what a future trip can carry. Recording why a person overruled a proposal helps us find missing rules; it does not mean every override should become one. How I used corrections to find the rules.

The physical side is why I start with the team rather than a database diagram. A guide can report a damaged boat in a message, but the report only helps if it is connected to that boat, its location and future assignments. Someone needs to verify the issue, decide whether it takes the boat out of service, and see which trips need another plan. The point of connecting those steps is to give people a current picture before the conflict becomes a launch-day surprise.

This work displaced part of my own coordination time: retyping, checking collisions and rebuilding plans. It did not remove the need for field judgment or a person accountable for money, compliance and safety. Faster updates can reduce drift, but only if signals are captured, connectors recover and people check the exceptions.

After launch

Audit history is not the whole feedback loop

An audit log explains what happened after someone looks. The team also needs to see when an event stops arriving, a connector fails, data goes stale, a conflict sits unresolved or an unusual number of suggestions get overruled. Decide who receives those signals and what they can do about them. Otherwise, the dashboard can look orderly while the business has quietly stopped updating it.

Corrections should improve the model only after review. Capture the original proposal, the person's change and reason, and whether it was a reusable rule or a local exception. Test the revised behavior on old and synthetic cases before using it on live work. That gives a growing operation a way to learn without letting one unusual day rewrite its rules for everyone.

Where the claim stops

What still needs testing

Products and integrations differ in which records they hold and which actions they permit. I do not yet know how much of one operation's model transfers cleanly to another service business. The test is whether later builds get easier without flattening the local rules that matter.

Start with the change your team still carries between tools by memory. Trace it, test it, and give a person a clear way to stop or correct it. If you want to work through that in your business, here is how I work on site.