Asking for reports in plain language: getting data without SQL

Tuesday morning, 9:12. The leadership meeting starts in eighteen minutes and the marketing lead needs exactly one number: how much closed-won revenue last quarter came from each lead source. The number exists in the database. Getting to it, though, usually means one of two things — asking an analyst and waiting until afternoon, or exporting three separate reports and lining them up in a spreadsheet for forty minutes. She tries a third route instead: she types “closed-won amount by source this quarter” into a box, and a few seconds later a bar chart appears, one column per source. The times and figures here are illustrative. The real question is what happened in those few seconds, and how much of that answer she can defend in the meeting.

This article covers how plain-language reporting actually works, which questions it answers well, and the point at which you should hand the job over to a purpose-built report or a data warehouse. We start with the steps that turn a sentence into a query, then look at why the same question often has several correct answers. After that: the four parts of a good question, how to verify an answer before you act on it, how your data model caps what you can ask, and how repeat questions should become permanent views. We close with permission boundaries, team rollout and an FAQ.

What actually happens between your sentence and the chart?

Plain-language querying is not magic; it is a well-defined translation job. Your sentence is broken into parts: which quantity is being measured, over which set of records, using which date field, grouped by which attribute. Once those four parts are resolved, the system builds a structured query on your behalf and renders the result. In Rocketly, the Ask in Plain Language field does exactly this: it reads “closed-won amount by source this quarter” as a metric, a period and a breakdown, generates the query, and returns a chart.

The distinction from search matters. A search box returns matching records; a plain-language query aggregates records and produces a computed figure. Type a company name and you get a record. Type “deals closed this month by rep” and there is no single record — there is a calculated table behind it. That is reporting, and a query runs underneath. We covered the mechanics of asking your CRM data questions in natural language separately; here the focus is where that mechanism strains under real reporting demands.

The fragile part of the translation layer is ambiguity. Does “last month” mean the calendar month or the trailing thirty days? Does “sales” mean invoiced revenue or closed-won pipeline? If your sentence does not settle those, the system settles them with a default and answers that. The answer is technically correct and not the question you asked. Learning to query in plain language is, in practice, learning to be precise about your own definitions.

Why does “what did we sell last month?” have more than one right answer?

Ask three people on the same team and you get three numbers. The sales manager reports total closed-won value. Finance reports invoiced revenue. The controller counts only cash collected. All three are honest; they measure different events. The day a deal is marked won, the day the invoice is issued, and the day the money lands rarely fall in the same month.

The choice of date field splits the answer just as sharply. Count deals by creation date and you are measuring what marketing produced that month; count them by close date and you are measuring what sales harvested. The two curves will not match, and they should not. Without deciding which KPIs your sales report is built around, plain-language querying speeds up the answer without ending the argument.

The practical fix is to write down three or four core metrics: closed-won value, conversion rate, average deal size and sales cycle length. For each one, agree once on the record set and the date field behind it. From then on, every plain-language question lands on the same definition, and two screens stop showing two numbers. Without shared definitions, speed only helps you disagree faster.

What are the four parts of a well-formed question?

Questions that get accurate answers almost always carry four components explicitly. First, the metric: amount, count, rate or average. “Sales” is not a metric; “closed-won deal value” is. Second, the period: this quarter, the last thirty days, January. Leave it out and the system applies a default, usually wider than what you had in mind.

Third, the breakdown — what the result is grouped by: by source, by rep, by product, by stage. Without one you get a single number, which is occasionally what you want and usually not enough to act on. Fourth, the filter: enterprise segment only, one region only, one campaign only. Filters narrow the result and make comparisons meaningful.

Packing all four into one sentence is a habit, not a skill. “Closed-won deal value by source this quarter, enterprise segment only” carries all four and gets answered correctly on the first attempt. Ask the same thing as “how is enterprise doing” and the odds that the returned answer matches your intent drop sharply. The quality of the question sets the ceiling on the quality of the answer.

Which questions work in plain language, and which do not?

The interface has a real scope, and knowing that scope saves time. The general rule: sums, counts and single-dimension grouping work well; multi-step derivations, cohort maths and causal questions do not. The table below helps you place a question before you type it.

Question type	Example	Expected result
One metric, one period	“Closed-won value this month”	Answered directly, returns a single figure
Metric plus one breakdown	“Closed-won value by source this quarter”	Answered directly, returns a chart
Two-dimension cross-tab	“Conversion by rep and by source”	Partial; turn the second dimension into a filter
Cohort or duration maths	“Average days from first touch to first order”	A library report or the custom builder is more reliable
Causal question	“Why did sales drop?”	Returns the figure; you read the cause from the records
Data held outside the CRM	“Return by ad spend”	Empty if spend data never enters the system

The last two rows deserve attention. A plain-language layer cannot invent data it does not hold; it aggregates the records in your system. If ad cost, cost of goods or shipping data never flows into the CRM, no phrasing will produce that answer. That is not a shortcoming — it is the boundary sitting where it belongs.

How do you verify the answer before you use it?

The main risk of a fast answer is that it reaches a slide unchecked. Every plain-language figure deserves three checks: definition, freshness and records. The definition check means reading how the number was computed. The Methodology Panel states this next to each metric: which source, which filters, which date field. When someone in the meeting asks what the revenue figure includes, the answer comes off the screen rather than from memory.

Freshness is the second check. The Data Freshness Indicator shows when each card was last updated; the live dashboard refreshes itself on a regular interval while the tab is open, and the refresh button bypasses the cache to pull the data again. Treating a cached figure as current does as much damage as a wrong one. The third check is the records themselves: Drill-down lets you click a slice of the chart and open the paginated list of rows behind it. Twenty seconds there usually tells you whether the number is plausible.

Then there is presentation. A correctly computed figure can still look inflated on a truncated axis or a badly scaled bar. The principles that keep a chart from lying apply to generated output too; a chart that arrived quickly is not a chart that has been reviewed.

How does your data model cap what you can ask?

The ceiling on plain-language querying is set by data structure, not by language. “Average deal size by industry” has an answer if the industry field on company records is populated, and none if it is blank. Relationships matter just as much: if it is unclear which company a deal belongs to, or which contact belongs to that company, every grouped question comes back partial. A system with contacts, companies and deals properly related multiplies the number of questions you can answer.

The second limit is data quality. Recording the same source as “Google”, “google ads” and “Google Ads” splits every source-level chart into three and quietly corrupts the result. Failures like this raise no error; they simply produce a wrong table. Working toward clean and validated customer data — picklists instead of free text, validation at entry — lifts the accuracy of every question you ask.

The third limit is coverage. If part of your customer base still lives in a spreadsheet or an old list, every question answers only for the slice inside the system. Consolidating the customer database in one place is a precondition for reporting; a query engine running on scattered data mostly shows you the scattering, faster.

What should replace asking the same question every week?

Plain-language querying is excellent for exploration and wasteful as routine. If you are asking something a second time, it is no longer a question — it is a report. The right move is to make it permanent. Saved Report Views store the combination of filters, date range, grouping and column layout as a single named view you can share with the team. Instead of re-describing the same slice every Monday, you open the view.

The step beyond that is delivery. Scheduled Reports let you set a daily, weekly or monthly send time; the report lands in recipients' inboxes as PDF or Excel. That removes any need for the requester to log in and ends the “can you send me that number” traffic. For threshold monitoring there are Report Alert Rules: which metric, which threshold, which period and who gets notified, defined by you rather than by what the system considers unusual.

Some teams want the result inside their own working files. In that case, rather than exporting to PDF, Excel or CSV by hand each time, it is more sustainable to set up a regular sync between your CRM and your spreadsheets; every manually downloaded file starts going stale the moment it is saved.

When does plain language stop being the right tool?

Three signals appear. First, asking the same question three times and getting three different results — the definition no longer fits in a sentence. Second, exporting the answer and correcting it by hand on a regular basis. Third, questions containing several rules at once: “and also”, “excluding”, “only when”. In all three cases the Custom Report Builder is the better instrument: you choose sources, fields, filters, grouping and aggregation across leads, customers, deals, quotes, tasks and appointments, build the report once, and the definition lives in the structure instead of the sentence.

When the question spans systems outside the CRM, the boundary shifts entirely. Putting ad cost, product cost or web analytics on the same chart as sales data is a joining problem, not a reporting one. That is where moving CRM data into a warehouse and a BI tool earns its keep; you bring the data together at the right layer instead of straining the query interface.

If the need is to unify behaviour across several marketing channels into one customer profile, the conversation moves to a different class of tool altogether. This is exactly where the difference between a CDP and a CRM becomes visible: one runs the relationship and the sale, the other consolidates behavioural data. Expecting both from a single question box is not realistic.

Should everyone be able to ask for any number?

Opening a question box is not the same as opening the data to everyone. Permission-Scoped Results handle this: a report shows only the rows the person running it is allowed to see. A team-scoped user gets their team's data and nothing more, and the same boundary applies when they ask in plain language. The interface changes; the scope does not. That is what makes a natural-language layer safe in an organisation of any size.

Sharing is the second question. A Shared Report Link lets you publish a report without requiring a login, with a password, an expiry date and a view limit, and you can revoke it whenever you want. That flexibility comes with the duty of tracking where those links end up; a link with no expiry is access with no expiry.

Third is where the processing happens. A query engine touches your records somewhere, and in many regulated sectors the country that “somewhere” sits in is a contractual matter. Where your data physically lives stays on the table as a question every bit as basic as the query interface itself, and it comes up in procurement.

How do you make this a team habit?

The fastest route is to have everyone write down three questions about their own work in the first week. A rep asks about their own pipeline, marketing about channel performance, a manager about team totals. Once those three become saved views, the habit installs itself. Nobody reads a training document; people copy a working example.

The second step is a shared phrasebook: keep the sentences that worked, verbatim, somewhere the team can see. Once “closed-won value by source this quarter” returns the right answer, the same pattern works for product, rep and region. As the phrasebook grows, question quality rises and support requests fall. The prebuilt report library feeds the same habit — reading how a library report is defined teaches how to frame the equivalent question.

The third step is measurement. At month end, count how many questions became saved views and how many became scheduled reports; those two numbers tell you whether the way your team reaches data has genuinely changed. To try it against your own records, start a free Rocketly account and ask your first question on your own data.

FAQ

Do I need SQL or reporting knowledge to use this?

No. All you need is to state the metric, the period and the breakdown in one sentence — something like “closed-won value by source this quarter”. The system builds the query. What your team does need is an agreed definition of what the metric means.

How do I know an answer is wrong?

Read the methodology panel to see which record set and date field produced the figure, check the freshness indicator for how current it is, then click into the chart and inspect the underlying rows. Those three checks take a few minutes and catch most bad numbers.

What should I do when a question returns nothing?

Widen the period first, then drop the filter, then simplify the breakdown. If it is still empty, the data may simply not be held in the system — ad spend is the classic example.

How do I get the same report every week?

Ask once, save the result as a named view, then set up a scheduled report. It goes out as PDF or Excel to your recipient list on the day and time you choose, with nobody needing to log in.