Natural-language reporting: asking your database questions in Turkish

At nine in the morning the sales manager asks a question: which customer’s orders dropped last month? The question goes to IT, and an Excel file comes back in the afternoon. The manager opens the file and only reaches the real question with a second report request. Natural-language reporting means reaching the information in the database by asking questions in everyday spoken language, without using SQL or a report designer.

There is a critical distinction here: asking questions in Turkish does not mean the AI writes queries against the database at will. In Fero, the YazSis Enterprise AI assistant, the question is answered with defined, read-only business tools. This article explains what that approach looks like in daily use.

How does a question become a screen?

• Understanding: Fero works out the intent, the period and whom you mean in the question. Which date range is “this week”, which sales rep is “Can”, which ranking is “top five”?
• Tool selection: Data is reached only through defined business tools. The AI does not write SQL, and no ad hoc query is run.
• Calculation: Figures such as totals, percentages and differences are calculated by the back-end system; the model cannot state a number that is not in the tool result.
• Display: Together with a short reply, the suitable ones are chosen from 13 approved dashboard components. The AI does not generate screen code.

The reason for this choice is accuracy. A system that generates ad hoc SQL looks flexible but carries two risks: wrongly joined tables can silently produce wrong figures, and it becomes harder to check which query ran. With defined business tools, what each tool does and how it calculates is known in advance. In return, flexibility is reduced; this is a deliberate choice that puts the correctness of the number the manager will see ahead of the fluency of the answer.

A chain of questions: from today to the cause

The real value of natural-language reporting appears not in a single answer but in the way questions link to one another. A question does not stop at getting a reply; it also prepares the ground for the next question. The flow below follows the demo scenario prepared with the product’s sample data; it is not real company data, but it shows the logic:

1. “How are our sales today?” A daily sales summary arrives with a short reply: the day’s sales, progress toward target, number of orders and the difference from the same day last week.
2. “Show it by sales rep.” The screen is not reset; the same subject drills down into a sales rep breakdown.
3. “Which sales reps are below target?” The two reps below target come to the front.
4. “What is this rep’s problem?” The customer breakdown opens; in the sample data the drop is seen to come from two customers.
5. “Look at the last three months.” The trend over recent months is shown for the same person.

In classic reporting this chain often means more than one report and more than one request, each request waiting for the answer to the one before. Here each step carries the context of the previous answer; follow-up questions move forward by updating the screen or drilling into detail instead of building it from scratch.

How do you ask a good question?

• State the period. Expressions such as “this month”, “last six months” or “the same day last week” reduce ambiguity.
• Say whom or what you are asking about. Customer, sales rep, product or shipment; if the subject is clear, the answer is clear.
• Ask for a comparison. Saying “compared with last week” makes a single figure meaningful.
• Go step by step. Asking for the general picture first and then drilling into detail is more reliable than asking for everything in one sentence.

A small example: the question “How are sales?” leaves open which period and which measure you mean. The question “How are our sales this month compared with last month?” gives the period and the comparison together. The second is not longer, only more complete; and the system builds a direct answer instead of guessing.

Asking in natural language makes it unnecessary to know the language of the data; but it does not make it unnecessary to know what the data means.

Limits: what not to expect

Because no ad hoc queries are run, the questions Fero can answer are limited to the subjects covered by the defined business tools; the product’s sample questions are grouped under sales, customers and sales reps, budget, shipments, stock and executive summary. A question type outside these requires the scope to be determined in the project. On the data side too, the source that is ready today is MySQL; sources such as SQL Server, PostgreSQL, REST API, Logo, SAP, Odoo and Excel are handled within a project.

There is also a matter of expectation: even if the system calculates the figure correctly, it is still the manager who decides which question to ask and how to interpret the answer. In cases that require an official report or a reconciliation, it is good practice to confirm the assistant’s answer against your own records. Do not make a decision without understanding which period and which set of customers a figure belongs to; asking a follow-up question at a point you do not understand is a natural part of the process, and it clarifies the answer without rebuilding the screen.

To begin, list the few questions your managers ask most often and look at which table their answers sit in today. To try the chain of questions with your own company’s questions, you can request a live demo on the Enterprise AI page.