Onboarding software runs the onboarding of new employees: it derives the necessary steps from the role’s requirement profile, assigns tasks to the people involved, tracks progress, and documents the records that result. What separates it from a checklist is that it evidences completion rather than asserting it.
Most companies have organised onboarding. What’s missing is the answer to one question: is the new person now qualified for their role — and how would we know?
Three kinds of onboarding software, and what each solves
The market puts three different tools under the same word. Choosing gets easier once you know which problem you actually have.
Administrative onboarding
Contract, master data, equipment, access, signatures. Solves the paperwork before day one. Says nothing about whether the person can do the job.
Learning-based onboarding
Courses, learning paths, progress through content. Solves knowledge delivery. Tells you who completed which course — not whether the role is covered.
Competence-based onboarding
The starting point is the position’s requirement profile. Onboarding counts as complete when the actual profile meets the target profile, not when a list is ticked. This is where Kollegia sits.
The three aren’t mutually exclusive. But buying an administration tool for a competence problem doesn’t solve it.
The difference between “onboarded” and “qualified”
In most companies onboarding ends on a date. After three months someone counts as onboarded because three months have passed.
That’s an assumption, not a finding. It holds until something happens — and surfaces the moment someone asks whether this person may take on a particular task. Then it turns out nobody knows which of the intended steps actually took place and which records exist.
Competence-based onboarding asks differently: what does the role require, which of those requirements are evidenced, which are still missing? That gives onboarding a defined endpoint and a checkable status at any point before it.
What the software takes on
Derives the plan from the role. Rather than assembling what needs doing for each hire, the onboarding plan follows from the position’s stored requirement profile. What such a plan contains is shown in our onboarding plan template.
Accounts for mandatory training automatically. Which instruction is required before independent work sits on the role profile, not in a manager’s memory.
Assigns and tracks tasks. Every step has an owner and a date. What isn’t done stays visible instead of disappearing into a document.
Produces records along the way. Attendance, instruction and confirmations arise within the process and then attach to the profile — rather than being hunted down afterwards.
Shows progress against the target profile. At any point it’s readable which part of the role’s requirements is already evidenced.
Checklist, spreadsheet, software: what’s enough when
| Checklist / spreadsheet | Onboarding software | |
|---|---|---|
| First few hires | Sufficient | Overkill |
| Basis of the plan | Rebuilt per case | Follows from the role profile |
| Changed requirements | Existing copies stay old | Apply to future onboarding |
| Completion | Asserted (a tick) | Evidenced (record on the profile) |
| Visibility | With one person | To everyone permitted |
| After onboarding | Ends | Continues as deadline monitoring |
The honest answer to “when does this pay off”: with one or two hires a year and a single role profile, a spreadsheet is fine. The need arises with several distinct role profiles, with mandatory training on renewal cycles — and the moment the state of an onboarding has to be demonstrated externally.
Onboarding doesn’t end when onboarding ends
The most common break is at the handover. Onboarding closes, the tool is set aside — and the records created along the way quietly age. An instruction from the first month falls due a year later; nobody notices, because the onboarding tool no longer owns that.
So at Kollegia onboarding isn’t a separate process but the beginning of ongoing competence management. What’s created during onboarding becomes part of the permanent register: the record captured in week two resurfaces eighteen months later as an expiring deadline. How that register works is covered on the skills matrix page; the deadline logic behind it on the training management software page.
Who tracks what gets dropped
Onboarding rarely fails on the plan and almost always on attention in week three, when the manager has other things to do.
So in Kollegia Antoine, one of the Digital Colleagues, takes that on: it identifies which mandatory training is outstanding for a newly filled role, flags steps not completed by their date, and reminds about the agreed interim conversations. Once onboarding ends, the same monitoring continues — for renewal deadlines and expiring records.
Three principles
- Permission intersection — a digital colleague never sees more than the person it works for. Onboarding data is personnel data; access follows existing permissions exactly.
- Fail-closed — when in doubt, nothing happens. If a detail is unclear or a permission is missing, the process stops rather than guessing.
- Audit trail — every notification and change is logged and traceable.
FAQ
Source: Section 12 Arbeitsschutzgesetz (ArbSchG) – Unterweisung, German Federal Ministry of Justice.
Onboarding software runs the onboarding of new employees: it derives steps from the role’s requirement profile, assigns tasks, tracks progress and documents the resulting records. It differs from a checklist in that completion is evidenced rather than asserted.
An LMS provides learning content and measures course progress. Onboarding software runs the whole onboarding process, of which courses are only one part — alongside tasks, conversations, access, instruction and the records that come out of them.
With one or two hires a year and a single role profile, a structured spreadsheet is enough. The need arises with several role profiles, with required instruction on renewal cycles, or when the state of an onboarding has to be demonstrable.
The effort sits less in the system than in the preparation: the roles’ requirement profiles have to be defined once. Anyone who already has them is quickly operational; anyone who doesn’t is completing an overdue step anyway.
Yes. Existing plans serve as the starting point for role templates. The most common extra work arises where the same requirement was named differently across plans.
