A personal booking link works perfectly for one person and breaks the moment a second is involved.
The requests keep arriving at whoever’s link is published, that person becomes the bottleneck, and the rest of the team is idle while the calendar of one is full.
Fixing this is a configuration problem rather than a tooling one, and it has three moving parts that are frequently confused with each other.
| Mechanism | Answers | Use when |
|---|---|---|
| Round-robin | Which team member gets this? | Anyone on the team can handle it |
| Routing | Where should this request go at all? | Different requests need different people |
| Collective availability | When are several people free together? | The meeting needs more than one of you |
Teams usually reach for round-robin first because it is the simplest, then discover that it distributes the wrong things evenly.
Sending a technical question to whoever is next in rotation is fair and unhelpful.

Routing asks a short set of qualifying questions on the booking form and sends the request to the right place based on the answers — region, product, company size, existing customer or not.
Configured with meeting routing, a request that needs a specialist reaches one directly instead of reaching a generalist who then has to rebook it.
Keep the form short. Every additional question costs conversions, and three well-chosen ones route more accurately than eight vague ones. Ask only what actually changes the destination.
Within a pool of people who can all handle a request, round robin scheduling distributes bookings across them.
Three details decide whether it feels fair:

Both mechanisms read from each person’s stated availability, and this is where most real failures originate.
A calendar that says free when the person is not produces bookings nobody can honour, and the fix is not in the scheduling tool.
Four settings in availability do most of the work:
Start narrow. Put one request type through routing, leave everything else as it is, and run it for two weeks.
Check three things: whether requests reached the right person, whether distribution was even, and whether anyone’s day became unworkable.
Then expand one type at a time. Teams that configure everything at once cannot tell which rule caused which problem, and the usual outcome is that the whole system gets switched off.

Someone owns the configuration — not everybody, one person. Changes to routing rules get announced, because a silent change looks like a bug to whoever stops receiving bookings.
Every pool has a fallback for when nobody is available, and the fallback is a person rather than an error message.
Done properly, none of this is visible to whoever is booking.
They answer two questions, pick a time, and speak to the right person. That is the entire objective; everything above is plumbing.