> ## Documentation Index
> Fetch the complete documentation index at: https://docs.1club.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Members overview

> How contacts, members, memberships, accounts, and credentials fit together in 1Club.

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, a drop-in, a parent on a household account, or a staff member - the `type` field decides where they show up in the UI.

The **Members** section in the admin gives you that table, plus the four things attached to it: memberships, attendance, accounts (households and companies), and access credentials.

## What's in this section

<CardGroup cols={2}>
  <Card title="Member list" icon="users" href="/members/member-list">
    The contacts grid. Tabs split it into members, drop-ins, leads, lapsed members, households, and unpaid. Filter by tag, plan, status, or progression level.
  </Card>

  <Card title="Member profile" icon="id-badge" href="/members/member-profiles">
    A single contact's page: notes, memberships, bookings, check-ins, transactions, messages, documents, credentials, and account links.
  </Card>

  <Card title="Memberships" icon="card-membership" href="/members/memberships">
    Every membership in the org. Filter by status (active, paused, pending, used, cancelled, expired) or billing frequency.
  </Card>

  <Card title="Accounts" icon="people-roof" href="/members/accounts">
    Group contacts into households or companies for shared billing and acting-on-behalf-of permissions.
  </Card>

  <Card title="Attendance" icon="clipboard-check" href="/members/attendance">
    Check-in log. Add manual check-ins, link them to bookings or memberships, view by date range.
  </Card>

  <Card title="Access cards" icon="key" href="/members/member-cards">
    QR codes, access cards, and PINs that members tap, scan, or punch in at a reader.
  </Card>
</CardGroup>

## 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` (used as the "deleted" disposition).
* A **member** is a contact with `type = member`, which typically means they have or had a membership.
* The page itself is labelled **Members**, but the underlying table is `contacts`. URL paths use `/members/list`, but API calls hit `/contacts`.

The Member list `type` column shows the bucket each contact is in. You can change a contact's type from their profile - the change is logged in the type history.

## Plans vs memberships

Plans are templates; memberships are instances:

* A **plan** lives under [Billing > Plans](/billing/plans). It defines price, billing frequency, signup fee, max uses per period, validity window, scope (which classes/areas/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.

The same contact can hold more than one active membership at a time.

## Accounts roll up billing

[Accounts](/members/accounts) let you group contacts under a shared billing entity:

* **Household** accounts (Owner, Adult, Dependent) keep a family unit together.
* **Company** accounts (Admin, Employee) bill an employer for its people.

Memberships stay attached to the individual contact. Invoices and transactions roll up to the account, and account roles control who can book or check in on behalf of whom.

## Credentials are how members get in

If you run access control, members carry one or more [credentials](/members/member-cards): a QR code, a physical access card, or a PIN. Credentials are assigned to a contact, and one is marked **primary**.

How strict the door is depends on your check-in mode. See [Access control](/settings/access-control) for the configuration and [Check-in models](/reference/check-in-models) for what each mode allows.

## Related

* [Member list](/members/member-list) - find and filter contacts
* [Memberships](/members/memberships) - the membership grid and lifecycle
* [Accounts](/members/accounts) - households and companies
* [Attendance](/members/attendance) - the check-in log
* [Smart tagging](/settings/smart-tagging) - automatic tags driven by rules
* [Billing > Plans](/billing/plans) - the plan templates memberships are built from