Hello ,
“Can you pull some numbers on our customer base?”
That’s an actual request you’ll get at work. No specifics. No timeframe. No context about what decisions will be made with the data.
Here’s the thing: this isn’t a bad question. It’s just an unfinished one. Your job isn’t to guess what they mean — it’s to ask the right questions to turn vagueness into clarity before you write a single line of SQL.
This is one of the most valuable skills an analyst can develop.
The 4-Step Translation Process
Step 1: Identify the Decision
Before anything else, ask: “What decision will this analysis inform?”
Vague request: “Pull some numbers on our customer base.”
Clarifying question: “What are you trying to decide? Are we looking at retention, acquisition, segmentation, or something else?”
The answer changes everything:
“We’re deciding where to focus our Q2 marketing budget” → Segmentation by value and activity
“We’re worried about churn” → Recency analysis and at-risk identification
“We’re presenting to the board” → High-level growth metrics and trends
Same “pull some numbers” request. Three completely different analyses.
Step 2: Define the Boundaries
Once you know the decision, define what “customers” and “numbers” mean:
Questions to ask:
Which customers? All-time, or active in a specific period?
What counts as “active”? A booking? A login? A payment?
What time period? Last 90 days? This year? All-time?
Which metrics? Count, revenue, frequency, something else?
Example:
Vague: “How are our customers doing?”
Translated: “How many customers have completed a booking in the last 6 months, segmented by experience level, with total revenue and average booking value?”
Now you can write SQL.
Step 3: Write the Query
With clear boundaries, the query practically writes itself.
Let me show you what this looks like with Summit Adventures (the fake adventure tourism company I created to help people learn business analytics):
The translated question: “Show me active customer segments for Q2 marketing planning — who’s booking, how much they’re spending, and where the gaps are.”
-- Customer activity summary for Q2 marketing planning
-- Decision: Where to allocate Q2 marketing budget
-- Definition: "Active" = completed booking in last 6 months
-- Metrics: Customer count, revenue, avg value, booking frequency
WITH customer_activity AS (
SELECT
c.customer_id,
c.experience_level,
c.city,
c.state,
c.country,
COUNT(DISTINCT b.booking_id) AS booking_count,
SUM(p.amount) AS total_spent,
MAX(b.booking_date)::date AS last_booking,
MIN(b.booking_date)::date AS first_booking
FROM customers c
INNER JOIN bookings b ON c.customer_id = b.customer_id
INNER JOIN payments p ON b.booking_id = p.booking_id
WHERE p.payment_status = 'completed'
AND b.status IN ('completed', 'confirmed')
GROUP BY c.customer_id, c.experience_level, c.city, c.state, c.country
)
SELECT
experience_level,
COUNT(*) AS customers,
SUM(CASE WHEN last_booking >= CURRENT_DATE - INTERVAL '6 months'
THEN 1 ELSE 0 END) AS active_customers,
ROUND(
SUM(CASE WHEN last_booking >= CURRENT_DATE - INTERVAL '6 months'
THEN 1 ELSE 0 END) * 100.0 / COUNT(*), 1
) AS active_pct,
ROUND(AVG(total_spent), 2) AS avg_lifetime_spend,
ROUND(AVG(booking_count), 1) AS avg_bookings
FROM customer_activity
GROUP BY experience_level
ORDER BY active_customers DESC;
This gives marketing exactly what they need: which segments are active, which are dormant, and where the opportunity lies.
Step 4: Frame the Answer for the Decision
Don’t just hand over data. Connect it back to the original decision.
Instead of: “Here’s a table showing customer counts by experience level.”
Say: “For Q2 marketing planning: Our expert customers have the highest average spend but the lowest active rate — only about 30% booked in the last 6 months. That’s our biggest re-engagement opportunity. Beginners have the highest volume but lowest spend per customer. I’d recommend splitting the budget: retention campaign for dormant experts, and upsell campaign for active beginners.”
You’ve gone from “pulling numbers” to providing strategic direction. Same data, completely different value.
The Translation Cheat Sheet
Here are common vague requests and the clarifying questions that unlock them:
| Vague Request | Ask This | You’ll Get |
|—————|———-|————|
| “How are customers doing?” | “What decision does this inform?” | Focus area |
| “Pull some revenue data” | “Which time period? Compared to what?” | Clear boundaries |
| “Show me the trends” | “Trends in what? Over what timeframe?” | Specific metrics |
| “Are we doing well?” | “Compared to when? By what measure?” | Benchmark context |
| “I need a report on bookings” | “What about bookings? Volume, value, or patterns?” | Metric selection |
Why This Skill Matters
Writing SQL is a technical skill. Translating business questions into analytical approaches is a strategic skill.
Most analysts wait for someone to hand them a perfectly defined question with exact specifications. That rarely happens. The analysts who advance are the ones who can take “pull some numbers” and turn it into a focused, decision-driving analysis.
This isn’t about being difficult or asking too many questions. It’s about making sure your work actually matters. A perfectly executed analysis that answers the wrong question is wasted effort.
A Simple Framework You Can Use Today
Next time you get a vague request, mentally run through this checklist before opening your SQL editor:
1. What decision? → Determines what analysis to do
2. What boundaries? → Determines your WHERE clause
3. What metrics? → Determines your SELECT clause
4. What comparison? → Determines your benchmarks and context
If you can answer all four, you’re ready to write the query. If you can’t, ask the requestor. They’ll appreciate the clarification — and the results will be far more useful.
The Practical Takeaway
The best analysts spend more time understanding the question than writing the query. The query itself usually takes minutes. Understanding what to query — and why — is where the real value lives.
Until next time,
Brian ([say hi on twitter!](https://twitter.com/briangraves))
—
P.S. This question-first approach is the foundation of the Mister Rogers Blueprint in Module 1 of SQL for Business Impact — approaching any new data challenge with curiosity and structured inquiry. If you want a complete framework for tackling unfamiliar business questions, check it out at [sqlforbusinessimpact.com](https://sqlforbusinessimpact.com).
P.P.S. What’s the vaguest data request you’ve ever received? Reply and share — I bet we’ve all been there. I read every response and might feature the best ones (with your permission) in a future newsletter.
Want More SQL Insights Like This?
Join thousands of analysts getting weekly tips on turning data into business impact.