What Is Ad Hoc Reporting? Meaning and Examples

An ad hoc report is a report built on demand to answer one specific question that no existing report answers, like "How many customers did we have last month?" or "Why did signups drop on Tuesday?" It usually isn't run again. "Ad hoc" is Latin for "for this," or as Merriam-Webster puts it in English, "for this purpose only."

What is an ad hoc report?

Ad hoc reporting is building those one-off reports as the questions come up, instead of on a schedule. If you've seen a report described as "generated on an as-needed basis," that's an ad hoc report.

Three terms get mixed up here:

• The ad hoc request is what the business sends: "Can you pull last month's customers?"
• The ad hoc query is what answers it. TDWI's glossary calls it "a one-time, user-defined request for information from a database, often used to answer a specific business question."
• The ad hoc report is what goes back: a number, a table or a chart.

What are some examples of ad hoc reports?

Ad hoc reports start as a message to the data team. Here are five requests you'd find in almost any company's data channel, each with the part the person asking didn't say:

• Sales: "Can you pull how many customers we had last month?" Everyone who placed an order, or only the ones whose orders went through?
• Finance: "What did we spend on contractors in Q3, by team?" Booked or paid? And which team gets a contractor who switched teams in August?
• Marketing: "How many signups came from the webinar?" During the webinar, or in the week after? Counted on first touch or last?
• Operations: "Which warehouse had the most late shipments this month?" Late against the date we promised, or the carrier's estimate?
• Product: "Are people using the new export button?" Clicked it once, or came back and used it again?

Once those gaps are filled, each of these is a few minutes of SQL. Filling them is the slow part.

How is an ad hoc report different from a standard report or a dashboard?

Standard reports and dashboards answer questions someone planned for. An ad hoc report answers the one nobody planned for.

	Ad hoc report	Standard report	Dashboard
Answers	One new question	The same questions every period	The same metrics, all the time
When it's made	When someone asks	Once, then on a schedule	Once, then refreshed
Who builds it	An analyst, or a business user with a self-serve or AI tool	The data team	The data team
How long it lives	Usually until the answer is sent	As long as the schedule runs	As long as people look at it
Good for	A question that needs an answer now	Numbers you can compare period to period	A quick read on metrics you already track

Ad hoc reporting and ad hoc analysis overlap, but they're different jobs. The report says what happened. The analysis works out why. Sigma's guide describes the order well: "The report surfaces an unexpected number, and the analysis explains it."

Why does an ad hoc request take days?

Daniel Merighi, Querio's founding operator, described a week most analysts will recognize: three business teams, "80 unanswered questions piling up in Slack," and an analyst who already lets Claude or Gemini write the SQL. "You send them back the answer. It's been 4 days."

If AI writes the query, the query isn't what takes four days. The time goes to the back-and-forth over what the question meant, and to every request waiting in line behind that one.

The meaning changes the answer more than people expect. On dbt Labs' public jaffle shop sample data, "How many customers did we have last month?" comes out at 31 if sales means anyone who placed an order in March 2018, 17 if finance means customers with a completed order, and 18 if marketing means first-time buyers. None of those is a mistake. Our AI dashboards guide shows the same thing happening with revenue.

Then the answer goes back as a bare number in a Slack thread. Next month someone asks again, a different person rebuilds the report, picks a different rule and gets a different number. Now two numbers are going around for one question, and the next meeting starts with working out which one is right.

What should you ask before answering an ad hoc request?

Four things decide the number. Settle them before you write the query, ideally in your first reply to the request.

1. What counts. Which customers: anyone who ordered, anyone whose order was completed, everyone in the customer table? On the sample data, that alone moves the answer anywhere from 17 to 100.
2. The time window. Calendar month or the last 30 days? Which time zone? If an order is placed on the 31st and paid on the 1st, which month gets it?
3. What's filtered out. Returns, cancellations, refunds, test accounts, your own team's accounts.
4. Which source. The warehouse, the billing system or the CRM? Two systems that should agree often don't, so name the one you used.

Then send the answer with its rule attached. For the customer request:

31 customers placed an order in March 2018, counting every order status. If you only count completed orders, it's 17.

That one extra sentence helps three ways. The person asking can see whether the rule matches what they meant, before the number lands in a deck. Whoever gets the question next month can reuse the rule instead of guessing. And when two numbers turn up in the same meeting, the rule shows why.

What should happen to an ad hoc report after you send it?

On most teams, nothing. The number sits in a Slack thread and the query sits in someone's SQL editor. Sigma names the cost: "A one-off analysis that lives in a local spreadsheet can't be audited, versioned, or re-run by someone else."

Keep three things in one place the next person can find: the question as it was asked, the rule you chose, and the query that ran. Then a repeat request is a re-run, not a rebuild.

Our rule of thumb: when the same request comes back a second or third time, it's stopped being ad hoc. Write the rule down as a named definition with an owner, like "active customer: placed an order in the period that wasn't returned," and put the number on a dashboard. Sigma has seen the same path: "Many of the best recurring dashboards started as one-off ad hoc investigations that revealed a metric worth tracking consistently."

The data team should own those definitions, and keep owning them. Nikolay Alexandrov, a founding engineer at Querio, lists what it takes: "owned definitions, baked-in grain and joins, canonical segment filters, a compile-to-SQL step, and tests against the blessed dashboard - then a human to re-bless all of it every time the business redefines a word."

Not every question should become a definition. Benn Stancil argues that ad hoc decisions "are, almost by definition, the most important decisions companies make." Those deserve an analyst's full attention, and they only get it once nobody is rebuilding the routine ones.

That's the workflow we built Querio around. Metric definitions, business context, notebooks and dashboards live in a git repo your team owns, and changes get reviewed like code. People ask in Querio, Slack or Claude, any agent can connect over MCP, and all of them answer from the same definitions. In Querio itself, every AI answer is real SQL or Python you can open, check and re-run.

Can AI answer ad hoc requests?

For the routine ones, yes. The catch is the rule. An AI that has to guess the rule guesses the way a new analyst would, and its answer looks just as sure whichever rule it picked. Give it written definitions to answer from and it can clear the "how many customers last month" requests by itself. That leaves your analysts the questions nobody has written a rule for yet. Our dbt Semantic Layer guide covers one way teams write those definitions down.