Membership waitlist and bond

The membership waitlist is how applicants become members. It is not the same as camp or lap waitlists.

• Public /join (and staff tools) add households as applicants. A real, non-member account. Applying now provisions a portal sign-in at apply time, so the applicant can magic-link in to finish or resume payment and manage their spot without waiting to become a member (this replaced the old abandoned-payment dead-end, where an applicant who bailed on Stripe had no way back in). They can sign in, but they're an applicant, not a member, member-only features stay gated until the household becomes a member.

• If an application fee is enabled (configured in Settings), applying opens an invoice and sends the applicant to Stripe Checkout. The household is only assigned a list position once that payment is confirmed. Because the sign-in is already provisioned at apply, a fee applicant can log back in to pay even before the payment webhook lands. An application that goes unpaid past the application window (configured in Settings) expires automatically; the household must resubmit at /join (resuming an abandoned Checkout reuses the same household rather than creating a duplicate).

• Intake mode is a copy switch, not a different flow. The membership_intake_mode setting (configured in Settings, waitlist or open, default waitlist) only changes wording and what the applicant sees: waitlist mode shows the queue and the applicant's position; open mode uses apply-to-join wording and never says "waitlist." The underlying apply/offer mechanics, and whether an application fee is charged, are identical either way.

• Managers reorder and send offers from Waitlist.

• To reorder, drag a row to its new spot (works with a mouse, or with the keyboard: tab to a row's handle, press space to pick it up, use the arrow keys to move it, space again to drop it). Each row also has a Move disclosure with a typed position box, for when dragging isn't practical. Moving a household renumbers everyone between the old and new spot, so two households can never end up sharing a position. Every change is recorded. To add a household, open its household page; create the household first if it is not already on file.

• To send several offers at once, use the batch-offer control: choose how many households, starting from the top of the list, and confirm — the confirmation names every household it will email before anything sends, since this is not something you can take back. It sends to whoever is actually waiting, so asking for more than are on the list simply offers to everyone waiting rather than erroring.

• The capacity panel shows how many more offers you can safely send right now without ending up with more accepted members than the club wants — it assumes every outstanding offer gets accepted, so it under-offers rather than promise a spot the club can't honor, and shows the rate at which past offers have actually been accepted alongside it. It reads the target number of member households setting (Club → Membership → Waitlist); with no target set, it shows the counts it has and points you at that setting instead of a number.

• Offer expiry and related fees are configured in Settings.

• Position is a plain staff-set number. There is no hidden auto-rank. Resident priority is a board policy you apply by hand when you reorder, informed by the resident-ratio stat shown on the Waitlist page. Turning on auto-advance (configured in Settings, off by default) does not add any ranking or scoring. It only automates sending the next offer, to whichever entry your own ordering puts next, after a decline, an expiry sweep that actually expired an offer, or an approved relinquishment frees a spot. Turning it on for a queue that already has waiting households does not immediately send a first offer — it primes future declines, expiries, and relinquishments, but the very first offer to a newly auto-advance-enabled queue still has to be sent by hand from Waitlist.

When an offer is accepted, the household gets a pending membership and an initiation invoice (fee + bond + first year's dues per your org's Settings amounts) in the same step. The membership only becomes active, and the bond only posts, once Stripe confirms the payment; accepting the offer does not activate membership immediately.

If the offer email doesn’t arrive, open the Spot offered filter on Waitlist. Replace accept link creates a new, copyable link without sending an email. Copy it before leaving the page and share it only with that household. Its previous link stops working. Resend offer email sends the offer email again with a new link; if sending fails, the previous link stays valid. Neither action extends the offer’s expiry.

When an offer's expiry window passes unaccepted, the entry moves to expired and the household is emailed automatically (this email was broken before 2026-08-19, ticket #268, so for offers that expired before then, do not assume the member was notified).

There is currently no admin action to remove or withdraw a household from the membership waitlist (unlike camp/event waitlists, which do have a Remove action). Until that's added, use reorder to move a household to the bottom of the list, or leave a note on the household record, rather than expecting a delete/withdraw control.

The Waitlist page header shows a resident ratio: "Current members: X of Y (Z%) are residents" (the word used there matches your club's residency-label setting). What it is: a live count of your current member households (not waitlist entries) whose record carries the resident flag, shown so the team has context when applying the board's residency policy by hand while reordering. What it is not:

• Not a waitlist statistic. It counts existing members, not who's waiting.

• Not a quota or a target the platform enforces.

• Not an input to any automatic ranking. Nothing reads it; ordering stays a plain staff-set number, and every reorder is audited.

If the board sets a residency target, this number tells you where the membership stands; acting on it is still a human reorder decision.

New members typically post a refundable bond (amount configured in Settings). The bond is club money held on the books. It is not a Stripe “hold” you refund through Checkout.

If your club has no bond, leave the amount at $0: the initiation invoice then carries no bond line, and the bond wording disappears from the public join page, the offer-acceptance page and the welcome email. There is no platform default bond. Set the amount before your first offer goes out, or applicants will be quoted an invoice without one.

When membership ends via relinquishment, bond return (minus any approved penalty) becomes a check payable on the Check run page. Never a card refund.