How to audit round robin meeting distribution with analytics

To audit round robin meeting distribution, compare each host's bookings with what your routing rules should have given them, based on who was available at the time. A plain count of meetings per rep can't tell you if anything went wrong. You need the rules, the eligibility and the dates behind the count.

Say Maya got 54 demos last quarter, Omar got 34 and Nina got just 12. That looks lopsided. But Nina was on leave for part of the quarter, and the team gave each rep a different weight on purpose. Once you allow for both, the split is within one meeting of what the rules intended.

This guide walks through that audit with the same example throughout. Start with context, then outcomes, so you don't break a working setup to fix a misleading report.

Decide what question the audit should answer

Round robin data can answer separate questions. An allocation audit asks if bookings followed your rules. A workload review asks if each person's load is manageable. A performance review asks how well people run their meetings. Keep them apart, because one leaderboard that mixes them leads to bad calls.

Then decide what fair means for this pool. Equal totals suit hosts who are interchangeable and keep similar hours. Weights create unequal totals on purpose, say when a senior rep takes half the load. Routing to whoever is free next favors speed over an even split. If you're still choosing, compare weighted vs equal round robin scheduling.

Before you pull any data, write down the meeting type, the routing pool, the date range, the rule settings in force and who approved them. Count original bookings created in that period. Keep later host changes and outcomes attached to each booking, but count them separately from the first assignment.

What data you need for a round robin audit

Treat that table as a wish list, since not every scheduler exports all of it. Today's calendars also can't show who was free for a booking six weeks ago. Without that history, you can describe the split you see, but you can't replay every routing decision.

Don't fill the gaps with guesses that happen to explain the result. Mark unknown eligibility as unknown. An honest partial audit beats a precise-looking fairness score built on invented history.

Work out each host's fair share of weighted round robin meetings

One way to build an expected count with weights: for each booking, list the hosts who could take it. Divide each host's weight by that group's total weight to get their share. Add the shares across all bookings to get each host's expected total.

This method fits only if sharing in proportion to weight is the rule you agreed on. Strict rotation, priority routing, caps and counter resets may need a different check. The example below is a reference model, and it doesn't claim to copy Caletus's internal routing logic.

In the second period, the available weight adds up to 80. So Maya's share becomes 50 ÷ 80 = 62.5%, and Omar's becomes 30 ÷ 80 = 37.5%. If you judged Nina against a flat target of 20 bookings (20% of 100), you'd be ignoring her leave.

Only count bookings that actually happened. If someone tried to book and no host was free, that belongs in a separate availability report. Don't hand those attempts to an imaginary host to make the numbers balance.

Compare who got meetings with how those meetings went

Maya got 54% of bookings, Omar 34% and Nina 12%. Against the leave-adjusted numbers, Maya is one under, Omar one over, and Nina right on target. Gaps that small don't prove a bug, and they don't prove the routing is perfect. You'd still check how the routing works and how much drift it allows.

Completion is a separate measure. Divide completed meetings by assigned meetings. Maya is 43 ÷ 54, about 79.6%. Omar is 27 ÷ 34, about 79.4%. Nina is 9 ÷ 12, or 75%. Canceled bookings count in the total here, so these are completion rates, and they'll be lower than attendance rates.

Be careful with Nina's small sample. One more completed meeting would move her rate by about 8.3 percentage points. Nothing in these numbers shows that one host is better, got better leads or deserves a different weight.

If every booking is 30 minutes, the scheduled time works out to 1,620 minutes for Maya, 1,020 for Omar and 360 for Nina. That's planned meeting time. It doesn't capture prep work or anyone's total workload.

Check the usual causes before you change weights

Most uneven splits have an ordinary cause. Look for approved leave, different working hours, a disconnected calendar, event-specific eligibility and meeting caps. Check when the settings changed, too. A rep who joined the pool halfway through the quarter didn't get the same chances as someone who was there all along.

If one person almost never gets picked, work through the round robin unavailable host checklist before you touch any weights. A broken calendar connection looks a lot like unfair routing in a report.

Compare like with like. A specialist who takes fewer, longer technical sessions has a different workload from a generalist running short demos. Match the meeting types before you turn a booking count into a staffing decision.

Cancellations can change a report without changing the original assignment. Keep canceled bookings in the original assignment group and report their outcome separately. Some schedulers count a canceled booking toward the next turn and some don't, so check how yours works before you draw conclusions.

The same goes for manual reassignments. If a manager moves a meeting from Omar to Maya, record both names. The first host tells you how the routing behaved. The final host tells you who actually did the work.

Start with Caletus's round robin scheduling analytics

Caletus can route round robin meetings by availability, equal load, priority or custom weights. Each one leads to a different fair split, so check which one your pool uses first. The round robin scheduling feature page explains the options.^[1]

Caletus's scheduling analytics page describes host and outcome comparisons, plus data you can export. Look at which fields the export includes before you build your own leave-adjusted report.^[2]

Start small: one event type and a few dozen bookings you can check by hand. Compare the original records with the host totals on screen, then look at changes and outcomes. If the export doesn't show who was eligible at booking time, say so in your write-up.

Label your expected counts and formulas as your own calculations. They're useful, but they aren't built-in Caletus metrics.

Look into one mismatch at a time

Pick one host or one booking that looks wrong. Check the rule, who was eligible and what the calendar showed at the time. Then ask where the problem sits: the rule, the data, the setup or the way the report defines things. Only then think about changing the routing.

If you think you've found a bug, send support the event, the booking time, the first host, the rule in force, who should have been eligible and what actually happened. Use anonymized examples through your usual support channel. Leave out candidate or customer details that aren't needed to show the problem.

If you find a real capacity mismatch and change the weights, write down the new weights and the date they took effect. Check a later period with the same method, and allow for changes in staffing and demand. A better split after the change doesn't prove the change caused it.

Say how complete your data is

Every audit should say how much of the history it could actually check. Note whether first-host records, rule versions and booking-time eligibility are complete, partial or missing. If only a small slice of the quarter is well logged, make that limit obvious before you give a verdict on the whole period.

Sort what you found into three groups: facts you can see, explanations backed by records, and ideas you still need to test. "Nina got fewer meetings" is a fact. "Nina was excluded during approved leave" needs dated proof. "The routing ignored her weight" needs a repeatable test of single booking decisions, because one odd total won't show it.

Keep a short audit note with the question, the bookings you checked, the data gaps, the finding, the next step, the owner and a review date. The next person who looks at the pool will see why things changed instead of guessing.

A repeatable checklist for scheduling fairness

1. 1Confirm the event type, pool, rule settings, date range and time zone.
2. 2Separate the first host from the current host for every booking.
3. 3Rebuild eligibility only where records support it, and mark the rest unknown.
4. 4Allow for leave, different hours, caps and rule changes.
5. 5Match host totals to original bookings, and keep cancellations in the assignment history.
6. 6Review completion, meeting length and reassignments apart from the split itself.
7. 7Write down the finding, an owner and a follow-up check before you change any settings.

A busy sales team might run this weekly. A smaller pool may need a month or more of data. Fix urgent failures right away, such as a host who's been skipped for days, and don't turn the review into a contest over tiny samples.

Fair round robin meeting distribution is a policy choice backed by evidence. A good audit explains the split you see and points to a sensible next step, even when the chart isn't perfectly even.

• round robin analytics
• host distribution audit
• weighted meeting routing
• scheduling fairness