Booking shared resources by time slot

Reservations handle nights. This handles hours.

Some things you rent aren't stays. A commercial vessel needs a landing dock for ninety minutes. A contractor needs the wash bay Tuesday morning. A guest wants the pavilion from noon to four. Running those through the reservation system means fighting a tool built around check-in, check-out, and per-night rates for something that never sleeps over.

Scheduled Resources is the tool for that. You define the thing people book, the rules for booking it, and how it's priced — and customers book it themselves from the portal.

It's deliberately generic. A resource is whatever you rent by the hour, and a session type is whatever you call the activity. Nothing in the system assumes an industry.

When you'd use this

• Commercial landings. Tour operators and charter captains book a dock for a scheduled arrival, and the landing fee is calculated from the vessel's length.
• Boat ramps and launches. Slot-limited access on a busy Saturday.
• Wash bays, lifts, work bays. One customer at a time, booked in advance.
• Pavilions, meeting rooms, courts, ranges. Anything shared and time-bounded.
• Equipment checkout. The loaner trailer, the pressure washer, the survey gear.

If people currently call you to ask "is the dock free at ten on Thursday" and you check a paper book, this replaces the paper book.

How it fits together

Three pieces, and it's worth understanding the split before you start clicking.

Resources are the physical things. Commercial Landing — Dock A. Wash Bay 2. Pavilion. Each one has a concurrent capacity — usually 1, but set it higher when a single resource genuinely holds several bookings at once. One long face dock with three tie-up positions is one resource with capacity 3, not three fake docks. That distinction matters later when you're staring at the schedule.

Session types are the rules. How long is a slot? What hours are you open? How far ahead can someone book, and how late can they cancel? Which resources does this apply to? Does the customer need a permit first? A single resource can host several session types — the same dock might take Commercial Landings on a 30-minute grid and Tour Departures in two-hour blocks.

Booking a slot and selling seats on it are separate decisions. Most bookings sell nothing — a freight barge takes a landing and that's the whole transaction. Selling seats is opt-in per booking, and covered in selling seats on scheduled sessions.

Fee rules are the pricing, and this is the part worth reading twice.

Fee rules: a price list item times a quantity

Every fee is a real item from your price list, multiplied by a quantity that the system reads from somewhere. You pick where:

That fourth one is the interesting one. If you charge landing fees per foot of vessel length, you create one fee rule: price list item Commercial Landing Fee (per ft), quantity from asset measurement, measurement key loa. When a 44-foot vessel books, the system reads 44 off that boat's record and bills 44 × your per-foot rate. Same mechanism prices a bay by trailer length or a crane by tonnage.

You can also step the rate by size using price breaks — vessels under 40 feet at one rate, 40 to 50 at another, above 50 at a third. Enter it as JSON in the fee rule:

{"breaks":[{"min":40,"unit_price":26},{"min":50,"unit_price":28}]}

Mark a fee rule optional and it becomes a checkbox the customer ticks at booking — pump-out, trash removal, extended berth. Required rules always apply and are never offered as a choice, because implying a mandatory fee is declinable is how disputes start.

Eligibility: reuse the permits you already issue

A session type can require the customer to hold an active pass or permit. Select one or more permit types, and only accounts holding all of them — active and unexpired — can book.

The important detail: customers who aren't eligible still see the page. They see the booking calendar, and underneath it a plain statement of what's blocking them, with each required permit's current status — Commercial Landing Permit — Awaiting approval. Hiding the page from them just generates a phone call asking where the booking page went.

One permit per vessel, when you need it. Tick For a specific asset on the permit type and each permit is issued against one boat, trailer, or rig rather than the company. An operator with two vessels applies twice and holds two permits that approve and expire independently — which is usually what you actually want, since the permit is really a property of the hull. Quotas count per asset too, so a "one at a time" limit doesn't block their second boat.

When that's on, the booking form asks which vessel, and shows any that aren't permitted greyed out with the reason. The application form asks the same question, and lets the applicant add a vessel right there if they don't see theirs — nobody has to abandon a half-finished application to go create a record somewhere else.

Setting it up — the typical workflow

1. Create your price list items first. Every fee has to point at a real item. Make them before you build the session type or you'll be bouncing between screens.
2. Add your resources under Administration ▸ Scheduled Resources ▸ Bookable Resources. Name them the way staff and customers actually refer to them. Set the concurrent capacity. If the resource is already a slot on one of your maps, link it — see the closure note below, it's worth it.
3. Build the session type under Session Types. Work top to bottom: name, time grid, resources, eligibility, fee rules, then portal settings.
4. Test it as a customer. Turn on Show on customer portal, log into the portal as a test account, and book something. The fee breakdown the customer sees is generated by the same code that produces the invoice, so if the number looks wrong on the portal it's wrong in the fee rule — not a display bug.
5. Turn on the portal section under Administration ▸ Customer Portal Settings ▸ Book a Time.

Linking a resource to a map slot

If your resource corresponds to a slot on one of your property maps, link it in the resource editor. The payoff: that resource then inherits the slot's closures. When you close Dock B for storm damage in Slot Closures, bookings on it are blocked automatically. You maintain one closure list, not two — and there's no scenario where the map says closed and the booking calendar says available.

Working the schedule

Scheduled Resources ▸ Booking Schedule is the day view: resources across the top, time down the side.

• Pick a session type in the filter bar first. You can't book an empty slot without one — the type is the rule set the booking gets validated against, so there's no such thing as a generic booking.
• Click an empty cell to book it. Drag a booking to move it to another resource or time; the length stays the same.
• Click a booking to open it — edit it, see its invoice, approve it if it's waiting, or cancel it.

Staff can book inside the notice window that customers can't. If someone calls from the channel ten minutes out, book it. What staff can't override is the structural stuff — operating hours, slot alignment, minimum and maximum length. Those are the rules that keep the schedule coherent.

When to bill

Two choices per session type:

• At booking time — the invoice is created immediately and the booking sits at Payment due until it's paid. Use this for anything where the price is fully known up front.
• After the session runs — no invoice at booking. An overnight job cuts one invoice once the session is over. Use this when a fee depends on a number that isn't final until it happens, which in practice means headcount.

Either way it's a standard invoice, paid through your normal payment flow, and it lands in your normal reporting.

Common mistakes

Creating three resources for one dock with three positions. Use one resource with capacity 3. Three separate resources means the customer picks a position, which they don't care about and shouldn't have to think about — and it makes your schedule three columns wider for no gain.

Forgetting to require the asset. If a fee is priced off an asset measurement and the session type doesn't require an asset, someone will book without selecting their boat and the fee will resolve to zero. Set Booking asset: Required on any type with a measurement-based fee.

Getting the measurement key wrong. The key has to match the field name on the asset type — if your boats record length as loa, the fee rule needs loa. Type length when the data lives under loa and every booking prices at zero. Check an actual asset record before you save.

Setting the cancel cutoff to 0. That means customers can cancel right up to the start time. If you need a real notice period, say so — 24 is a common answer. Use -1 to stop customers cancelling online at all.

Deleting fee rules that have been used. Remove a rule from a session type and it's deactivated, not destroyed, so past bookings keep their pricing history. That's deliberate. Don't work around it by editing an old rule into something unrelated — create a new one.

Assuming the portal calendar shows a specific dock. It doesn't. Customers pick a time; the system assigns the first available resource. That's usually what you want. If customers genuinely need to choose a specific one, give each its own session type.

Related articles

• Passes & Permits — selling and issuing access — the eligibility gate
• Selling seats on scheduled sessions — public bookings with a roster
• Uploading and configuring your property map — map slots and closures