How to price instructional design services (without undercutting yourself)

Start from outcomes, not hours

Clients buy business outcomes—faster onboarding, fewer errors, compliant launches—not Storyline hours. Anchor proposals to milestones (analysis sign-off, pilot, v1 launch) with clear deliverables.

Hours still matter internally, but public pricing pages and proposals should emphasize what is delivered and what "done" means.

Reframe every conversation from "how many hours will this take" to "what does success look like when this ships." If a client says "we need a 30-minute e-learning module," ask what business problem triggers the request: is it a compliance deadline, a product launch, a spike in customer complaints, or a new-hire ramp problem? The answer changes the design, the scope, and what you charge. A 30-minute compliance module with legal review, three SME passes, and SCORM 2004 packaging for Cornerstone is a fundamentally different project than a 30-minute Rise course for internal awareness—price them differently.

Build your internal rate sheet around effort tiers, not hourly math. A typical tier might look like: Tier 1 is a simple click-through awareness module in Rise with stock assets, one review round, and SCORM 1.2 packaging. Tier 2 is a scenario-based module in Storyline with custom branching, two SME review rounds, quiz with reporting, and SCORM 2004 packaging. Tier 3 is a multi-module program with xAPI instrumentation, facilitator guides, job aids, and a pilot cycle. When you quote a project, slot it into a tier and adjust for audience size, languages, and review complexity rather than counting hours.

When you anchor to milestones, name what the client gets at each gate: "After the analysis phase, you receive a design document with objectives mapped to activities, an estimated seat time, and a storyboard outline for review." That sentence makes the milestone tangible. If the client cancels after analysis, they still received a deliverable they can hand to another vendor—and that clarity is why they trust you enough to start. Milestone payments also protect you: if the project stalls because the client cannot schedule SMEs, your analysis fee is already collected.

Track your actual hours per tier internally for six months. You will discover patterns: Tier 2 projects consistently take 60–80 hours, Tier 3 projects run 120–180 hours depending on review cycles. Use that data to set fixed prices with confidence rather than guessing. If a project blows past your estimate, diagnose why—scope creep, slow SME access, or your own underestimation—and adjust the tier definition, not the next client's bill.

Three pricing patterns that work

Milestone pricing for defined modules, sprint pricing for discovery-heavy work, and advisory retainers for teams that need ongoing oversight. Mixing models is fine if you label boundaries.

Milestone pricing works best when the scope is clear and the deliverable is concrete: "one Storyline module, 20 minutes seat time, SCORM 2004 package, two revision rounds, facilitator guide." Break it into three payments—deposit at kickoff, second payment at storyboard approval, final payment at SCORM delivery. This protects both sides: the client does not pay everything upfront, and you do not deliver everything before getting paid. If the client adds a fourth revision round, that triggers a change order at your revision rate—define that rate in the SOW before signing.

Sprint pricing suits projects where the scope is fuzzy at the start: needs analysis, curriculum mapping, or rapid prototyping for a client who is still figuring out what they want. Price in two-week sprints with a defined output per sprint: "Sprint 1 delivers a needs analysis report and storyboard outline; Sprint 2 delivers a functional prototype in Storyline with one scenario path." The client can stop after any sprint without penalty, and you get paid for completed work. This model is especially useful for new clients where trust is still building—it reduces their risk while giving you predictable income.

Advisory retainers work when a client's internal team builds the content but needs your oversight on design quality, SCORM packaging, accessibility, or LMS configuration. Structure the retainer as a monthly block of hours—typically 10 to 20—with a clear menu of what those hours cover: design reviews, storyboard feedback, SCORM QA, pilot facilitation. Unused hours do not roll over; that keeps the engagement focused. Retainers also position you as a strategic partner rather than a vendor, which leads to longer relationships and referrals.

You can mix models within one engagement: milestone pricing for the build phase, sprint pricing for the discovery phase that precedes it, and an optional retainer for post-launch optimization. Label the boundaries explicitly in your proposal: "Discovery is sprint-priced at $X per two-week sprint; Build is milestone-priced at $Y total; Post-launch retainer is $Z per month for up to 15 hours." Clients appreciate the clarity, and you avoid the trap of a single flat fee that either undervalues your work or overcharges for a simple project.

Portfolio as sales enablement

Your portfolio should host proof aligned to each package: a flagship module for build work, a case study for discovery, and a governance story for retainers.

Map each service tier to a portfolio project that demonstrates what the client will get. If you offer milestone-priced Storyline builds, your flagship case study should walk through a completed module with the SCORM hosted for playback, the storyboard artifact attached, and the outcomes section showing post-pilot metrics. When a prospect asks "what does a Tier 2 project look like?" you send them directly to that project page instead of writing a new email every time.

For discovery and sprint work, create a case study that emphasizes the process more than the final artifact: how you ran stakeholder interviews, what the needs analysis revealed, how you prioritized content, and what the storyboard outline looked like before build began. This helps prospects who are unsure of their own scope—they see that hiring you for discovery is a real deliverable, not a vague consulting engagement. Include a redacted version of a design document or curriculum map if you can, so the prospect can picture the output.

For retainer work, tell a governance story: "We reviewed 14 modules across three quarters, flagged accessibility gaps in seven, and helped the internal team standardize their Storyline templates so new authors produced consistent output from day one." That narrative sells oversight as a value-generating activity, not overhead. If you tracked metrics during the retainer—reduced revision cycles, fewer SCORM packaging errors, faster LMS uploads—include those numbers. They justify the monthly fee in the prospect's mind before they even call you.

Keep your portfolio updated as your pricing evolves. If you stop offering hourly work and shift to packages, remove any language or case studies that imply hourly billing. If you raise rates, update your case studies to reflect the tier of work you want to attract—remove the $500 quick-turn project from your featured section if you now charge $5,000 minimum. Your portfolio trains prospects on what to expect; stale pricing signals attract the wrong clients.

Protecting scope

List what is excluded (translation, LMS admin, endless SME meetings) and how change orders work. Clarity prevents resentment on both sides.

Write your exclusions in plain language, not legalese. A simple bullet list works: "This project does not include: translation or localization, LMS upload and configuration, voiceover recording (we provide scripts; client sources talent), ongoing maintenance after delivery, more than two rounds of SME review." Each item should be something a past client has asked for mid-project—if it has happened once, it will happen again. Adding it to the exclusion list is not adversarial; it protects the timeline the client also needs.

Define how change orders work before the first one arrives. A typical change order clause reads: "Additions beyond the agreed scope—including new modules, additional review rounds, new audience segments, or format changes—will be scoped and quoted separately. Work on change orders begins after written approval and does not delay the original timeline unless both parties agree in writing." That language gives you leverage when a VP drops a new requirement two weeks before launch without being hostile about it.

Build a "scope creep early warning" habit: when a client says "could we also..." in a meeting, write it down visibly and say "great idea—let me scope that as an add-on so it does not delay the main delivery." That sentence accomplishes three things: it validates the request, it signals there is a cost, and it protects the existing timeline. If you say yes to everything in the moment, you train clients that scope is negotiable after signing.

Review your SOW with a peer before sending it to the client. A second pair of eyes catches ambiguous language like "reasonable number of revisions" (define the number) or "support during launch" (define the hours and duration). Ambiguity in your favor feels good until the client reads it in their favor—then you have a conflict instead of a contract. The clearest SOWs use numbers: two revision rounds, three SME review sessions of 60 minutes each, one pilot cohort of up to 50 learners. Those numbers prevent arguments because both sides agreed to them in writing.