12 June 2026 · Pedro Aldea
98% of companies say they 'use AI'. How fast does yours answer a simple question?
Adopting AI and being able to ask your business a question are not the same thing. The stopwatch test: from 1-3 days to seconds per question, told from a system in production.
A new survey puts the number at 98%. That’s the share of IT leaders who say their company uses AI. GoTo and Workplace Intelligence surveyed 2,500 employees and IT leaders between November 2025 and January 2026, and the headline is that AI at work is no longer an experiment. Good. We won’t argue with that. The more people try these tools, the better. But there is a wide gap between “using AI” and something much more concrete: any person in your company asking your operation a question and getting a reliable answer while they still care about it. The first one gets settled in a survey. The second one gets measured with a stopwatch.
The stopwatch test
The proposal is simple, and anyone can run it this week. Pick a normal business question, the kind that comes up in any meeting: what did we sell last quarter in this territory, by product family? Ask it the way it always gets asked. To the admin person, the IT lead, whoever “knows how to pull that”. Start the clock. Stop it when you’re holding an answer you trust enough to decide with.
In most companies where we’ve run this exercise, the clock doesn’t measure minutes. It measures days.
And it’s worth watching the route, because the time doesn’t go where you think. Running the query against the ERP takes seconds. What takes days is everything around it: the email to the person who knows the query, the request queue it lands in, the gap in their calendar, the export to a spreadsheet, the reply, and often a second round because the question wasn’t quite the right one. At an industrial distributor we worked with, that full loop took between one and three days per question. Not for a hard question. For every question.
The bottleneck isn’t technical
The first thing to say about that loop is that the technology isn’t what fails. The data exists. It sits in the ERP, reasonably clean, and the query is trivial. What you have is an organizational toll booth: only two or three people know how to extract the data, and everything the company wants to know about itself passes through their inbox.
That toll has a visible cost and an invisible one. The visible one is the hours spent by people acting as translators between the business and the database, answering one by one the questions that keep repeating. The invisible one is worse: all the questions nobody bothers to ask anymore. When getting a number costs three days and a favor, people stop asking. Decisions get made on instinct, on habit, or on last year’s number. Not because anyone is careless, but because the loop turns every question into a paperwork exercise. A company can be “using AI” in marketing, in support, in email drafts, and still run like this on the inside.
What we built, and why it didn’t start with AI
At that distributor we built a natural language interface on top of the ERP: any authorized employee types their question in plain language and gets the answer directly. But the work that made that system possible wasn’t model work. It was operations work, and we think the order matters enough to tell it that way.
Before writing any code, we mapped the questions the organization was already asking: the ones arriving in IT’s inbox, the ones that repeat at every month-end close, the ones each department keeps in its own spreadsheet. About twenty business questions covered the overwhelming majority of requests. And there was a less comfortable discovery: many were the same question wearing different words, not always with the same definition. What exactly counts as an “active customer”? What does “margin” include? From when is an order “shipped”? Settling those definitions with the people who use the data every day was the hard part of the project. The interface came after, with its guardrails: role-based access, query validation, and verification of results, because a fast wrong answer is worse than a slow right one. And the rollout went phase by phase. Commercial team first, the rest of the departments after. No company-wide premiere on day one.
The result gets measured, not told
The before and after fit in one line: a question to the ERP went from taking one to three days to taking seconds, and it stopped depending on anyone’s calendar. That was the goal, and it’s verifiable, which is the only thing we ask of any project. If it can’t be measured, it didn’t improve.
But what interests us most about this case is the effect that was never in the plan. Once asking stopped costing three days, people started asking more. And above all, asking better. Follow-up questions, comparisons nobody used to bother requesting, hypotheses checked in the same meeting where they came up. The system didn’t make anyone smarter. It removed the toll that was blocking the intelligence already in the room.
Adopting is not accessing
Back to that 98%. If your company is in that group, the interesting question isn’t whether it “uses AI”. It’s where. On the periphery, with texts, summaries and emails? Or at the center, where the operation’s data lives? Our experience, across five systems running in real production with zero failed implementations, is that the big value is at the center, and getting there is almost never a model problem. It’s an operations problem: knowing which questions your organization actually asks, what every business term means, and where the days of waiting leak out today. AI is the piece you install at the end, once all of that is clear. Operations first. Technology after.
So the practical conclusion is the one we started with: run the stopwatch test. One normal question, the usual loop, the real time to a reliable answer. That number, days almost certainly, is the distance between the AI your company “uses” and the AI it’s missing.
How fast did the clock run in your company?
If you want to see this on your own data, this is how we approach data intelligence: we start by mapping the questions your organization already asks, and the ones it stopped asking because they cost too much, before proposing a single piece of technology.