Memberium · Group Accounts
Sell the seats.
Let the customer fill them.
A company buys twenty-five seats, the invoice clears, and then the real work begins for you. Group Accounts makes the organization the unit of access, handing back the roster to the owner who bought it, and gives you your time back.
The problem: the access-granting line
You never wanted to become the HR department for every company you sold to
The platform had no concept of an organization, so every consequence of that absence landed on your desk. Four costs show up every time you sell team, corporate, or classroom seats.
The HR-clerk ticket loop
Every hire, departure, and role change inside the customer’s organization becomes a ticket on your desk. The customer can’t add their own people, so your support queue fills with someone else’s onboarding rather than real support tickets.
The seat that walks out the door
An employee leaves the customer’s company and nobody tells your membership site, because nobody at the customer has a way to act. The account stays active, the seat stays consumed, and the customer pays for access no one is using.
The roster you can’t see
You have individual users rather than organizations. A request about "the Acme account" sends you hunting through a flat list trying to reconstruct which twenty-five of them belong together. There is no front desk for the group, because there is no group.
The deal that never ends
A corporate deal runs twelve months. Month thirteen arrives, the renewal lapses, and access continues, because nothing in the system knows the deal had an end date. The revenue leakage runs quietly until someone notices.
The shift
The customer runs their own front desk
Group Accounts changes who holds the roster. Instead of every access change routing through your support queue, the owner who controls the purchase manages their own people: invites them, seats them, organizes them into teams, and removes them when they leave.
Access flows from belonging rather than configuration. The group is the access policy.
- A group carries the tags and memberships its members should receive
- The moment a person joins the group, they inherit the access automatically
- The moment they leave, the access goes with them without per-user cleanup
- Existing members, admins, and individual buyers are untouched
Pillar 1 · Delegation
The group owner’s dashboard
A front desk the customer runs themselves, on the front end of the site, behind their own login. From there they see their roster, their teams, their pending invitations, and their seat counts. They invite a new hire, the hire receives an email, the hire clicks, and the hire is in without a ticket ever reaching you.
- Invite by email rather than by account: the owner need not know whether the person already exists
- Bulk CSV import for the big onboarding, with a result report of what landed, duplicated, and failed
- Seat counts that mean something: filled and remaining, counting active members and outstanding invites
- Removal that actually removes: membership deactivates, inherited access falls away, the seat reopens
Two tiers of authority, no god-mode
An owner carves the group into teams and appoints a manager to each. A manager sees only their own team: they invite to it, remove from it, and watch their team’s seat count. They can’t see the rest of the group or reconfigure it. Authority follows the organization chart the customer already has.
Pillar 2 · The Invite
Onboarding without the detour
The invitation is a complete onboarding path compressed into a single click, not a mere notification. The invitee opens the email, clicks the accept link, and lands inside the group: already authenticated, already granted the right access, already on the right team.
- Existing account recognized: the invitee is signed in and the group is added to their memberships
- No account, so one is created on the spot: username from email, strong generated password, name from the invite
- Registers later through a different path: any pending invite tied to their email is honored automatically
Invite links that can’t be scavenged
Each invite link works only for the person it was issued to. Forwarding it to someone else grants nothing, and a stolen database yields nothing usable; the link proves nothing without its intended recipient. Invitations expire after seven days, and a fresh one can be sent whenever a seat changes hands.
Pillar 3 · The Access Policy
Membership that grants itself
The reason an owner can add a stranger to the group without your involvement is that access is attached to the group, not to the individual. Every active member inherits the group’s tags and memberships at session-generation time, through the same persona pipeline that powers the rest of the platform.
- Add a member: the access appears, on the next session and every session after
- Remove a member: the access disappears, because there was never anything per-user to clean up
- One change serves everyone: upgrade a group’s tier and every member moves up together
Deals that close themselves
A group can carry an end date, and when that date arrives the deal closes itself: members go inactive, their access falls away, and pending invitations are dropped. A twelve-month deal ends in month twelve on its own, with no ticket and no one left to suspend accounts by hand. The rest refuses to break: an owner cannot be deleted while they still own a group, and a full group will not accept another seat.
Pillar 4 · Visibility
A roster you can actually see and show
Belonging to a group is a first-class fact about a member’s session: visible, conditionable, and personalizable. The member is no longer an isolated login; they are part of something the site can recognize and reflect back.
- Show what they belong to: group name, team name, and manager’s details, pulled live from the membership
- Gate content by role: one block to owners, another to team managers, a third to plain members
- Recognize the organization on any protected page: gating, personalizing, or routing by company
The "Acme account" becomes a real thing
For the site owner, the admin surface holds the full picture: every group, its owner, its seat count, its teams and managers, its members and invitations. One row, one roster, one place to look, rather than twenty-five users you have to reconstruct from memory.
Why it matters
One solution closes all four pain points
The four costs share a single cause, seen from four angles: the platform had no concept of an organization, so every consequence fell on the site owner’s desk. Group Accounts makes the group real, makes it the unit of access, and hands control of it to the customer who bought it.
Stop running their HR department
Put the roster in the customer’s hands, where the leverage always belonged
Group Accounts layers on top of the membership engine without replacing it. The customers who need groups get groups; the customers who do not, do not. License Memberium and give organizations a front desk of their own.