Rotating meeting facilitator calculator
With Alice, Bob, Carol and Dana on the list, the first meeting (number 0) goes to Alice, Bob is next and Dana went before; after Dana the cycle starts again. Everyone using the same list gets the same answer. Free in your browser.
- Free
- Runs in your browser
- No sign-up
- Your data stays on your device
Run — free
Worked example
- Roster
- Alice, Bob, Carol, Dana
- Meeting index
- 0
- Roster size
- 4
- Owner
- Alice
- Owner index
- 0
- Cycle position
- 1
Recurring standups, all-hands, and ops reviews work better when facilitation rotates fairly instead of defaulting to the same manager every week. This rotating meeting facilitator calculator takes an ordered roster of names and a zero-based meeting occurrence index, then applies classic modular round-robin arithmetic so you always know who owns the next session, who follows, and who came before in the cycle. Teams embed the same deterministic contract in bots, calendars, and runbooks without inventing ad-hoc spreadsheet formulas that drift when someone joins or leaves.
How round-robin meeting ownership works
A fair facilitator rotation is nothing more than a fixed ordered list of people and a counter for how many times the meeting has already run. When the counter reaches N, the remainder wraps to zero and the first person facilitates again; when it reaches N plus one, the second person takes the chair, and the pattern continues forever without special cases for leap weeks or calendar months.
Because the formula uses only integer division remainder, two clients that share the same roster order and the same occurrence counter will always agree on the same owner even if they run in different time zones or offline. The capability does not invent holidays, vacations, or skip lists: if someone is out, edit the roster or bump the index in your orchestration layer. Keeping the core pure means chatbots, GitHub Actions, and spreadsheet plugins can reuse one oracle instead of re-coding modulo logic in three languages.
When a rotating facilitator helps most
Engineering managers schedule weekly demos and want the host to rotate without a private spreadsheet that only one person updates. Scrum masters automate standup facilitation so the same senior engineer is not forever running the clock. Incident commanders rotate weekly on-call ceremony ownership with a roster that matches the schedule document.
HR and people-ops teams assign monthly all-hands hosts fairly across departments.
What you can do with it
Weekly standup host rotation
Pass the team roster and the standup week counter to print who facilitates today’s stand-up and who is next, without a shared spreadsheet.
Fair all-hands and demo hosts
Rotate monthly all-hands or demo hosts across departments using the same ordered roster your handbook already publishes.
FAQ
What if someone is on vacation?
This calculator does not model absences. Temporarily remove them from roster or skip their index in your orchestration layer before calling.
Who facilitates after the last person on the list?
The rotation starts again with the first name. With Alice, Bob, Carol and Dana, the fifth meeting goes back to Alice, and the same order repeats with no special cases for months or unusual weeks.
Why does the first meeting count as zero?
Because the counter records how many meetings have already happened. The first meeting is number 0 and goes to Alice; the result also shows the position in the cycle counted from 1, such as 1 of 4, so it reads naturally.
Does it also show who is next and who went before?
Yes. Along with today's facilitator you see the next one and the previous one. For the first meeting that is Bob next and Dana before, which helps when you need last week's notes.
What if someone joins or leaves the team?
Update the list in rotation order and keep counting meetings as before. Anyone using the same list and the same meeting number gets the same facilitator, so a shared calendar and a chat reminder never disagree.
Related tools
For developers — API access
Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.
API endpoint
Prefer to automate it? One authenticated POST creates the task; the result comes back by webhook or a signed link. The same capability also runs here on the web, by email and from Telegram — and soon from our app too.
Call it from your stack
curl -X POST https://api.kit.forhosting.com/biz/rotating-meeting-owner \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"roster":["Alice","Bob","Carol","Dana"],"meeting_index":0}'const res = await fetch("https://api.kit.forhosting.com/biz/rotating-meeting-owner", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"roster": [
"Alice",
"Bob",
"Carol",
"Dana"
],
"meeting_index": 0
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/biz/rotating-meeting-owner",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"roster": [
"Alice",
"Bob",
"Carol",
"Dana"
],
"meeting_index": 0
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/biz/rotating-meeting-owner", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"roster":["Alice","Bob","Carol","Dana"],"meeting_index":0}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"roster":["Alice","Bob","Carol","Dana"],"meeting_index":0}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/biz/rotating-meeting-owner", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Example request
{
"roster": [
"Alice",
"Bob",
"Carol",
"Dana"
],
"meeting_index": 0
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "biz.rotating_meeting_owner",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.
Pricing
Published price — no tokens, no invented credits. A failed task is never charged.
Errors
| HTTP | Code | Meaning |
|---|---|---|
401 | unauthorized | Missing or invalid API key. |
402 | insufficient_balance | Your balance doesn't cover the task price. |
404 | unknown_type | That task type doesn't exist. |
429 | rate_limited | Too many requests. Use the webhook instead of polling. |
Technical notes
Invalid empty names or negative indices fail with invalid_input and are not billed.
How round-robin meeting ownership works
Index the first occurrence as meeting_index zero, the second as one, and so on. If the roster has N people, the owner for that occurrence sits at owner_index equals meeting_index modulo N. Cycle position is reported as owner_index plus one so humans can say “third of four this cycle” without converting zero-based indexes by hand. Next owner is simply the name at owner_index plus one modulo N; previous owner wraps the other way, which is useful when you need to ping last week’s facilitator for notes.
Input contract, response fields, and validation errors
Optional output fields are never filled with null: every success field is always present for this simple contract. POST a JSON body with two required fields. roster is a non-empty array of one to one hundred facilitator name strings in rotation order; each entry is trimmed, and blank strings after trim are rejected as invalid_input naming the bad index. meeting_index is a non-negative integer from zero through one billion identifying which occurrence of the series you are resolving—zero is the first meeting. Aliases members, people, and facilitators are accepted for roster, and index, occurrence, and week_number for meeting_index, so existing automation can map familiar keys without renaming payloads. On success the body echoes the normalized roster and meeting_index, roster_size, owner and owner_index, cycle_position (one-based within the cycle), next_owner and next_owner_index, previous_owner and previous_owner_index, plus a short formula string stating owner_index equals meeting_index mod roster_size. Example: roster Alice, Bob, Carol, Dana with meeting_index five yields owner_index one because five modulo four is one, so Bob facilitates, Carol is next, and Alice is previous. Missing roster, empty roster, non-array roster, non-integer or negative meeting_index, and oversized rosters all fail with invalid_input and do not consume balance.
Where a rotating facilitator API earns its keep
Product ops bots post “this week’s facilitator is …” messages in Slack or Teams by calling the API with the series index stored in a counter key. Keep the roster ordered the same way in every system of record, increment meeting_index once per occurrence (including skipped weeks if you still want the rotation to advance), and you get reproducible ownership decisions for calendars, runbooks, and edge workers without standing up a scheduling service of your own.
Integration use cases
Chatbot and calendar automation
Have a bot call the API each occurrence with the series index and post “facilitator: …” into Slack, Teams, or a calendar description.
Technical questions
How do I find whose turn it is to facilitate?
Send roster (ordered names) and meeting_index (0 for the first meeting). The owner is roster[meeting_index mod roster length].
Is meeting_index zero-based or one-based?
Zero-based: the first occurrence is 0, the second is 1, and so on. Cycle position in the response is one-based for display.
Can I pass members instead of roster?
Yes. Aliases members, people, and facilitators map to roster; index, occurrence, and week_number map to meeting_index.
What does the rotating meeting facilitator calculator cost?
The browser tool is free. API requests use prepaid KIT balance at $0.002 per successful call; invalid input is not billed.