Sign in by text (SMS code)

Members can sign in with a 6-digit code texted to their phone instead of an email magic link. But only after they verify their number themselves, once, from inside the portal. There is still no password anywhere.

1. Member signs in the usual way (email link or Google).

2. In the portal, under Household → Sign in by text, they enter their mobile number and press Text me a verification code.

3. They type the 6-digit code from the text. Done: from then on the login page's "sign in by text" option works for that number.

Staff cannot do this for them, on purpose: proving control of the phone while signed in to the account is what makes the number safe to accept as a login. A phone number on the household record (imported or typed by staff) gives zero sign-in ability until the member completes this step themselves.

• The member enters their mobile number and always gets the same message, "If [number] can sign in by text, a code is on its way" — whether or not the number is verified for sign-in. Like the email path, this is deliberate: the login page never confirms who is or isn't a member. "It said it sent a code" does not confirm the number is set up.

• The text comes from Swim Ops, not from the club's notification number: sign-in codes are delivered by Twilio Verify, a separate verification service, so they arrive from a different sender than dues reminders or closure notices and read "Your Swim Ops verification code is …". A member who is texting STOP to the club's number does not stop sign-in codes, and vice versa.

• Codes expire after 10 minutes, and 5 wrong guesses burn the code. Requesting a new code does not reset the guess counter.

• Rate limits: 3 codes per number per 15 minutes, and platform-wide daily caps. Past a limit the member sees "Too many codes requested.": ask them to wait 15 minutes, same script as the email limiter.

This is the case staff exist for. Phone numbers get recycled by carriers, if a member gives up a number, its next owner would receive that member's sign-in codes. The member should turn text sign-in off themselves (Household → Sign in by text → Turn off text sign-in), but when they can't:

1. Open Households, find the person, go to People.

2. Their verified number shows as Text sign-in: +1 … on their row.

3. Use Unlink text sign-in number. This immediately stops that number from signing in to their account; email sign-in is unaffected.

4. The member can re-verify their new number from the portal any time.

Every unlink is recorded in the audit log.

Multi-club members: a text sign-in number is tied to the person's single sign-in identity, which is shared across every club they belong to. So unlinking a number (whether the member does it or you do) turns text sign-in off for that person at all their clubs, not just yours. It's fully recoverable: they re-verify from any club's portal: but say so if you unlink for a member who might use text sign-in at another club.

Each phone number can be the sign-in number for exactly one account, first verified, first served (a shared "family phone" can't be two people's login). If a household insists the number belongs to the person being refused, the other account's owner (or staff, via Unlink) has to release it first.

Same pattern as the Google button: the option hides itself until SMS is actually provisioned for the platform (a deployment/engineering setting, not an admin Settings toggle). Nothing is wrong on the member's end: members use the email link until it appears.

• The notification checkbox is separate. "Text me membership and billing notices…" (the SMS opt-in) has nothing to do with sign-in codes. A member with the box unchecked can still sign in by text, and checking the box never makes a number a login credential.

• The contact phone field is separate. Editing a member's phone in admin or the portal changes who the club texts, never how they sign in.

• Any report that someone received a sign-in code they didn't request repeatedly (a one-off is usually a typo'd number; a pattern may be someone probing).

• Any claim that a number signs in to the wrong person's account: treat as potential unauthorized access, don't experiment from the admin side.