Seat Management, Bulk Enrollment and Permissions, Explained

These three features get filed under "admin functionality" and deprioritised in favour of something more visible. Then a corporate customer with forty staff can't work out how to remove someone who left, and the renewal conversation gets difficult.

What a seat actually is

A seat is a licence owned by the organisation, temporarily occupied by a person. That distinction is the whole design.

If you model access as "this user has access", you've built named licences, and the company has to contact you every time an employee changes. If you model it as "this organisation owns 20 seats; here's who currently occupies them", the customer manages their own team and you never hear about it.

Reclaiming seats — the bit that's usually wrong

Freeing a seat is easy. Deciding what happens to the person's work is not, and it needs an explicit answer:

• Does progress survive? Usually it should. If someone returns, or the company is audited, that record matters.
• Do certificates stay valid? Generally yes — they earned it. But the buyer may want it excluded from active reporting.
• Can the seat be reassigned immediately? Yes, or the customer will over-purchase to be safe, then resent it at renewal.
• Is there a cooling-off period? Some organisations cycle seats weekly to game a smaller purchase. A short lock after reassignment stops that without punishing normal use.

Decide these deliberately. Every one of them becomes a support ticket if it's left implicit.

Bulk enrollment done properly

The naive version takes a CSV and creates accounts. It causes three problems: people get accounts they didn't ask for, passwords have to be distributed somehow, and duplicates appear for anyone who already had an account.

The better pattern is invitation-based:

• The admin pastes or uploads email addresses
• The system checks for existing accounts and links rather than duplicates them
• Everyone else receives an invitation and sets their own password
• Seats are marked pending until accepted, and the admin can see who hasn't responded
• Invitations expire, so seats aren't held indefinitely by people who ignored the email

That last point sounds minor and prevents a specific recurring complaint: an organisation with all seats "used" and half its staff unable to get in.

Permissions without over-engineering

Resist building a permissions matrix. Three roles cover almost every real organisation:

• Admin — buys, manages billing, assigns and reclaims seats, sees all reporting
• Manager — enrolls and reports on their own group, no billing access
• Member — accesses content, sees only their own progress

Two rules matter more than the roles themselves. First, a manager sees only their group — a department head shouldn't see the whole company's completion data. Second, every organisation needs at least one admin, so the last one can't remove themselves. That bug locks a customer out of their own account and is embarrassing to explain.

The edge cases worth deciding early

• Someone belongs to two organisations. Consultants and contractors do. Can one account hold two memberships?
• The company shrinks at renewal. Which seats are released, and who chooses?
• An admin leaves. There must be a recovery path that doesn't involve emailing you.
• Content is added mid-term. Do existing seats get it, or is it an upsell?

Answer these on a page before anyone writes code. They're cheap decisions now and expensive migrations later — and they're the reason membership platforms get painful as they grow.

Our Membership, LMS & B2B service builds seats, invitations, roles and reporting with these decisions made explicitly. Scoped to your build.