Adoption is the only feature that matters in firm-wide software

Software procurement in firms is run as a feature comparison. A matrix, a shortlist, a scoring exercise, a decision. For most categories that is sensible. For anything whose value depends on the whole firm using it, it is close to irrelevant, because one variable dominates every other and it is almost never on the matrix.

Why coverage is not linear

Suppose your firm deploys a system for recording what engagements each person has led, and a third of people use it.

The intuition is that you get a third of the value. You do not. You get almost none, and the reason is worth stating precisely.

A user searches for who has experience of something. The system returns two names. The user now faces a question the system cannot answer: are these the only two people in the firm with this experience, or are they the only two whose records happen to be in here?

There is no way to tell. So the answer cannot be relied on for the decision that prompted the search, and the user does the thing they were going to do anyway: they send the broadcast email. Having done that twice, they stop searching.

Below the coverage threshold, a knowledge system cannot produce a usable negative, and a system that cannot say no cannot be trusted when it says yes.

This is the mechanism behind every dead wiki in every firm. Not that the content was bad. That there was not enough of it for absence to mean anything.

The threshold is higher than people expect

Where it sits depends on the question, but the direction is consistent: it is high, and it is not reached gradually.

For expertise lookup, coverage has to be near complete within any practice group a user might plausibly search, because the failure mode is a false negative and false negatives are invisible. The user does not learn they got a wrong answer. They learn the firm has no experience, act on that, and never find out otherwise.

For relationship history it is worse, because the searcher usually has a specific prior belief. If a partner suspects the firm has dealt with a stakeholder before and the system says nothing, they conclude the system is incomplete, not that the firm has no history. One such experience is enough to reclassify the tool as unreliable, permanently.

Why the usual adoption levers do not clear it

Firms have a standard toolkit for this and it produces compliance rather than coverage.

Mandates. A partnership can require a field to be completed. It cannot require the field to be true. Mandated entry produces records that clear a validation rule and mean nothing, which is worse than an empty record because it looks like data.

Champions and sponsorship. Genuinely helpful, and it moves the curve by some amount for some period. It does not survive the first busy quarter, because the underlying arithmetic has not changed: the time is still non chargeable and the benefit still accrues to someone else.

Training. Addresses a cause that is not the cause. Nobody fails to update the system because they do not know how.

Making it easier. Faster forms, better defaults, mobile entry. This is real progress and it has a ceiling: the minimum viable effort is still greater than zero, and greater than zero loses to billable work reliably.

The MIT Sloan research on organisational memory reached this conclusion thirty years ago from twenty two projects across professional services and other sectors: technology alone did not improve performance, and the projects that worked were the ones where memory was a by product of how the work already ran rather than an activity alongside it. That is the only lever with the right shape.

The design consequence

If partial adoption produces near zero value, then the only viable design target is coverage close to complete, and the only route to that in a billable culture is capture that costs the fee earner nothing.

Not "low friction". Zero. The moment there is a step, however small, its completion rate becomes a function of how busy the person is, and the busiest people hold the most valuable knowledge. That inverse correlation is what makes partial adoption not merely incomplete but biased: the records will be systematically thinnest where they would be worth most.

This is the reasoning behind how material reaches OrgAtlas. Each account has its own address, and the team uses it inside the habits they already have: blind copy it on the way out, forward a thread that has just concluded, upload a document in the browser. None of those are new work. The first is a keystroke on an email that was being sent anyway.

It is not literally zero, and claiming otherwise would be dishonest. Somebody has to add the address. What matters is that the action sits inside an existing motion rather than beside it, so it competes with muscle memory rather than with billable time.

The question is not how long the step takes. It is whether the step is a separate act.

How to evaluate for this

Four questions, worth more than any feature matrix in this category.

1. What must a fee earner do, in a normal week, for this to stay current? Ask for the specific action, not the philosophy. If the answer is any form of "review and update", the coverage curve is already determined.
2. What is coverage at existing customers, twelve months in? Not licences. Not logins. What fraction of the firm's actual work is represented. Vendors who have solved this will tell you; vendors who have not will answer a different question.
3. Can a user distinguish "no record" from "no experience"? If the interface cannot express the difference, negatives are unusable and the tool will only ever be consulted to confirm things people already suspect.
4. Where does the data come from when nobody is thinking about the system? This is the same question as the first, asked in a way that is harder to answer with a roadmap.

The uncomfortable corollary

A system with excellent features and 30% coverage loses to a worse system with 95% coverage, every time, and it is not close.

That is an unusual thing for a software vendor to write, and it cuts both ways for us. It means the right question to put to OrgAtlas is not what the atlas can do. It is what an account team has to do in a normal week for the atlas to be true, and whether that survives the week the client's programme goes wrong and nobody has time for anything.

We think it does, because the answer is a blind copy on mail that was being sent anyway. But that is the question to press on, for us and for anyone else in this category.

Related: why knowledge management failed, and the cost structure that killed it