There are two ways to put more than one person behind a booking link, and every tool names them the same way. Round-robin. Collective. The dropdown offers both and explains neither.
The difference is one word, and the word is in neither name. Round-robin availability is a union. Collective availability is an intersection. Everything else follows, including the part that catches teams out in week two.
What each one puts in front of the booker
Stand where your customer stands: a grid of times, some of them clickable.
On a round-robin event type, the booker sees every time at least one person in the pool is free. Five ordinary calendars produce a page that looks almost completely open, because a slot needs only one of the five. The tool assigns a host when the booker picks a time. The booker never learns there was a pool.
On a collective event type, the booker sees only the times everybody is free at once. Three hosts, one time, all three in the room. A shorter list, and a meeting your side is actually all in.
Round-robin answers "can somebody take this?". Collective answers "can all of us?". The names describe the rota. The behaviour is set theory, and the set theory is what bites.
The intersection collapses, and faster than anyone expects
This is the part that settles most of these arguments, and the part nobody writes down. Take one working day, nine to five, and three people who would each call it a normal day. The numbers are illustrative: I made them up to make the shape visible, not to report anything about your team.
- Alex is free 09:00 to 11:00, 12:00 to 13:00 and 15:00 to 17:00. Five free hours out of eight.
- Priya is free 10:00 to 12:00, 13:00 to 14:00 and 16:00 to 17:00. Four free hours out of eight.
- Sam is free 09:00 to 10:30, 11:00 to 12:30 and 14:00 to 16:30. Five and a half free hours out of eight.
Alex and Priya first. Overlap those windows and two survive: 10:00 to 11:00, and 16:00 to 17:00. Alex's lunch ends exactly where Priya's begins, and their afternoons miss each other by a full hour. Two people each free for most of the day have two mutual hours.
Now add Sam, the most available of the three. Intersect the survivors with Sam's windows and you keep 10:00 to 10:30 and 16:00 to 16:30. Three people with five, four and five and a half free hours have one mutual hour, in two half-hour pieces.
Then the meeting length decides whether that hour is worth anything, because free time does not add up unless it is contiguous. A thirty-minute meeting has exactly two bookable starts: 10:00 and 16:00. A sixty-minute meeting has none. Not fewer. None: neither piece is an hour long.
Buffers finish the job quietly. Ten protected minutes either side means the 10:00 slot must keep 09:50 to 10:40 clear, and Sam has something at 10:30. The 16:00 slot needs 15:50 to 16:40, and Sam has something at 16:30. Both go. The day is empty, and every calendar in it still looks more free than not.
The general shape: each host added to a collective event type multiplies availability rather than adding to it, and the multiplier is never above one. One host to two is the biggest single drop. Two to three usually decides whether the event type is usable at all.
Adding a host to a round-robin event type buys you availability. Adding one to a collective event type spends it.
Which one you actually want
One question settles it: does it matter which person shows up?
If the answer is no, use round-robin. An inbound intro call, a support session, a demo from a bench who all give the same one, a first-round screen. The prospect wants half an hour with your company, not a named individual. Round-robin keeps the page full and spreads load without a rota to maintain.
If the answer is yes, use collective and accept the cost. A founder plus the engineer who will build the thing. An account manager plus the specialist who can answer the question that killed the last call. An interview panel, where the point is four people hearing the same answers at once. The combination is the meeting, and a tool that quietly picks one of them has booked the wrong one.
The two are not exclusive, and the good setup is usually both: round-robin on the front door so a stranger can always find a time, collective on the second meeting where the deal needs the technical person. If the front door carries volume, fix who gets through it first, which is qualifying leads before they book.
The case teams get wrong
Two hosts, one of whom is only sometimes needed. The instinct is collective, because both names belong on the meeting. Collective then intersects a calendar that did not need intersecting, halving availability for somebody who attends one call in four. Mark them optional rather than required if your tool draws that distinction, or run round-robin and add them by hand when a call warrants it.
What "several hosts on one event" becomes on the calendar
This is where tools genuinely differ, it is never in the feature list, and almost nobody checks before buying. "Multi-host" covers three outcomes.
- One event, everybody an attendee. Every host on the guest list, nobody optional, everybody actually asked to respond. They can decline. Edit the time once and it moves for all of them, because there is only one thing to move.
- One host's event, the others notified. It belongs to one person. The rest are CC'd, added as optional, or auto-accepted into a meeting nobody asked them about. Identical in a screenshot, different the moment one of them has a conflict.
- Separate events on separate calendars. One per host, written in parallel, sharing no identity. They agree on the day they are created and desynchronise the first time anybody edits one, which ends with two people certain of different times.
One hard constraint sits underneath this, worth knowing before you judge a vendor for it: a Google Calendar event has exactly one organiser. That is the Calendar API, not a preference anybody can configure away. A product claiming several organisers is either writing duplicates or overstating. The correct implementation is one event on one connected calendar, with every host, including the account that created it, a full attendee carrying the same flags as everyone else.
How to check it, in about four minutes
- Book a real meeting on your own collective event type, with a colleague as second host.
- Open it in their calendar. Are there Yes, No and Maybe buttons, or was it accepted on their behalf? Someone never asked is an audience, not a host. Check whether they are marked optional too.
- Move the meeting in the scheduler and look at both calendars. If only one moved, there were two events all along.
- Cancel it, and see whether the withdrawal reaches everybody the way the invitation did.
Plenty of schedulers get this right, so it is less a competitive point than a thing worth verifying yourself. The Setupp integrations page sets out the flags it sends, down to optional: false and responseStatus: "needsAction", the two that decide whether a host is a guest or a spectator.
An empty collective calendar is usually working correctly
The ticket reads "the booking page shows no times". Most of the time the page is right, and the honest answer is that there are no times.
Three fixes, and each is a trade you have to actually make rather than a setting that makes the problem disappear.
- Shorten the meeting. Halving the duration turned an unbookable day into two usable slots above. Thirty minutes intersects far better than sixty, fifteen better again. The cheapest fix, and the one teams try last.
- Widen the window. More days searched, more chances at an overlap. It also means the meeting is a fortnight away, which for an inbound lead is worse than sending one host now.
- Require fewer hosts. Every host dropped from the required list is a multiplier removed. Ask whether the third person attends because the meeting needs them, or because they were on the last one.
Rule one cause out first: a host whose calendar is not connected. A scheduler that reads an unreadable calendar as wide open will offer times that person is busy. One that reads it as unknown offers nothing. Both are defensible, both are invisible from the booking page, and a collective event type only tells the truth once every required host is connected.
Where Setupp sits on this
Both shapes are a setting on the event type rather than two products. Collective offers only the times every required host is free. Round-robin offers any time one of them is, and puts that host on the booking. It is included from the Team plan upwards rather than on every tier, worth knowing before you plan around it.
The calendar write is the first shape above: one event, every host an attendee with optional: false and a response genuinely requested, the booker on the same guest list, and the invitation delivered by Google or Microsoft rather than by us.
The part that is actually different is the invoice. A host is a workspace setting here, the way a calendar connection is, rather than a seat bought per person. That matters most in exactly this case: a collective event type needs several people by definition, and under per-seat pricing three people in one meeting means three subscriptions a month. The arithmetic is in what per-seat pricing really costs a team.
None of which changes the set theory. Before building a process on a collective event type, open two of the calendars side by side and find the overlap by hand. If it is thin on paper it will be thin in the product. No scheduling tool has ever created time that was not already there.