What this guide is, and is not
An enrolment engine is the layer that sits between the systems where workforce data lives (the CRM, the ATS, the HR file) and the LMS where the training record ends up. It is the wrapper that gives the business the HR training capability it never bought.
This is a field guide. It tells you what good looks like, where most setups quietly fail, what to demand of any builder (Gibson included), and what to refuse to sign off without. It is not a build playbook. The exact eligibility rules engine, the message-scoring layer, the LMS write-back contract, and the multi-system reconciliation pattern Gibson runs are proprietary. You will finish this guide knowing how to evaluate any enrolment engine, including one we might build for you. You will not finish with a clone.
Why the chase is the engine, not the link
Most providers will tell you they can send the enrolment link. Sending the link is the easy part. Every LMS already does it.
The value lives in what happens after the link goes out and the candidate does nothing. In a real cohort Gibson worked, eligible staff numbered around 157 and only 37 made it through enrolment without intervention. The gap is not a link problem. It is a follow-up problem. Whoever owns the chase owns the outcome.
Any provider who quotes you on 'sending the enrolment link' without describing what happens on day 2, day 4, day 7, and day 14 is quoting you on the wrong thing.
The seven questions to ask any enrolment-engine provider
Before signing, ask each of these. The answers separate a real engine from an Excel macro with a UI.
- +How does the engine ingest staff lists? Monthly. Recurring. Delta-based, not full re-upload. If the answer is 'you upload a fresh CSV every month' you are buying a worse version of what you already do.
- +Where does eligibility live? Inside the engine as versioned rules, or in a spreadsheet someone has to maintain? If the rules live in a workbook, the engine cannot enforce them and the audit trail dies on the first staff change.
- +What does the chase actually look like? Specific. Day 2 reminder, day 4 second channel, day 7 voice escalation, day 14 close-as-lapsed with reason code. Vague answers mean the chase is manual.
- +How are replies classified? A real engine reads the reply, decides whether it is a question, a date negotiation, a refusal, an opt-out, or noise, and routes accordingly. If every reply lands in a single inbox for a human to triage, the engine is a glorified scheduler.
- +How does it write back to the LMS? Through documented LMS APIs or by browser automation? API write-back survives an LMS version bump. Browser automation breaks the next time the LMS team ships a UI change.
- +What happens to the funding-body or AASN handoff? External partner data exchange (MEGT, Busy At Work, similar) is where compliance evidence either exists or does not. If the engine cannot show a per-candidate handoff trail, the funding-audit conversation gets ugly.
- +What reporting does the operator actually see? Eligible-vs-enrolled per cohort. Stalled candidates by reason. Days-since-link-sent. If the provider can only show 'number of messages sent' the engine is measuring the wrong thing.
Where most setups quietly fail
Having seen the category from inside several builds, these are the failure modes that come back repeatedly.
- +Spreadsheet-led eligibility. Rules live in Excel, the engine consumes the output. Anyone who edits the spreadsheet silently changes the eligibility logic. Audit nightmare.
- +One-shot link sends. The engine sends the enrolment link once and considers its job done. Completion stays at 20 to 30%.
- +Single-channel chase. SMS-only or email-only. Real cohorts respond to different channels for different reasons. A real engine escalates between them.
- +Black-box LMS writes. The engine writes to the LMS but logs nothing the operator can read. When a learner record is missing or wrong, nobody can prove what the engine did.
- +No conversation memory. Each reminder is generated fresh, with no awareness of what was already sent or what the candidate replied to. Candidates disengage the moment they feel like they are talking to a robot.
- +No 'lapsed' state. Candidates who do not enrol sit in limbo forever. The cohort report can never close cleanly because nobody knows whether to count them.
The compliance frame, non-negotiable
Australia. Privacy Act 1988. Spam Act 2003. State-level vocational training compliance (NCVER, ASQA for RTOs). The engine needs to be defensible against each of these on day one.
- +Consent capture and storage. Every contact in the engine must have a documented consent basis: the employer-cohort opt-in or the individual learner opt-in. Implied consent does not cover proactive enrolment chasing.
- +Opt-out paths on every channel. SMS STOP, email unsubscribe, voice 'remove me' all routed back into the engine so the next message does not send.
- +Data minimisation. Personal info goes in only where it is needed. DOB, visa, address fields should be encrypted at rest and not flow back to the CRM where the sales team can see them.
- +Audit trail. Every send, every reply, every LMS write, every status change is logged with timestamp and source. A funding-body audit should be answerable from the engine alone, without ringing the operator.
What you should refuse to sign off without
If you are paying for an enrolment-engine build, these are the deliverables that protect you.
- +A versioned eligibility-rules layer the operator can read and the engine enforces. Not a spreadsheet.
- +A multi-day, multi-channel chase plan documented per cohort, with example messages and escalation triggers.
- +Per-candidate audit trail visible inside the engine: when the link sent, when the reminders fired, what the replies were, when the LMS write happened.
- +A 'lapsed' state with reason codes so the cohort report closes cleanly. No phantom enrollments.
- +API-based LMS write-back where the LMS supports it. Browser automation only with explicit acknowledgement of its fragility.
- +A monthly evidence pack: eligible counted, enrolled converted, lapsed by reason, compliance breaches (should be zero), funding-body submissions made.
Where the value flows
A well-built workforce enrolment engine reshapes more than the enrolment number.
- +Operations: the administrator who used to spend two days a month chasing eligible staff gets those days back.
- +Sales / employer relationships: every cohort completes closer to its eligible ceiling, which makes the employer happier and the next renewal easier.
- +Compliance: funding-body audits stop being a panic. The evidence pack is one click.
- +Strategy: the business can take on cohorts it previously had to decline because it could not chase them. Capacity stops being administrator-limited.
Want us to build it for you?
Gibson runs this build pattern as a 48-hour working prototype. Your existing LMS, your CRM, your ATS, your funding-pathway logic. From $1,000 for the prototype, scoped engagement after.
Book a 30-min diagnose call from the Sandbox page.