Round-Robin Scheduling: How to Share Bookings Fairly

Round-robin scheduling assigns each new booking to one member of a group, rotating through the group so that the work is shared. It is used by sales teams who take inbound demo requests, support teams who offer consultations, advisers who see clients and any group where "anyone on the team can take this meeting."

A guest sees a single page. Behind it, the system decides who gets the booking. How it decides, and what limits it respects, determine whether the arrangement is fair and whether the guest finds a slot at all.

Simple rotation and its weakness

The simplest form hands bookings to each member in turn: first Ana, then Ben, then Chloe, then Ana again. It is easy to explain. It has two weaknesses. First, it treats members as identical, so a colleague who works part time takes as many meetings as a full-time one. Second, it ignores availability, so if the next person in turn is busy at the time the guest wants, the system must still find someone, and the rotation drifts.

Cumulative count with weights

A fairer approach keeps a running total of bookings per member and gives each new booking to the member with the lowest total who is available at the chosen time. Weights adjust the total, so that a member who should take twice as many meetings counts each booking as half.

Atlas booking pages use this method. Every booking goes to the pool member with the lowest cumulative count, and a tie is broken by position in the pool. A member on weight two absorbs roughly twice as many bookings as one on weight one, so a part-time colleague can be given a lower weight and take proportionally fewer. A daily cap stops anybody from having a wall of calls: a member whose cap is already met for the candidate day is skipped entirely.

If someone joins the pool late, their count starts at zero and they would receive every booking until they caught up. Use Reset to clear the cumulative counts so they are not permanently ahead or behind.

Availability comes first

A guest should only be offered a time when at least one member can take it. Atlas offers slots only when they are possible: the notice period hides slots that are too soon, the maximum days ahead hides slots that are too far away, blackout ranges remove days when the team is away, and per-day, per-week and per-month caps remove slots once they are used. If the busy-time check is on, a slot that overlaps an event on a connected Google or Outlook calendar is hidden too. The check does nothing for a host without a connected calendar, so connect the calendar first and then enable the check.

Different meeting types for different people

Not everyone should take every kind of meeting. A page can offer several meeting types, each with its own length, buffer and notice period, and each type can be restricted to specific members of the pool. Leaving every box unticked on a type means the whole pool is eligible, which is the default. This lets one page offer a quick intro call to anyone and a technical session to specialists only.

What happens with an empty pool

Round-robin applies only when the pool has at least one enabled member. With an empty pool, or with round-robin off, every booking goes to the page owner. The fallback is deliberate: a page that silently accepted nothing because the pool was empty would be worse than one that falls back to its owner.

Checks before launch

• Set the page time zone. A page without one is read as UTC, which is rarely intended.
• Test the page with each member's calendar to see that busy times hide the right slots.
• Review the by-host breakdown in the booking analytics after the first weeks to see that the load matches the weights.
• Decide who tells guests when a host cancels, and how the booking is reassigned.