When Allocation Does Not Behave
The owner in the rotation, load balancing that looks arbitrary, and commitments Zyntro cannot see.
Three causes between them explain nearly everything.
The owner is in the rotation unless you removed them. They appear in the member list already selected, so a calendar created without a thought about it allocates to its owner.
Round robin balances load, it does not take turns. A member with the fewest upcoming bookings is preferred, so runs of consecutive bookings to one person are expected.
Zyntro can only avoid commitments it knows about. A member whose real week lives in another calendar looks free.
Also worth knowing before you start: a refusal is usually correct behaviour. Zyntro declines a booking rather than assigning it to somebody who is busy.
Known Issues
One member is getting all or most of the bookings
Most often the strategy is Sequential, which always takes the first free member in list order — and the list starts with the owner. It can also be that the other members have little availability, so they are rarely free when a booking is made.
Switch the strategy to Round robin if you wanted even distribution.
If it is already round robin, compare the members' availability. Round robin can only choose among the free, so a member who is only free two mornings a week will receive proportionally fewer bookings however the rule is set.
Round robin is not alternating between members
It is not meant to. It picks whoever has fewest upcoming bookings on this calendar, which is load balancing rather than turn-taking.
Nothing to fix — look at a month rather than a handful of bookings. Someone back from leave, or newly added, has an empty diary and will take several in a row until they are level. That is the mechanism correcting an imbalance, and it is why distribution evens out over time rather than per booking.
The owner keeps being allocated bookings
The owner is in the booking rotation by default. They appear in the member list already selected.
Open the calendar's settings and deselect the owner in Allowed Members in the Group. They remain the owner with full visibility and configuration rights, and stop receiving bookings.
If they are the only member, Zyntro will continue to allocate to them regardless — a group calendar is never left with nobody to allocate to, so add the other members first.
A booking was refused saying no team member is available
Nobody eligible was free for that exact slot at the moment the booking was submitted. Usually someone took the slot in the time between the visitor opening the page and completing the form.
This is correct behaviour and no action is needed for a one-off. If it happens often, the team's combined availability is too thin for the volume you are getting — widen the availability windows, add a member, or reduce the daily cap so the page offers fewer, more reliable times.
A member was allocated a meeting they could not take
The commitment that should have blocked them is not visible to Zyntro — typically it lives in a personal Google or Outlook calendar that has not been connected.
Have each member connect their own calendar so their outside commitments count as busy time here. That is the single most effective fix for allocation quality.
Failing that, members need to keep their commitments on a Zyntro calendar, since only what Zyntro can see removes availability.
Allow Booking with Specific Member appears to do nothing
On a booking page or a form, it genuinely does nothing as of October 2026 — the booking page offers no way to choose a person, and a form sends no preference, so the strategy always decides.
If a particular person's time needs to be bookable directly, give them an individual calendar alongside the group one and share that link where it matters.
The setting does take effect for bookings created through Zyntro's Create Event API, which accepts a member.
A specific member was requested and the booking failed rather than going to someone else
An explicit member request is honoured strictly. If that member is not free for the slot, the booking is refused rather than quietly reassigned.
That is deliberate — someone who asked for a named person should not silently be given somebody else. Offer them another time with that member, or book them onto the general rotation instead.
A member on two group calendars got double-booked
They should not be. A booking where someone is the host blocks them everywhere, including on other group calendars.
Check that both meetings really are bookings allocated to them, rather than one being an event created by someone else without them attached as host. If a commitment does not name them, it cannot protect them — the fix is to make sure they are on the meeting rather than merely implied by it.
Two different people booked the same time slot
On a group calendar this is intended. One slot supports as many bookings as there are free members, which is the reason to pool a team.
If a slot should only ever be taken once, that is an individual calendar, or a group calendar with a single member in the rotation.
A member was removed but still has bookings
Removing a member changes who receives future bookings. It does not move meetings they already have.
Reassign or cancel their existing meetings deliberately. For anything a customer booked, use the cancel or reschedule route so the customer is informed rather than silently moved.
Bookings through a form ignore the form's own lead routing
A group calendar attached to a form decides the owner, and that takes precedence over the form's routing settings.
This is intended: the person who has to attend the meeting should own the lead. If you need different behaviour, the Forms documentation on lead allocation sets out the full order of precedence.
Troubleshooting Guide
Is the problem that bookings go to the wrong person?
Is distribution uneven rather than wrong?
Was someone allocated a meeting they could not take?
Frequently Asked Questions
The meeting on the calendar carries its host, and the resulting contact belongs to that member. If a booking came through a form, the completion records who it was assigned to and why.
No. It only affects bookings made from that point on. Existing meetings stay with whoever has them.
Not through the strategy. The practical approach is an individual calendar for that person, shared directly.
Because they also have to be free for that slot. Availability is filtered before the strategy is applied, so a less busy member who is occupied at that time is not a candidate at all.
No. A cancelled booking stops counting towards load, so that member becomes a more likely candidate again.
