Turning a Vague Request Into an Analysis Brief

"Can you pull the sales numbers?"

You can. You will spend two days on it, present a dashboard with eleven charts, and watch the person who asked scan it, look mildly disappointed, and say "so should we shut down the Chattogram warehouse or not?"

That was the actual question. It was never stated, and you never asked.

The gap between the request someone makes and the decision they're trying to make is where most analyst effort is wasted. Closing it is a skill, it's learnable, and it matters more to your career than any query you'll write.

Why requests arrive vague

It's tempting to read a vague request as carelessness. It usually isn't. Three things are happening.

They're translating for you. They have a business problem and they're guessing at what data might address it. "Pull the sales numbers" is their attempt to speak your language, and it discards the context you actually need.

They don't know what's possible. If they don't know you can attribute revenue by cohort, they can't ask for it. They ask for what they've seen before.

The decision is uncomfortable. Someone weighing a warehouse closure may not want to say so out loud yet. The vague request is deliberate vagueness.

None of these are solved by working harder on the literal request. They're solved by a short conversation.

Four questions

You don't need a formal intake process. You need four questions, and they take about ten minutes.

1. What decision will this inform?

The single highest-value question in analytics. Phrase it as "what will you do differently depending on what I find?"

If the answer is specific — "we'll close it or keep it" — you now know the analysis needs to compare costs against revenue attributable to that site, not describe sales in general.

If the answer is "I just want to see how we're doing," you've learned something equally useful: this is monitoring, not analysis. Build something small and repeatable rather than a deep one-off.

2. What do you expect to see?

Ask for their prior. "Do you think Chattogram is underperforming, and by roughly how much?"

This does three things at once. It reveals the hypothesis you're really testing. It surfaces their mental model of the business, which is often where a wrong assumption lives. And it means that when your result contradicts them, you can address the disagreement directly — instead of watching them quietly disbelieve your chart.

3. What's the deadline, and what's it attached to?

Not "when do you need it" but "what happens on that date." A board meeting on Thursday means a defensible headline number beats a thorough model. A quarterly planning cycle three weeks out means the opposite. The deadline tells you how much precision to buy.

4. Who disagrees?

If the operations lead thinks the warehouse is fine and the finance lead thinks it's bleeding money, your analysis is walking into an existing argument. You need to know that before you present, because both will attack your methodology in different places, and you can meet those objections in advance.

Callout: Ask these before you open your query editor, not after. Once you've built something, sunk cost makes you defend the analysis you happened to produce rather than the one that was needed.

Write it down and send it back

Then take five minutes and write the brief. Not a document — a message.

Subject: Chattogram warehouse analysis - confirming scope
 
Decision: whether to close the Chattogram warehouse.
 
Question: does revenue attributable to Chattogram cover its
operating cost, and what share of that revenue would we expect
to keep if orders were served from Dhaka instead?
 
Deliverable: a one-page summary with a recommendation, plus the
underlying numbers as an appendix.
 
By: Thursday 4 Sep, for the ops review.
 
Assumptions I'm making - tell me if any are wrong:
- "attributable revenue" = orders shipped from Chattogram in
  the last 12 months
- customers within 50km could be served from Dhaka with 1 extra
  day of delivery time
- operating cost = the figures in the finance model, which I'll
  take as given rather than rebuild
 
Out of scope: staff redeployment costs, lease exit terms.
 
Open question: do you want scenarios for partial closure, or
just open/close?

This is the highest-leverage artefact in the whole process, for a reason that has nothing to do with documentation: it converts your assumptions into their assumptions. When someone reads "customers within 50km could be served from Dhaka" and doesn't object, that assumption now belongs to both of you. When they do object — and they will, on roughly one item in three — you've saved a day of work.

It also protects you. Two weeks later, when someone asks why lease costs weren't included, the answer is a link, not an argument.

Handling the answers you'll actually get

"I'll know it when I see it." They can't specify because they haven't thought concretely. Give them something to react to: sketch the summary on paper, with made-up numbers, and ask "if the answer looked like this, what would you do?" People are far better at critiquing a concrete thing than at specifying an abstract one.

"Everything, just give me all of it." This is usually fear of missing something. Narrow it by time instead of scope: "here's the single most useful cut by Thursday; then we'll decide what to add." Nobody argues with a first increment.

"Both." They want the deep analysis and the quick number. Fine — the quick number is a checkpoint, not a competing deliverable. Send it tomorrow, and you've bought goodwill and an early sanity check on your data.

"Just do what you did last time." Ask what they did with the last one. Often the honest answer is "nothing," and you've found a report to stop producing.

Then keep the loop short

A brief is not a contract to disappear behind. Two habits keep the work aligned:

Show a rough cut early. At maybe 30% done, send the shape of the answer with caveats attached. It feels premature and it's the best-spent message of the project — it catches misunderstandings while changing course is still cheap.

Report surprises immediately. If the data says something you didn't expect, or a column you needed turns out to be unreliable, say so the same day. Nobody minds a scope change. Everyone minds finding out about it in the final presentation.

Why this compounds

The technical work is the part that feels like the job, and it's the part that's most easily replaced — by a tool, a template, or someone cheaper. Understanding what someone actually needs, and reliably converting that into a decision they can act on, is the part that gets you invited to the conversation earlier.

Which is where the good problems are. The analyst who receives "pull the sales numbers" is downstream of the decision. The one who gets asked "how would we tell whether closing Chattogram is a good idea?" is in the room where it's made.

The four questions are how you move from the first position to the second, and they cost ten minutes.