The 79% Problem: Why the People Who Need Data Still Cannot Get It

The 79% Problem: Why the People Who Need Data Still Cannot Get It

Picture the person who knows your customers best. Maybe it is the account manager who speaks to them every week. Maybe it is the operations lead who sees every delayed order. Maybe it is the sales rep who knows exactly which deals are about to slip.

Now ask that person a simple question. How many customers churned last month, and which ones?

In most companies, they cannot answer it themselves. They have to write a ticket, send a message, or walk over to someone on the data team. Then they wait. And while they wait, they keep making decisions using instinct, memory, or a spreadsheet they built by hand three months ago.

This is not a small inefficiency. Industry research consistently finds that roughly 79% of employees who need data for their job must ask someone else to get it. Only a minority can retrieve the numbers they need on their own. The people closest to the problem are structurally separated from the evidence.

The Bottleneck Is Not the Analysts

It is tempting to blame the data team for being slow. That is unfair and it misses the point.

Analysts are not slow because they are careless. They are slow because they are asked to be the single point of access for every question in the company. A typical analytics team receives a constant stream of ad hoc requests, each one urgent in the eyes of the person asking. Every request has to be understood, translated into a query, validated, and explained. That is skilled work, and there are only so many hours in a week.

The consequence is a queue. And queues do not just delay answers. They change behavior. When people learn that asking a question takes three days, they stop asking. They make the decision without the data, or they build a shadow spreadsheet, or they simply guess. The organization does not become more data driven. It becomes more resigned.

There is a second cost that rarely gets measured. The analyst who spends Tuesday answering a question about last month's churn is not spending Tuesday building the model that would have predicted next month's churn. The most valuable analytical work is the work nobody had time to request. That work is what disappears first when the team is buried in tickets.

Why Most Self-Service Tools Did Not Fix It

The promise of self-service analytics was supposed to solve exactly this. Give business users a tool, teach them to drag and drop, and let them answer their own questions.

It did not work as intended. Adoption of traditional BI tools has hovered around 25% of employees for years, and it has barely moved despite a decade of investment. The tools are powerful, but they demand a new vocabulary. Users have to understand dimensions, measures, filters, joins, and the difference between a sum and an average. They have to know where the data lives and what it means. Many of them try once, get an unexpected number, lose confidence, and never come back.

The deeper issue is that a self-service dashboard still asks the user to do the analytical thinking. They have to figure out which view to open, which filters to apply, and how to interpret what they see. That is a real skill, and most people do not have it. They are experts in their domain, not in data modeling.

What they actually want is simpler than a dashboard. They want to ask a question in the same language they use in a meeting, and get an answer they can trust.

What Conversational Access Actually Requires

Natural language querying sounds like a solved problem. You type a question, the system generates SQL, and the answer appears. Several products do this today.

But the hard part was never the SQL generation. The hard part is everything around it.

The system has to know the shape of the business. A question like "how are sales doing" means something different in a subscription business than in a retail one. Without an understanding of the schema, the table relationships, and the business definitions that live in the application, the generated query will be technically valid and practically wrong.

The system has to respect permissions. If a regional manager asks for revenue, they should see their region, not the whole company. If a support agent asks for customer data, they should see only the customers they are allowed to see. Conversational access is worthless if it is also a security incident waiting to happen.

The system has to execute safely. Running generated queries against a production database is risky. That is why read-only execution matters, along with validation that the query does not do something destructive or expensive.

The system has to explain itself. An answer without context is just a number. Users need to know what period it covers, what it includes, and what it does not. That turns a query result into something a person can actually rely on for a decision.

This is the approach the BlunxAI backend takes. The SDK scans the application's own database schema, enforces read-only SQL execution through a dedicated role, and applies role-based access rules before any result reaches the user. The answer comes back as a chart, a table, and a plain-language summary, all inside the application the user already works in. The question is asked in natural language, but the guardrails are built into the architecture.

The Shift That Matters

The real change is not that users can type a question instead of clicking a filter. The real change is that the analyst stops being a required middle step for every simple question.

When routine questions are answered directly inside the application, three things happen at once. Business users get their answers in seconds instead of days. Analysts get their time back for the work that actually requires their expertise. And the organization starts to build a habit of consulting data before deciding, because the friction that used to make that impractical is gone.

The 79% problem is not a technology gap. It is an access gap. The data exists. The question exists. What has been missing is a path between the two that does not go through someone else's inbox.

Closing that gap does not require replacing the analyst. It requires giving the analyst something better to do.

Curious how conversational access works inside a real application, with permissions and guardrails built in? Explore the BlunxAI SDKs →