Booking: Availability, Teams and Routing How bookable hours are derived from your hubs, how to group who takes bookings, and how to send bookers to the right person.

The other three configuration sections of the Booking Engine. Event Types define what can be booked; these define when, by whom, and how the right person is chosen.

Availability

The bookable window for an event type, derived from your team's hub hours rather than set separately here.

This is the important thing to understand: availability is not a calendar you maintain in the booking engine. It comes from the hub each person belongs to - its business hours, its working days and its timezone. Change a hub's hours and booking availability follows.

Two consequences worth knowing:

• A hub with wrong hours produces wrong availability. If your Dubai hub is set Monday to Friday when the team works Sunday to Thursday, the booking page offers Fridays and hides Sundays. Fix it in Hubs, not here.
• Multi-hub teams work correctly by default. A booker sees slots in their own timezone, resolved against each person's hub, so a London customer booking a Dubai team member sees the right hours without anyone doing arithmetic.

Buffer time from the event type is applied on top.

Teams

Who takes bookings, and how they are grouped. A team is the pool an event type draws from.

Keep pools honest. Someone in the pool who never actually takes these calls creates gaps that look like availability - the slot is offered, the booking lands, and it goes to someone who cannot help.

When somebody leaves or changes role, removing them from booking pools is easy to forget and produces exactly this failure. Add it to your offboarding routine.

Routing

Send bookers to the right person using qualifying questions, rather than making them choose from a list of names.

The principle: the booker answers a question they can answer, and the platform decides who that means. A booker knows they need help with pricing; they do not know which of your five account managers covers their segment.

1. Ask a question the booker can answer - what they need, roughly how big they are, which product.
2. Map each answer to the team or person who should take it.
3. Set a fallback for answers that match nothing.

Always set a fallback. Routing with no fallback drops the bookings that do not match any rule, and those are disproportionately the unusual ones - which are often the interesting ones.

Assignment Logic

Once routing has chosen a pool, assignment logic picks the person. Round robin rotates fairly through the pool.

Fair rotation is right when everyone in the pool is interchangeable. When they are not - different specialisms, different languages, different territories - do that split in routing rather than hoping rotation lands well.

Insights

Booking volume, conversion and no-show analytics.

The number to watch is no-shows. A rising no-show rate usually means the gap between booking and meeting is too long, or the confirmation is not setting expectations. Both are fixable: shorten the bookable window, or rewrite the event type's description.

Conversion tells you whether the bookings are turning into anything. High volume with low conversion means the booking page is attracting the wrong people, which is a routing or a messaging problem, not a capacity problem.

Common Questions

Someone's slots are wrong. Check their hub's business hours, working days and timezone. Availability derives from the hub.

Can a person be in two teams? Yes. Watch their total load - two pools means bookings from both.

A booker got the wrong person. Either routing has no rule for their answer and they hit the fallback, or the pool contains someone who should not be in it.

Can I block a specific day? Time off is honoured through the calendar. For a permanent change, adjust the hub's working days.