The problem dispatch solves
You sell or share a course. The customer imports the SCORM zip into their LMS. Now the course lives on their platform, outside your control. When you fix an error, you have to send a new zip and ask every customer to re-import it. You cannot tell how many people have taken it, you cannot stop access when a contract ends, and once the zip is on their server, nothing stops it being copied to another. For anyone distributing courseware to more than one organisation, this is the central problem, and dispatch is the standard answer to it.
What a dispatch package actually contains
A dispatch is a SCORM package like any other — the customer imports it the same way — but instead of containing the course, it contains a small launcher. The launcher is a SCO whose only job is to phone home: it opens the real course from wherever you host it, and it relays the SCORM runtime calls back and forth between the customer's LMS and your hosted content. To the customer's LMS it looks and behaves like an ordinary course. To you, the actual content never left your server.
Because the launcher is tiny and generic, the same dispatch can front a course that you change whenever you like. The customer's LMS is talking to the launcher; the launcher is talking to your current version.
How a launch works
- A learner opens the course in the customer's LMS. The LMS launches the dispatch SCO and provides the SCORM API, exactly as for a normal package.
- The launcher authenticates to your hosting service and requests the current version of the course, subject to whatever rules you have set (is this dispatch still active? are seats left? has it expired?).
- The real course runs, served from your infrastructure. Its runtime calls — initialize, set score, set completion, commit — are relayed through the launcher to the customer's LMS, so their reporting works normally.
- You record the launch on your side, which is how seat counting, analytics, and revocation become possible.
What you gain: update, meter, expire, revoke
- Update without re-import. Fix a typo or replace a module and every customer gets the new version on the next launch. No new zip, no re-import request.
- Seat ceilings. Cap a dispatch at, say, 500 registrations. When the cap is reached, further launches are refused — useful for licensing by volume.
- Expiry. Set a date after which the dispatch stops working, so a course tied to a one-year contract simply stops at renewal.
- Revocation. Turn a dispatch off immediately if a contract ends or terms are breached, even though the launcher still sits in the customer's LMS.
- Real usage data. Because launches pass through your service, you can see registrations, completions, and errors across all customers in one place, rather than asking each administrator for a report.
The trade-offs
Dispatch is not free of cost. Be clear about them.
- It needs a live connection. The real course is served from your infrastructure, so a learner offline, or behind a firewall that blocks your host, cannot launch it. If the destination environment is locked down, confirm the launcher's host is allowlisted before you rely on dispatch.
- You are now hosting. Uptime of your service is uptime of every customer's course. That is a responsibility a plain zip does not carry.
- Some platforms are fussy about launchers that open new windows or relay calls across origins. It should be tested against the target LMS the same way any package is — see testing before upload.
- It does not make content uncopyable. Dispatch controls access to the launch, not what a determined viewer can capture once the course is on screen. It reduces casual redistribution of the package; it is not digital rights management.
Dispatch vs. sending the real package
| You want to… | Send the zip | Dispatch |
|---|---|---|
| Deliver a course once, to your own LMS | Yes | Overkill |
| Update content after delivery without re-import | No | Yes |
| Cap the number of learners per customer | No | Yes |
| Expire access on a date | No | Yes |
| Revoke access after delivery | No | Yes |
| Work with no dependency on your servers | Yes | No |
The rule of thumb: if the course goes into one LMS you control, ship the package. If you are distributing courseware to other organisations and need to keep updating, metering, or controlling it after delivery, dispatch is the mechanism built for exactly that. SCORM Central produces both from the same course, so the same content can be a plain package for one customer and a metered, expiring dispatch for another.