Analytics Request Triage: Intake Rules That Keep Data Teams Focused

Twelve years running analytics teams, mostly as the queue between engineering and everyone else.

Vague requests are not lazy. Someone asks for "the numbers on churn" because they have a decision they cannot articulate yet, and the request is their attempt to think out loud. Answering it literally produces a correct chart that changes nothing.

Nobody wants data. They want to stop being uncertain about something, and they rarely say what.

So the rule is one line on the intake form: what will you do differently depending on the answer? If it cannot be answered, the request is not ready, and a fifteen-minute conversation saves a week.

It also handles prioritisation. Requests tied to a decision with a date sort themselves.

The cost is that it feels obstructive at first, and it must be applied to executives too. Exempt one person and it becomes a rule for people without power.

The rework I used to see most came from requests that sounded specific but weren't—someone asking for conversion rate by channel without saying which conversion event or which attribution window they meant. So the boundary I put in place isn't about priority order; it's a requirement that the requester define the exact metric in writing before any work starts, including what counts and what doesn't.

If someone can't write that definition themselves, we write it together in a five-minute call, and that call surfaces the vague-goal problem immediately, because half the time two people asking for the same metric actually want different things once you press for specifics.

On tight timelines specifically, I separate the deadline from the definition. The definition gets locked first no matter how much time pressure exists, because a fast wrong answer costs more time than a slower correct one once someone has already made a decision based on it and has to walk it back. The requests that skip this step are the ones that come back three days later asking why the number does not match what they expected.

When an analytics request comes in with a vague goal and a tight deadline, I try not to respond by immediately pulling data. That can feel productive, but it often creates more work later when everyone realizes they were answering a different question.

The first thing I want to understand is the decision the analysis is supposed to support. I'll ask, "What decision will you make differently if you have this information?" That question has saved me from spending hours producing a technically correct report that nobody actually needed.

I've seen this happen in different businesses where someone asks for a dashboard, customer breakdown, or performance report because they believe more data will solve the problem. Once we dig into the request, the real need is often much narrower: deciding whether to change a campaign, investigate a drop in sales, allocate resources, or determine what needs attention today.

My most consistent intake rule is simple: every analytics request needs a clearly defined question and a specific decision or action attached to it. If those aren't clear, I'll clarify the request before committing to the analysis.

That doesn't mean I block urgent work. If something genuinely needs an answer quickly, I'll define a minimum viable analysis: the smallest amount of reliable information needed to make the immediate decision. We can always expand the analysis later if the decision warrants it.

I also try to establish what "done" means before the work begins. Is the requester looking for a number, a trend, an explanation, a recommendation, or a recurring dashboard? Those are very different deliverables.

The reason this boundary works is that it puts the focus on the business problem rather than the analytics team's capacity to produce charts. It also gives the requester an opportunity to catch misunderstandings before work starts.

I've found that a few minutes spent clarifying the question can save hours of rework. In a fast-moving business, analytics shouldn't become a bottleneck itself. The goal is to provide enough trustworthy information to improve a decision, then move on.

No report gets built until the requester writes down the decision it will change.

That is the whole rule, and it does more work than any prioritisation framework we tried. Someone asks for a breakdown by channel and month and region. We ask what they will do differently depending on what it says. If there is an answer, we build it. If the honest answer is that they want to see it, we put it in the queue behind the requests that have a decision attached, and most of the time it quietly stops mattering.

It was not popular at first. It sounds like gatekeeping. What made it acceptable was making it a template rather than a conversation: the request form has a required field for the decision, and the person filling it in is the one who realises there is not one. Nobody has to be told no by a human.

The rework it prevents is specific. Vague requests come back three times, because each version reveals what the person actually wanted, and each version is built on a different cut of the data. When the decision is stated up front, the cut is obvious and the first version is usually the last.

The second boundary, which is about timelines rather than goals: we separate the number from the analysis. A tight deadline can almost always be met with the number. The interpretation of the number takes longer and does not have the same deadline. Splitting those two into separate deliverables stopped us from shipping rushed conclusions attached to correct figures, which is the more dangerous failure.

The exception we make: anything for a regulator or a client contract skips the queue, no justification needed.

The one thing everyone on my team has learned is to force every business analysis request to state first one outcome that can be measured in numbers and a quick estimate of what that outcome will return in money or time. We then help the business rank these by the speed of the value they'll create versus the effort required, and that keeps everyone moving. We also won't start any work on a project unless the person making the request names the exact decision that this data will drive and the date by which he or she needs that decision. That boundary kills vague goals and stops rework cold.

I've learned not to let the loudest request set the agenda. I ask three things right away: What decision will this answer change, who owns that decision, and what is the real deadline? If those answers aren't clear, I send it back for more detail or put it on hold. I focus first on work tied to revenue, a customer promise, compliance, or a near-term business decision. The rule that has saved my teams the most time is simple: no analytics request starts until the requester can explain the decision they'll make with the answer. That one boundary cuts out a lot of "nice to know" work, gives people clarity, and keeps the team focused on work that actually matters.

The rule is one sentence on every request: what decision will this number change, and when is that decision being made? If the requester cannot name a decision, the request is curiosity, and curiosity goes into the monthly report rather than jumping the queue. If they can, the decision usually tells me which number they actually need, which is rarely the one they asked for.

I work in-house at a real estate brokerage in Marrakech, with a head of sales and a small team of agents, and analytics requests arrive as messages like “can you tell me where our website visitors come from, by Friday”. That request as written is a day of work in the analytics tool with country breakdowns, device splits and a slide deck nobody reads. When I asked what decision it would change, the answer was whether to translate the site into French first or into Arabic first, because the site was English only and the budget covered one language.

That is a different question, and a much shorter one. The decision did not depend on visitors at all; it depended on buyers, so I pulled the enquiries from the last months and split them by the language the buyer wrote in and the country they wrote from. That took an hour, and French won without any need for a chart. The head of sales got an answer the same afternoon instead of a deck on Friday.

What the rule prevents is redoing work. Nearly every time I have skipped it, the first version answered the literal request, the requester came back with “yes, what I really need is”, and the second version was the one that mattered. Asking for the decision up front moves that second conversation to the beginning.

When analytics requests arrive with vague goals and tight timelines, I anchor decisions to our roadmap and timeline and ask whether the work supports a long-term outcome. I prioritize requests that resolve recurring patterns across customer groups instead of chasing one-off problems. Before committing, I assess the value the change delivers relative to its resource cost to avoid diverting effort. My one intake rule is to defer single-use requests that do not align with the roadmap or broader customer impact, which prevents redoing work and preserves team velocity for high-impact tasks.

Our most reliable boundary is that every request includes the action that follows every possible result. We ask what the team will do if the answer is higher, lower, or unchanged. This simple habit quickly exposes unclear requests before work begins across the whole team. We either decline the request or reshape it into a focused exploratory discussion.

This rule helps us handle urgent data requests without creating unnecessary confusion or delays daily. We begin with the smallest evidence set needed to support the next business decision. We avoid collecting extra details that do not clearly change the final response. This approach keeps our conversations practical, aligned, and easier for everyone to understand and execute.

We're simply not going to put up with vague goals. The analytics work we provide is one of our core services, and we're skilled not just at crunching the data but at knowing what's worth measuring and what isn't. One of my jobs as CEO is to stand up for my team and make sure that they're being given reasonable, worthwhile tasks and achievable deadlines, and if a client isn't happy with that, I'm the one they talk to.

We use a one-sentence hypothesis as the entry ticket for every analytics request. We ask each requester to explain what they believe is happening and why it matters. We also include the action we will take if the data supports the idea. This simple habit improves the quality of every conversation before the work begins together.

We avoid becoming a report factory by testing assumptions before creating new analysis. We can reshape weak requests early and save valuable time for everyone involved. We also spot requests where the decision will stay the same without analysis. We finish with a clear record that keeps later discussions focused and honest throughout.

The intake rule is one sentence: name the decision the number will change this week, or the request waits.

Vague analytics asks with tight timelines used to redo work while 60-minute visits and 6 to 8 week follow-ups still needed coverage. If they cannot say whether the answer changes staffing or booking, we do not pull the report. Care ops keep moving. Curiosity without a decision does not.

I ask for the decision the analysis is meant to change before anyone opens a notebook. If the requester cannot name a choice, a threshold, or a release that would move on the back of the numbers, the request waits. Vague goals with tight timelines usually mean someone wants reassurance, not a build, and that work burns engineering time twice: once for the scramble, again when the question gets rewritten.

The intake rule that stuck for us is simple. Every analytics request needs a one-line decision statement and a definition of done. No decision statement, no ticket. It feels blunt the first few times, then the rework drops because we stop shipping charts that answer a different question from the one people thought they asked.

In a product team that runs expense workflows, that boundary keeps the roadmap honest. Analysis supports shipping and operations. It does not become a parallel product of its own.

We used to say yes to everything and re-scoped three times a week. Then a client asked for "better campaign visibility" with a Monday deadline on a Friday at 4 p.m., and our analyst spent 18 hours building a dashboard that was useless because "visibility" meant three different things to three people in their org.

The rule we built: no request gets intake without a single written sentence answering "what decision does this data need to inform." Not a deck, not a goal statement. One sentence. "We need to know which product category drives repeat purchases" or "We're deciding between email and SMS for reactivation." That's it.

Sounds small, but it kills 40% of incoming requests immediately because once you force that sentence, the requester realizes they don't actually know what they're asking for. The ones that pass through are the ones that move fast because everyone's measuring the same thing.

The second part: we time-box the intake call to 20 minutes. Not negotiable. If it can't be articulated in 20 minutes, the request goes to "backlog review," not "build this week." Sounds harsh, but it's actually humane because it stops people from over-investing in specs for work that shouldn't be prioritized anyway.

The work doesn't slow down. It just gets routed correctly earlier.

Our rule is that no analytics request gets picked up until the requester can state what decision the answer is going to inform. A vague ask like "can you pull performance numbers on this campaign" gets sent back with one question: what are you going to decide based on this—pause it, increase budget, report it upward? That single question usually clarifies the actual scope fast, because "just get me the numbers" and "tell me if this campaign is worth scaling" require completely different analysis, and without knowing which one it is, it's easy to build the wrong report entirely.

The boundary that's prevented the most redone work is refusing to start pulling data until that intent is explicit, even under a tight deadline. It feels counterintuitive when time is short, stopping to ask a clarifying question when someone wants something fast, but skipping that step is exactly what used to cause rework: we'd deliver a solid, accurate analysis that answered the wrong question because nobody had actually said what decision it needed to support. A day spent clarifying intent upfront has consistently saved more time than it cost, since redoing an entire analysis after delivering the wrong angle takes far longer than a two-minute clarifying conversation would have at the start.

For our company, TKEG Expat, which is a corporate-services firm, the one boundary I would name for any request about revenue or money received is a very simple definition we wrote down: revenue is the price we billed, in the currency we billed it, and the USD figure our system calculates is for analytics and does not mean money earned. We set it after a growth multiple built on that analytics field had to be recomputed on real prices (about 2.2x year-on-year once corrected).

When we re-ran a 100-row sample of completed items, the billed price and the analytics figure disagree on 93 rows, including 8 of the 15 billed in USD, where no currency conversion is involved at all. Moreover, 5 rows show a negative analytics value on work billed at a positive price.

One place where our data cannot carry the number is channel performance in our current budget; therefore, we wrote down that channel ROAS is not reliably computable and put lead-rate and a cost-per-lead ceiling in its place as the monitoring metrics, so the business still has numbers to act on. That rule came after an earlier channel-ROAS table overstated returns by more than an order of magnitude, a serious mistake, and was retracted.

Promo-week analytics only leave my desk when the ask names one wash-day question, a date range, and which jars among the 28 are in the promo. Anything vaguer waits.

That boundary stopped us rebuilding the same chart twice in one week when someone wanted numbers with no pattern or porosity attached. In The UK Curl Report 2026: Britain's Curl Patterns Mapped, 24% of UK women with textured hair still were not sure of their pattern. A report that ignores that gets opened once and ignored. The intake rule is the named question first, the pretty dashboard never.