How to scope an onboarding e-learning module: 12 questions to answer before you buy

Most onboarding e-learning projects that go sideways don't fail in production. They fail in the first conversation, when nobody wrote down who the module is for, what people should do differently after it, or who has the final say on the script. By the time those gaps show up, the storyboard is half built and every fix costs a review round.

This is the list I walk through with teams before quoting a custom onboarding module. You don't need perfect answers to all twelve. But if you can answer most of them in a page, any studio you talk to (including mine) can give you a firmer price, a realistic date and fewer surprises.

Start with the learner, not the content

1. Who exactly is the new hire?

"New employees" is not a learner profile. Write down the role, where they work (desk, warehouse floor, field, retail), what device they will open the module on, and what they already know on day one. A new operations coordinator who came from another logistics company needs something very different from a graduate in their first full-time job.

2. When in the onboarding journey does this module run?

Pre-boarding, day one, the end of week one and the end of month one are four different modules. Before their first day, people want reassurance and logistics. In week two, they want to know how to handle the situation that just confused them. The timing changes the tone, the length and the examples.

3. What should people do differently afterward?

This is the question that saves the most money. Phrase the outcomes as observable behaviors: "logs a safety incident in the right system within the shift", not "understands our safety culture". If you can't name two or three behaviors, the module will drift toward a tour of the org chart, and that is the kind of content people click through without reading.

Pin down the material and the experts

4. What source material already exists?

List it: slide decks, policy PDFs, SOPs, a recorded welcome session, a handbook. Note which pieces are current and which are "mostly right". A studio can build from imperfect material, but it needs to know which document wins when two of them disagree.

5. Who is the subject-matter expert, and how much time do they have?

Every onboarding module needs at least one person who knows how the work is really done, not how the policy says it's done. Agree up front on how many hours they can give: usually a workshop at the start and two short reviews. If the expert is only available on Fridays, the schedule has to reflect that.

6. Who approves, and how many reviewers are there?

One accountable approver per review keeps a project on schedule. Five reviewers with equal veto power will each want a different module. Decide who signs off on the script and who signs off on the final version, and give everyone else a clear window to comment through that person.

Decide the format before you compare quotes

7. How long should it take a learner?

Onboarding modules tend to work best when they are a focused block of time rather than an afternoon. Be explicit about the target: "about an hour of learning, split into pieces people can finish in one sitting" gives a studio something to design to. Length is also the biggest driver of price, so two quotes for "an onboarding course" are only comparable if they assume the same learning time.

8. Which pieces does it need?

A typical custom module combines some of these:

• a short video that sets context and shows what good looks like;
• an interactive guide or set of short chapters with practice questions;
• a scenario where learners make decisions and see consequences;
• a job aid or checklist they keep after the module ends.

You don't need all of them. But you should know which ones you are paying for, how long each runs, and what "interactive" means in the quote. "Click next to continue" is not interactivity.

9. How will you know it worked?

Decide what you will measure before anything is built: completion, a passing score, a scenario outcome, or a behavior your managers can observe in week two. This drives the assessment design and the data the module sends to your LMS. If you want more than completion and a score, raise it now, because it affects the technical standard (see question 10).

Settle the technical and legal details early

10. Which LMS, and which standard?

Name the LMS and ask your admin which packaging standards it accepts. Most corporate LMSs accept SCORM 1.2, and many also accept SCORM 2004 or xAPI. If you can, ask for a sandbox account so the studio can test the package in your actual system before handoff. It's the simplest way to avoid a launch-day surprise. I wrote more about choosing between standards in SCORM vs. xAPI for onboarding.

11. What are your accessibility and brand requirements?

If your organization has an accessibility policy, share it at the start. The Web Content Accessibility Guidelines (WCAG) 2.1 (opens in a new tab) at level AA is a common target for corporate learning: captions, keyboard navigation, contrast and a structure screen readers can follow. Share your brand guidelines too, and say whether the module should look like your intranet or can have its own visual style.

12. Who owns the files afterward?

Ask what you receive at the end: the SCORM packages only, or also the source files, the script and the video files with captions. Ask whether you can edit the module yourself later, and in what tool. Policies change, and an onboarding module that only the vendor can update gets out of date quickly.

Put it on one page

Once you have answers, fit them on a single page:

Topic	What to write down
Learner	Role, setting, device, prior knowledge
Timing	Where the module sits in the onboarding journey
Outcomes	Two or three observable behaviors
Material	Documents, which ones are current, which one wins
People	Subject-matter expert hours, one approver per review
Format	Target learning time and the pieces you want
Measurement	What you track and where it is reported
Technical	LMS, standard, sandbox, accessibility target
Ownership	Files you receive and how you will update them

That page is your brief. It lets you compare quotes on the same basis, and it gives the studio's discovery workshop a head start instead of a blank whiteboard.

What to watch for in the quotes you get back

With the brief in hand, three things separate a quote you can rely on from one that will grow:

• A fixed scope per module, stated in learning time and pieces, not just "one course".
• A named number of review rounds, and what happens if you need another one.
• A date that starts from a clear event, such as the kickoff workshop, with an explicit rule for what happens to the date when a review takes longer than planned.

If a quote is vague on any of these, ask. The answers tell you more about how the project will run than the portfolio does.

---

If you'd like a second pair of eyes on your brief, book a 30-minute call. We'll go through these questions with your material in front of us, and you'll leave with a scope you can take to your stakeholders. You can also look through a complete sample module to see what one version of these answers looks like in practice.