Ad Hoc Reporting: What It Is & How To Reduce Requests In 2026

Ad hoc reporting answers one-off data questions that no existing dashboard or report covers, such as "what was churn for enterprise accounts in Q3, without the pilot customers?" Each one reaches the data team as an ad hoc data request, and those requests are cheap to ask and expensive to answer: in the worked example below, 30 requests a week take 30 analyst hours a week, about $128,000 a year in loaded salary, before counting the requesters' own time and the days they wait. The teams that cut them triage every request through a short intake form, batch what can wait into office hours, publish metric definitions, and send quick lookups to an AI analyst in Slack or Teams, while one-off strategic analysis stays with people.

What is ad hoc reporting?

Ad hoc reporting builds an answer to a question no dashboard, report or saved query answers yet: a new cut of a known metric, a number nobody can find or trust, a definition, or a one-off investigation. The question arrives as an ad hoc data request from a business user. "Ad hoc" is Latin for "for this": the answer is built for one question, once. Ad hoc analysis goes a step further and asks why something happened.

Why ad hoc requests pile up

Dashboards answer the questions someone predicted. Ad hoc requests are the long tail: every combination of metric, segment, period and filter that nobody built a chart for. Four forces keep the queue full:

• The answer exists, but nobody can find it. At Choco there were "lots of questions from global stakeholders on little things that were available in Looker but lost in the pile" (Marina Begovic, Analytics Manager, Choco case study).
• The answers disagree. "We had nearly 50 different dashboards and none of them matched up. It really hurt trust in our data," said Jeff Albenberg, Director of Software Engineering at Emerge (Emerge case study).
• The question needs SQL the asker does not have. At Duolingo, "anyone who wasn't a regular SQL user would have to consult our Data Scientists and Data Platform teams to construct more complicated analyses" (Lavanya Aprameya, Senior Software Engineer, Duolingo case study).
• Every answer creates follow-ups. In Sigma Computing's 2020 survey, about 53% of data experts said they get three to four follow-up questions after they deliver an ad hoc request (Sigma Computing).

Underneath sits demand you never see. Before Ramp built Ramp Research, its AI analyst in Slack, data questions queued in #help-data behind a single on-call analyst. In the four weeks before Ramp wrote it up, the Ramp Research beta channel answered 1,476 questions, against 66 in #help-data (Ramp engineering blog; our breakdown is in Ramp Research: the analyst agent in Slack). Those questions were always there. Asking a person just cost too much.

What ad hoc requests cost: a model you can check

The figure everyone quotes is a percentage. In Sigma Computing's "Data Language Barrier" survey, run by Atomik Research in 2020 with 801 data experts and 800 business employees at US companies, 76% of data experts said up to half of their time went to preparing ad hoc reports, and 55% said the average turnaround for a data request was one to four weeks (Sigma Computing, BigDATAwire coverage). It is a six-year-old vendor survey, so treat it as a direction, not a benchmark. The calculator above runs this arithmetic:

Analyst cost per year = requests per week
                      × analyst minutes per request ÷ 60
                      × 46 working weeks
                      × loaded cost per analyst hour

• Analyst minutes cover clarifying the question, finding the table, writing and checking the query, replying, answering follow-ups, and getting back into planned work. That last part is not zero. In Gloria Mark's field research at UC Irvine, interrupted work was resumed on average 23 minutes and 15 seconds later (Gallup interview). That is the time until people got back to the task, not time wasted.
• Loaded cost is salary plus benefits and employer costs, over 1,840 working hours (46 weeks, or 230 days).

A worked example

A company of about 300 people with a central data team of three analysts. The inputs marked "assumption" are mine:

Input	Value	Basis
Requests reaching the team	30 a week	Assumption: DMs, the help channel and tickets combined
Analyst time	60 minutes per request: 45 hands-on, follow-ups included, plus 15 of switching	Assumption; the 15 is below Mark's 23 minutes, because not every request interrupts deep work
Analyst salary	$120,230 a year	US median wage for data scientists, May 2025, the closest BLS occupation to a data analyst (BLS)
Loaded cost per analyst hour	About $93	$120,230 ÷ 0.70 = about $171,800 a year, because wages and salaries were 70.0% of private-industry employer compensation costs in June 2026 (BLS), divided by 1,840 hours

1. Analyst time: 30 requests × 60 minutes = 30 hours a week, 25% of a three-person team's 120 hours.
2. Per year: 30 hours × 46 weeks = 1,380 hours, or 0.75 of a full-time analyst (1,380 ÷ 1,840).
3. Analyst cost: 1,380 hours × $93 = about $128,000 a year.
4. Requester time, which the calculator leaves out: 30 × 15 minutes (assumption) × 46 weeks = 345 hours × $46.89, the average private-industry employer cost per hour worked in June 2026 (BLS) = about $16,000 a year. A floor: most requesters are managers.

What the model leaves out

• The wait. At a two-day turnaround (an assumption, and a kind one next to Sigma's one to four weeks), 30 requests are 60 request-days of waiting every week. Each one is a decision made late, made on instinct, or not made.
• Rework. Two analysts answer the same question with different filters, and someone has to reconcile them.
• The work that doesn't happen. At Emerge, engineering and analytics "invested excessive effort addressing ad-hoc requests rather than enhancing infrastructure".

To get your own inputs, log every request for two weeks with four fields: who asked, which lane it falls in (next section), minutes spent, and working days to answer.

Triage: sort requests into five lanes

A queue of ad hoc requests is not one problem, and each lane has a different fix:

"Three or more times" is a rule of thumb; the point is to promote repeat questions out of the queue on purpose.

Data request form template

A request form makes the asker think for a minute and gives the analyst what they need on the first pass instead of the third. Keep it short enough that people don't route around it through DMs. Paste it into a Google Form, Microsoft Form, Jira request type or a Slack workflow:

DATA REQUEST
1. Decision this will inform, and what you'd do differently depending on the answer (required):
2. Your question, in one sentence (required):
3. Metric, with a link to its definition or dashboard (required):
4. Time period, segment, filters, grain (required):
5. Compared with: last period / last year / target / other:
6. Dashboards or reports you already checked (required):
7. Needed by, and why that date (required):
8. Format: number in Slack / table or CSV / chart / slides
9. One-off or recurring? (required)
10. Personal, HR or restricted financial data involved? Y/N
11. Is a ballpark fine? Y/N

Put the form where requests already arrive, such as a pinned link in the help channel, and triage the queue once or twice a day instead of the moment each message lands.

Five ways data teams cut ad hoc requests

1. A triage rota and the intake form

One analyst takes the queue for the day or the week, and everyone else is protected from it. The rota does not shrink the hands-on minutes, but it moves most of the switching minutes onto one person who has planned for them.

2. Office hours

A fixed weekly hour where anyone can bring a question; the analyst answers live or turns it into a scoped request. Batching pays the switching cost once per session instead of once per request. In the worked example, if half the requests (15 a week) can wait for office hours and their switching overhead falls from 15 minutes to about 2, the team saves 15 × 13 = 195 minutes a week: about 150 hours, or about $14,000, a year. Metabase recommends a related habit: a trained power user in each department as a "data hero" who handles their team's own analyses (Metabase).

3. A metrics catalog or semantic layer

Definition questions ("how do we count an active user?") and "which number is right?" questions stop when there is one published definition per metric. For BI tools and AI analysts, the definitions have to be machine-readable: dbt MetricFlow, LookML in Looker, Power BI semantic models, Cube or Malloy. Emerge replaced roughly 50 contradictory dashboards with one source of truth (case study). Writing a semantic layer used to be the expensive part; I've argued it no longer has to be, in AI didn't make the semantic layer necessary. It made it cheap.

4. Fewer, better dashboards

Dashboards are the right answer for the recurring lane; retire the ones nobody opens. Recurring numbers that need commentary belong in a weekly business review or a scheduled report.

Dashboards do not fix the long tail, though: more of them is how Choco's answers got "lost in the pile". Self-service BI helps the people who will learn the tool. Metabase reports that one customer, Alto, saw a nearly 90% drop in ad hoc requests after rolling it out (Metabase case study), and our guide to setting up self-service analytics covers the groundwork. The people who won't learn the tool keep asking.

5. An AI analyst in Slack or Teams

An AI analyst answers the quick-pull and find-it lanes where the questions are already being asked. Whichever one you pick, hold it to the bar you would hold a junior analyst to:

• It shows the SQL and the tables behind every number.
• It asks a clarifying question when the request is ambiguous, instead of guessing.
• It uses your metric definitions, not its own.
• It applies the asker's permissions and row-level security, not one shared service account.
• The data team can correct it once and have the correction stick for everyone.
• You can measure its accuracy on questions whose answers you already know.

GetDot in Slack and Teams

GetDot is the AI analyst we build, so weigh this section accordingly. Against that bar, from our product pages and changelog:

• Where people ask: Slack, Microsoft Teams, email, the web app, and MCP clients such as Claude or Cursor. In Slack, Dot reads only the threads it is asked in.
• Ambiguity: Dot asks a short clarifying question. When an answer rests on a choice your workspace does not settle, it marks it "Assumption made" and says what it assumed (Chat).
• Your definitions: context from dbt, Looker, Tableau, Power BI, Sigma, Metabase, Malloy and Cube, plus docs in Notion, Confluence or Google Drive.
• Corrections that stick: "this metric is wrong" in a chat becomes a proposal the data team reviews and merges or rejects (Context Agent).
• Measured accuracy: Train tests Dot on questions with answers you trust, fixes its context in a separate environment, and reports accuracy before and after.
• A request log for free: every SQL query Dot runs carries a comment naming the user, the workspace, what triggered it and the chat (on BigQuery, job labels too): the two-week log, without the spreadsheet.
• Recurring asks become schedules that deliver only when the answer matters, for example "only deliver if revenue dropped more than 5%".

In our published case studies, Choco saved 3,300+ hours, Duolingo saves 12,000+ hours a year, and Emerge reports 2,000+ hours saved a year. Dot queries your warehouse in place with your access rules, and its LLM providers run with zero data retention. It is SOC 2 Type II and GDPR compliant; SSO and row-level security come with the Team plan. If you have a request log, replay it: start on the free plan, with 300 one-time credits and no credit card.

Alternatives, fairly

Dot is not the only way to put an analyst in chat. As of October 2026:

Option	Choose it when	Watch out for
Power BI Copilot	Your metrics live in Power BI semantic models and you already pay for Fabric capacity	Needs a paid F2 capacity or above and an admin to enable Copilot (Microsoft Learn; costs in our Fabric pricing guide). Power BI Copilot vs Dot
Databricks Genie	Your data and governance already live in Databricks	The Slack app was listed as Public Preview in June 2026 and the Teams app reached Public Preview in July 2026 (June and July release notes). Genie vs Dot
ThoughtSpot Spotter	You already run ThoughtSpot models	In Slack, only the person who started a conversation can ask follow-ups (ThoughtSpot docs). Spotter vs Dot
Hex Agent in Slack	Your analysts already work in Hex	Team plan and above, and each user connects their own Slack account (Hex docs). Hex vs Dot
Claude Tag (Anthropic)	You use Claude across the company and can build the skills and governed layer yourself	Queries the warehouse as a service account, not as the person asking; Anthropic advises limiting that account to governed data (Anthropic). Claude vs Dot
Build your own	You have engineers and analytics engineers to own it, as Ramp did	You maintain the agent, its context and its tests. See how 14 companies built AI data analysts
GetDot	You want a governed analyst in Slack and Teams on your existing warehouse and definitions, without building one	Billed on credits, so cost grows with question volume; answers are only as good as the definitions it can read

The worked example, with an AI analyst

This is the calculator's second result. Its inputs: 30 requests a week, 60 analyst minutes per request with switching, $93 an hour loaded, and the share GetDot answers without an analyst, 50% by default. Our claim is 80% of the requests that take an analyst under an hour; the default is lower because not every request is quick.

1. Hours freed: 30 × 50% × 60 ÷ 60 = 15 hours a week, minus about 2 hours a week of reviewing correction proposals and keeping definitions current (assumption) = 13 hours a week.
2. Per year: 13 hours × 46 weeks = 598 hours × $93 = about $56,000.
3. Credits: a chat answer costs 1 credit. 15 requests a week × 52 ÷ 12 × 4 messages each (the question plus three follow-ups, in line with Sigma's survey) = about 260 credits a month.
4. Plan: the cheaper of Pro and Team, billed annually, as of October 2026 (pricing). Pro is $180 a month with 150 credits, and extra credits are $1.80 each, so about $378 a month, or $4,536 a year.
5. Net: $56,000 − $4,536 = about $51,000 a year back.

When asking gets cheap, people ask more, as Ramp's numbers show, so credit use grows with adoption.

When not to automate

• One-off strategic analyses. A pricing change, a market entry, a board narrative. The value is in framing the question and defending the answer in the room, so use AI for the legwork, not the judgment. At KRY, Dot worked from the existing LookML model and the data lead's revenue framework, tested about 20 hypotheses and sized an €800K-a-year opportunity in about 10 minutes, work that took 2 to 4 hours per hypothesis by hand (KRY case study). The framework and the decision stayed with people.
• Metrics without an agreed definition. Settle the definition first. Otherwise any tool, human or AI, picks one.
• Sensitive data. Compensation, health or individual performance questions stay with people who have the access, unless row-level security and access rules are already in place.
• Causal questions with money on them. Experiment readouts and attribution calls that move budget deserve an analyst's review, even when an AI does the first pass (Root Cause Analysis).

How to tell if it's working

• Analyst hours on ad hoc work per week, from the request log. This is the number that matters, not the request count, which grows with a successful rollout.
• Turnaround by lane. Find-it and quick-pull requests should drop to hours; real analysis should hit its agreed date.
• Share of requests answered without an analyst.
• Corrections. How often the data team has to correct an answer, and whether that rate falls after corrections are merged.
• Questions per employee. This should go up. If it does not, the questions are still waiting somewhere you can't see.

FAQ