It’s January, and a family who sent two campers last summer opens this year’s registration. They know the drill, and they’re already braced for it: the same fifteen minutes of typing the same birth dates, the same allergy list, the same two emergency contacts they entered a year ago, into a form that has no idea they were ever here. Then a third camper. Then the sibling discount they have to remember to ask about, because last year somebody applied it by hand after the fact.
That re-keying is not a small annoyance. It’s the most predictable friction in the whole season, it falls on your most loyal families, and it produces wrong data — because a parent re-typing a birth date from memory at 10pm gets it wrong sometimes, and now your roster disagrees with last year’s. This is the part of camp registration software that decides whether coming back feels like coming back or like starting over. The fix is structural: the registration should remember the family, not make them reintroduce themselves.
Why returning families re-key everything in a stitched-together stack
The reason a returning family starts from blank every year isn’t carelessness. It’s architecture. When last year’s registration lived in one tool and this year’s lives in a fresh copy of that tool — or a different tool entirely — there is no shared record between them. The form doesn’t know this camper exists, because as far as the form is concerned, the season is the unit and each season starts empty.
So the family re-enters everything. The director, meanwhile, re-keys whatever arrives as a loose submission into the roster, exactly as they did the first time, with no credit for the fact that this camper has been here three years running. The data that should be the most stable thing you own — a returning camper’s name, birth date, school, allergies, the same two parents — is re-typed annually by two different people, and every re-typing is a chance to drift. A camp that keeps its families for years should be getting easier to run each season. On a stack with no memory between seasons, it gets exactly as hard every time.
Prefill: the record is the starting point, not a blank form
The alternative is to treat last year’s registration as a draft of this year’s. When a returning camper begins a new registration, their existing record comes forward as the starting point. The camper’s own fields — first name, last name, date of birth, gender, grade, school — are already filled from the camper row. Their most recent completed answers on each form are carried in, so a question they answered last season shows last season’s answer. Their medical information — allergies, medications, dietary restrictions, doctor — is there. Their saved contacts are there, primary first.
What the parent does is review and correct, not re-enter. Grade ticks up a year; a new medication gets added; the rest they confirm and move past. The work shrinks from “fill out the whole thing again” to “tell us what changed,” which is both faster for the family and more accurate for you, because confirming an existing birth date doesn’t introduce the typo that re-typing one does.
Two details matter for trust. Prefill only engages when the camper genuinely has a prior completed registration on file — a first-time camper still starts clean, with nothing borrowed from a record that doesn’t exist. And the prefilled values are a starting draft the parent edits, not locked-in facts, so the family stays in control of their own information. The point isn’t to assume nothing changed; it’s to stop pretending nothing is known.
Siblings link to the family, and the discount applies on its own
The second tax on returning families is the sibling math. A family with more than one camper should pay less on the additional camper, and on a manual setup that means someone cross-references every registration against the family behind it and applies the reduction by hand — which is tedious enough that it gets missed, applied inconsistently, or done from a list the director maintains of which families have two campers.
Done on the record, it’s automatic. The family’s campers are linked through the family relationships, so the system already knows which campers belong together. When a parent registers a second camper into a session, it checks the family’s other campers against that same session’s registrations. If a sibling is already enrolled there, the camp’s configured sibling discount applies to the new registration — no code to type, no eligibility for the family to claim, no list for you to keep. The family sees the reduced total at the moment it becomes true, and you didn’t calculate anything.
It’s worth being precise about what’s configured versus what’s automatic. You set the sibling discount once for the camp — the amount and that it’s active. After that, the detection and the application are the system’s job, every time a qualifying second registration comes through. The mechanism here is the same shape that governs promo codes, early-bird pricing, and sibling discounts across the board: a reduction that lives on the registration it reduces, so it reconciles against enrollment instead of surviving as a side note you square up at close.
The director’s view of who came back
Re-enrollment isn’t only the parent’s experience; it’s a thing the director has to manage. Which of last year’s families have come back? Which haven’t, and need a nudge before the early window closes? On a stack with no cross-season memory, answering that means exporting two lists — last year’s registrants and this year’s — and diffing them by hand.
When the seasons share a record, the answer is a view. The returning-families list reads the camp’s prior-year registrations and groups those families by whether they’ve re-enrolled for the current year yet: returning families already back in, and prior-year families who haven’t re-registered, with a retention read across them. The director works from who’s actually outstanding rather than from a reconstructed spreadsheet. And when next season’s sessions need to exist before anyone can register into them, last season’s session can be carried forward as the template for the new one — its fee tiers and configuration cloned into a fresh set of dates — so setting up the year you’re inviting families back to isn’t a from-scratch rebuild either.
One record across seasons
Pull the threads together and it’s a single principle: the family is the unit, not the season. The camper record persists, so a returning camper’s registration starts from what you already know about them. The family relationships persist, so siblings are linked without anyone declaring them, and the discount that follows applies itself. The prior season persists as a view, so the director sees who came back without diffing lists, and as a template, so next year’s sessions don’t start from nothing.
Contrast that with the duct-taped version, where each season is an island. Every returning family pays the re-keying tax, every sibling discount is a manual catch, and every “who hasn’t come back?” is an export-and-diff. None of it is hard in isolation. All of it repeats annually and falls hardest on the families you most want to keep. Camp Runner carries the record across seasons so the director can spend re-enrollment welcoming families back instead of making them reintroduce themselves — the same coherence that keeps online registration forms from falling apart at scale. If returning-family registration is currently fifteen minutes of re-typing per loyal family, join the waitlist.
Common questions
- How does returning-camper prefill work?
- When a returning camper starts a new registration, the system pulls their existing record forward as the starting point — name, date of birth, grade, and school from the camper row, plus their most recent completed answers per form, their medical information, and their saved contacts. The parent reviews and edits what changed rather than re-typing what didn't. Prefill only kicks in when the camper actually has a prior completed registration on file, so a brand-new camper still starts clean.
- Do sibling discounts apply automatically, or does a family enter a code?
- They apply on their own — no code to type. When a parent registers a second camper into a session, the system looks up the family's campers through the family relationships, checks which of them are already registered for that same session, and if a sibling is already in, applies the camp's configured sibling discount to the new registration. The family sees the reduced total at the moment it's true, and nobody hand-calculates eligibility.
- What counts as a returning family?
- A family with at least one camper who was registered in a prior season. The returning-families view reads last year's registrations for the camp and groups those families by whether they've re-enrolled for the current year yet, so the director can see at a glance who has come back and who hasn't. It's the same family record carried across seasons, not a fresh entry each year.
- What happens to last year's data when a camper re-registers?
- It stays on the same camper record and feeds the new registration as a prefilled draft. The parent isn't starting from a blank form — they're confirming and updating an existing one. Because the data lives on the camper rather than in last year's separate tool, the medical info, contacts, and prior answers are already there to review.
- How is this different from running registration on a generic form tool each year?
- A standalone form has no memory of last season. Every returning family re-keys the same name, birth date, allergies, and emergency contacts they entered the year before, and the director re-keys any of it that lands as a loose submission. When the registration is built on the camper record instead, last year's data is the starting point and returning families confirm rather than re-enter.
