Every scheduling tool with a team plan claims to do round-robin. Most of them implement the same thing: keep a pointer, hand the next booking to whoever is next in the list, advance the pointer. It demos beautifully. It falls apart in the second week.
Why a rotating pointer drifts
A pointer only counts offers, not outcomes. Consider a three-person team where everyone is nominally equal:
- Priya works Tuesdays through Fridays.
- Marco is on Pacific time; the team’s booking page is mostly booked by European prospects in the morning.
- Dana has back-to-back internal meetings every Monday.
The pointer doesn’t know any of that. It offers Marco the 9am CET slot, finds he has no availability, and skips to the next person. Skipping doesn’t cost Marco his turn — so he stays at the head of the queue and gets skipped again. By Friday, Priya has taken sixteen calls and Marco has taken three, and nobody touched a setting.
If your round-robin is drifting, you'll see it in the calendar before you see it in a report: one person's week is solid colour and everyone else has gaps.
Counting what actually happened
BunnyCal assigns on booked load, not queue position. When a guest opens a team booking page, we compute eligible hosts for each individual slot, then rank them:
- Eligibility first. A host who isn’t free at that exact time is never a candidate, so being unavailable can’t consume a turn.
- Fewest meetings in the balancing window. By default that’s a rolling seven days, so a heavy Monday self-corrects by Thursday.
- Longest since last assigned, as the tiebreak.
Because the ranking is per-slot rather than per-page-view, two guests loading the page at the same moment and picking different times get different hosts — without a lock, and without either of them seeing a slot that’s about to vanish.
Weighting on purpose
Equal distribution is the default, not the rule. A weight of 0.5 on a host who
splits their time with support means they land roughly half the meetings of a
full-time rep — deliberate imbalance, which is different from drift:
| Host | Weight | Meetings / 20 |
|---|---|---|
| Priya | 1.0 | 8 |
| Marco | 1.0 | 8 |
| Dana | 0.5 | 4 |
Set weights on the team’s Members tab. Changing a weight affects future assignments only; meetings already on the calendar stay where they are.
What we deliberately didn’t do
We don’t rebalance retroactively. It’s technically possible to move a booked meeting to a different host when the distribution skews, and it is a genuinely terrible experience for the guest who already has a calendar invite with a name and a face on it. Balance is a scheduling-time decision. Once it’s booked, it’s booked.
For the full configuration reference, see Round-robin assignment in the docs.