Natural-Language Sales Analytics: What It Takes

Building natural-language analytics on sales data: why a semantic layer, a constrained query builder and honest fallbacks matter more than the model.

A manager wants to type a question about last month's sales and get a number they can take into a meeting. It sounds like a job for a language model. In practice, the model is the smallest part of the work.

Start with the dictionary

Ask three departments what sales means and you get three answers: invoiced, delivered, or collected. Before any model writes a query, each business term needs one agreed definition tied to specific tables and filters. This semantic layer is dull to build and it is the whole foundation.

• Measures: net sales, quantity, collection, return value, each with one formula.
• Dimensions: product, category, distributor, territory, sales officer, period.
• Synonyms: the words people really use, mapped to the official term.

Let the model choose, not invent

Free-form text-to-SQL is impressive in a demo and risky everywhere else. A generated query can join the wrong tables and still return a believable number. A safer pattern is to let the model map a question onto known measures, dimensions and filters, then have ordinary code build the query.

Question: "Top 5 distributors in Chattogram last month by net sales"

{
  "measure": "net_sales",
  "group_by": "distributor",
  "filters": { "territory": "Chattogram" },
  "period": "last_month",
  "order": "desc",
  "limit": 5
}

• The model picks from a catalogue: measure, grouping, period, filters.
• Code validates the choice and builds a read-only query.
• The answer shows which definition and period it used, so it can be checked.

Query the warehouse, not the live system

Analytical questions scan a lot of rows. Pointing them at the transactional database slows down the people entering orders. Run them against a reporting copy or a data warehouse with pre-aggregated tables. I explain when that step becomes necessary in when reports need a data warehouse.

Respect permissions

A territory manager should get answers about their territory only. Apply the same row-level rules the reports already use, in code, after the model has made its choice. Never rely on the prompt to enforce access.

Make I-don't-know a valid answer

A wrong number delivered confidently does more damage than no number. When a question does not match the catalogue, the system should say so and suggest the closest thing it can answer. Trust in the tool is built on the times it declines.

The interesting result is not that people stop asking analysts for reports. It is that they start asking better questions, because the first answer now takes seconds.