Round-Robin Scheduling: Distribute Bookings Across the Team Without a Bottleneck

Every team that grows hits the same wall: scheduling still runs through one person. One link, one calendar, one bottleneck. As demand rises, the waitlist grows, leads go cold, and bookings pile up on whoever answers fastest — overloading some people and leaving others idle. Round-robin fixes this by distributing bookings across the team automatically, with no one manually deciding who handles whom.

One calendar is a bottleneck

When a multi-practitioner clinic, a sales team, or a recruiting function uses a single shared calendar, three things happen:

1. Capacity is capped at the busiest person. If the senior practitioner's calendar fills up, the whole link looks "fully booked" — even if three colleagues are free in the same window.
2. Distribution becomes a lottery. Whoever shows up first grabs the best slot; whoever distributes contacts relies on someone's memory and goodwill.
3. Response time spikes. Every request waits for a manual triage before it becomes a confirmed meeting.

None of these problems are about staffing. They're about routing. The team has capacity — it just isn't being used in a distributed way.

What round-robin means, in plain terms

Round-robin is automatic rotation. Instead of a booking always landing on the same person, it's assigned to the next available team member, in turn. The guest picks a time; the system decides which member gets that meeting — no spreadsheet, no internal "can someone take this?" message.

In practice, it turns the question "who's free, and why did this land on me again?" into an automatic, predictable answer.

How round-robin works in Calendinho

In Calendinho, an event type has a scheduling type (scheduling_type), which can be individual, collective, or round-robin. When it's round-robin, the event no longer belongs to a single person — it's served by a set of hosts.

That set is built from host slots, and each slot has a kind:

• Fixed slot — pins one specific person to that role. Use it when a position always needs the same person: the responsible doctor, the sales manager who joins every closing call, the required technical interviewer.
• Pool slot — defines a group of members who rotate among themselves. Use it when the role can be filled by anyone on a team: any qualified SDR, any physiotherapist at the clinic, any recruiter on the screening rotation.

A single event can combine both. For example: a discovery call with a fixed slot for the account manager plus a pool slot that rotates among three product specialists. The guest books once; Calendinho assembles the meeting with the fixed person and the next one up in the pool.

Configurable distribution

Each pool slot has a configurable distribution that decides how the rotation picks the next person. Calendinho's data model today supports two strategies:

• One that prioritizes filling the calendar — useful when the goal is to respond as fast as possible with whoever is available.
• One that balances the load across pool members — useful when fairness and an even split of commissions/cases matter more than raw speed.

Choosing between the two is an operations decision, not a technical one: you decide whether what matters for that event is responding fast or splitting evenly.

The shared link: /m/{public_token}

An important operational detail: individual event types live on a person's public link (/your-name/chat). But a round-robin event isn't "one person's" — it's served by several hosts.

For that, Calendinho generates its own shared link, in the form /m/{token}. That token is created by the system when the event is created and acts as the single, stable address for that team booking. You share one link — in your email signature, on the site, in a campaign — and the rotation happens behind it, invisible to whoever is booking.

The guest never needs to know who's "next in line." They see an available time, book it, and get an email confirmation with the right person already assigned.

Who benefits from round-robin

Multi-practitioner clinic

A clinic with five physiotherapists (or psychologists, or dentists) doesn't want the patient to pick "which practitioner" before seeing a time — it wants to fill the whole team's calendar. A round-robin event with a pool of all five distributes first appointments evenly and keeps every calendar full, with no front desk triaging by phone.

Sales team

A lead who fills out a form and books a demo needs a fast response and a clear owner. A round-robin event with a pool of SDRs auto-routes to the next person in line. Nobody asks "whose lead is this?" in the internal chat, and no lead sits waiting for someone to "grab it."

Recruiting

Initial screens scale poorly when they depend on one person coordinating calendars. With a pool of recruiters, the candidate books the screening interview and the system distributes it across the team. For technical stages, a fixed slot ensures the right specialist interviewer is always present.

Agency

An agency offering "talk to a specialist" doesn't want everything concentrated on one person. A fixed slot for the account manager plus a pool of specialists ensures relationship continuity and load distribution across the technical team — in the same booking.

Fairness and speed aren't details — they're revenue

Round-robin's two gains have a direct impact on results, and a simple calculation makes it visible.

Fairness (even split). Picture a pool of 4 reps and 80 meetings a month. Without rotation, it's common for 2 people to concentrate ~80% of the meetings because they respond faster or are more "on hand." With balanced distribution, each gets ~20 meetings. The effect isn't only morale: overloaded reps prepare worse for each call, and idle reps lose rhythm. Balancing the load tends to raise the average execution quality of the whole team.

Illustrative example (labeled assumptions, not a market figure): a pool of 4 · 80 meetings/month · target of ~20 each instead of 48/16/10/6.

Speed (responding first). Consider 100 leads per month and a 25% conversion rate when the response is fast. If manual triage delays the booking and 15 of those leads go cold before they schedule, that's ~4 deals lost per month from routing latency alone — not from lack of capacity. Round-robin removes the manual triage step: the lead books, the system assigns, the response goes out immediately.

Illustrative example (labeled assumptions): 100 leads/month · 25% conversion with a fast response · 15 leads lost to triage delay ≈ ~4 deals/month. Your numbers, not a market statistic — replace with your own operation's.

The takeaway is direct: every meeting waiting on a person to be distributed is parked revenue. Round-robin takes that person off the critical path.

How to get started

1. Create an event type and set its scheduling type to round-robin.
2. Build the slots: a fixed slot for every position that always needs the same person, and a pool slot for every role any member of a group can fill.
3. For each pool slot, choose the distribution — prioritize availability (respond fast) or balance the load (split evenly).
4. Share one shared link (/m/...) in your signature, on the site, and in campaigns.
5. Let the rotation run. Confirmations go out by email with the right person already assigned.

Worth noting what exists today: booking confirmations and notifications are by email. WhatsApp notifications are on the roadmap, not yet available.

To go deeper on scaling beyond one-to-one, see also scheduling group classes and cohorts and the Calendinho vs Calendly comparison.