Skip to main content
Everyone you track lives in one table: contacts. A contact becomes a member the moment you sell or assign them a membership. The same record may also be a lead in your sales pipeline, a drop-in, a dependent on a household account, or a staff member - the type field decides which bucket they show up in across the UI. The Members section in the admin gives you that table and what hangs off it: the sales pipeline, accounts (households and companies), access cards, and document signatures. Three related pages moved to other sections: memberships are under Sales, matches under Events, and attendance under Schedule.

What’s in this section

Member list

The contacts grid. Tabs split it into all, members, drop-ins, leads, unpaid, accounts, and lapsed. Filter by tag, status, missing details, plan, or progression level.

Member profile

A single contact’s page: activity, bookings, memberships, check-ins, charges, documents, cards, notes, and account links.

Leads and pipeline

The Leads tab: your sales pipeline as a board or a list, with stages, sources, and assignees.

Accounts

Group contacts into households or companies for shared billing and acting-on-behalf-of permissions.

Access cards

The Cards page: access cards and PINs members use at a reader or kiosk.

Document signatures

The ledger of waivers and other documents members have signed.
The section also covers:

Pages that moved

The overflow menu on the member list still links to Memberships and Matches, so you can reach them from Members too.

Contact vs member

The two terms are not interchangeable in the data model, but the UI uses “member” almost everywhere:
  • A contact is any person record in your org. Type can be contact, member, lead, drop_in, lapsed, staff, or archived (the “deleted” disposition - records are soft-deleted, never removed).
  • A member is a contact with type = member, which typically means they have or had a membership.
  • A lead is a contact who has never been a customer and is in your pipeline.
  • The page is labelled Members, but the underlying table is contacts. The admin URL is /members/list, while API calls hit /contacts.
The type follows what the contact actually holds and does, so you don’t set it by hand. Click the type chip on a profile to see its type history.

A member belongs to the organization

A contact belongs to your whole organization, not to one of its Clubs. Staff at every location see the same member, so a person registered at one location is not added again at another. Where a member trains is recorded on what they do: each membership, booking, check-in, and order records its own Club. Members permissions follow the same rule. Access to the member list and profiles is granted for the whole organization, and members access has no per-Club scope in Permissions.

Plans vs memberships

Plans are templates; memberships are instances:
  • A plan lives under Sales > Plans. It defines price, billing frequency, signup fee, max uses per period, validity window, scope (which classes, areas, or instructors it covers), and whether it auto-renews.
  • A membership is what you assign to a specific contact when they sign up. It snapshots the plan’s terms at the moment of sale, so editing the plan later does not retroactively change existing memberships. Find them all under Sales > Memberships.
The same contact can hold more than one active membership at a time. A padel gym, for example, might sell a member both a “Court access” plan and a separate “Group coaching” plan that run in parallel.

Accounts roll up billing

Accounts let you group contacts under a shared billing entity:
  • Household accounts use the roles Owner, Adult, and Dependent to keep a family unit together. A parent enrolling two kids in a jiu-jitsu kids program is a household.
  • Company accounts use the roles Admin and Employee to bill an employer for its people, for example a corporate gym membership.
Memberships stay attached to the individual contact. Invoices and charges roll up to the account, and account roles control who can book or check in on behalf of whom.

Cards are how members get in

If you run access control, members carry one or more cards: a physical access card or a PIN. One is marked as their main card. Members with a portal account also have a QR member code they can show from the portal or app. How strict the door is depends on your check-in mode. See Access control for the configuration and Check-in models for what each mode allows.