A business can own a solution, pay for it every month, record it as adopted, then still not use it. That gap is one of the most reliable places to find value, because nobody has to be doing anything wrong for it to open up.
The BBC reported in August 2026 on why Japanese firms have been slow to take up AI. Two figures in it sit oddly together.
Japan's Ministry of Finance says 75% of companies now use the technology, up from 11% five years ago. Yet OECD data cited in the same piece puts the share of Japanese workers using AI in their job at 8.4%, against 50% in the US and 32% in the UK.
Both numbers can be true. A company counts as an adopter the moment somebody switches something on. That tells you nothing about whether the work changed.
Adoption is a purchasing event. Use is an operating one
This is the distinction most reporting collapses. Most businesses collapse it too.
The article quotes critics arguing that at many of those companies only a tiny proportion of staff actually use the tool, with those who do using it lightly. Professor Parrisa Haghirian of Kyoto University of Advanced Science, quoted in the same BBC report, notes it is mainly applied to low-risk tasks such as writing or summarising, "much less for core operations or decision-making and for improving overall processes".
That is the shape of the problem. The capability sits at the edge of the business rather than in the work that actually costs money.
It is rarely an argument about the technology
The most useful line in the piece is not about AI at all. Haghirian, in the same report, observes that "the challenges of adopting it are the same as adopting any change".
That reframes the whole question. If the barrier were technical, the fix would be technical. It is usually not. The article describes companies where consensus process slows decisions, where tolerance for error in anything client facing is close to zero. Austin Xu, co-founder of Kuse AI, which sells AI systems into Japan, told the BBC that some firms would "rather leave a role unfilled than let a machine handle it".
Read that last one carefully. It is a rational choice by people protecting something they value, which is reliability in front of a customer. It is also expensive. Both things are true, which is why it never gets resolved by argument.
What it sounds like inside a business
This is the transferable part, because every business has a version of it. It is almost never labelled as culture or governance internally. It sounds like:
- We tried that before
- That is not how we do things here
- The team would never use it
- We looked at it, it was not right for us
- It works fine as it is
Each of those is a finding. None of them appears in a technology review, because a technology review does not ask the question that produces them. You get them by talking to people at every level, then checking what they say against what the systems show.
And they are worth chasing, because a refusal is cheaper to resolve than a rebuild. The capability is already bought.
Two things a diagnostic separates
There is a version of this where the refusal is correct, which is why it needs evidence rather than assumption.
- The solution is genuinely wrong for the business. It was sold on a demo, it does not fit how the work runs. Or the risk it introduces is real enough to matter. Forcing it through would cost more than leaving it. Finding this out is a saving.
- The solution is fine. The conditions around it were never built. Nobody was trained past the basics. The process it was meant to replace still runs alongside it. The person who would own it has no authority to change anything.
Those look identical from the outside. Both present as low usage. They need opposite responses, which is why the answer has to come from evidence rather than from whoever argues hardest.
The compounding version
The article notes around 60% of company computer systems in Japan are more than 20 years old, alongside a projected shortfall of nearly 800,000 IT professionals by 2030.
That is the harder case. When the constraint is old systems plus scarce skills plus a culture that treats error as unacceptable, no single intervention moves it. The sequencing question becomes the whole question, which is exactly what a prioritised roadmap is for.
How to measure your own adoption gap
The useful thing about this particular gap is that almost every system reports on itself. You are looking for the distance between licences paid for and licences actually used.
| Where to look | What to pull | The calculation | What it tells you |
|---|---|---|---|
| Microsoft 365 and Entra admin | Active users per app, last sign-in per licence | Active seats ÷ paid seats = utilisation | Seats paid for against seats used. Usually the fastest win in the list |
| Service and CRM: HubSpot, Salesforce, Zendesk, ServiceNow | Logins per user per week, records created per user | Weekly active users ÷ licensed users | Whether the system runs the pipeline or merely records it afterwards |
| Finance system: MYOB Advanced, NetSuite, Business Central | Which modules have transactions this quarter | Count of modules with zero transactions | Modules bought in a bundle and never switched on |
| Job, project or workforce system | Feature usage reports, plus how many exports go to spreadsheets | Exports ÷ active users | A high export rate means the real work happens outside the system |
| Any subscription | The vendor's own usage or adoption dashboard | Whatever the vendor reports | Vendors track this closely. Most will show you on request |
| Your supplier ledger | Every recurring software charge, listed | A count, not a ratio | The list itself is frequently the finding |
These are standing metrics with alert thresholds rather than a one-off exercise.
Start with the last row. List every recurring software cost, then put a name against each one as the person who would notice if it stopped. Anything without a name is either unused or undefended. Both are worth knowing.
The one number to track
- Paid seats against seats with a sign-in in the last thirty days, per system.
Signed in ÷ paid= utilisation - Under 60% is common
- Under 30% means you are funding something the business decided against without telling anyone
The control worth introducing
- Every recurring software line gets a named owner at the point of purchase, not at renewal
- Renewal requires that owner to state the utilisation figure. No figure, no renewal
Where your number will mislead you
- A licence can be signed into daily and still be barely used. Sign-in is a floor rather than a measure of value
- Shared or generic accounts inflate utilisation, because one person keeps the seat warm for a team that stopped
- A low figure on a seasonal system is not a finding. Read it across a full cycle
What have you already bought that nobody uses?
Most businesses have at least one. A system, a module, a licence, a capability that was implemented, announced, then quietly worked around.
The question worth sitting with is whether that happened because the thing was wrong for you. The alternative is that nobody built the conditions it needed. Those look identical from the outside. They need opposite responses, which is why the answer has to come from evidence rather than from whoever feels most strongly.
The Free Health Check will show you where the gaps are likely to sit, in about three minutes. If you want to know which of the two you are dealing with, a diagnostic is built to establish exactly that.