SAM Instructional Design: The Successive Approximation Model

Go from storyboard to an interactive course in minutes

Start Free

Take a hypothetical retail chain that asks for a course on customer returns. The training team spends six weeks on analysis and a design document, which store managers approve without reading closely. Within a week of launch, managers say the course spends three pages on policy and never shows staff what to do when a customer has no receipt. Every page matched the approved design. The design was wrong, and nobody saw it until it was finished.

SAM, the Successive Approximation Model, is Michael Allen's iterative model for building training: instead of waiting for a complete design document, SAM puts a rough prototype in front of the people who know the job early, improves it in short review rounds, and releases it as alpha, beta and gold. (It is unrelated to successive approximation in psychology and ABA therapy.) I prototype courses most weeks as an instructional designer at Coursebox, where we make instructional design software.

What is the SAM model of instructional design?

SAM is an agile model for designing and developing training in which you create and test rough versions of the learning experience early, then improve them through repeated rounds of review. Michael Allen, CEO of Allen Interactions, set it out with Richard Sites in Leaving ADDIE for SAM (ASTD Press, 2012). Allen says the process had been tested and revised since the late 1970s, long before the book gave it a name.

People are better at reacting to something they can see than at describing what they want in advance. So SAM spends less time on upfront analysis and more on showing stakeholders a prototype and asking what is wrong with it.

There are two versions:

In 2026 the Allen Interactions about page still lists SAM as one of its two core methodologies, alongside the CCAF design framework (context, challenge, activity, feedback). The way I read them, CCAF shapes what each learning activity looks like and SAM is the process for building it.

Case study: Sales training at AutoNation

In Allen Interactions’ AutoNation case study, the dealer needed training that would improve sales conversations without keeping staff away from the sales floor. Its workforce included over 20,000 sales associates; that is not the pilot sample size.

The team used SAM and CCAF to develop blended training with realistic challenges, spaced practice and classroom role-plays. Stakeholders and recent learners helped identify the performance problems.

The vendor reports a 22% productivity increase and a month-three sales-menu close rate of 57% in the redesigned-training pilot versus 43% in the existing-training control. The report is undated and does not explain group selection or isolate SAM from the other changes.

Practical lesson: prototype the sales conversation and plan workplace measures early. A better development process still needs evidence that people perform differently.

The three phases of SAM2, worked through one course

For this hypothetical project, a retail chain with 40 stores needs new and casual staff to handle returns under its policy, including customers who have no receipt. The course should let staff practise the conversation and choose the correct action, rather than just read the rules. Two store managers, a customer service lead and the training lead will review the prototypes. This is a useful SAM example because a rough customer interaction can expose a missing design requirement before the full course is built.

Phase 1: Preparation

Preparation is short on purpose. It has two parts.

• Backgrounding: collect what already exists. The current returns policy, the most common complaints, any past training, and who will sign off. Allen suggests asking a blunt question at this stage: why shouldn't we do this? It surfaces the risks and the people who doubt the project before you build anything.
• Savvy Start: a working session, from half a day to three days or sometimes longer, with the people who own the problem. The group starts from the final learning experience and works backwards, the prototyper builds rough versions in the room, and everyone reacts. Allen's own materials place it sometimes at the end of preparation and sometimes at the start of iterative design; either way it comes before detailed production; the workshop itself is design work. Allen's guidance lists who should attend: the budget maker, the owner of the performance problem, a supervisor of the learners, a subject-matter expert, potential learners, recent learners, a project manager, the instructional designer and a prototyper.

In the returns example, the Savvy Start takes one day. Within an hour of seeing a rough scenario on screen, a store manager says the real problem is customers with no receipt who get angry when they are refused. The policy pages the training lead planned to lead with go to the bottom of the list.

The Savvy Start ends with a priority sort. Allen's version uses four labels:

Phase 2: Iterative design

Iterative design turns the Savvy Start's rough ideas into a design the team can build from. The team plans the project, then keeps designing and prototyping the remaining content in short rounds with the same reviewers.

Allen's breadth-before-depth guidance is to give every content type its initial design rounds before concentrating effort on one area. For the returns course, rough out no-receipt returns, exchanges and faulty items before polishing any one of them. The risk is spending the budget on one attractive section while neglecting more important needs.

Seven customers who wrote to our support team after their first AI draft asked to revise it rather than replace it: new objectives, a missing lesson, images added without touching the text. One coaching business asked for a keep, fix and rebuild plan and told us to change nothing until they had approved it, which is how a SAM review round should run.

Phase 3: Iterative development

Development starts with a design proof, then builds the course in three releases, each reviewed before the next:

• Design proof: a sample built with the real tools, content style and platform. It tests the production system as much as the content. Does it run on the stores' tablets? Do the scenarios load on the LMS?
• Alpha: the first complete version, with all content planned for this release in place, including the Threshold requirements. Reviewers work through it and list fixes.
• Beta: the corrected version. Allen says the errors left at beta "should include only minor typographical errors". If bigger problems show up, the team fixes them and runs another beta. In our support inbox, creators often ask how to share a finished course with a few testers before going public, which is a beta by another name.
• Gold: the version that goes live. Allen is clear that no project reaches perfection; gold means the agreed release criteria are met. Accuracy, accessibility, functionality and any required compliance checks must pass; only non-critical improvements belong on the later-release list.

Case study: A biostatistics e-course in Kazakhstan

A 2026 Karaganda Medical University study describes a five-module Moodle course developed with SAM and an AI assistant. Each module went through three to six iterations, with eight-student focus groups informing revisions.

Of 215 students surveyed, 64.7% agreed or strongly agreed that the course improved their understanding of biostatistics. This is perceived understanding, not a measured increase caused by SAM. There was no control group.

Practical lesson: use learner feedback to change explanations, visuals and question difficulty. The team also required no critical technical failures before advancing a module, rather than relying on an average rating alone.

Case study: An augmented reality fracture-training app in Iran

Researchers at Mashhad University of Medical Sciences describe the VASHA augmented reality training app for recognising missed fractures. A multidisciplinary team used SAM and stakeholder evaluations to refine the app.

Across 46 participants, mean test scores rose from 13.91 before training to 18.08 afterward (p < 0.001). Without a control group, the result does not establish that SAM caused the improvement or that the app outperformed another approach.

Practical lesson: involve clinical experts and intended learners in reviews, then assess learning separately from whether reviewers approve the prototype.

Running a SAM review round in Coursebox

In my experience, SAM's bottleneck was the prototype. A clickable version took days to build, which is why review rounds got cut. So on 6 October 2026 I ran a returns course for retail staff through Coursebox, the course builder we make, the way a SAM team would.

I gave it the three things staff must be able to do: process a standard return, handle a no-receipt return under a store-credit policy, and refuse a refund politely when policy says no. I asked for one practice scenario and one role-play, and no long policy reading. The first prototype covered all of it: a no-receipt practice activity called "The Missing Receipt", a refund-refusal role-play, calm-conversation practice and two short checks. It was bigger than I asked for, at six sections, 10 pages and about 48 minutes, which is normal for a first version and exactly what a review round is for.

Then I sent a review round written the way a store manager would, as numbered changes: put no-receipt returns first because staff get those wrong most often, put calm conversations and refund refusals next, move standard returns to the end, cut the introduction section, and add no new pages.

The revision applied all five changes. No-receipt returns opened the course, the conversation and refusal sections followed, standard returns moved to the end, the introduction was gone and the page count dropped from 10 to 9. Numbered, specific feedback is what made the round work; it is the same discipline that makes a human prototyper's round work. I still compare each revision with the request, and the iteration log keeps that record.

This was a test of outline generation and revision rather than a finished clickable prototype or a measure of learner performance.

SAM vs ADDIE

The useful comparison is how you organise feedback. ADDIE organises work into analysis, design, development, implementation and evaluation. It can include prototypes and formative evaluation throughout. SAM makes short prototype-and-review cycles explicit. Its contrast is strongest with a phase-gated implementation of ADDIE, not every use of ADDIE.

In practice many teams use a hybrid: ADDIE's analysis and evaluation around SAM's design and build rounds. If you want a model even closer to software development, agile instructional design and Megan Torrance's LLAMA approach work in sprints that each deliver finished, usable pieces. Lou Russell draws the contrast this way: delivering complete components in sprints "is not prototyping".

When SAM does not work well

• Reviewers who cannot show up. SAM depends on the same people reacting in short, regular rounds. If the store managers can only meet once a month, rounds stall and the advantage disappears.
• Heavy regulation and audit. A 2026 paper from the Saudi Commission for Health Specialties describes SAM as "harder to govern in regulated settings" and stronger "when the deliverable is exploratory, and the audit burden is light".
• No exit rules. Without an agreed definition of done for each round, iteration turns into endless revision. The priority list and the beta rule are there to stop it.
• A team that has not learned it. SAM looks simple on paper, and it is easy to end up running it as ADDIE with extra meetings.
• Thin research base. The cases reviewed here include a vendor report and uncontrolled studies. They show how teams used SAM, but do not establish that SAM produces better learning than ADDIE. This is a focused source review, not a systematic review of all SAM research.

How to run a lightweight SAM project in six steps

1. Background in days, not weeks. Collect existing material, ask "why shouldn't we do this?", and book the Savvy Start.
2. Run the Savvy Start with the right people. Budget maker, problem owner, supervisor, subject-matter expert, potential and recent learners, and a prototyper. Leave with rough prototypes and a priority list.
3. Agree reviewers, dates and exit rules. Same reviewers every round, on a fixed rhythm, with a written definition of done.
4. Prototype breadth before depth. Rough out every content type before polishing any.
5. Build a design proof on the real platform. Catch technical problems before alpha, not after.
6. Release alpha, beta and gold. Resolve major issues during alpha. If a serious problem appears at beta, fix it and repeat the review. Release only after the agreed checks pass; defer non-critical improvements.

If you want a lighter version of the same idea for a single module, rapid prototyping in instructional design covers it.

Make each SAM review change the design

SAM is useful when an early prototype helps learners, experts and the project owner discover what the training should become. Repeated reviews can change the design before the team invests in a polished build. If feedback is collected but decisions are already fixed, the project has lost much of that benefit.

Before the Savvy Start, agree the performance problem, bring the people who can make decisions and reserve their time for the next reviews. Prototype enough of the course to expose different learning and technical risks, then record what each round changed. Release only after the agreed checks pass. A short review cycle is useful when it produces better decisions and a learning experience ready for its audience.