What businesses actually want
Strip away procurement and feature comparisons, and what a business wants from software is simple to state: the exact system that maximizes business value. Knowing it was never the hard part. Getting it was.
Outcomes, not software
No board has ever celebrated the acquisition of software. They celebrate faster quotes, fewer invoice errors, shorter lead times, customers who stay. Software is the cost paid to reach outcomes, and the industry's oldest trick is getting buyers to evaluate the cost as if it were the outcome.
That trick is why demos exist. A demo shows the software being impressive; it cannot show your Tuesday afternoon becoming shorter. The question a business actually needs answered — what does this do to our numbers — is the one question a feature tour never touches.
The exact system
The ideal is precise: the exact workflows, the exact processes, the exact information, the exact automations and the exact interfaces that maximize business value. Nothing more. Nothing less.
Both halves bite. "Nothing more" rules out the modules nobody opens, the features meant for a different industry, the settings pages that exist because some other customer once demanded them — all of it paid for, all of it in the way. "Nothing less" rules out the gaps, and gaps never stay empty: they fill with spreadsheets, side channels and one person who knows how things really work.
Every business runs the sum of both errors. Software it pays for and does not use, next to processes it runs outside the software it paid for.
Not fewer systems — the right system
Consolidation, as usually pitched, means fewer vendors: replace nine tools with one suite and call it simplification. The goal was never fewer systems, though. A single suite that fits approximately is the same compromise as the patchwork, purchased in one invoice instead of nine.
Suite vendors will answer that everything-in-one-place is exactly what this principle demands. It is not. One place built for the average company is the average company's system. One system is only the right system if it is your system — your workflows, your terminology, your rules, not a configuration surface stretched over someone else's.
One system is only the right system if it is your system.
How to ask for it
The practical consequence lands on how systems get specified. A requirements document written as a feature list has already surrendered — it describes software, so it will be answered with software. Describe the business instead: what happens from inquiry to cash, where the hours leak, which decisions arrive too late, what a good Tuesday looks like.
Deciding what deserves to be built at all is its own discipline, and it is where the value question gets answered or dodged. The system that maximizes business value starts as an honest description of the business, not as a shopping list.
What is worth building