RosterFlow
A scheduling tool that builds fair monthly rosters for 60+ volunteer musicians across 7 care homes, with backups and carpools built in.
The Problem
Music for the Golden Age is a volunteer group of 60+ musicians who play live shows at 7 long-term care homes across the GTA. Every month, we had to decide who plays which show, who drives, and who steps in when someone cancels, all by hand.
We were left cross-checking a chat, a spreadsheet and a list of rules to guess at a fair, workable schedule.
Approach
RosterFlow takes the upcoming shows, everyone’s availability and limits, and the group’s rules, then builds a draft schedule the coordinator reviews, tweaks and publishes. The pipeline runs in three stages: collect, build and review.
The build step is a constraint programming model made with Google OR-Tools. Musicians mark which shows they can make through self-service links, and nothing changes for them until the coordinator publishes.
Each show gets ranked backups, sized to the day. Cancellations usually come about two days ahead, so the first backup can be called in. A backup counts toward their monthly limit only if they are called in, and they play the songs they already know instead of taking over the cancelled musician’s songs.
Live demo: rosterflow-phi.vercel.app (made-up sample data that resets on refresh).
Outcome
RosterFlow now schedules 60+ musicians across 7 care homes, and the group uses it in real life. Adopting the backup policy raised the share of fully staffed shows from 77% to 96% in simulation, and carpool grouping cut the average number of musicians driving to each show from 8 to 3.
| Measure | Before | With RosterFlow |
|---|---|---|
| Shows fully staffed after cancellations | 77% (no backups) | 96% (with backups) |
| Musicians driving per show, on average | 8 | 3 (62% fewer vehicles) |
The fill-rate figures come from a Monte Carlo simulation of 5,000 runs with a fixed 1-in-8 chance that any musician cancels. They estimate the effect of the backup policy under that assumption and are not a measured season of real shows.
Personal Takeaways
Being part of the group meant I already understood the day-to-day constraints, like who needs a ride, why every show needs a pianist and how often people cancel. That helped me build a model that matches how the group actually works.
I treat every musician equally with no reliability scoring, and a backup only counts toward their monthly limit if they are called in. Those choices keep the schedule fair and easy to explain.
The public demo runs on made-up data that resets on refresh, so anyone can test it without exposing real musicians. Fixing the bugs that testing surfaced taught me what it takes to keep a live tool reliable.