Business Questions Are Not Technical Queries: The Translation Problem Holding Analytics Back

The translation problem in analytics is the lossy conversion between what a business person asks and what a data system can execute. Salesforce's State of Data & Analytics report (2nd edition), surveying more than 7,600 business and data leaders, puts numbers on it: 63% of data and analytics leaders say translating business questions into technical queries is prone to error, 91% say technical queries limit analytics use at scale, and 93% of business leaders say they would perform better if they could ask data questions in natural language.

The instinctive fix is natural language interfaces: let people ask in plain English and have AI write the SQL. This article argues the survey data points somewhere deeper: the translation fails not because the syntax is hard, but because the business meaning of the question was never represented anywhere a query could reach.

What does the data say about the translation problem?

It says the technical barrier between questions and answers is now the binding constraint on analytics, and it is reshaping both behavior and buying.

Per the survey, only half of business leaders are fully confident they can use data to drive decisions, and just 47% are confident they can generate timely insights. Rather than wait in ticket queues, they route around the bottleneck: 54% do the analysis themselves, and AI has become the single most common way business leaders find, analyze, and interpret data, at 64%. On the technical side, 92% of data leaders cite lack of data fluency among staff as a limiting factor. The constraint has even reached procurement: 88% of data and analytics leaders say AI advances are changing how they evaluate analytics software, with real-time data and AI-assisted workflows topping their criteria.

Every one of these numbers describes the same wall from a different side: a business question exists, an answer exists in the data, and the path between them requires a translation that most of the organization cannot perform and the rest performs slowly.

Why doesn't natural-language-to-SQL solve it?

Because NL-to-SQL automates the syntax of the translation while leaving its semantics exactly as ambiguous as before.

Consider the question "how did the new pricing affect churn in our mid-market segment?" Converting that to SQL requires knowing which of several date fields marks the pricing change, how this company defines mid-market, which of three churn definitions finance actually reports, and whether a migration event last quarter should be excluded. None of that is in the question, and none of it is in the schema. It is business context, and the same survey quantifies what happens when it's missing: 93% of business leaders agree insights are only relevant when grounded in business context, and 49% of data leaders say their companies draw incorrect conclusions from data that misses or misunderstands it.

An NL-to-SQL layer without that context doesn't remove the error-prone translation the 63% complain about. It performs the same guess faster, with confident-looking output, and without the analyst who might have known which churn definition to use.

What has to exist for a business question to be directly answerable?

A queryable representation of the business itself: its definitions, its processes, and the rules that connect them to the data.

Three layers of meaning sit between a business question and a correct query, and each must be structured, not assumed.

Definitions. What the organization means by its own terms: mid-market, active customer, churn, on-time. These are business decisions, and they must be encoded once and referenced everywhere, not re-derived per query.

Process context. Which workflow the question lives inside: what stage the data reflects, which events change its meaning, which exceptions apply. A flagged transaction inside a remediation process is a different fact from the same transaction outside one.

Applicability rules. The conditions and boundaries that determine which data legitimately answers this question: time windows, exclusions, thresholds, and known distortions.

When these exist as structure, a business question can be resolved against them deterministically. The natural language interface becomes the easy part, because the meaning it needs is finally somewhere a system can look it up. This is the difference between teaching a model to write SQL and making the business itself queryable.

Why do agents raise the stakes on this?

Because the survey shows organizations are betting on agents to close the access gap, and agents inherit the translation problem in full.

Business leaders hold strikingly high expectations for agentic analytics: 94% expect more relevant insights, 93% expect more timely and more accessible data, and 88% expect less analysis paralysis. And 94% say they would perform better with direct data access inside the apps where they already work. That is a mandate for agents as the new analytics interface.

But an agent answering business questions performs the business-to-technical translation autonomously, at volume, without a human checkpoint. If definitions, process context, and applicability rules aren't structured for it to query, each agent resolves them by inference, differently across runs and across agents. The survey already records where that leads: 89% of data leaders using AI have experienced inaccurate or misleading outputs. Scaling the interface without building the meaning layer scales the error rate with it.

Summary

The Salesforce data documents a translation bottleneck: nearly two-thirds of data leaders call business-to-technical translation error-prone, nine in ten say technical queries cap analytics at scale, and business users are already routing around the bottleneck through AI. The tempting fix, natural language on top of the same ungrounded data, automates the guesswork instead of eliminating it. The durable fix is making the business queryable: definitions, process context, and applicability rules structured so that questions resolve against what the organization actually means. Ask-in-plain-English is the interface. The queryable business is the infrastructure underneath it.

Frequently asked questions

Isn't this what text-to-SQL models already do? Text-to-SQL handles syntax. The failure mode the survey describes is semantic: the query runs but answers a subtly different question because definitions and context were guessed. Structure removes the guessing; better SQL generation only speeds it up.

Is a data catalog enough to fix this? Catalogs document what data exists and where. They generally don't encode business definitions as enforceable logic, process context, or applicability rules, which is what direct answerability requires.

Where do the statistics in this article come from? All figures are from Salesforce's State of Data & Analytics report, 2nd edition, a double-anonymous survey of more than 7,600 data, analytics, and line-of-business leaders across 17 countries and 18 industries.

What is the first practical step? Pick the ten business questions your teams ask most, and write down every definition, process condition, and exclusion needed to answer each correctly. That list is the specification for your first queryable business layer.

Homer Semantics makes the business itself queryable: definitions, process context, and rules structured so business questions, asked by people or by agents, resolve against what your organization actually means. Write to info@homersemantics.com to see it on your ten most-asked questions.

Visit https://www.homersemantics.com/ to understand how we can help.

This article uses Salesforce's State of Data & Analytics report (2nd edition) for reference.

Privacy Policy

This website may use essential and third-party cookies for embedded media, basic site functionality, and performance monitoring.