Your data team spends 80% of their time answering ad-hoc questions. 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 whether the answers were right.
• 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 15 minutes. The context layer handles the rest.