Service · INTAKE · Capacity-aware booking

The calendar said
I was free.
My week said otherwise.

Static booking tools publish office hours and hope. I publish the capacity the week can actually give, claim the slot once, and show what the new commitment changes before the rest of the calendar moves.

Capacity-aware booking built around the work the week already holds
Service
Capacity-aware booking
Class
Live on PickBits.AI
Takes
Real capacity, protected time, commitments, placement rules
Confirms
One atomically claimed slot
Proposes
The changes the rest of the week now needs
Gate
The operator applies the re-plan

The collision.

Calendly and Acuity are good at publishing office hours. That is not the same as publishing availability. They do not know what the week already holds, which work can move, or which empty-looking hours are protecting the work on either side of them.

So they hand out slots that are technically open and actually impossible. The meeting fits. The work it displaced does not.

What this booking flow does.

Publish capacity, not a repeating window.

Availability is derived from the week as it stands now. Existing commitments, capacity limits, placement rules, and protected time all count. If an hour is needed to keep the week possible, it is withheld instead of offered.

Claim the slot before confirming it.

A selected slot is claimed atomically. Two people cannot take the same opening while two browser tabs are looking at it. Once the claim succeeds, the booking is confirmed on the spot.

Show the rearrangement the booking requires.

The booking becomes a real commitment, not an isolated calendar event. The planning engine recalculates the week around it and prints the consequences as a diff. The operator reviews and applies that re-plan; the booking is automatic, the judgment is not.

The honest proof.

This replaced Acuity on this site. The Book a call links open the live flow, and the capacity behind those slots is Mark's real week. That is the evidence today: not a customer roster, but the system doing the job it describes here.

The compounding loop.

Booking captures the demand. The planning engine absorbs it into capacity and proposes the new arrangement. Scheduling ops is the managed version, where I keep the queue and calendar true as the week changes.

Each offer stands alone. Together, an inbound booking changes the proposed week before the operator has read the email, without taking the decision away from them.

Where it fits.

Real capacity
Protected time
Atomic claim
Immediate confirmation
Operator-approved re-plan

Who it suits - An operator whose empty calendar space is not the same thing as spare capacity.

What it replaces - Static office hours that make every new booking somebody's problem later.

What stays human - The proposed re-routing of the week is reviewed and applied by the operator.

This runs against a changing week; if something here has gone stale, tell me and I will fix it.