The report after a software rollout almost always reads well. Attendance was high. The sessions scored well. Nearly everyone passed the knowledge check, and somewhere in the deck there is a slide saying the programme was a success.
Six weeks later the support queue has the same questions in it that it had before. The workflow the tool was bought to replace is still being done the old way, in a spreadsheet, by people who attended the training and liked it. And the person who approved the budget asks a question that nobody in the room can answer with the data they collected: did it work?
Both halves of that story are true at the same time, which is exactly the problem. The training happened, people did like it, and nothing changed. The Kirkpatrick model exists to make that sentence impossible to say by accident, because it forces anyone claiming success to say which kind of success they are claiming, and to notice that the two easiest kinds to prove are the two nobody was paying for.
The model comes from corporate training rather than from software, and almost everything written about it is aimed at learning and development teams running classroom courses. This guide is the other version: what the four levels of evaluation actually mean, why software rollouts and onboarding programmes stop at level two with such depressing regularity, what each level looks like when the thing being evaluated is a product rather than a course, and what to do about the gap between the levels you can measure and the levels you were funded for.
Key takeaways
- The Kirkpatrick model evaluates training on four levels: reaction (did they like it), learning (do they know how), behaviour (are they doing it) and results (did the number move).
- The levels are not four metrics. They are four different claims, and each one needs a different kind of evidence than the one below it.
- Levels 1 and 2 are cheap, immediate and entirely inside the training team's control. Levels 3 and 4 are late, contested and visible only where the work happens. That gradient, not laziness, is why almost every programme stops at two.
- In software, level 3 lives inside the product. Completion rates, quiz scores and thumbs-up ratings on a tour are level 1 and level 2 measures being asked to do a level 3 job.
- The later revision of the model says to design backwards, starting at level 4, and adds required drivers: the reinforcement at the moment of work that decides whether level 2 ever becomes level 3.
- The gap between knowing and doing is not a knowledge problem. It is an availability problem, which is why guidance that lives in the product does what a session cannot.
What Is the Kirkpatrick Model? (Definition and Origin)
Kirkpatrick model: definition
The Kirkpatrick model is a framework for evaluating training on four levels of increasing difficulty and increasing value: level 1, reaction, how participants responded to the training; level 2, learning, what they can now describe or demonstrate; level 3, behaviour, what they actually do differently once they are back at work; and level 4, results, what changed in the outcomes the organisation cared about. Each level answers a question the level below it cannot answer, and each one costs more to answer than the level below it.
The four levels were set out by Donald Kirkpatrick, an American academic writing for a training-industry audience, and they became the default vocabulary of corporate learning and development almost immediately. The reason they stuck is not sophistication. It is that before the four levels existed, training teams had one word for success, and that word covered everything from a warm room to a measurable drop in error rates. Giving each claim a number made it obvious which one was being made.
The model was later revised by Jim and Wendy Kirkpatrick into what is usually called the New World Kirkpatrick Model. Two changes in that revision matter more than the rest, and both come up repeatedly in software rollouts: the instruction to plan the four levels in reverse, starting with the result, and the addition of required drivers, the processes and support that have to exist after the training if anything is to carry over into work. Both are covered further down.
Two details are easy to read past and worth slowing down for.
The first is that the levels are claims, not metrics. There is no single level 3 number you can look up. Level 3 is the assertion that people are behaving differently, and it will be evidenced differently in a warehouse, a call centre and a SaaS product. Teams that go looking for "the level 3 metric" usually come back with a level 1 metric wearing a better name.
The second is that the levels are a ladder of evidence, not a ladder of quality. A level 4 result is not a better version of a level 1 reaction. It is a completely different assertion about the world, with different owners, a different time horizon, and a different standard of proof. This is why a programme cannot simply decide to "measure at level 4" at the end of a quarter. The thing that would have made that measurable had to be decided before the programme ran.
The Four Levels of Evaluation, One at a Time
Here are the four levels side by side, with the question each one answers, how it is usually measured, and, more usefully, what it can and cannot prove.
| Level | The question | Usually measured with | What it proves | What it cannot prove |
|---|---|---|---|---|
| 1. Reaction | Did they find it engaging, relevant and worth their time? | End-of-session form, a star rating, a thumbs-up on an in-app guide | That the training was tolerable and that nothing actively repelled people | That anything at all was learned, retained or applied |
| 2. Learning | Do they now know how to do it, and believe they can? | Knowledge check, quiz, demonstration, certification, self-rated confidence | That the content transferred into memory under test conditions | That it will be available to them on a busy Tuesday, three weeks later |
| 3. Behaviour | Are they doing it differently at work, on their own? | Observation, manager check-in, and in software, what the product records | That the change survived contact with real work and real deadlines | That the behaviour you chose was the one that produces the result |
| 4. Results | Did the outcome the organisation funded this for actually move? | Retention, renewal, ticket volume, cycle time, error rate, time to value | That the number changed in the window you were looking at | That your programme is why it changed, unless you planned for that |
1. Reaction: did they like it
Level 1 asks how people responded. It is collected immediately, usually with a short form, and it is by far the most commonly reported level because it is the only one available before everyone goes back to their desks.
Reaction is worth collecting and worth almost nothing on its own. Its real value is as a negative signal. A strongly negative reaction reliably predicts that nothing else happened, because people who found the session irrelevant or confusing are not going to apply it. A strongly positive reaction predicts very little, because enjoying something and being changed by it are only loosely related. A well-run session on a topic nobody needed can score beautifully.
The New World revision tightened this level by splitting it into engagement, relevance and satisfaction, which is a genuine improvement: "was this relevant to my job" carries far more information than "was this good", and relevance is the half that actually predicts the levels above.
2. Learning: do they know how
Level 2 asks what changed in the person: knowledge, skill, confidence, and in the revised model, commitment. It is measured with a check of some kind, from a quiz through to watching someone perform the task in a sandbox.
Level 2 is where most evaluation stops, and it is a genuinely seductive place to stop, because a knowledge check produces a hard number that looks like proof. The trouble is the conditions. A knowledge check happens while the training is still fresh, in an environment designed for it, with the person's full attention and no competing deadline. Those are precisely the conditions that will never apply again. What you have measured is best-case recall, and best-case recall is a weak predictor of what someone does under time pressure with a customer waiting. That gap between knowing and doing has a name in training circles, the transfer problem, and it is the single most important thing the model has to teach a software team.
3. Behaviour: are they doing it
Level 3 asks whether the behaviour changed where the work happens. Classically it is measured by observation or by asking a manager some weeks later, which is expensive, subjective and slow, and which is why it gets skipped.
In software this is the level that changes character completely, and in your favour. You do not need to stand behind anyone with a clipboard. The product already records whether the task is being done, by whom, by which route, how often, and whether the person needed help to do it. Nowhere else in training evaluation does level 3 come almost free. It is the most important fact a product or onboarding team can take from the whole model: the level everyone else finds hardest is the level you already have the data for.
The caveat is that it has to be the real task, performed unaided, after the guidance has gone. A user clicking through a tour is not performing the task. They are being walked through a simulation of it while the answer is on screen.
4. Results: did the number move
Level 4 asks what happened to the outcome the organisation was actually buying: fewer errors, shorter cycle times, a smaller support queue, better retention, faster time to value. It is the level the budget was approved against and the level least likely to be reported.
Two things make it hard. It arrives late, usually after the quarter in which anyone cared, and it never arrives with a clean cause attached. A support queue that shrank over three months was also exposed to a release, a seasonal lull, two new hires on the support team and a pricing change. This is not a reason to skip level 4. It is a reason to decide, before the programme runs, which number you are claiming and what comparison would make the claim credible: a holdout group, a staged rollout where one region goes first, or at minimum a baseline written down in advance with the other known changes listed beside it. The honest arithmetic for the money side of that claim is in our guide to onboarding ROI, which is the level 4 conversation in its financial form.
Why Almost Every Software Rollout Stops at Level Two
It is tempting to read the gap as a discipline problem: teams are busy, nobody follows up, the report gets written from whatever is to hand. That is not what is happening. Three gradients run the same direction across the four levels, and together they make stopping at level 2 the rational choice for almost everyone.
-
The cost gradient
A reaction form costs a minute of someone's time at the end of a session that is already happening. A level 3 observation costs a person's attention weeks later, at a moment nobody has scheduled. The evidence gets more expensive exactly as it gets more valuable.
-
The timing gradient
Level 1 is available the same afternoon. Level 2 is available by the end of the week. Level 3 needs several weeks to mean anything, and level 4 usually arrives after the review in which the programme was going to be judged. The reporting deadline sits between levels 2 and 3, which is not a coincidence so much as a habit nobody has questioned.
-
The ownership gradient
Levels 1 and 2 are produced by the training team, about the training, using instruments the training team controls. Levels 3 and 4 live in someone else's system: the product's analytics, the support platform, the finance dashboard. Getting them means asking another team for access, agreeing a definition, and accepting a number you cannot adjust.
There is a fourth reason underneath those three, and it is the one worth sitting with. Levels 1 and 2 can be produced by the training itself. Level 3 cannot. Level 3 requires something to happen at a moment when the training is not present: a Tuesday afternoon, a real customer, a deadline, a screen the person has seen twice. A classroom cannot be in the room when the work happens. A webinar cannot. A recorded video cannot. A sixty-page document theoretically can, and in practice is not opened.
A product can. That is the whole reason in-app guidance exists as a category, and it is a much better argument for it than any feature list: it is the only form of instruction that is present at level 3.
This also explains a pattern anyone who has run a rollout will recognise. Training budgets get spent almost entirely on the two levels that cannot reach the moment of work, and then the shortfall at level 3 gets diagnosed as a people problem. More sessions are scheduled. Attendance is made mandatory. A reminder email goes out. All of it lands at levels 1 and 2 again, and the transfer gap does not move, because nothing has changed about what is available at the moment someone is actually stuck.
Levels 1 and 2 in SaaS: What Your Completion Rates Actually Are
Software teams rarely say the words "level 1". They do, however, report a set of numbers that map onto the lower two levels with uncomfortable precision, and usually present them as evidence of adoption.
| What gets reported | What level it is | Why it is not what you think |
|---|---|---|
| Product tour completion rate | Level 1 | It records that someone clicked Next until the guide ran out. Engagement, not knowledge, and certainly not behaviour. |
| Thumbs-up or star rating on a guide | Level 1 | The purest reaction measure there is. Useful as a negative signal, close to meaningless as a positive one. |
| Onboarding checklist completion | Level 1 or 2 | Closer, because the items are usually real actions. Still performed with the instruction on screen, which is test conditions. |
| Quiz or certification score in an academy | Level 2 | Genuine level 2, and genuinely useful. Also collected at the moment of maximum freshness. |
| Webinar or session attendance | Level 0, arguably | It records that a calendar invite was accepted. |
| Logins, seats activated, weekly active users | Not level 3 | Presence is not behaviour. A login proves someone opened the tool, not that the work moved into it. |
None of these numbers are worthless. The mistake is a category error, not a measurement error: they get quoted in answer to a question they cannot address. "The tour has an eighty per cent completion rate" is an answer to "did people engage with the tour". It is not an answer to "are people doing the thing the tour was about", and the two can move in opposite directions, which is the uncomfortable part. A tour can be completed more often precisely because it got shorter and emptier.
We have written separately about which numbers to watch across a whole onboarding programme in user onboarding metrics, and about the specific trap of judging a tour by its own completion rate in common user onboarding mistakes. What the Kirkpatrick frame adds is a precise name for the error. These are not bad metrics. They are lower-level metrics being asked to carry a higher-level claim, and once you can say that out loud in a review meeting, the conversation changes.
Level 3 Is the Only Level That Lives Inside Your Product
If your product is the workplace, then level 3 is not an interview or an observation study. It is a measurable property of what the product recorded. Five signals separate real behaviour change from its lookalikes, and none of them requires new instrumentation beyond what most teams already have.
Not the tour, the task: the invoice sent, the report built, the record imported, with no guide open. This is the closest thing to a definition of level 3 in software, and it is the number that should be on the slide instead of completion rate.
Two users who both produced the report may have taken very different routes, one through the feature you built and one through an export and a spreadsheet. Only the first is the behaviour you were trying to change. The second is a workaround that will quietly cap your level 4 result.
A behaviour performed once, while being prompted, is level 2 in costume. The honest test is whether it recurs in week three with nothing on screen telling anyone to do it.
Behaviour change shows up in the support queue as a change of subject. If the questions have moved from "where do I find this" to "can it also do this", the first behaviour has landed. Same volume, different content, completely different meaning.
One enthusiastic admin doing everything correctly is not organisational behaviour change. Count the share of the people who were meant to change, not the activity of the people who were always going to.
Two of those signals deserve a note. The repetition test matters because forgetting is the default, not the exception, and no amount of good teaching changes that. Our guide to recognition over recall covers why users forget what you taught them and what to put on the screen instead, and learnability covers scaffolding and fading support as competence grows, which is the mechanism by which level 2 becomes level 3 without the guidance becoming permanent furniture.
The path signal matters because it is the one that stops a false positive from reaching the board. A team that only measures outcomes will report that the behaviour changed when what actually happened is that people found a way to produce the output without changing anything.
Plan Backwards, Evaluate Forwards
The single most useful instruction in the revised model is also the one most often ignored: the four levels are evaluated from 1 to 4, and they should be designed from 4 to 1. Programmes built in the order the evidence arrives end up evaluating whatever they happened to produce. Programmes built in reverse have had to name the result first, and everything after that is a chain of stated assumptions rather than a list of activities.
The levels are evaluated left to right and designed right to left. Each arrow between two boxes is an assumption, and a programme built from the left has made all three of them without writing any of them down.
Working backwards produces four sentences, and the discipline is that each one has to be specific enough to be wrong.
Start at level 4: name the number
Not "improve adoption". A single number, with a baseline and a date: the share of accounts that complete their first real export in the first fortnight, the volume of password-reset tickets, the time between signing and first production use. If nobody can name it, the programme has no level 4, and that is better discovered now than in the review.
Then level 3: name the behaviour that moves it
Which specific, observable thing would people have to do differently for that number to move? This is the step that quietly kills most training plans, because it exposes that the proposed behaviour and the proposed number are not actually connected. Teaching everyone the reporting module will not reduce password resets.
Then level 2: name what they must be able to do unaided
Derived from the behaviour, not from your feature list. The test is a sentence of the form "by the end, someone in this role can do X without asking anyone". A syllabus organised by menu structure almost never survives this step, because products are organised by architecture and work is organised by task.
Then level 1: decide what has to feel worth their time
Last, and genuinely last. Reaction is a constraint on the design, not a goal of it: the session or the guide has to be short enough, relevant enough and well-timed enough that people do not refuse it. Starting here is how you end up with a polished programme that is engaging about the wrong thing.
A useful test for any adoption plan: read it backwards. If the level 4 number is missing, you have a list of activities. If the level 3 behaviour is missing, you have a content plan. If only level 1 is specified, you have an event.
Required Drivers: What Turns Level 2 Into Level 3
The revised model adds a component that the original four levels left implicit, and it is the most practical idea in the whole family: required drivers. These are the processes and systems that reinforce, encourage, monitor and reward the new behaviour after the training ends. The claim behind them is blunt. Without required drivers, most of what was learned does not become behaviour, no matter how good the training was.
In a classroom world, required drivers are things like a manager who checks in, a job aid pinned beside the desk, a checklist on the wall, a team norm, a metric someone reviews. In a software world they translate almost one for one, and almost all of them translate into the product rather than around it.
| Required driver | What it does | What it looks like in a product |
|---|---|---|
| Reinforcement | Puts the instruction back in front of the person at the moment they need it, not before | A tooltip or a hotspot on the control everyone hesitates over, shown on the screen where the task happens |
| Encouragement | Keeps someone going through the part where they are slowest and least sure | A checklist with visible progress, so an open-ended setup has a finish line the user can see |
| Monitoring | Tells you who is stuck while it is still cheap to help them | Per-step completion and drop-off, plus activation milestones per segment |
| Accountability | Makes the new way the default path rather than the virtuous one | The old route retired or deprecated on a published date, with the change announced in-product |
| Refreshers | Catches the decay that happens between the training and the next time it is needed | Guidance that can be re-launched from a checklist item, for the task people do once a quarter |
| Reward | Makes the behaviour feel worth repeating rather than merely compliant | The outcome shown back to the user at the moment they produce it, not a badge |
Read that column on the right and notice what it has in common. Every one of those drivers is a small thing that appears at a specific moment on a specific screen. None of them is a session. None of them would ever survive a roadmap prioritisation on its own merits, because individually each is a label, a tooltip or a progress indicator. Collectively they are the entire difference between level 2 and level 3, which is a reasonable description of why so many well-run training programmes fail to produce anything.
The practical rule: when level 2 is strong and level 3 is flat, do not buy more training. Buy presence at the moment of the task.
The Four Levels Translated: Internal Rollouts and Customer Onboarding
The model was written for employee training, and it is used just as often now for customer-facing onboarding. The levels do not change, but the instruments do. This table is the translation most teams actually need.
| Level | Internal rollout (your staff, your new tool) | Customer onboarding (your users, your product) |
|---|---|---|
| 1. Reaction | Session feedback, relevance rating by role, how many people asked to leave early | Guide rating and dismissal rate, early-session survey response, how often the guide is skipped at step one |
| 2. Learning | Knowledge check by role, a demonstration in a sandbox, self-rated confidence before and after | Academy or certification score, correct first attempt in a guided flow, answers to a short in-app check |
| 3. Behaviour | The task performed in the real system, by the intended route, weeks later, by the share of staff it was meant for | Unaided completion of the core task, repeat use in week three, feature used by the segment it was built for, workarounds not taken |
| 4. Results | Cycle time, error and rework rate, licence utilisation, ticket volume to the internal help desk, the old system switched off | Time to value, activation rate, retention and renewal, expansion, support cost per account |
Two notes on the internal column. "The old system switched off" is the most honest level 4 measure in any software rollout, because it is the one thing nobody can fake, and it is why the software rollout plan should name the date the old way gets retired, out loud and in advance. And licence utilisation is a level 4 number that behaves like a level 3 one: it is covered in detail in our guide to licence utilisation.
What the Pattern of Levels Is Telling You
The levels are far more informative read as a pattern than read one at a time. Put level 2 against level 3 and four situations appear, each with a different diagnosis and only one of which is actually a training problem.
Level 2 knowledge runs bottom to top, level 3 behaviour runs left to right. The two arrows are different kinds of work, and the bottom right quadrant is the one most likely to be misreported as a failure.
The transfer gap (top left) is high knowledge and low behaviour. People can describe the new way and are not doing it. This is the classic result of a well-run programme with no required drivers, and the instinctive response, running the training again, makes it worse by consuming the goodwill that paid for the first attempt. The fix is not more teaching. It is moving the support from before the work to during the work.
An event, not a change (bottom left) is low on both. Nothing moved in the product data and the same questions keep arriving. Before scheduling a second round, check the thing that is easiest to get wrong: whether the training was aimed at a real task people actually have, or at a tour of the software's menus. A syllabus organised around features rather than jobs produces exactly this quadrant.
The product is carrying them (bottom right) is the interesting one, and it is routinely written up as a failure. People score poorly on the knowledge check and do the task correctly every time, because the product tells them what to do at the moment they need to know. That is not a problem. That is the goal, and it is worth saying plainly: a user who never had to learn something is a better outcome than a user who learned it well. The only genuine risk here is dependency on guidance for a task that needs judgement rather than steps, which is a reason to check what you are guiding, not a reason to go back to teaching.
It worked (top right) is not a resting state. Behaviour that has been established can be dismantled by a redesign that moves what people had learned, or by staff turnover that replaces the trained population with an untrained one. That is the quiet argument for treating guidance as permanent infrastructure rather than as a launch activity, and it is why rolling out a redesign is a re-training problem wearing a communications hat.
A Worked Example: Four Levels Written Down in Advance
The model is most useful before anything happens, so here is what it looks like filled in ahead of a rollout. The scenario is a mid-sized company moving expense claims out of email and spreadsheets into a new system. The figures below are illustrative, chosen to show the shape of the plan, and are not benchmarks from anywhere.
Level 4, decided first
The number is the share of expense claims submitted through the new system without finance having to return them for correction, measured monthly. The baseline is whatever the old process produced in the quarter before launch, written down now. Known confounders are listed beside it: a finance team hire in month two, and the annual travel peak in month three.
Level 3, derived from it
The behaviour is that a claimant attaches the receipt and selects the cost centre at the point of submission, rather than submitting and fixing it later. This is a specific, observable action, it happens inside the system, and the link to the level 4 number is explicit rather than assumed. Measured as the share of claims submitted complete on the first attempt, by the share of staff who submit any claim at all.
Level 2, derived from that
People must be able to find the cost centre for their own team without asking, and know what counts as an acceptable receipt. Note how narrow that is. It is two things, not a tour of the expense system, and both come directly from the behaviour above rather than from the product's feature list.
Level 1, decided last
Whatever carries that knowledge has to cost a claimant under two minutes on their first claim, and must not appear before they are submitting one. That constraint rules out an hour-long session for the whole company and effectively specifies in-product guidance, because the only thing that can be present at the moment of a first claim is the claim screen itself.
The required drivers, named
A tooltip on the cost-centre field carrying the one rule people get wrong. A short checklist on the first claim, which disappears after it is completed. Monitoring through per-step drop-off, so finance can see which field is causing the returns rather than guessing. And an accountability driver with a date: email claims stop being accepted at the end of month two, announced in the product and not only by email.
Written this way the plan takes an afternoon, and it has a property the usual version lacks: every claim in it can be falsified. If level 3 moves and level 4 does not, the behaviour chosen was wrong, which is useful information rather than an embarrassment. For the wider change-management context around a rollout like this, change management and the ADKAR model cover the readiness side, and hypercare covers the support window immediately after go-live, which is where most of the level 3 evidence first becomes visible.
What the Kirkpatrick Model Gets Wrong (Honest Limitations)
The model has been in use long enough to have accumulated serious criticism, and a guide that does not mention it is selling something. Five limits are worth knowing.
It is tempting to read the ladder as "level 1 leads to level 2 leads to level 3". It does not. A session people disliked can still change behaviour, and a session they loved frequently changes nothing. Treating the levels as a chain is how a strong level 1 result ends up on a slide as evidence of impact.
The model assumes a discrete intervention with a before and an after. Much of how people actually learn software is continuous and ambient: a colleague, a label, a guess that worked. Those leave no event to evaluate, which tends to push attention toward the formal training that is easy to measure rather than the product changes that did the work.
It is an evaluation framework, not a design one. It will tell you a programme did not change behaviour. It will not tell you which behaviour to have chosen, which screen is confusing, or what the content should have been.
Business outcomes have many causes and training is rarely the largest. Without a holdout, a staged rollout or at minimum a documented baseline, a level 4 claim is a correlation presented with confidence.
The fifth limitation is the one that does the most damage in practice. The model is easy to turn into a reporting ritual: four boxes filled in after the fact to justify what already happened. Used that way it produces more paperwork and no better decisions. Its value is almost entirely in the planning direction, as a set of questions asked before anything is built, and a team that only meets the four levels at reporting time has kept the cost and discarded the benefit.
Kirkpatrick, Phillips and the Alternatives
A few related models come up in the same conversations, and it is worth knowing what each one adds so you can tell whether you need it.
Associated with Jack Phillips, it adds a fifth level above results: return on investment, which converts the level 4 outcome into money and sets it against the fully loaded cost of the programme. It also insists on isolating the effect of the training from other causes, which is the discipline most level 4 claims are missing. If your audience is a finance review, this is the version you want, and our onboarding ROI guide works the same arithmetic for onboarding specifically.
Associated with Robert Brinkerhoff, it abandons the attempt to average across everyone and instead looks hard at the people for whom the training clearly worked and the people for whom it clearly did not, then asks what differed about their circumstances. For a software rollout this is often more actionable than any average, because the difference usually turns out to be a required driver that one team had and another did not.
There is also a broad line of criticism arguing that the four levels put too much weight on reaction, and that evaluation should instead start from whether the task gets performed correctly in the real environment. For a product team that critique is less a rival model than a confirmation of where to spend: the level that matters is the one that happens on your screens.
Kirkpatrick Model: Do vs. Don't
✅ Do
- Decide the level 4 number before anything is designed, and write down the baseline.
- Name one specific, observable behaviour that would move that number.
- Derive what people must know from the behaviour, not from your feature list.
- Measure level 3 as unaided completion of the real task after the guidance has gone.
- Build the required drivers at the same time as the training, not afterwards.
- Watch the path people take, not only the outcome they produce.
- List the other things that changed in the same window, before claiming level 4.
- Report which level a number belongs to whenever you quote it.
❌ Don't
- Quote a completion rate or a satisfaction score as evidence of adoption.
- Treat the four levels as a chain where a good level 1 implies a good level 3.
- Answer a flat level 3 by scheduling more training.
- Measure level 2 only at the moment of maximum freshness and call it retained.
- Count logins, seats or attendance as behaviour change.
- Report a level 4 movement without naming what else happened that quarter.
- Read a weak knowledge check as failure when the product is doing the remembering.
- Fill in the four levels after the fact to justify a programme that already ran.
Running Level 3 With Kompassify
It is worth being straight about which part of this model a guidance tool touches. Kompassify will not write your training strategy and it cannot choose your level 4 number. What it does is occupy the level everyone else finds hardest to reach: it puts instruction at the moment of the task, and it records what happened there.
The mapping is direct. Product tours carry the first attempt at a real task rather than a tour of the menus. Tooltips and hotspots are the reinforcement driver: the explanation sits on the control everyone hesitates over, available on the Tuesday afternoon when it is actually needed. Onboarding checklists give an open-ended setup a visible finish line, and a checklist item can re-launch the guidance for the task somebody only does once a quarter. Announcements re-form the behaviour after a release has moved something people had already learned. In-app surveys collect level 1 and a light level 2 read at the right moment rather than at the end of a session.
Per-step completion and drop-off is the monitoring driver in practice. It tells you which step is costing you the behaviour while it is still cheap to fix, instead of telling you months later that the programme did not work.
The measurement side is where the Kirkpatrick frame and a guidance tool line up most neatly. Product analytics give you activation milestones, feature usage by segment and user flows, which is to say level 3 evidence: whether the task is being completed, by whom, by which route, and whether it recurred. That is the level a classroom programme has to buy with observation studies and manager interviews, and here it is a by-product of the product running.
Segmenting by what people have actually done, rather than by whether they attended, is the difference between a level 3 claim and a level 1 one.
All of it is built without engineering time, which matters more here than it sounds. Required drivers are made of small things, and small things do not survive a roadmap: one tooltip on the field everyone gets wrong, a checklist that ends where the user's first real outcome begins, an announcement when a screen moves. Individually none of them would ever be prioritised. Together they are most of the distance between level 2 and level 3.
Put the training where the work happens
Build tours, tooltips and checklists that appear at the moment of the task, and measure whether the task actually gets done. No code required. Free up to 100 monthly active users, plans from $129/month, GDPR-compliant and EU-hosted.
Start for free →For the programme around the product, our guides to training employees on new software and customer education cover how to build the training itself, train the trainer covers enabling a champion to teach inside a customer account, and digital adoption covers the wider practice this all sits inside. If you want the companion model for why an individual accepts or rejects a tool in the first place, that is the technology acceptance model.
Frequently Asked Questions
What is the Kirkpatrick model?
The Kirkpatrick model is a framework for evaluating training on four levels. Level 1, reaction, asks how people responded to the training. Level 2, learning, asks what they can now describe or demonstrate. Level 3, behaviour, asks what they actually do differently once they are back at work. Level 4, results, asks what changed in the outcome the organisation funded the training for. Each level answers a question the level below it cannot answer, and each one costs more to answer than the level below it. It was set out by Donald Kirkpatrick and later revised by Jim and Wendy Kirkpatrick into what is usually called the New World Kirkpatrick Model.
What are the four levels of the Kirkpatrick model?
Reaction, learning, behaviour and results. Reaction is whether people found the training engaging and relevant, usually collected with a feedback form at the end. Learning is whether knowledge, skill or confidence changed, usually measured with a knowledge check or a demonstration. Behaviour is whether people apply it at work, weeks later, without being prompted. Results is whether the business outcome moved: fewer errors, shorter cycle times, a smaller support queue, better retention. The four are not four metrics, they are four different claims, and each needs a different kind of evidence.
What is the difference between level 2 and level 3?
Level 2 is knowing. Level 3 is doing. The distinction matters because the conditions are completely different. A knowledge check happens while the training is fresh, in an environment designed for it, with the person's full attention and no competing deadline. Level 3 happens on a busy Tuesday, three weeks later, with a customer waiting and nothing on screen reminding anyone what to do. The gap between them is known as the transfer problem, and it is not closed by teaching the content better. It is closed by making the right support available at the moment of the task.
Why do most training programmes stop at level 2?
Three gradients run the same direction across the levels. Cost: a feedback form takes a minute of time in a session that is already happening, while level 3 evidence needs attention weeks later at a moment nobody has scheduled. Timing: levels 1 and 2 are available within the week, level 3 needs several weeks to mean anything, and level 4 usually arrives after the review that was going to judge the programme. Ownership: levels 1 and 2 belong to the training team, levels 3 and 4 live in someone else's system. Underneath all three is a harder fact. Levels 1 and 2 can be produced by the training itself, and level 3 cannot, because it requires something to happen at a moment the training is not present.
How do you apply the Kirkpatrick model to software training or user onboarding?
Design it backwards. Start at level 4 by naming one number with a baseline and a date. Derive the level 3 behaviour that would move that number, stated as something specific and observable inside the product. Derive from that the level 2 knowledge people must have unaided, which is usually far narrower than a tour of the software. Decide level 1 last, as a constraint: whatever carries the knowledge has to be short and well timed enough that people do not refuse it. Then build the required drivers alongside, because they are what turns the level 2 result into a level 3 one.
What are required drivers in the Kirkpatrick model?
Required drivers are the processes and support that reinforce, encourage, monitor and reward the new behaviour after the training ends. They were added in the New World revision of the model, and the claim behind them is that without them most of what was learned never becomes behaviour, however good the training was. In software they translate almost one for one into the product: a tooltip on the control people hesitate over is reinforcement, a checklist with visible progress is encouragement, per-step drop-off is monitoring, a published date on which the old route is retired is accountability, and guidance that can be relaunched is a refresher.
Is product tour completion rate a level 3 metric?
No. Tour completion is a level 1 measure. It records that someone clicked through a guide until it ran out, which is engagement, not behaviour. Checklist completion is a little closer, usually level 1 or level 2, because the items are often real actions, but they are performed with the instruction on screen, which is test conditions. The level 3 equivalent is unaided completion of the real task after the guidance has gone, by the intended route, repeated weeks later. Tour completion and task completion can move in opposite directions, because a tour can be completed more often precisely because it got shorter and emptier.
What is the difference between the Kirkpatrick model and the Phillips ROI model?
The Phillips model, associated with Jack Phillips, keeps the four levels and adds a fifth above results: return on investment, which converts the level 4 outcome into money and sets it against the fully loaded cost of the programme. It also places more emphasis on isolating the effect of the training from other causes, which is the discipline most level 4 claims are missing. If your audience is a finance review rather than a training review, the fifth level is the one they are asking for.
What are the criticisms of the Kirkpatrick model?
Five come up repeatedly. The levels are often read as a causal chain when they are not, so a strong level 1 result ends up presented as evidence of impact. The model assumes training is a discrete event, while much real learning of software is continuous and ambient and leaves no event to evaluate. It evaluates rather than designs, so it will tell you a programme did not change behaviour but not which behaviour to have chosen. Level 4 attribution is genuinely hard without a holdout or a staged rollout. And it is easy to turn into a reporting ritual, four boxes filled in afterwards to justify what already happened, which keeps the cost of the model and discards the benefit.