Why Enterprise Software Is Universally Hated

I was reading the DeLone and McLean IS Success model for what must have been the fifth time when something about it started bothering me. Not the model itself. It is elegant. Six dimensions: system quality, information quality, service quality, use, user satisfaction, and net benefits, with feedback loops between use and satisfaction. The 2003 update added service quality and collapsed individual and organizational impact into a broader construct called net benefits. Clean. Parsimonious. Widely cited. The thing that bothered me was what the model silently assumes: that the person evaluating the system is also the person using it.

Enterprise software breaks that assumption. It breaks it completely, structurally, and by design.

SAP, Oracle, Workday. These systems run the Fortune 500. They are the backbone of global logistics, finance, HR, and supply chain. They also inspire a level of daily frustration that consumer software rarely reaches. People do not make memes about hating Spotify. They make memes about hating their expense reporting system. And the standard industry explanation is UX: the interface is clunky, the workflows are rigid, the configuration is a maze. I think that explanation is wrong. It diagnoses the symptom while missing the disease.

The disease is that the buyer and the user are separate people. The buyer is procurement, IT leadership, the C-suite. They evaluate a system on integration requirements, vendor stability, compliance checkboxes, and total cost of ownership. The user is a manager in a business unit or an employee submitting a purchase request. They evaluate the system on whether they can finish their work without wanting to throw their laptop out a window. These two sets of criteria have almost nothing in common. The buyer signs the check. The vendor optimizes for the buyer. The user is downstream of a decision they never made.

DeLone and McLean's model makes this visible in a way that I think the IS field does not talk about enough. User satisfaction is right there in the model, connected to use and net benefits through feedback loops. The assumption is that satisfaction shapes continued use and continued use shapes satisfaction. That feedback loop is real in consumer contexts. If I hate a music streaming app, I stop using it, the company loses revenue, and either the product improves or the company dies. The feedback loop works. In enterprise contexts, if I hate my expense reporting system, I still have to use it. My manager approved it. IT configured it. Procurement signed a three-year contract with penalties for early termination. I have no exit. The feedback loop from satisfaction to use is broken. Disuse is not an option.

Bhattacherjee (2001) built his Expectation Confirmation Theory of IS continuance on the assumption that satisfaction drives continued use. His model says continuance intention comes from satisfaction and perceived usefulness, and satisfaction comes from whether expectations were confirmed. It is a good model when the user has agency. In enterprise software, I had no expectations because I never chose the system. My usefulness was never the metric. I continue using it not because I am satisfied but because I have no exit. This is not continuance in Bhattacherjee's sense. It is forced engagement with a tool you resent.

I think Burton-Jones and Grange (2013) gave us the vocabulary for understanding what happens next. They distinguished use from adoption from evaluation, and they defined effective use as faithful domain representation. A system is used effectively when its users engage its deep structure to accomplish real domain tasks. In enterprise software, the surface structure gets used perfectly. The login rate approaches 100%. The workflows get followed. The required fields get populated. But the deep structure, the actual organizational reality the system is supposed to represent, gets mangled. Salespeople enter data to satisfy the CRM, not to represent customer relationships. Managers approve items to close their queue, not to exercise judgment. The system is used. It is not used effectively. And because the buyer measures adoption rates, not effective use, the dashboard shows success while the domain representation rots underneath.

I wrote before about why logging in is not the same as using, and that argument matters doubly here. The person measuring the logins is often the person who bought the system. They have every incentive to see adoption numbers that justify their purchase. They have no incentive to ask whether those logins produced anything resembling faithful domain representation. The metric is gamed, and the game is built into the incentive structure.

This structural gap shows up cleanly in collaboration tools. Slack spread bottom-up: a team tried it, liked it, told another team, and IT eventually had to decide whether to pay for it. Teams spread top-down: Microsoft bundled it with Office 365, procurement signed the agreement, and everyone had Teams because the license was already paid for. Slack users chose their tool. Teams users received theirs. The adoption pattern predicts satisfaction almost perfectly, and it has nothing to do with interface design. Microsoft has some of the best engineers on the planet. The difference is structural. When the user chooses, the vendor's incentive is to please the user. When the buyer chooses, the vendor's incentive is to please the buyer.

The gap also distorts what gets built. Enterprise vendors compete on features that buyers evaluate: access control granularity, audit logging, integration breadth. These are impressive in a CIO demo. They are not features that make a line manager's daily workflow easier. The product accumulates buyer-facing features at the expense of user-facing usability. The result wins RFPs and loses employees. I wrote about why technology spending alone rarely produces value, and enterprise procurement is a case study in that logic: every checkbox gets checked, and the output is a system nobody wants to use.

I should say I do not think this is a conspiracy. Procurement departments have a job: evaluate vendors across integration, compliance, risk, and cost. Adding "will every employee like using this" is structurally impossible because they cannot know what every employee needs. The problem is not bad people. It is a bad market structure. The market separates the evaluator from the user, and the evaluator's criteria dominate.

Some organizations are experimenting with user panels in vendor selection. Some vendors include end-user satisfaction metrics in renewal conversations, knowing renewal depends on it even if initial selection did not. I think the real shift will come when procurement frameworks incorporate user satisfaction as a weighted criterion alongside integration, compliance, and cost. That sounds utopian. It is really just DeLone and McLean, applied honestly. If user satisfaction is a dimension of IS success, and you want the IS to succeed, measure it before you buy.

Until then, the person signing the check will keep buying tools the user hates, and the user will keep using them because quitting is not an option. DeLone and McLean gave us the model. The market just refuses to follow the feedback loop.