Wiring calendar round-robin across client workspaces without double-booking AEs

Round-robin booking looks simple until an AE is on Client A's demo while Client B's page still shows them free. Multi-client agencies do not have a calendar problem. They have an isolation-plus-availability problem.

This post is the motion craft for wiring round-robin so each client workspace gets fair distribution without stacking two live meetings on one human.

What round-robin is for

Team scheduling tools use round-robin to pick one host from a pool when a prospect books. Common distribution modes:

• Maximize availability. book anyone free (more meetings, less even load)
• Equal distribution. hide hosts who are ahead on meeting count so load stays fair

Calendly's own docs note an important detail: a round-robin event can still accept multiple bookings in the same time window if different hosts are free. That is usually what you want for a sales team. It is not a global "only one meeting exists in the company" lock. Double-booking of a single AE is prevented by that AE's connected calendar busy times. Double-booking of a room or a shared constraint needs extra rules.

For agencies, the scare case is different: the same AE sits in several client round-robin pools, and one client's booking page does not see busy times from another client's tool, personal calendar, or hold.

Hard rule: one availability truth per AE

Before you tune distribution stars and weights, fix the calendar graph:

1. Each AE connects the real calendar they live in (work Google/Microsoft calendar).
2. Every client-facing booking link for that AE reads busy events from that same calendar.
3. Personal holds, lunch blocks, and internal 1:1s must appear as busy, or they are fiction.
4. Buffer before/after demos is configured once and inherited, not reinvented per client page.

If Client A books through Tool X and Client B through Tool Y, and only one tool is connected, you will double-book. Two tools both connected to the same calendar is fine. Two tools inventing availability from memory is not.

Per-client pools, shared humans

Structure pools by client workspace, not one mega pool for the whole agency:

• Client A pool. AEs allowed to take Client A demos (ICP-trained, conflict-cleared)
• Client B pool. possibly overlapping people, different event type, different intake questions
• Event types carry client branding, duration, and qualification questions for that workspace
• Distribution mode chosen per client (equal distribution for fairness on retained AEs; maximize availability when a client has a thin bench)

Overlapping membership is normal. Isolation belongs at the event type and CRM writeback layer: the booking must land on the right client opportunity, with the right owner, in the right workspace.

Prevent the double-book failure modes

Failure A. AE calendar not connected in one workspace's scheduler

Symptom: Client B books over Client A's live call.

Fix: onboarding checklist item, "AE calendar connected and test-booked," required before the client booking link goes live. Re-test after password resets.

Failure B. holds not written back

Symptom: a manual AE hold in Slack never hits the calendar, so round-robin still offers the slot.

Fix: no verbal holds. If it blocks a demo, it is a calendar event.

Failure C. two round-robin event types ignore each other but share hosts

Symptom: both pages offer 2pm because each event type only looks at its own assignments, and the AE calendar sync lagged or excluded the event.

Fix: rely on the underlying calendar busy sync, not on event-type awareness. Confirm sync direction and delay. Prefer one scheduling system per AE when you can.

Failure D. equal distribution hides the only available AE

Symptom: prospect sees no times while an AE is free, because the fairness algorithm is waiting for another host to catch up.

Fix: know when to switch that client to maximize availability, or add hosts. Fairness that shows zero slots is a broken client experience.

Wiring checklist for a new client workspace

• Named AE pool for this client, with backups
• Event type: duration, buffers, location (Meet/Zoom), intake questions
• Distribution mode chosen and documented
• Each host calendar connected; test booking creates a busy block others see
• Booking writeback: client CRM record, workspace ID, campaign/source
• Confirmation and reminder cadence owned (ties to held-rate, not just booked)
• Emergency path: how ops reassigns if the assigned AE calls out sick
• Daily limit per host if a client is flooding one person

Agency ops metrics on the calendar layer

Watch weekly per client:

• Bookings assigned per AE (spot load imbalance)
• Double-book incidents (should be zero; treat any as a Sev)
• Invitee-visible slot count (detect fairness starvation)
• Hold-to-book latency after positive reply
• Meetings held rate (round-robin that books ghosts is still a failure)

Calendar ownership SLAs still matter: someone owns exceptions when the round-robin assignment is wrong. Automation assigns. Humans repair.

How this fits the GTM motion

Outbound that ends in "book" needs a calendar path that respects client isolation. The reply lands in the client workspace. The booking link is for that client's pool. The AE's real calendar is the conflict source across every client they serve. Round-robin is distribution. The calendar graph is safety.

Wire the graph first. Then tune fairness. Then measure held meetings, not just scheduled ones.

If you want find → qualify → write → send/reply/book inside client-isolated workspaces, join the GTM waitlist.

Sources: Calendly round robin distribution overview, Calendly shared round robin event type, Calendly community on concurrent round-robin bookings, GTM product knowledge.