Nothing gets dropped
Booking software is good at one moment: a guest picks a date and pays. After that it goes quiet. It doesn't tell you a balance was never charged and the trip launches in three days, or that someone called twice and never got a human, or that a guide is thirty miles into a canyon with no signal.
- $11,411caught in a single morning's unpaid balances
- 22team channels, routed by base and by trip
- 0money or safety actions taken without a human
Every one of those gaps is money or safety slipping through something the booking system has no view into. So I built the layer that watches all of it and surfaces what needs a person. Everything the operation needs to know arrives in one place, and a human decides what to do about it. The system never acts on money or safety on its own.
Money, before it walks out the door
Every morning the system reads the booking data and posts the balances still owed on trips launching in the next six days: who owes what, how much they've paid, and a one-click link to charge or follow up. One recent morning it flagged $11,411 outstanding across five reservations, all launching that week.
That is money the booking software collected a deposit for and then stopped watching. Left alone, some of it simply never gets charged, and you find out when you happen to look. Surfaced every morning, it gets run before the guests are on the water.
The leads and calls nobody answered
The harder gap is the one you can't see at all: the people who tried to book and got silence. A digest runs every morning across the phone line and messages and sorts the last day into what actually needs a human: calls that need a callback, texts that went unanswered, leads that started and stalled. It reads the whole thread, so it can tell the difference between "party of four delayed by a crash, already resolved" and "two first-timers wanted a day trip, asked when someone would be in the office, and got zero replies."
It is deliberately read-only. It surfaces, a person acts, nothing is auto-answered.
This is the half of the business booking software ignores completely. A booking system can tell you about the reservations you got. It has nothing to say about the ones you lost because a text sat unanswered on a Saturday morning. In a business where filling the seats is half the game, that blind spot is expensive.
Field communication that doesn't live on one phone
Our trips run through canyons with no cell service. A satellite messenger, out of the box, sends to one phone. That is the design: one device, one contact, usually the owner. If that person is driving, asleep, or on the water themselves, the message just sits there.
Ours relay through the company number into a team channel instead, where every manager and lead guide sees them at once. A guide reporting "water is brown, blowout reported" or asking for a van at a takeout reaches whoever is actually available, and it gets escalated to the right person immediately rather than waiting for one phone to light up. Timing pings run the other way: automated "leave in ten minutes for the pickup, boats land at 1:33" messages, timed off the actual trip.
The same timing engine also runs a revenue line the company didn't used to have. At set points in a trip it pings a photographer to get downriver and be in position at a specific rapid before the boats come through, so the shots actually get taken instead of missed. Back at the shop those photos flow into PicThrive, which runs an automatic slideshow on the store TV and handles the pricing and the sale. I built the whole loop, from the field timing to the point of sale, and it opened a photo-sales profit center the operation didn't have before. The customer chooses to buy. The system's only job is making sure the moment on the river got captured and the storefront was ready to sell it.
Time off, which a whiteboard cannot hold
Time off is the request type that quietly breaks a seasonal operation. A whiteboard shows you today. It can't tell you that four people asked for the same weekend in August, that a request came in three weeks ago and nobody answered it, or that the guide you just assigned to a five-day trip is leaving on day three. Those requests arrive by text, in person, and in passing, and they live in whoever happened to hear them.
Now when a guide submits time off or a schedule change, it lands in the management channel with the dates and the reason, linked straight to the record. It is tracked instead of remembered, it is visible to every manager instead of one, and it sits against the same schedule the assignments come from, so a request that collides with a trip shows up as a conflict rather than a surprise.
Why it's a layer, not a feature
None of this is a chatbot and none of it acts on its own. It's a set of senses wired into one nervous system. One channel is where the whole operation's signal arrives, and the system's job is to watch the money, the phones, the field, and the crew, and tell a person what needs them. The human stays in every loop that touches a dollar or a safety call.
Booking software tells you a booking happened. This layer tells you what's slipping. The shape of it, money owed, leads unanswered, field coordination, internal requests, is the same in every operationally complex service business, not just this one. That argument is the one I make in booking software solved the transaction and left the operation unbuilt, and this is the working half of it.