Bunk and roster assignments: buddy requests, age groups, and the logic underneath

Bunking is the puzzle that arrives every season looking deceptively small and turns out to have the most moving parts. A spreadsheet of camper names, a wall of sticky notes, and a stack of buddy requests — half of them naming a camper who is in a different age group, the wrong gender for the cabin, or already in a bunk that’s full. The job is to place every camper somewhere that honors as many requests as the real constraints allow, and then to keep that placement honest as campers arrive, leave, and move between sessions.

This is a guide to assigning bunks against buddy requests, age groups, gender, and capacity — and keeping the roster current once camp is underway. Bunking is part of summer camp operations, and it reads off the same camper record as registration and medical.

Buddy requests start at registration

The bunking puzzle is easier to solve when the inputs are clean, and the cleanest place to collect a buddy request is during registration, while the family is already filling out the rest of the camper’s record. A parent names the camper their child wants to bunk with, and that request rides on the camper record from then on.

The detail that saves real grief is collecting the request as a structured pick rather than a free-text note. When a parent types “Sam” into a box, the camp is left to guess which Sam — and a session can hold more than one. When the parent picks the actual camper from a session-scoped list, the request points at a specific camper record, not a name that may collide. Camp Runner supports both, but the structured pick is the one that removes the guesswork before it reaches the bunking board.

The strongest signal is a mutual request: camper A names camper B, and camper B names camper A. That pair wants to be together, both sides agree, and honoring it is rarely a hard call. A single-sided request — A wants B, but B named someone else — is a softer preference the camp weighs against the others. Seeing which requests are mutual and which are one-way, before any placement happens, is the difference between honoring the requests that matter and chasing every name on the list.

Age groups and capacity are the constraints

A buddy request is a preference. Age groups, gender, and cabin capacity are limits — and the limits win. Most camps define age groups as bands by age, and want a cabin to hold one band rather than mix the youngest campers with the oldest. Gender draws its own line for most cabins. Capacity is the hard ceiling: a bunk holds the number of beds it holds, and no request changes that.

These constraints are why bunking is a puzzle and not just a sorting job. A buddy request that crosses an age group, puts two campers of different genders in the same cabin, or asks for a bed in a full bunk can’t be honored as written. The useful move is to see that conflict early — the request and the limit it collides with, side by side — so the director makes a deliberate call rather than discovering the collision at move-in. Age groups also carry a color through the bunking views, so a camper sitting in the wrong band is something you can see at a glance rather than something you have to check.

Build bunks against the preferences without breaking the count

With requests collected and constraints defined, the placement itself can start from a proposal instead of a blank grid. The camp picks the grouping axis — age group, grade, or age — decides whether to split by gender, sets each cabin’s capacity, and adds any hard rules: must-pair to keep two campers together, must-not-pair to force two apart. From there the system proposes an assignment that honors mutual buddy requests and the hard rules where the constraints allow, and packs cabins without exceeding capacity.

The honest part of an automatic proposal is what it does with the campers it can’t place. A camper whose only buddy request crosses an age line, or who’s pinned to a full cabin, can’t be slotted in without breaking a rule — so rather than forcing a bad placement, the system sets that camper aside and surfaces them as a short list to resolve by hand. The proposal is a draft the director reviews, adjusts, and re-runs, not a final answer handed down. You keep the judgment calls; the system does the bookkeeping of who fits where.

Moving a camper keeps the roster honest

No bunking plan survives contact with the actual campers. A family adds a sibling, a camper switches sessions, two kids who were going to room together have a falling-out the week before camp. The plan has to change, and the danger in changing it is the count — move a camper in one place, forget to update another, and the roster and the reality drift apart.

The fix is to move the camper on the same roster the whole camp reads, so the count follows the move automatically: the cabin they left drops by one, the cabin they joined gains one, and neither number has to be edited by hand. Each cabin shows filled-against-capacity as you go, so a move that pushes a bunk over its limit shows up the moment it happens — over capacity, at capacity, or with room to spare — rather than as a surprise when the beds run out. The move is a single action with a count that stays correct, not a change you then have to reconcile across a spreadsheet and a whiteboard.

The roster the whole staff reads from

A bunk roster is only useful if everyone is reading the same one. The version that matters is the current version — and when the assignment, the buddy requests, the age groups, and the staff coverage all live on one bunk record, current is the only version there is. The counselor assigned to a cabin is assigned to the actual campers in it, not to an abstract slot someone later maps to a real group.

That shared record is also where bunking meets staffing. The cabin a camper is assigned to is the same cabin your staff scheduling and bunk coverage puts counselors on, so a roster change and a coverage change read off the same structure instead of two ledgers you keep in sync by hand. And the bunk a daily headcount counts is the same one check-in and check-out work against, so the roster that bunking produces is the roster the rest of the day relies on.

Where one system earns its keep

You can bunk a camp with a spreadsheet and a wall of sticky notes. Plenty of camps do, and it works until the season it doesn’t — the buddy request honored for the wrong Sam, the cabin quietly two over capacity, the move that updated one list but not the other. The cost of the sticky notes is that each one holds a fragment, and you are the one reconciling them, by hand, under move-in pressure.

When buddy requests, age groups, gender, capacity, the assignment, and the staffing all sit on one bunk record inside one system, bunking is a puzzle you solve once and then edit — not one you redraw every time something changes. The mutual requests are visible, the constraints are enforced, the count stays honest through every move, and the roster the staff reads is the roster that’s actually true.

You run the bunking. Camp Runner lets you honor the requests that matter, keep the constraints enforced, and hold the roster current as the season moves. Bunk and roster assignments are one piece of summer camp operations kept on the camper record. If that is the season you want, join the waitlist.