Spots stay the workload measure. The new people number is the minimum humans needed if setup crews roll into service roles, which is the event's biggest time block.
A chip can carry more than one role per night. The + adds another role, and stacked chips get a teal outline so leaders can see who's pulling doubles. Your examples, as they'd appear:
Clicking + only offers roles in blocks the person doesn't already occupy. Same-block roles show up disabled with the reason, so nobody gets double-booked at 4pm.
Every stacked role fills a real spot, so the gap chips and the heatmap self-correct as admins record actual plans. Undo removes one role at a time.
Spots remain the fill target. The new people line stops the numbers from overstating the recruiting problem: 967 spots reads as 967 people, when the floor is 609.
| Coverage plan | Slots produced | vs 967 spots | vs 609-person floor |
|---|---|---|---|
| FT staff × 3 nights (current expectation) | 645 | short 322 | covers |
| FT × 3 + current volunteers | ~764 | short 203 | covers +155 |
| FT × 4 | 860 | short 107 | covers +251 |
If double-serving is normal (and your examples say it is), the existing 3-night expectation plus current volunteers already clears the realistic people bar. The recruiting push then becomes about the 4pm service block specifically, not 967 raw spots.
Build cost: dual numbers are a small display change. Multi-role stacking needs the database to allow one person in several roles per night (currently capped at one), the add-role menu above, and block-aware conflict checks. Roughly an hour of careful work, fully compatible with the existing sync and audit log. The public signup page stays as-is; stacking is recorded in this tool only.