How to enroll 40 learners when you don't know their names yet
Company buys 40 training seats and can't give you the attendee list. Here's why the usual workarounds fail, and how to run bulk enrollment without one.
BLOG
You've closed the deal. A company has bought forty places on your next intake. You send the onboarding email asking for the attendee list, and you get back some version of: "We'll confirm nearer the time."
The course starts in nine days.
Anyone who sells training to organizations knows this gap. The purchase and the participants are two separate decisions, made by two different people, often weeks apart. Procurement commits the budget; the department decides who attends. Meanwhile your platform wants an email address for every learner before it will create a single account.
The problem isn't your platform. The problem is the mismatch between how you sell training and how most learning systems assume it works.
The three usual workarounds — and why each one costs you
The shared login. One account, one password, forty people. It works for exactly one day — until you need to know who submitted the homework, who passed the assessment, or who actually showed up. You've also just made your completion data worthless, which is the thing the client will ask for at the end.
Placeholder accounts. attendee1@client.com through attendee40@client.com. Now you have forty accounts nobody can log into, forty password reset requests in week one, and a rename job when the real names arrive. If your platform sends an activation email to each address, you've also generated forty bounces.
Chasing the list. The most common and the most expensive. Someone on your team sends follow-ups the week before every intake, then spends a day copying names into a form. It scales linearly with your sales: the better your quarter, the worse your admin gets.
All three exist for the same reason — the platform insists an account must be created by someone who has an identity, before anyone can learn.
Flip it: create the account at first use
The alternative is to stop treating enrollment as something you do to a list, and start treating it as something the learner does to themselves.
The buyer takes a number of seats on an intake. Each seat generates one unique access code. The codes go to the client contact, who distributes them however they like — email, Slack, a printed sheet at kickoff. When a person enters their code, the account is created at that moment, with the name they type in.
You never needed the list. The list assembles itself.
This changes who does the work. In the old model, your operations team is responsible for data they don't have. In this one, the person with the information — the learner — supplies it when they have a reason to.
What you still get to track
The objection is usually about visibility. You're selling to a client who will want a report.
You don't lose anything if the seat is a real object in the system. Each seat carries its status: issued, activated, unused. This means:
How many of the forty seats have been claimed
Who claimed them, once they've entered their names
Who has logged in since, and who activated a code and never came back
That last group is gold — unused codes a week before the start date are the earliest warning you get that an intake will under-deliver.
And give the buyer their own view. Most "my code doesn't work" emails aren't about broken codes. They're about a coordinator who doesn't know which codes they sent out, or whether someone who says they didn't get one actually did. If the buyer can see their own seats and their status, that entire category of email stops.
Three practical rules for the codes
If you go this route, the details matter more than they sound:
Leave out ambiguous characters. Drop I, O, 0 and 1 from the alphabet. Codes get read over the phone and typed in a hurry — every look-alike character you remove is a support ticket you don't get.
Don't require an email address to redeem one. The moment email is mandatory, you've excluded younger learners entirely and added friction for everyone else. Let people add an email later if they want one.
Make each code single-purpose. One code, one seat, one learner. Codes that work more than once quietly turn back into shared logins.
Why this matters
Bulk enrollment feels like an administrative annoyance, but it's really a modeling error. Most platforms were designed around a consumer buying a course for themselves — buyer and learner are the same person. Training businesses are B2B2C. Someone buys on behalf of someone else. Every workaround above is the cost of forcing that shape into a model that doesn't fit.
Once seats and learners are separate things, the name list stops being a blocker. It becomes something that fills in on its own.
LMSFlex is built around exactly this model. You sell seats, learners redeem codes, and accounts create themselves on first use. No email required. See how access works or book a demo.
Follow us
Flexible Learning Management System
LMSFLEX
CREATE
About
Contact
RESOURCES
Forum & Private Notes
Homework Submissions
Learner Accounts
Module Assessments
COMPANY
Educational Instutions
Boutique Consultancies
Onboarding Training
Team Trainings
AI Course Builder
AI Course Interactions
AI Voiceover
Lesson Editor & Blocks
Layout Management
USECASES
PUBLISH
ENROLL
Cohort Publishing
Landing Page Builder
Storefront & Enquiries
ENGAGE
Seats & Access Codes
Buyer Portal
Learner Accounts