Ask any owner of a mortgage bank about the last piece of software they bought for their production floor. You will hear some version of the same story. The demo was great. The rollout was a war. Six months later, three loan officers use it, the rest went back to their spreadsheet and their phone, and the seat licenses renew anyway because nobody wants to admit it.
This is not a training problem and it is not a stubbornness problem. It is a math problem.
A producing loan officer will not trade time for a promise
A loan officer doing ten to fifteen units a month is running at capacity. Every new system asks them to spend time now, learning a tool and feeding it data, in exchange for a benefit later. From where they sit, the time cost is certain and immediate and the benefit is speculative and distant. Declining is not irrational. It is the correct read of the offer.
The industry's response has been to push harder. Mandates from the top. Adoption dashboards. A manager standing over someone's desk asking why they have not logged their calls. This produces compliance theater, which is worse than nothing, because now the data in the system is both incomplete and wrong.
So we inverted the ask
Our internal rule is that Lia should deliver one hundred percent of its value at zero percent usage. Not low usage. Zero. If a loan officer never opens Lia, never logs anything, never changes a single habit, the product still has to be worth what the lender pays for it.
That constraint rules out most of what software companies want to build. No data entry, because we do not get to ask for any. No new system of record, because they already have two and will not maintain a third. No workflow the loan officer has to remember to follow, because they will not.
What survives the constraint is a narrow thing. Lia reads what is already there, works out what should happen next, and puts the finished work in front of the person. The loan officer's only interaction is the one they were already having: reading something and deciding whether to send it.
Why this changes the sale
When a product requires adoption, the buyer is buying a change management project and they know it. The real question in the room is not whether the software is good. It is whether this particular team, with these particular people, will actually use it. Nobody can answer that honestly, so the deal stalls.
When a product requires no adoption, that question does not come up. The owner is not betting on behavior change. They are evaluating output. Either the drafts are good enough to send or they are not, and that is something you can find out in an afternoon rather than a quarter.
The uncomfortable version
There is a harder implication here that we have made peace with. If the value has to survive zero usage, then every feature we might want to build has to justify itself without assuming anyone will go looking for it. A brilliant dashboard nobody opens is worth zero. A clever configuration screen is worth less than zero, because it implies someone has to configure it.
It is a frustrating constraint to design under. It is also the only one we have found that produces software a working loan officer will actually keep.