eLearning Content Development
SCORM Development That Actually Reports Back
Custom SCORM courses, conversion of existing material, and repair of packages that install cleanly but refuse to record completion. Built to the version your LMS needs, tested on the platform your learners actually use, and handed over with the editable source files.
A SCORM package is two deliverables
One is the course a learner sees. The other is the conversation that course holds with your LMS in the background. Most SCORM problems are entirely in the second one, which is why they survive a content review and only surface once real learners are enrolled.
The manifest
The imsmanifest.xml file that tells your LMS what the package contains, how it launches and what the completion rules are. A malformed manifest is the difference between a course that imports and one that is rejected without explanation.
The runtime calls
Every score, bookmark and completion status travels through the SCORM API at runtime. If those calls are not made, or not committed before the window closes, the learner finishes the course and your reports show nothing happened.
The completion rule
What actually counts as done — last slide reached, assessment passed, minimum time spent, or a combination. Ambiguity here is the most common reason a compliance audit and an LMS report disagree with each other.
Bookmarking state
Resuming where a learner left off depends on suspend_data, which SCORM 1.2 caps at 4,096 characters. Long courses quietly exceed it, bookmarking fails silently, and learners restart from slide one without anyone being told why.
Hosting and domains
A package served from a different domain than the LMS can be blocked by the browser from reaching the SCORM API at all. The course looks perfect and reports nothing — a failure mode that never appears in local testing.
Accessibility
Keyboard navigation, screen-reader semantics, colour contrast and caption tracks. Built in from the storyboard this is part of the design; retrofitted after sign-off it becomes an audit-and-rework cycle on finished content.
Which standard fits your situation
There is no best answer here, only a correct one for your platform and your reporting needs. This is the reasoning we work through before anything is built.
SCORM 1.2 — the default, and usually the right one
The most broadly supported version across LMS platforms. It records completion, score and time, which is what the large majority of compliance and onboarding programmes actually need. Choose it unless you have a specific requirement it cannot meet.
SCORM 2004 — when order or nuance matters
Adds sequencing and navigation control, so sections can be gated behind prior completion, and separates completion from success so you can record that someone finished without passing. The cost is more variable platform support and sequencing rules that are genuinely hard to debug.
xAPI — only with somewhere to send the data
Records granular activity, including learning that happens outside a course, to a Learning Record Store. Powerful when someone is genuinely analysing that data. Without an LRS and an owner for it, xAPI adds complexity and returns nothing SCORM would not have given you.
cmi5 — the middle path
Uses xAPI as its transport while keeping the familiar LMS launch-and-track model. A reasonable choice when you want richer data but are not ready to move away from LMS-centred delivery.
Build new, convert, or repair
Three genuinely different pieces of work that get bundled under one heading. Knowing which one you need changes the scope, the cost and who has to be involved.
Custom SCORM build
From subject-matter input to published package: instructional design, storyboarding, media, interactions, assessment and tracking. The right route when behaviour has to change rather than just knowledge transfer — safety judgement, escalation decisions, sales conversations.
Conversion of existing material
Decks, documents, recorded sessions and legacy Flash or older SCORM content brought into a current, mobile-capable, trackable package. Faster and cheaper than a rebuild — provided the source material already teaches well on its own.
Repair and re-packaging
Courses that import but do not report, packages your LMS rejects outright, bookmarking that silently fails, or content built for a platform you have since migrated away from. Often fixable from the published package alone when the original source has been lost.
When conversion is enough — and when it is not
The honest version of a question most vendors answer in whichever direction is more profitable.
Conversion is the right call when
- The existing material already teaches without a presenter filling the gaps
- Content is stable and factual — policy, process, product specification
- You need broad coverage across many topics rather than depth in one
- The goal is documented completion against a compliance obligation
- The content will be refreshed again within a couple of years anyway
- Subject-matter experts have little time for review cycles
A custom build earns its cost when
- Behaviour has to change, not just knowledge — judgement under pressure
- Learners need to practise a decision and see its consequence
- The course is customer-facing and carries your brand externally
- One build serves several years and several thousand learners
- The subject is hard enough that a page-turner will be quietly ignored
- You are localising into several languages, so design work is paid for regardless
How the work runs
Testing against your actual platform is a stage, not a formality. It is where most of the faults that would otherwise reach your learners get caught.
Scope and standard
What the course must teach, what evidence your LMS has to record, which SCORM version your platform supports properly, and what counts as completion. Settled in writing before anything is designed, because changing it later changes everything downstream.
Source review
An honest assessment of what you already have. Clean, current, well-structured material is a substantially smaller build than a folder of legacy decks. This is where scope surprises get found — before the estimate, rather than as change requests afterwards.
Storyboard and sign-off
Structure, screen-level treatment, interactions and assessment mapped out and approved before production begins. Review rounds are agreed and counted here, because unlimited revisions are never actually unlimited — the limit is simply undocumented until you reach it.
Build and media
Production against the signed storyboard: interactions, narration, on-screen text, graphics and assessment logic. Accessibility requirements are built in at this stage rather than audited afterwards, which is materially cheaper and produces a better result.
Packaging and cross-platform testing
Published to the agreed standard, then imported and run on your target platform — completion, score, bookmarking and resume all verified against real reports, on the browsers and devices your learners use. Not simulated, and not tested only in an authoring-tool preview.
Handover
The published package, the editable source project, the media assets, and documentation of the completion rules and tracking behaviour so whoever maintains it next does not have to reverse-engineer your decisions.
Faults we see most often
If any of these describe a course you already own, it is usually repairable.
Frequently asked questions
What is the difference between SCORM 1.2 and SCORM 2004?
SCORM 1.2 is older, simpler and still the most widely supported version across LMS platforms — if you only need to know that a learner completed a course and what they scored, it does everything required. SCORM 2004 adds sequencing and navigation control, so you can enforce an order, gate sections behind prior completion, and it separates completion from success, letting you record that someone finished a course but did not pass. The tradeoff is that 2004 support varies more between platforms and its sequencing rules are genuinely difficult to debug. Unless you specifically need enforced sequencing or the completion-versus-success distinction, 1.2 is usually the safer choice.
Why does my SCORM course show as incomplete even though the learner finished it?
This is the single most common SCORM fault and it is nearly always a communication problem rather than a content problem. The usual causes are the course never calling the commit method before the window closes, the completion criteria being set on a slide the learner never reaches, the LMS session timing out before the final status is written, or the package being served from a different domain than the LMS so the browser blocks the API connection entirely. Diagnosing it means watching the actual SCORM API calls the package makes at runtime, not re-examining the storyboard.
Can you fix or re-package a SCORM course another vendor built?
Usually yes, and this is a common request. If the editable source project exists, remediation is straightforward. If only the published package survives, we work with the package contents directly — the manifest, the tracking calls and the assets are all inspectable, so problems like broken completion reporting, a malformed manifest, missing resources or an incompatible SCORM version can generally be corrected without the original source. What cannot be fully recovered without source files is deep instructional restructuring, which is a rebuild rather than a repair.
What is suspend_data and why does it break long courses?
suspend_data is the field SCORM uses to remember where a learner left off — their position, their answers, their progress state. SCORM 1.2 caps it at 4,096 characters, and some LMS platforms enforce that limit strictly. Long courses with many interactions can exceed it, at which point bookmarking silently fails and learners restart from the beginning. The fixes are structural rather than cosmetic: split an oversized course into shorter modules, reduce what the course stores in state, or move to SCORM 2004, which raises the limit substantially.
Should we use xAPI or cmi5 instead of SCORM?
Only if you have somewhere to send the data and a reason to want it. xAPI records granular learning activity to a Learning Record Store, including activity that happens outside a course, which is genuinely valuable if you are analysing learning behaviour. But xAPI without an LRS gives you nothing SCORM would not, and many organisations adopt it, discover no one is querying the data, and carry the added complexity for no return. cmi5 sits between the two, using xAPI as its transport while keeping the LMS launch-and-track model. Start from the question of what you will do with the data, then choose the standard.
Do we get the editable source files or only the published package?
You receive both. The published package in whichever SCORM version your LMS needs, and the editable source project alongside it. This matters more than most buyers expect at the point of signing: whoever holds the source files controls the cost of every future revision, including small text corrections that ought to be trivial. It is worth confirming this term in writing with any vendor, not only with us.
Will the course work on our LMS?
That is a testing question rather than a build question, and it is why cross-platform testing is a distinct stage of the work rather than an afterthought. Standards compliance and real-world behaviour are not the same thing — platforms differ in how strictly they enforce the specification, how they handle suspend_data, whether they permit cross-domain hosting and how they treat a session that ends unexpectedly. Packages are tested against the target platform, on the browsers and devices your learners actually use, before handover.
Talk it through before you scope it
Bring the LMS you are on, the standard it supports and whatever content already exists. We will tell you whether you need a build, a conversion or a repair — including when the answer is that your existing package is fine.
Book a Free Demo