| The test | The cause | The fix |
|---|---|---|
| The testAsk a field worker to log in in front of you, unaided, and time it | The causeOver two minutes: access is too slowTool side | The fixSimplified access, no work email required |
| The testAsk three field workers what they learned and used last week | The causeNo concrete answer: the content does not serve the jobOrganisation side | The fixStart from the questions actually asked on the ground |
| The testCompare usage rates between comparable teams, manager by manager | The causeWide gap: the frontline manager is not on boardOrganisation side | The fixGive the manager a use of their own, not another instruction |
| The testCompare login times with the hours people are actually free | The causeClear mismatch: the timing is wrongTool side | The fixMatch prompts to available time, offline mode |
| The testAsk what people think happens if they skip the training | The causeVague answer: the benefit is not immediateOrganisation side | The fixTie every piece of content to a concrete consequence |
In short, the five diagnostic paths: a timed login over two minutes means access is too slow, a tool cause. Three field workers with no concrete answer means the content does not serve the job, an organisation cause. A usage gap between comparable teams means the manager is not on board, an organisation cause. Login times out of step with real availability means the timing is wrong, a tool cause. A vague answer on what is lost by skipping training means the benefit is not immediate, an organisation cause. Three of the five are not fixed by changing platform.
The platform has been live for six, twelve, eighteen months. The modules exist. Budget was signed off, the leadership team briefed, the launch celebrated. And yet, when you open the dashboard, the login figures are sobering. This is not a failed project. It is an adoption problem nobody ever diagnosed.
An LMS rolled out but unused is not a failed project
The gap between rollout and real usage is the rule rather than the exception, particularly with people who have no fixed desk. A project lead who kept to the plan, held the budget and delivered a working platform did their job. What happens next, real adoption by teams in stores, warehouses or out on the road, is a subject in its own right, with its own causes and its own levers.
Then comes the most common and most expensive mistake: treating non use as a motivation problem. A reminder email campaign, an internal comms push, a nudge from the leadership team will change nothing if the real cause lies elsewhere. Non use is a symptom, not a diagnosis. You do not revive an LMS with communication, you revive it by identifying which of the five points is actually blocking.
- Email campaign, internal memo, reminder from the exec team
- Treats non use as a motivation problem
- Usage rises for a few days, then falls back
- Touches none of the five real causes
- Five tests, each doable in under an hour
- One week in the field, watching people work
- One main cause, one secondary cause
- The fix addresses what actually blocks
In short: the reflex is to relaunch through communication, which treats non use as a motivation problem and touches none of the five real causes. The method is to diagnose, with five tests each doable in under an hour and one week spent watching people work.
To go further on how engagement holds up over time, our article on sustaining engagement over time picks up where this diagnosis leaves off.
Why your current metrics tell you nothing
Your headline metrics, login counts or overall completion rate, mislead because they aggregate populations whose constraints have nothing in common. An average of 35 % can hide one team at 80 % and nine others at 20 %. Looking at the average is looking in the wrong direction.
Three breakdowns reveal the real cause: by team and by manager, by content type, by time of day. If you only pull one figure this week, pull usage by manager. It is usually the one that shows fastest where to look.
Worth remembering: if one team uses the platform and the others do not, the tool is not the problem. That single rule saves weeks spent changing LMS for nothing. To dig into measurement on the content side, improving your completion rate covers that angle.
- The first figure to pull
- Shows whether the block is the tool or the management line
- If one team uses it and the others do not, the tool is not the problem
- Shows whether the content actually serves the job
- Surfaces the content nobody opens
- Steers production towards the useful, not the catalogue
- Shows whether prompts land at the wrong moment
- To be set against the teams' real working hours
- Flags areas with no usable network
In short: three breakdowns reveal the cause. By team and by manager, which is the first figure to pull. By content type, to spot what serves nobody. By time of day, to set prompts against real working hours.
The 5 causes of low LMS adoption, and how to test yours
Five causes account for almost every case of an unused LMS, and each one can be tested in under an hour. Before launching an action plan, work out which one is yours: the fix differs with the cause.
Cause 1: access is too slow or too complicated
This is the most common cause with people who have no fixed desk. The test: ask someone to log in in front of you, unaided, and time it. Over two minutes, this is your main cause. This is precisely where an LMS built for field teams like Beedeez differs structurally from a tool designed for the office: login without a work email, reachable in seconds, native offline mode for areas with no coverage.
Cause 2: the content does not serve the job
The test: ask three people what they learned and used last week. No concrete answer points to this cause. The fix is not to produce more content, but to start from the questions teams actually put to their manager, rather than from a catalogue designed at head office.
Cause 3: the frontline manager is not on board
The test: compare usage rates between comparable teams, manager by manager. If two comparable teams show a wide gap, the variable is the manager, not the platform. This cause is rarely fixed by changing tool.
Cause 4: the timing of prompts is wrong
The test: look at what time logins happen in the teams that do use the tool, and set that against the real hours of the teams that do not. This one particularly affects teams on shift patterns or in areas with unreliable coverage. Short formats, readable offline and picked up automatically on reconnection, answer it directly.
Cause 5: the benefit is not immediate
The test: ask people what they think happens if they skip the training. A vague answer points to this cause. It is the subtlest to diagnose, because it requires asking rather than assuming. Someone who does not know what they lose by not training has no rational reason to do it.
Let us close this section on an honest and deliberately uncomfortable note: three of these five causes cannot be fixed by changing platform. An LMS better designed for the field solves the material causes, not the organisational ones.
One week to know
The full diagnosis runs over a week, in the field, watching people use the tool, not poring over dashboards from a desk.
Here is the rule that makes the difference: watch people work, rather than ask for their opinion. Someone will rarely tell you they could not work out how to log in. They will far more readily say they did not have time.
The relaunch plan, week by week
The relaunch plan does not target the whole company at once: it concentrates on one representative pilot team, and turns its result into the internal proof for what follows.
- Day 1Pull usage by team, by manager and by content typeDiagnosis. Output: the real spread, not the average
- Day 2Go on site and watch three people log in, without stepping inDiagnosis. Output: the real login time, measured
- Day 3Two short interviews with managers, one whose team uses it, one whose team does notDiagnosis. Output: the gap explained
- Day 4Five short interviews with field workersDiagnosis. Output: what they believe they lose by not training
- Day 5Conclude on one main cause and one secondary causeDiagnosis. Output: the cause to fix first
- Week 1Fix the main cause, on the pilot scope onlyRelaunch. Output: the fix live for one team
- Week 2Produce or rework three pieces of content directly useful on the jobRelaunch. Output: three short sequences available
- Week 3Bring the pilot manager on board and give them a use of their ownRelaunch. Output: the manager self sufficient on team follow up
- Week 4Measure, compare with the starting point, decide on the rolloutRelaunch. Output: the internal proof, or the next cause to tackle
In short: five days of diagnosis, from pulling usage data to concluding on a main and a secondary cause, then four weeks of relaunch on a pilot scope, from fixing the main cause to deciding on the rollout. An indicative framework, to be adapted to your context, with no guarantee of results.
Yes, that means a month before scaling. It is the price of a relaunch that holds, rather than a comms campaign that runs out of steam in three weeks. The relaunch is judged on the pilot team's real usage, never on a global figure that hides the gaps.
To produce the useful content of the relaunch plan quickly without depending on an external supplier, producing useful content fast sets out how a subject matter expert builds a capsule in a few hours. And if your situation is really about restarting a rollout from the ground up rather than reviving it, taking the rollout back to basics covers that case.
The metrics that matter after the relaunch
After the relaunch, four metrics are enough to steer what follows: they matter more than raw login counts.
- The share of people active over 30 days, not the number of accounts created.
- The time between a piece of content going live and its first view.
- The completion rate by content type, to spot what serves nobody.
- The usage gap between comparable teams, which should narrow if the relaunch is working.
These are figures observed on field deployments, not a promise of results. Yours will depend on the cause you fix and on how well the plan is executed.
In short: a 95% completion rate and 92% engagement are benchmarks observed on field deployments, to be compared with the 20 to 40% completion of a standard LMS. At Amorino, the top 30% performing franchises all reach at least 90% completion. These are observed figures, not a promise of results.
On well designed field deployments, the benchmarks observed run up to a 95 % completion rate and 92 % employee engagement, against 20 to 40 % completion for a standard LMS. These are observed figures, not a promise: your own result depends on the cause you fixed and on how well the plan was executed. At Amorino, the 30 % of franchises with the strongest commercial performance all record a training completion rate of at least 90 %. That figure illustrates a correlation observed at one customer, not a guaranteed causal link.
To go further on measuring impact beyond usage, our article on measuring effect and not just usage sets out how to connect completion with results in the field.
Frequently asked questions
How long does it take for an LMS to be genuinely adopted?
A full diagnosis takes a week, and a first measurable relaunch runs over 30 days on a pilot scope. Rolling that out across the organisation takes longer, depending on how many teams you have and which cause you fixed. There is no universal timeline: it depends on the cause, not on the calendar.
Should training be made mandatory to force usage?
Mandating works for compliance, not for real skills growth. Making a course mandatory can lift a login figure without fixing the cause of the non use, which will resurface on the next optional piece of content. Diagnosis stays the first step; mandating is only a one off lever.
Is gamification enough to revive LMS usage?
No, not if the real cause is access or content. Gamification acts on engagement once people can actually log in and find the content useful. Our article on how gamification works sets out where and when it has a real effect.
How do you bring frontline managers on board without overloading them?
By giving them a use of their own, not one more instruction to chase people. A manager who can see live who is progressing and who is dropping off treats the platform as a management tool, not as extra admin. That is what an LMS built for field teams such as Beedeez enables: the manager follows their team's progress from their phone, with no export and no request to the L&D team.
Should you change platform if adoption never takes off?
Only if the diagnosis points to a cause structurally tied to the tool, such as an access flow too heavy for teams with no fixed desk. An LMS built for field teams like Beedeez answers the material causes (login without a work email, offline mode, short formats); organisational causes are fixed internally, whatever platform you choose.
What usage rate should you aim for with field teams?
There is no universal threshold, but a narrow gap between comparable teams is the most reliable sign of successful adoption. Benchmarks observed on well designed field deployments run up to a 95 % completion rate, against 20 to 40 % for a standard LMS. Those are figures observed on Beedeez deployments built for the field, with login without a work email and short formats: they depend first on the cause you fixed, not on the platform alone.
You now have what you need to turn a discouraging dashboard into a dated action plan. Non use is not the fate of a failed project: it is a five way diagnosis, one week to make it, and 30 days to fix it on a pilot scope. Book a Beedeez demo to see how an LMS designed for the field removes the material causes of non use.
