Enterprise software is bought by people who never use it (that’s the problem)

A VP of Supply Chain approves the budget. A driver picks up the app for the first time with 40 stops and a two-hour window closing fast. The person who made the decision and the person who lives with it are rarely the same.

This has always been true of enterprise technology, but the AI wave is making the gap harder to absorb. Companies are now rolling out AI-powered tools across frontline operations at a scale and pace that leaves little room for extended onboarding or gradual adoption. When those tools don’t fit how work actually happens on the ground, teams either don’t use them or find workarounds.

Across enterprise software, the top 6% of features drive 80% of actual usage. The rest were built for a slide deck, not for the person holding the device. That’s not a product quality problem in isolation. A significant part of it is a design and deployment problem rooted in who the product was built for in the first place.

Why AI makes this worse

The buyer-user gap becomes harder to paper over when AI enters the picture. A driver mid-route dealing with a road closure, a compressed delivery window and three failed attempts from earlier in the day isn’t working in a controlled environment. The constraints that actually define last-mile delivery — traffic patterns, dock cut-off times, vehicle capacity, local regulations — are exactly the conditions that surface how limited a lot of these tools really are.

Technology is only useful if it solves problems for the people using it, and for frontline teams, usefulness gets tested in real time, under pressure, with no room to troubleshoot.

When the official tool falls short, people adapt. A growing share (78%) of employees are now bringing their own AI tools to work rather than relying on what their company has deployed. Employees are attempting to take matters into their own hands by filling a gap that their enterprise solutions leave open.

The irony is that workarounds tend to compound the original problem. Individual tools used outside a company’s sanctioned stack mean fragmented data, inconsistent decision-making and no visibility for the teams responsible for overall operations. The adoption failure becomes an operational one.

Also Read: AiThority Interview with Glenn Jocher, Founder & CEO, Ultralytics

This is what “built with empathy” actually means

“Built with empathy” is a phrase we often use at Locus. What it boils down to is asking one question at the design stage: “Does this make the end user’s job simpler in the moment?”

Not simpler on a slide deck, and not simpler as measured by a director looking at a dashboard. Simpler for the warehouse supervisor who needs to make a call in the next two minutes, or the driver who picks up the app for the first time with no training session behind them and dozens of stops ahead.

This framing should change how and what we build. Interfaces need to be intuitive enough that a new user can get functional fast. The underlying system needs to account for real-world constraints, not just ideal routing conditions. When something goes wrong mid-operation, the tool should surface the right information quickly without requiring the user to know where to look for it.

In my experience, the biggest barrier to adoption in large enterprises is whether the teams responsible for using their systems can actually get fluent with it at the pace the business requires. A new user coming in without time for formal training shouldn’t be left to figure it out. When a tool is built with the frontline user in mind from the start, adoption follows more naturally. When it isn’t, no amount of onboarding effort fully compensates.

So, what should buyers do differently?

The procurement process for enterprise software is thorough in a lot of ways. Just think about how extensive the security reviews, integration assessments and commercial negotiations alone are. What’s missing is a serious evaluation of how software performs for the people who will actually use it daily.

Simplicity, usability and real-world fit aren’t soft criteria to be weighed against more serious technical requirements. They are the technical requirements, because they determine whether the capability an enterprise paid for ever gets used at scale.

That’s why frontline teams should have input in that evaluation process. They will surface friction points that demo environments alone may fail to reveal, and their feedback is genuinely predictive of whether adoption holds up over time. When was the last time your frontline team had a seat at the table during a software evaluation?

That evaluation shouldn’t stop at go-live either. Whether the investment is actually working shows up later — in whether the people expected to use the tool are using it, or finding ways around it.

At the end of the day, adoption is the real measure of ROI. Everything else is just potential.

Also Read: ​​The Infrastructure War Behind the AI Boom

[To share your insights with us, please write to psen@itechseries.com]

About the Author of this Article

Subhro Chakraborty is chief revenue officer at Locus, a leading AI-native logistics technology company, where he is responsible for driving revenue growth and leading the company’s global go-to-market strategy. Subhro has built his career driving growth in the technology sector, with experience scaling revenue, lowering customer acquisition costs, and leading go-to-market efforts. Prior to joining Locus, he served as Chief Business Officer at Capillary Technologies and Head of Digital Marketing Solutions at Adobe.

About Locus

Locus is a software solutions provider for global logistics, known for building the world’s first Agentic Transportation Management System (TMS) automating the human decisions in delivery and logistics since 2015.