Capacity is not a number
Every booking system I have used treats capacity the same way. A trip has a number of seats. Seats get sold. When the number hits zero, the trip is full.
Simple, and wrong.
Real capacity is not a counter. It is a question about what you should be filling, with whom, and in what order, given everything already on the calendar.
A large group booking a short trip and a small group booking a long one are not equivalent just because both technically fit. They consume different amounts of boat, crew, vehicle, and day. They are worth different amounts. And which one you should want depends on what else is already committed that week, and on what is still likely to come in.
And the ceiling itself moves. If a big group books far enough ahead, we can bring in part-timers and guides who worked past seasons, rent boats, and pull gear from another base. A trip that is full at its default size can take a much larger group if we know in time. “Full” is not a fact about the operation. It is a fact about the configuration the software happens to be holding.
So the real question is never “are there seats.” It is “can we make this happen, and should we.” Answering it means knowing who would pick up a shift, what gear is free at another location, and what it costs to assemble. None of that lives in the booking system, so the answer is a phone call and somebody’s memory of who guided here two seasons ago. Manual, every time.
Then change one group’s size by a few people and the answer flips. Group sizes change constantly, right up until launch.
So the operator does the only thing available. He keeps a rough model of all of it in his head and makes the call. That is the whiteboard problem again, except this time it does not cost you an afternoon. It costs you a little on every week of the season, and you never see the bill.
The engine
So I built the part that was missing. A model of what our capacity actually is, trip type by trip type, against real costs and real constraints, that can look at a week and work out what should go where.
It works. And it can only advise.
The engine produces recommendations. I read them, verify them, and then enter them into the booking system by hand, one at a time. The booking system is the system of record. It owns the inventory. Nothing else is permitted to change it.
Which means what actually gets applied is bounded by how much manual entry I have time for. Some weeks that is most of it. Plenty of weeks it is not.
The recommendations that never get entered are not mistakes exactly. They are just revenue nobody ever sees, and nobody ever counts, because there is no line item for the trip you could have fit.
Pricing is the same problem in a different hat
Everything above is about which bookings to take. The same engine should be setting what they cost.
In peak season the last open seats on a trip that is already running are worth something different from the first ones, and the same trip in a quiet week is worth something different again. Airlines and hotels have priced this way for decades. Guided experiences mostly do not, because the price lives in the booking system, and changing it means going in and changing it, one trip at a time. So it happens rarely, and late, and usually only when somebody notices.
An engine that already knows what the week looks like could be adjusting what is left continuously. It cannot, for exactly the same reason it cannot fill the trip. The number it would change is not its to change.
And it goes well past pricing
Once you see the shape, it is everywhere.
A group grows past what the boats on hand can carry. The system knows there is a supplier sitting on the route the shuttle already drives, and roughly what the detour costs in time. It could say: grab two more boats on the way, here is the window that works.
A crew comes off a multi-day trip at a takeout a couple of hours from where tomorrow’s group launches. Instead of sending them home and calling different people in, the system could route them to the next put-in and rebuild both crews around it.
A trip gets pushed over its normal size. That changes the gear, the vehicle, the food order, and who needs to be standing at the ramp, and every one of those is knowable in advance from things the system already tracks.
None of this is exotic. It is the ordinary arithmetic of an operation, done continuously instead of whenever somebody has an hour to think about it. Each one is small. There are hundreds of them in a season.
The wall, in money
This is the write-back problem, stated in dollars instead of architecture.
Most of what I write about the operations layer comes out sounding like it is about speed, and it is. But this is the version that costs the most and shows up the least. An engine that can reason about your entire season stops mattering the moment its output has to pass through a person’s keyboard to become real.
And it is the accumulation that matters, not any single miss. One trip you could have fit is a rounding error. Filling, pricing, rerouting, and re-crewing continuously across a whole season is a different business than doing each of those occasionally, by hand, when there is time. That gap is what would pay for the layer several times over, and it is invisible in every report anyone runs, because nothing anywhere records the version of the season you did not have.
What I want is not complicated to describe. Let the engine propose. Let it write the change back through an API. Keep a human on the approve step wherever the stakes deserve one.
Read access lets software understand your business. Write access lets it run your business.
The line
Booking software owns the inventory, so only booking software can change the inventory. That is the line, and it is drawn the same way across the whole category. I do not think it was drawn carelessly. Inventory is the thing you least want an outside system corrupting.
But the layer on the other side of it, the one that knows what your capacity is actually worth and can act on that, does not exist yet in anything I can buy.
That is the seam. It is not a feature request. It is the difference between software that records your season and software that helps you fill it.
The strange part is that the hard half already works. Knowing who would pick up a shift, which boat came off the water damaged, that a group’s count moved again this morning: none of that arrives as a field, it arrives as a text somebody sends at nine at night. I built the layer that reads it, and it updates the operating model without anyone opening a record, because that database is mine and I decide what is allowed to write to it.
So the sensing runs at the speed of the operation. It is only the inventory that stays out of reach. If you want to see the rest of it working, here is the board that replaced our whiteboard.