School Booster Network · Athletics, band & music, theatre boosters · Early access · 2026

Organised by program, run by season — the booster club platform built for game night and show night

School Booster Network is built for the way booster clubs actually operate: by program and by season, not by fiscal year and committee meeting. Football boosters, marching band boosters, and theatre boosters each run their own event schedule, treasury, and fundraiser under one club. The game-night operations stack — gate-scan at the entrance, concessions POS at the stand, and the exact-cent split engine for the fundraiser — is the built core. Early access — no pricing commitment, no signup, no live payments today.

Book a conversation How it works

Season structureprogram → season → events → treasury — all under one booster club

Exact centsexact-cent split engine — fee off gross first, largest-remainder reconciliation, every leg stated

Fail-closedno-oversell at the data layer; unscreened volunteer cannot claim a screening-required slot

Consent-gatedfamily and member data owned by the organisation, never sold

The game night and the show night — the booster club’s biggest operational events

Three programs, three seasons, one booster club — the operating stack that keeps them sorted

A school booster club running football, marching band, and theatre in the same year is running three separate operations on three separate schedules. Football plays Friday nights from August to November. Marching band competes Saturdays through October. Theatre runs three weekends in March. Each needs its own ticket sale, its own concessions operation, and its own share of the year-end fundraiser proceeds — kept separate from the school’s activity fund by the club’s SEPARATE-ENTITY treasury.

School Booster Network runs all three under one club, on one shared, exact-cent, fail-closed treasury kept distinct from the school’s activity fund by the SEPARATE-ENTITY flag. On a game night, three things happen simultaneously: gate-scan at the stadium entrance marks tickets admitted against the box-office record; the concessions POS at the stand rings up each sale with per-item pricing and reconciles the till at close; and the split engine knows which proceeds flow to the football booster and which stay in the school’s activity fund. A treasurer sees all of it in one place — not in three spreadsheets stitched together after the fact.

The box-office engine, gate-scan foundation, and concessions POS are built and production-ready. The charge rail that moves money is honest-off: not enabled for live transactions today. When it is enabled, the operational picture described here is what the platform delivers, because that is what the code does.

Book a conversation Full platform

How it works

The booster club year in four stages

School Booster Network runs on a season rhythm: program setup before the season, first events and fundraiser launch at the opener, game nights and show nights through mid-season, and a clean year-end reconciliation and officer handoff. Every stage is described as it is built today.

Step 1 · Pre-season — program and season setup

Officers set up the year’s programs — athletic teams, ensembles, and performance programs — and the events, fundraisers, and volunteer slots that run against each season. The booster club’s SEPARATE ENTITY flag is set at this stage, keeping the club’s single treasury distinct from the school’s administrative accounts (per-program sub-treasuries are roadmap, not built). Volunteer screening requirements are defined per slot type before the season opens. Consent for family communications is collected before the first event — no message reaches a family who has not opted in. The organisation owns its program and family data from day one.

Step 2 · Season opener — first events, volunteer slots, and fundraiser launch

The first events of the season are configured in the box-office engine: ticket types, capacity, pricing, and reserved-seating shape for a theatre house or general-admission limits for a stadium gate. Season passes and multi-game packages go live alongside single-event tickets. Volunteer slots open for the first event — ticket takers, ushers, concessions stand staff. The opening fundraiser is configured in the split engine: fee off gross first, split to the club treasury.

Step 3 · Mid-season — game nights, show nights, concessions, fundraisers

Gate-scan handles door check-in at each event. The concessions POS rings up sales with per-item pricing and reconciles the till at close (counted float, expected-vs-counted cash, variance surfaced). The split engine runs mid-season fundraisers, projecting the exact-cent distribution to the club treasury before the charge rail runs. Volunteer slots fill and close through the coordination engine, fail-closed on screening requirements. The club’s treasury stays distinct from the school’s activity fund in the ledger.

Step 4 · Year-end — treasury reconciliation and season handoff

The year-end reconciliation runs on exact-cent records: every event, every concessions till count, every fundraiser split, every penny accounted for. An officer-transition export delivers the full record to the incoming treasurer in a portable format they can read without the platform. The organisation owns its data. One-click export is available in writing — if the organisation ever leaves, every record leaves with it: event history, fundraiser splits, concessions records, volunteer logs, and communication consent status.

The full platform

Five engines — honest about what is built and what is coming

Every feature is labelled honestly: Built means the underlying engine is production-ready. In development means the surface, wire-up, or carrier integration is in active build. We do not claim otherwise.

Game night and show night ticketing — season passes, gate-scan, no-oversell

The box-office engine manages ticket types, pricing, and per-event capacity for every game and performance on a program’s schedule. Season passes and multi-game packages let an athletics booster sell a full-season commitment in one transaction. Reserved-seating shapes support a theatre house with assigned rows; general-admission capacity limits support a stadium gate. A no-oversell rule is enforced at the data layer — a ticket type with a set capacity cannot sell one beyond that limit, not by disabling a button but by refusing the transaction at the engine. Gate-scan handles door check-in at the entrance, marking each ticket admitted against the ticket record in real time. The box-office engine and gate-scan foundation are built and production-ready. The live checkout interface that accepts payment from ticket buyers is honest-off — present in the platform, not enabled for live transactions today.

Box-office engine built · live checkout honest-off

Concessions — a real point-of-sale operation for the stand

The concessions point-of-sale rings up items with per-item pricing in a cart and totals each sale to the exact cent. Cash is the base tender, and the till is fail-closed — a cash sale cannot complete under-tendered. At close, the till reconciles: it opens with a counted float, and the drawer is counted against expected cash so any variance is surfaced. Each sale records its exact-cent total and the number of lines rung up. Card payment runs through the payment rail, which is honest-off today. The concessions POS engine — cart, per-item pricing, cash tender, and fail-closed till reconciliation — is built and production-ready. Card payment at the stand is honest-off — present in the platform, not enabled for live card transactions. Per-event inventory tracking and volunteer stand-shift assignment are on the roadmap, not built today.

Concessions POS built · card payment honest-off

Spirit merch and team store — catalog and cart substrate, storefront in build

The cart substrate and catalog management are built on the platform’s commerce layer. Spirit wear, program merch, player packs, and senior banners can be catalogued against a program, associated with a season, and added to a cart. The storefront — the customer-facing interface where a parent browses the catalog and checks out — is honest-off: the checkout interface that accepts payment does not yet go live. Spirit merch is described accurately: cart primitives and catalog on a built substrate, with the storefront checkout honest-off while in active development. No live team store claim is made here.

Cart substrate built · storefront checkout honest-off

Per-program fundraising — the exact-cent split engine, scoped to the program

The fundraising split engine divides gross proceeds with exact-cent precision, applied at the program level. The fee is deducted from gross proceeds first — before any split is calculated — and splits are applied to the net remainder. Parties sum to exactly 10,000 basis points. A largest-remainder reconciliation pass ensures the distribution totals to the cent, with no penny lost or unaccounted for. The platform earns a modest, disclosed residual leg of the net — stated in the split, never hidden inside it. The athletics-fundraiser-split engine keeps booster club money separate from the school’s activity fund — enforced in the ledger, not a manual spreadsheet the outgoing treasurer hands to their replacement. A treasurer sees the exact projected distribution — every leg, including the platform residual — before the charge rail runs. The split engine is built and production-ready. The charge rail that moves money is honest-off — present in the platform, not enabled for live transactions today.

Split engine built · charge rail honest-off

Game-day volunteer shifts and SEPARATE ENTITY governance

The volunteer coordination engine manages named slots per event: ticket takers, gate crew, ushers, stage crew, concessions stand staff, chain gang for a football sideline. The fail-closed screening rule is enforced at the engine layer — an unscreened volunteer cannot claim a slot flagged as requiring screening, not by a policy reminder but by code. The booster club’s SEPARATE ENTITY flag keeps its treasury distinct from the school’s administrative accounts at the data layer; a treasurer and an auditor can see which entity owns which record. Background-check provider integration — the external service that performs the actual screening — is an honest-off wire. The named-slot coordination core and the SEPARATE ENTITY governance layer are built and production-ready. Live signup routing and reminder fan-out are honest-off.

Coordination engine built · live routing honest-off

Who uses it

Built for the athletics booster, the band booster, and the theatre booster — all running on one substrate

Athletics boosters

The football booster club runs Friday nights from August to November. Season passes and multi-game packages let families commit before the schedule publishes. Gate-scan handles the stadium entrance. The concessions stand runs its own POS shift at every home game. The athletics-fundraiser-split engine keeps booster proceeds separate from the school’s activity fund. Senior night, banquets, and end-of-season recognitions each carry their own event configuration.

Band and music boosters

The marching band competition circuit runs Saturdays through October, each competition a ticketed event with its own capacity and gate. Concert seasons, winter guard, and orchestra performances carry reserved-seating configurations for a smaller indoor venue. Travel fundraisers and sponsor-a-student campaigns run through the split engine, with proceeds split to the band booster treasury and never commingled with other programs.

Theatre boosters

The spring musical runs three weekends in March, with a theatre house that has assigned rows. Reserved-seating shapes in the box-office engine map the house: general admission downstairs, patron section with a wider seat, benefactor row by the pit. Stage crew, ushers, and pit orchestra are named volunteer slots in the coordination engine. Intermission concessions and programme sales run through the POS. The booster treasurer reconciles the run’s proceeds per program at close.

Game-day volunteer shifts — the screening gate and the SEPARATE ENTITY rule

A screening requirement on a slot means something — not just that it is written in the handbook

A stadium gate has slots that require a background check — ticket takers, gate crew, anyone in direct contact with students — and slots that do not: the person in the parking lot with an orange vest. The coordination engine enforces the difference. An unscreened volunteer cannot claim a slot flagged as requiring screening: not by a reminder email that could be ignored, by code. The organisation defines which slots require screening; the engine enforces it.

The SEPARATE ENTITY governance rule is enforced at the same data layer. A booster club’s treasury is a distinct legal entity from the school’s administrative accounts — and the platform preserves that distinction without the treasurer having to remember to do it manually. A fundraiser that splits proceeds between the booster and the school’s activity fund keeps those records separate in the ledger from day one. An auditor can follow the chain.

Member data & family consent

Your data. Your organisation’s data. Consent-gated, never sold.

The membership roll, the event records, the fundraiser ledger, and the opted-in communication list belong to the organisation — not to the platform. No member or family data is sold to or shared with outside companies or advertisers. Family data that involves minor students is consent-gated: a family must opt in to communications from the organisation before their contact is added to any list. Consent is not assumed. It is collected. Consent can be withdrawn at any time.

Minor student data runs on our own systems and is never shared with advertisers. It is never visible to other families. The one-click export is available in writing — if the organisation ever leaves the platform, every record leaves with it: event history, fundraiser splits, concessions records, volunteer logs, and communication consent status. This guarantee is part of the onboarding agreement, not a footnote.

What is built and what is coming — plainly

The engines are built. The charge rail is not live yet.

Built and production-ready today: the box-office engine and gate-scan foundation (no-oversell at the data layer, season passes, reserved-seating, multi-game packages); the concessions POS (per-item cart pricing, cash tender, fail-closed till reconciliation; per-event inventory and stand-shift assignment are roadmap, not built); the cart substrate and catalog management (spirit wear, program merch, player packs); the exact-cent split engine (fee-off-gross-first, largest-remainder reconciliation, athletics-fundraiser-split, club treasury kept distinct from the school’s); the volunteer coordination core (named slots, fail-closed screening gate, PII-free); and the membership and SEPARATE ENTITY governance layer (dues-current, voting eligibility, separate treasury enforcement).

Not yet enabled for live use: the payment rail (the part that moves money), live ticket-sale checkout, card payment at the concessions stand, the storefront checkout for spirit merch, live dues checkout, live carrier delivery for communications, and the background-check provider wire. These are honest-off — present in the platform, not enabled for live transactions. There is no live checkout here. No billing. No subscription. We say so directly because booster club treasurers deserve to know what is production-ready and what is still being wired.

Connected to the school platform

The booster club tickets the game. Assembly captures the night. Seen puts every athlete and performer on a page.

School Booster Network runs the gate, the stand, and the fundraiser. Assembly is the moment layer: live school events captured, ticketed, and archived — the Friday night game, the spring musical opening, the marching band competition final. A booster event and an Assembly event are the same night; wiring them together is natural. Seen is the recognition layer: the programme that ensures every student athlete and performer lands on a real page in the yearbook, the newspaper, or the playbill — adviser-approved and consent-verified.

assembly.school seen.school homeroom.software

Early access · Booster presidents, treasurers, athletic directors, band directors

Book a conversation to see the current state honestly

School Booster Network is in active development. We do conversations that show the current state honestly: how the box-office configures a game-night ticket sale, how the concessions POS rings up a sale and reconciles the till, how the split engine projects a fundraiser to the club treasury, and how the fail-closed screening gate works for a game-night volunteer slot. There is no pricing commitment and no signup. If it looks right for your program, we discuss what early access looks like.

To book: email [email protected].

FAQ

Common questions

What does “program and season structure” mean in practice?

A booster club doesn’t operate as one undifferentiated fund — in the real world it runs by program and by season. Football runs fall to early winter; marching band runs August through competition finals; the spring musical runs February to April. School Booster Network is designed for that operating rhythm: a club sets up its events, fundraisers, and volunteer slots against that calendar. The separation the platform enforces today is the one that matters most for compliance — the booster club’s treasury is a SEPARATE ENTITY from the school’s own accounts, kept distinct at the data layer, exact-cent, and never overdrawn. Per-program sub-treasuries — a distinct ledger per program under one club — are on the roadmap, not built today; the treasury is a single club treasury for now.

Is the payment rail live? Can we collect ticket sales, concession revenue, and fundraiser donations now?

Not yet. The box-office engine, the concessions POS, the split engine, and the coordination core are built and production-ready — the logic, the ledger, and the distribution math are all there. The payment rail that moves money is honest-off: it exists in the platform but is not enabled for live transactions today. There is no live checkout, no billing, and no subscription. When the charge rail is enabled (a founder-gated decision), organisations will be notified. The CTA here is “book a conversation,” not “sign up and pay.”

How does the gate-scan work on game night?

Gate-scan is part of the same box-office core as ticket sales. A scanner at the gate marks each ticket as admitted against the ticket record in the engine. The no-oversell rule is enforced at the data layer — a ticket type with 500 capacity cannot sell a 501st, not because a form disables a button, but because the engine refuses the transaction. Gate-scan check-in is built alongside the box-office foundation. The live checkout interface that creates the ticket in the first place is honest-off until the charge rail is enabled.

How does the concessions POS work?

The concessions point-of-sale rings up items with per-item pricing in a cart and totals each sale to the exact cent. Cash is the base tender; the till is fail-closed, so a cash sale cannot complete under-tendered. The till opens with a counted float and reconciles at close — counted cash against expected, with any variance surfaced. Each sale records its exact-cent total and the number of lines rung up. Card payment runs through the payment rail, which is honest-off today. The concessions POS engine — cart, per-item pricing, cash tender, and fail-closed till reconciliation — is built and production-ready; card payment at the stand is honest-off. Per-event inventory tracking and volunteer stand-shift assignment are roadmap, not built today.

What about spirit merch and team stores?

The cart substrate and catalog management are built on the platform’s commerce layer. Spirit wear, program merch, player packs, and senior banners can be catalogued against a program and associated with a season. The storefront — the customer-facing interface where a parent browses and checks out — is honest-off: the checkout interface that accepts payment does not yet go live. We describe it accurately: cart primitives and catalog on a built substrate, with the storefront checkout honest-off while in active development. We do not claim a live team store.

How does the exact-cent fundraising split engine work at the program level?

A booster club can run a fundraiser for any of its programs. The split engine applies three rules in order: fee off gross first (not hidden inside the split); splits calculated on the net remainder (never on the gross, which would inflate the platform’s share); and a largest-remainder reconciliation pass that assigns any residual penny to the party with the largest remainder — so the total always equals exactly what came in, minus the fee, with every leg stated to the cent. The platform earns a modest, disclosed residual leg of the net — shown in the split, never buried in it. The split keeps the booster club’s share distinct from the school’s activity fund in the ledger. The split engine is built and production-ready. The charge rail that moves money is honest-off.

What does SEPARATE ENTITY governance mean for a booster club?

A booster club’s treasury is a distinct legal entity from the school’s own accounts. The SEPARATE ENTITY flag preserves that distinction at the data layer: the booster club’s membership and fundraising records are not commingled with the school’s administrative records. A treasurer and an auditor can see which entity owns which record. This is an explicit governance choice the booster club makes at setup — not a side-effect of how data happens to be organised. The membership and governance policy layer is built and production-ready.

What can our booster club actually use right now?

The platform is in active development. In a demo we walk through the current state honestly: the box-office configuring a game-night ticket sale (season passes, multi-game packages, reserved section vs. general admission), the concessions POS ringing up a sale and reconciling the till, the split engine modelling a fundraiser split to the club treasury, and how the fail-closed screening gate works for a game-night volunteer slot. None of those involve live payments today. A conversation is the honest next step — we show what is built, what the charge-rail timeline looks like, and what early access means for your program.

How does family and member data work? What about minors?

The booster club owns its member and family data. No member or family data is sold to or shared with outside companies or advertisers. Family data that involves minor students is consent-gated: a family must opt in to communications from the organisation before their contact information is added to any list. Consent is not assumed — it is collected. Consent can be withdrawn at any time. Minor student data is never visible to other families. One-click export is available in writing — if the organisation ever leaves the platform, every record leaves with it.

How is this different from a general parent-organisation platform?

A general parent-organisation platform is built around the membership calendar of a parent-teacher association — meetings, dues drives, general fundraisers, family communications. School Booster Network is built around the operational reality of a booster club that runs by program and by season: the fall football schedule, the marching band competition circuit, the spring musical run. The gate-scan, concessions POS, and season-pass ticketing are purpose-built for the game night and show night operations that define a booster club’s calendar.

When is the platform available?

The platform is in active development. The box-office engine and gate-scan foundation, the concessions POS, the exact-cent split engine, the cart substrate, and the coordination and governance core are built and production-ready. The payment rail, live checkout, card payment at the concessions stand, the storefront checkout, and live carrier delivery for communications are honest-off — present in the platform, not yet enabled for live use. The best next step is a conversation where we show the current state honestly and discuss what early access looks like for your program.