You Don’t Have to Teach Everything Yourself

You started the course. You’re good at the part you know. But your catalog has a ceiling the moment it depends on one person’s calendar, one person’s expertise, and one person’s willingness to keep recording new lessons.

Every course platform will tell you to “add more content.” Almost none of them tell you how to add more people without turning your back end into a mess of shared logins, manual spreadsheets, and end-of-month guesswork about who gets paid what.

This is the one feature that changes what your course business actually is: a single-instructor operation, or a marketplace with your name on the roof. It’s also the feature most course creators put off the longest, because it looks like an operational headache rather than a growth lever, right up until the day a promising new hire or a genuinely brilliant guest expert asks “so how does the money work if I teach here,” and you realize you don’t have an answer better than “let’s figure it out.”

The single-instructor ceiling is real, and it’s not about talent

If you’re the only instructor on your site, your catalog grows exactly as fast as you can teach. That’s it. There is no shortcut around a calendar. You can batch-record for a weekend, but you can’t be in two subjects at once, and you can’t personally have expertise in cloud security, UI design, and Kotlin, unless you actually are all three of those people.

The moment you decide to bring in someone else who is those people, a new set of problems shows up that has nothing to do with teaching:

• Who owns the course listing if two people worked on it?
• Does the guest instructor see revenue numbers for courses that aren’t theirs?
• What happens when they leave, or when you want to reduce their cut because they’re doing less work on it than the person who built the curriculum from scratch?
• How do you pay them, on what schedule, and how do you know the number is right?

Most plugins solve exactly none of this. They give you one “instructor” role, tied to a single WordPress user, and if you want a second person on a course, your only options are giving them the admin’s own login or writing the split down in a shared Google Sheet. Neither scales past a handful of courses, and both are a liability the day someone disputes what they’re owed.

There’s a quieter cost too. Sharing a login means you can’t tell who actually did what. If two people have the same admin credentials, you have no record of which of them uploaded the broken video, changed the price without asking, or refunded a student out of turn. The spreadsheet has the same problem in reverse, it captures an agreement, but it enforces nothing. The plugin still pays out however it was already going to pay out, and the spreadsheet is just a promise sitting next to the real system.

We looked at this from the other side: how many instructors does a course actually need to name, who among them should touch money, and how do you let someone in on the business without giving them the keys to the building.

Real numbers: what a multi-instructor catalog looks like day one

We pulled this directly from a working Learnomy install, not a demo screenshot staged for a blog post. Here’s the Instructors screen as it actually renders, with 26 real instructor accounts already active.

Notice what this list leads with. Not “manage instructor,” a generic label, five columns that answer the questions an admin actually asks when they open this screen: how many courses does this person teach, how much have they earned across their time on the platform, and how much of that is sitting unpaid right now. Olusegun Adeyemi: 12 courses, $448.70 lifetime, all of it pending. Wei Zhang: 6 courses, $571.90 lifetime, all pending. Sofia Martins: 5 courses, $0.00, she’s active but hasn’t generated a sale yet, and the dashboard shows that plainly instead of hiding a zero.

There’s also an Applications tab sitting right next to Instructors, currently showing 19 pending. That’s not decorative. It means becoming an instructor on this site is a workflow with a gate, not a WordPress role you assign by hand in Users. Someone applies, someone reviews, someone approves, and only after approval does that person show up in the roster with courses and payouts attached to their name.

This matters more than it sounds like it should. The difference between “instructor” being a checkbox on a user profile and “instructor” being an application-reviewed status is the difference between a course library and a marketplace with quality control.

There’s also a Joined column, sortable, showing when each instructor came on board, every account on this install joined June 12, 2026, which tells you this roster was seeded in a batch rather than trickling in one signup at a time. On a live site that column is how you’d spot your newest instructors at a glance, or sort the other direction to see who’s been generating revenue the longest. And next to every row sit two actions that matter more than they look: View and Suspend. Neither is decorative, and the second one is worth its own section, because “removing an instructor” is one of those operations that sounds simple until you think through what happens to the courses they’re on.

How an application actually becomes an instructor

That Applications (19) badge is the front door. Before anyone shows up in the Instructors list with courses and payouts attached to their name, they’ve gone through a request-and-review step that never touches your user table directly. Someone fills out an application, presumably describing what they teach and why, and it sits in a queue exactly like the 19 waiting right now, until an admin looks at it and makes a call.

This is the detail that separates a “marketplace” from “a site where anyone with an account can upload a course.” Think about what happens without that gate: your Instructors screen would just mirror your Users screen, filtered by role. Anyone who registers could self-assign as an instructor, publish a course, and start showing up in commission calculations before you’d ever evaluated whether they should be teaching on your platform at all. The application queue means every name in that 26-instructor list passed a decision, even if that decision was made in a batch, even if it was “approve everyone who applied this month”, rather than existing by default.

For a site owner, that’s the difference between curating who represents your brand and just hosting whoever shows up. If you’re running a professional cohort platform, say, a coding bootcamp brand with a reputation to protect, that gate is not optional. You cannot have your name on a course taught by someone you’ve never vetted.

Removing someone without breaking their courses

Eventually, an instructor relationship ends. Maybe they’ve moved on, maybe there’s a dispute, maybe they’ve simply stopped being active and you need to reassign their courses to someone else. This is the scenario where badly-designed instructor systems fall apart, because deleting a WordPress user usually means deleting, or silently orphaning, everything tied to that user ID: their courses, their enrollment records, their transaction history.

The Suspend action on the Instructors list exists specifically to avoid that. Suspending an instructor is not the same operation as deleting their account. A suspended instructor stops being able to act, no new courses, no editing existing ones, no dashboard access, but their existing courses, the students already enrolled in them, and the revenue history attached to their name don’t disappear. The course detail screen’s Primary Instructor dropdown still shows who built the thing; the Earnings ledger still shows what they earned before suspension. You’ve cut off the relationship going forward without rewriting history or leaving five enrolled students staring at a 404.

This matters because “instructor” isn’t just a content label, it’s a party in a financial relationship with pending payouts and lifetime totals attached. A destructive delete on that kind of record is a liability. A suspend is a status change, reversible, auditable, and safe to use the moment a relationship needs to end without waiting for a clean transition plan.

Assigning instructors per course, not per site

Here’s where most plugins get the model wrong. They treat “instructor” as a global site role, you’re either an instructor everywhere, or you’re not an instructor at all. That’s backwards for how teaching teams actually work. The person who co-built your React course might have contributed nothing to your Cloud Security course, and shouldn’t have any claim on it.

Learnomy assigns instructor relationships at the course level. Open any course’s detail screen and you’ll find a dedicated Instructors & commission section, not a single dropdown, but a real ownership model with a primary instructor and a roster of eligible co-instructors.

Look at what’s actually happening in that screenshot. Maya Chen is set as the Primary Instructor for this course, “React Fundamentals: Build Your First 3 Apps”, and she’s the one shown as the course’s face and the one whose commission the sale is calculated against. Below her, every other instructor account on the site (Aisha Hassan, Arjun Patel, Avery Perry, Christian Bishop, and on down the alphabetical list to Wei Zhang) appears as a Co-Instructor checkbox, unchecked by default. You check the ones who actually contributed to this course. Nobody gets swept in by accident, and nobody is locked out because they weren’t the one who hit “publish.”

This is the part that makes multi-instructor courses workable instead of theoretical: assignment is explicit, per course, and reversible. If Maya brings on a co-instructor for the next module, that’s a checkbox, not a support ticket.

Commission that resolves per course, with a real default

The harder problem than “who’s on the course” is “how much does each person get.” A flat site-wide split sounds simple until you actually run a catalog for a few months. Some instructors bring their own audience and deserve a bigger cut. Some courses need heavier platform support (hosting, marketing, support tickets) and justify the platform keeping more. A single number for the whole site can’t represent both realities at once.

Learnomy’s actual default, visible in the Earnings screen, is an Instructor 70% / Platform 30% split, set once in Settings, and used automatically unless something more specific overrides it.

That “unless” is the interesting part. Right on the course detail page, under Instructors & commission, there’s a Platform commission field showing the real number for this specific course:

48.61% for this Course, “The platform keeps this percentage; the Instructor gets the rest.”

That’s not 30%. That’s a course-specific override, sitting well above the site default, saved with its own Save button right there in the course editor. Maya Chen is earning 51.39% on this particular course instead of the standard 70%, and that number was set deliberately for this course, not inherited blindly from a global setting.

The Earnings screen shows the same override mechanism operating across the whole catalog, not just one course:

The Commission Rules panel here is doing real work. It reads: “Default split: Instructor 70.00% / platform 30.00% (change in Settings). Add a rule below to override it for a specific Course or Instructor.” Below that is a live table of actual overrides already in effect on this install:

Course	Instructor Rate
Figma for UI Design: Complete Beginner to Pro	70.66%
Cloud Security: AWS, Azure & GCP Best Practices	66.82%
Terraform: Infrastructure as Code for Beginners	65.61%
Kotlin Multiplatform: Share Code Across Platforms	69.85%

Every one of those is a real, saved, per-course rate that differs from the 70% baseline and from each other. That’s a rules engine, not a single toggle. You can override by Course or by Instructor, the dropdown at the top of the panel offers both, so a top instructor can get a better rate across everything they teach, while a specific high-cost course can carry its own number regardless of who’s on it. Whichever rule is more specific wins; the site default only applies when nothing more targeted has been set.

Money you can actually reconcile

None of this matters if the numbers on screen don’t add up to something real. Look again at the Earnings dashboard totals: $12,266.03 lifetime revenue, $5,199.38 pending withdrawals, 43 active subscribers generating $489.14 monthly recurring. These aren’t placeholder stats, they’re the same figures a site owner would pull before running a payout batch or reconciling a month-end report.

That reconciliation depends entirely on the commission math being deterministic and per-transaction, not an estimate calculated at export time. Because every course carries its own resolved commission rate (course override, then instructor override, then site default, in that order of precedence), every sale on that course can be split correctly the moment it happens. The instructor’s “lifetime earned” number on the Instructors list and the “pending withdrawals” total on the Earnings page are two views into the same underlying ledger, not two systems that might drift apart.

This is also why the instructor list shows pending payout as its own column, separate from lifetime earned. Olusegun Adeyemi’s $448.70 lifetime and $448.70 pending are currently identical, meaning nothing has been paid out yet. The moment a payout runs, that pending number drops while lifetime stays fixed, a paper trail an admin can audit without opening a spreadsheet.

Why the application gate matters as much as the commission math

It would be easy to treat the 19 pending applications as a minor detail next to the commission engine, but it’s the other half of the same decision: who gets to be an instructor on your site in the first place. A commission system with no gate on entry just means anyone with a login can list a course and start collecting a cut. An application review step means every instructor on your roster passed a decision point a real person made.

That single design choice is what turns “a plugin that lets multiple people upload lessons” into “a marketplace you’d actually put your brand on.” The commission engine handles the money once someone is in. The application queue decides who gets in.

Three ways site owners actually use this

The feature reads as one system, but in practice it supports a few very different businesses, and it’s worth being specific about which one you are, because that changes how you’ll use the commission overrides.

The specialist-recruiter. You’re the primary instructor on most of your catalog, and you occasionally bring in someone with expertise you don’t have, a security specialist for one course, a Kotlin developer for another. You stay the face of the brand; the guest instructor gets a fair cut on the specific course they built, set as a course-level override, and nothing else on your site changes. This is the lightest use of the system: one or two overrides, most courses left on the site default.

The co-teaching partnership. Two or more people build a course together as genuine equals, one handles curriculum and video, the other handles quizzes and grading. Here the primary/co-instructor split isn’t really about seniority, it’s about who’s the named face for support and student questions. The commission override on a course like this often lands close to a 50/50 instructor-side split between the partners, negotiated once and set as a course override, exactly like the 48.61% platform commission we saw on “React Fundamentals” translating to just over half going to Maya Chen and the remainder available to split or absorbed by the platform depending on how the course was staffed.

The open marketplace. You’re not personally teaching much of anything, your business is building a course marketplace that curates other people’s courses under one platform, the way the 26-instructor roster on this install suggests. Here the application queue is your quality gate, the per-instructor commission override (not just per-course) becomes the more useful tool, since you’re negotiating a standing rate with each instructor rather than course-by-course, and the site-default 70/30 split becomes the floor most instructors start at before you negotiate anything better for your top performers.

None of these are hypothetical feature combinations we’re imagining could work, they’re three different ways to read the exact same admin screens we’ve shown throughout this article, using the same rule-precedence engine (course override, then instructor override, then site default) to get three different business models out of one plugin.

Common questions before you turn this on

Does a co-instructor get their own dashboard? Co-instructors are added at the course level through the checkbox list on the course detail screen, distinct from the primary instructor who’s shown as the course’s face and paid its commission. If you’re planning a course with genuine co-teaching, decide upfront who’s primary, that’s the person the commission percentage is calculated against, and the one whose name the platform surfaces to students.

What happens to the commission if I change the primary instructor mid-course? The Primary Instructor field is a live dropdown on the course editor, and the Platform commission override sits right next to it with its own Save button. Changing the primary instructor doesn’t automatically change the commission rate, the override is attached to the course, not the person, so if a new primary instructor negotiated a different rate, that’s a separate edit to the Platform commission field.

Can I set a different commission for the same instructor across different courses? Yes, the Commission Rules panel on the Earnings screen offers overrides by Course or by Instructor, and they’re separate rule types. An instructor-level rule sets a standing rate for everything that person teaches; a course-level rule (like the four we saw in the live table, Figma at 70.66%, Cloud Security at 66.82%, Terraform at 65.61%, Kotlin at 69.85%) overrides just that one listing regardless of who’s teaching it. When both could apply, the more specific course-level rule wins.

Is the pending payout number live, or does it need to be recalculated? It’s a running total maintained as sales happen, which is why it moves in lockstep with lifetime earned until a payout actually runs. That’s what makes it usable for a real payout process, an admin can trust the number on screen without cross-checking it against a separate report first.

What actually happens to a suspended instructor’s existing students? Nothing changes for them. Suspension is a status on the instructor’s ability to act going forward, publish, edit, access their dashboard, not a deletion of their courses, enrollments, or transaction history. Students already enrolled keep their access exactly as it was.

What this actually unlocks for you

If you’ve been putting off bringing in co-instructors because the back-end math felt like more work than it was worth, that math is already built:

• Recruit instructors with a real intake process instead of handing out admin passwords. Nineteen people can be sitting in your applications queue right now, and none of them have touched your database until you approve them.
• Assign co-instructors per course, not per site, so contributor lists stay accurate as your catalog grows and specializes.
• Negotiate rates that make sense per course or per instructor, using overrides instead of forcing every deal through one flat percentage that’s wrong for half your catalog.
• Reconcile payouts against a single source of truth, lifetime earned, pending payout, and the commission rule that produced each number, all visible in the same place you approved the instructor in.

You didn’t start a course business to become a full-time accountant for other people’s teaching. The point of a commission engine that resolves correctly on its own is that you don’t have to be. Bring in the person who actually knows cloud security, set their rate once, and let the platform handle the part that used to require a spreadsheet and a level of trust nobody should have to extend on a handshake.

If this is the feature your platform search hinges on, our comparison of the best LMS plugins with multi-instructor support walks through how each one handles roles, commission splits, and payouts.

Setting it up: what to decide before your first co-instructor

If you’re moving from a single-instructor site to a multi-instructor one, the mechanics are already built, but a few decisions are worth making deliberately rather than defaulting into them.

Set your site-wide default first, and set it low enough to negotiate up from. The 70/30 instructor/platform split we found on this install is a reasonable starting point, generous enough to attract instructors, high enough on the platform side to cover hosting, support, and the work of running the marketplace. Whatever number you choose in Settings becomes the floor every course and every instructor starts from unless you override it, so pick a number you’re comfortable defending to your first ten instructors, not just your first one.

Decide who reviews applications, and how fast. A queue of 19 pending applications is only a quality gate if someone is actually working through it. An application sitting unreviewed for three weeks isn’t curation, it’s a bottleneck that will cost you instructors who found somewhere else to publish while they waited. If you’re running this as a real marketplace, treat the Applications tab as a standing task, not a folder you check when you remember to.

Reserve course-level overrides for exceptions, not your entire catalog. The four course-specific rates we saw live on this install (ranging from 65.61% to 70.66% instructor-side) work precisely because they’re exceptions to a clear default, each one presumably reflecting something specific about that course or that negotiation. If every course on your site ends up with its own hand-set override, you’ve effectively abandoned the default and turned a rules engine back into a spreadsheet, just one hosted inside your admin instead of in a separate file. Use instructor-level overrides for standing relationships and course-level overrides for genuine one-offs, and the system stays legible six months from now when you’re trying to remember why a specific number is what it is.

Decide your suspension policy before you need it. It’s much easier to write down “we suspend an instructor’s access after 90 days of inactivity, or immediately on a policy violation” while you’re calm and setting up the system than to decide it in the middle of an actual dispute with a real person’s payout on the line. The mechanism is safe either way, suspension doesn’t touch existing students or history, but having a policy means you’re not inventing the rule under pressure.

None of this is complicated once you’ve decided it. The plugin isn’t asking you to build a legal framework; it’s asking you to make four small decisions once, so that the commission math, the application queue, and the suspend button all have a clear policy behind them instead of being configured ad hoc, course by course, as problems come up.