New teams get free Claude credits for their trial. Learn more

Your data team spends more time answering ad-hoc questions than doing analysis. It shouldn't.

July 3, 2026•5 min read•Vivek Sah

Hi, this is Vivek, building Contextflo. I share practical notes on getting answers from your data, a couple of times a month.

Your data team spends more time answering ad-hoc questions than doing analysis. It shouldn't.

If your data team spends more time answering ad-hoc questions than doing actual analysis, the problem isn't headcount. It's access.

I've talked to dozens of data leads over the past year. The story is almost always the same: they set up dashboards, wrote documentation, trained the team on Looker or Metabase, and people still Slack them with "can you pull this?"

The dashboards answer the questions nobody is asking. The actual questions are things like "what happened to conversions last Tuesday" or "how does this cohort compare to last quarter's" or "can you check if this campaign is working." These are one-off, slightly different every time, and impossible to pre-build dashboards for.

So the data team becomes a help desk. And the backlog grows.

Why dashboards don't fix this

Dashboards are great for recurring metrics. Weekly revenue, daily active users, monthly churn. You build them once, they update automatically, and leadership checks them every Monday.

But most data questions aren't dashboard questions. They're follow-ups. They're "why" questions. They're "just this one thing" requests that take 15 minutes to answer but 3 days to get to because there are 20 of them in the queue.

The data team isn't slow. They're overwhelmed.

The self-serve promise that doesn't work

Most teams try to solve this by giving people access to a BI tool and saying "you can self-serve now." It rarely works.

Business users open Looker, see 200 tables, don't know which one has revenue data, write a bad query, get a wrong number, lose trust in the tool, and go back to Slacking the data team.

The problem isn't the BI tool. The problem is that raw data access without context is useless for people who don't think in SQL.

What actually works

The approach that's actually reducing backlog is letting people ask questions in the tools they already use (Claude, ChatGPT) with a context layer in between that knows what the data means.

Here's what that looks like in practice. A marketing manager asks:

"What was the conversion rate for the summer campaign by channel?"

Instead of filing a ticket and waiting 3 days, they type this into Claude. The context layer knows which table has campaign data, what "conversion" means in this company's terms, and which channels are tracked. Claude writes the SQL, runs it against a read-only connection, and returns the answer in seconds.

The data team never heard about this question. The marketing manager got their answer. The backlog didn't grow.

What the data team needs to trust this

Data teams don't resist self-serve because they want to be gatekeepers. They resist it because they've seen what happens when people query data unsupervised: wrong numbers, wrong tables, wrong conclusions presented to leadership.

For the handoff to work, the data team needs:

  • Shared definitions. "Revenue" means the same thing for everyone, every time. Not whatever Claude guesses from the column name.
  • Access controls. Marketing sees marketing data. They don't accidentally query payroll.
  • Audit trail. The data team can see what questions were asked, what SQL ran, and can review the ones that look off.
  • Context that stays current. When the schema changes, the context updates. Nobody is manually editing a prompt doc.

Without these, self-serve is a liability. With them, the data team can hand it off and focus on the strategic work they were hired to do.

The real metric

The question isn't "how many dashboards do we have" or "how many people have Looker access." The question is: how many data questions get answered without the data team being involved?

If that number is going up, your data team is scaling. If it's flat, you have a tool. Not a solution.

How we built this

This is exactly the problem Contextflo solves. You connect your database (Postgres, Snowflake, BigQuery, whatever you use), generate a context layer that knows what your data means, set up access controls, and your team asks questions directly in Claude or ChatGPT.

One of our customers, Tilt, went from a multi-day ticket backlog to 4,000+ self-serve queries per month. Their data scientist went from answering ad-hoc questions to doing actual analysis.

The setup takes about 10 minutes. The context layer handles the rest.

Here is a more in-depth look at Contextflo and how it works.

What is Contextflo?

Contextflo is a governed context layer between your data and the AI your team already uses. Connect your warehouse once, and your team asks questions in their own Claude or ChatGPT. The model writes and runs the SQL; Contextflo supplies the definitions, the per-user access control, and the audit that make the answers trustworthy. Your data never moves, and you do not need a data team.

How it works

1
Connect your data
Point Contextflo at your warehouse or database, or upload a CSV. It reaches multiple sources at once, so a single question can span all of them.
2
Generate context automatically
Connect your code repo, Notion docs, or a data dictionary, and Contextflo annotates each table in your data source where it can. You review and correct them. That becomes the foundational context layer: your AI agent does not just see tables, it sees the context around them.
3
Define metrics and save golden queries
Pin the verified SQL behind a metric once. Every question then resolves against the same definitions, so the number is consistent no matter who asks or how they phrase it.
A short walkthrough on a BigQuery warehouse.

Your team queries in their own Claude or ChatGPT over MCP, so you bring any agent rather than a locked-in bot, and every answer comes back with the SQL shown and access enforced per user.