A course build runs late far more often because of how it was reviewed than because of how it was developed. The development time is predictable. The number of review rounds, and how long each one sits waiting for someone to respond, is not.
Most eLearning projects run three review stages after the storyboard – alpha, beta, and gold master – and each one exists to catch a different kind of problem. Treating them as three chances to change your mind is what turns a six-week project into a four-month one.
What each round is actually for
| Stage | What you are looking at | What you should be checking |
|---|---|---|
| Alpha | The course fully built, with draft media and placeholder voice-over | Content accuracy, flow, interactions, whether it teaches |
| Beta | Alpha with every agreed fix applied, plus final audio and media | That your comments were applied correctly, and nothing broke |
| Gold | The final package, tested on the LMS | That it launches, tracks, and reports properly |
Two review rounds are the norm: one at alpha and one to verify the beta. Gold is a confirmation, not an opportunity.
Alpha: the round that matters
Alpha is where you have real influence. The course exists, you can click through it, and you can finally see whether the thing you approved on paper works as a learning experience. Review it as a learner, not an editor: take it start to finish at normal speed, without skipping, then go back and write up what you found.
- Anything factually wrong or out of date
- Interactions that do not behave as expected
- Sequences that confuse rather than teach
- Assessment questions that are ambiguous or test the wrong thing
- Missing content a learner would reasonably need
What not to spend alpha on: placeholder images, draft narration quality, and anything the project already agreed to exclude. Those are not defects.
Beta: verification, not a second opinion
Beta is the same course with your alpha comments applied and the final media in place. The job here is narrow: check that each comment was actioned as you meant it, and that applying it did not break something nearby.
This is where projects most often slip, because beta is where a reviewer who was busy during alpha finally opens the course and starts raising new points. They may be perfectly valid. They are also change requests against an approved alpha, and they cost time nobody budgeted. The fix is simple and unpopular: get the right people to look at alpha.
Gold master and deployment
Gold is the finished package, published to your SCORM or xAPI requirement and tested on the destination LMS. Checks here are technical, not editorial:
- The course launches on your LMS, in the browsers your learners use
- Completion and scores report back correctly
- Bookmarking resumes where the learner stopped
- Source files and assets are handed over
If editorial comments appear at gold, something went wrong earlier in the process.
How to give feedback that does not cost you a week
- Consolidate. One file, one voice. Five reviewers sending separate emails produces contradictions that we cannot resolve for you, so the file comes back to you anyway.
- Be specific about location. Screen number and the exact text being changed. "The bit about safety" costs an hour of hunting.
- Say what it should be, not what is wrong with it. "Change to: …" is actionable. "This doesn't read well" is a second conversation.
- Resolve disagreements before sending. If two experts want opposite things, decide internally first.
- Send it in one go. Rolling feedback over four days means the developer starts, stops, and reworks.
Where scope creep actually starts
Scope creep rarely arrives as a big request. It arrives as a sequence of small ones, each reasonable on its own: one more scenario, a different assessment, a new section because a policy changed. Handled openly that is fine. What causes trouble is absorbing it silently, because then there is no record of why the date moved. If a request falls outside what was agreed at storyboard sign-off, you should hear its cost and schedule impact before it is done, not after.
Frequently asked questions
How many review rounds do we get?
Two are standard: alpha and a beta verification. More can be arranged, and are quoted as additional rounds. Changes that reopen an approved storyboard are handled as change requests.
How long should we take over a review?
Agree the window at kickoff and put it in the schedule. A review that was planned for five days and takes three weeks moves the launch date by more than the delay, because the team has to be scheduled back on.
Who should review?
The subject-matter expert, someone who represents the learners, and Legal or Compliance if the content is regulated. All of them at alpha, not spread across the rounds.
Does this change when the course is multilingual?
Yes, and significantly. Every alpha change multiplies across the languages, so the English version should be fully signed off before translation starts. Our localization guide explains how the two schedules fit together.
The round before all of this is the one that decides the rest. See our post on why the storyboard is where course projects succeed or fail, or the full route on our process page.
Ready to talk about your course?
Tell us the launch date you need and who has to approve the content, and we will tell you whether the schedule is realistic before you commit to it.
