How to Translate a VP of Sales Question Into a Data Query

“Which customers are about to churn?” Sounds simple. Translating it into a query is anything but.

A VP of Sales walks into your Slack channel and asks a question that seems perfectly clear to them. They want to know which deals are at risk. Or which segments have the highest lifetime value. Or why Q3 pipeline looks soft. To them, these are straightforward business questions. To you, they are ambiguous specifications that could map to dozens of different queries depending on definitions, timeframes, and data sources you need to pin down before writing a single line of SQL.

This translation gap - between the language of business and the language of data - is one of the most expensive inefficiencies in data-driven organizations. It burns analyst hours on clarification loops, produces results that miss the mark, and erodes trust between business teams and analytics teams. This guide provides a practical system for translating business questions into data queries efficiently and accurately, with a specific focus on the kinds of questions sales leaders ask.

The Translation Problem

The VP of Sales asks: “Which customers are about to churn?” This question contains at least five hidden ambiguities that the VP does not realize they have left unspecified:

• What is a “customer”? An account? A subscription? A billing entity? A user? In many organizations, these are different things with different tables in the database.
• What does “about to” mean? Within the next 30 days? Before their renewal date? Before the end of the quarter?
• What does “churn” mean? Cancellation? Non-renewal? Downgrade to a free plan? Reduced usage below a threshold? Each definition produces a different list.
• What signals indicate risk? Declining usage? Support tickets? Missed QBRs? Payment failures? The VP likely has an intuition but has not made it explicit.
• What will they do with the answer? If the goal is to assign CSMs for intervention, they need the list sorted by save-ability. If the goal is to forecast revenue, they need it sorted by ARR.

These are not edge cases. Every business question that a sales leader asks contains this kind of ambiguity. The analyst who starts querying before resolving these ambiguities will produce technically correct results that answer the wrong question.

The translation problem is made worse by organizational dynamics. The VP does not want to spend 20 minutes defining their terms. They asked what they consider a simple question and expect a quick answer. The analyst does not want to seem unhelpful by pushing back with a list of clarifying questions. So the analyst guesses, spends a day building the query, delivers a result, and then starts the cycle again when the VP says “that is not quite what I meant.” For a broader framework on handling this dynamic, see our guide on handling vague stakeholder requests.

Common Sales Questions Decoded

Most questions from sales leaders fall into five categories. Knowing the category helps you anticipate the ambiguities and resolve them faster.

Health and Risk Questions

“Which accounts are at risk?” “Are our enterprise customers healthy?” “Who should we be worried about?”

These questions require you to define a health or risk score based on observable signals. The translation involves: defining which behavioral signals indicate health versus risk (login frequency, feature usage, support interactions, expansion activity), setting thresholds that separate healthy from at-risk, and choosing the time window over which to evaluate. A customer who has not logged in for 14 days is a very different signal in a daily-use product versus a monthly-reporting product.

Performance Questions

“How did we do this quarter?” “Which reps are performing?” “Are we hitting our targets?”

These questions require clarifying: performance on which metric (bookings, pipeline, win rate, deal velocity), at which level of granularity (company, team, individual rep, deal), and compared to what baseline (target, previous quarter, same quarter last year). The same question - “how did we do?” - produces radically different analyses depending on these choices.

Forecasting Questions

“Will we hit our number?” “What does pipeline coverage look like?” “How much revenue are we at risk of losing?”

Forecasting questions are uniquely tricky because they require you to combine historical data with forward-looking assumptions. The translation involves: defining the forecast period, choosing the forecasting methodology (weighted pipeline, historical conversion rates, regression model), and making explicit the assumptions embedded in each approach. A pipeline-weighted forecast assumes that deal stages have stable conversion rates, which may not be true if the market or product has changed.

Segmentation Questions

“Who are our best customers?” sounds like a simple question, but “best” could mean highest revenue, highest growth, highest engagement, best retention, or most likely to refer. Each definition produces a different list with different strategic implications.

Segmentation questions require you to define the dimension (what makes one segment different from another), the metric (what you are measuring for each segment), and the purpose (what decision will the segmentation inform). If the VP wants to know best customers to inform a case study campaign, the answer is different than if they want to know best customers to inform pricing strategy.

Attribution Questions

“What is working?” “Why did churn spike?” “What drove the increase in enterprise deals?”

Attribution questions are the hardest to translate because they ask about causation, which data alone rarely proves. The translation involves: defining the outcome precisely, defining the candidate causes, and choosing an analytical approach that provides useful signal (correlation analysis, cohort comparison, time-series analysis) while being honest about the limitations of causal inference from observational data.

Mapping Questions to Metrics

Once you have identified the question category and resolved the key ambiguities, the next step is mapping the business question to specific, queryable metrics. A five-element translation checklist makes this systematic.

1. Define the Entity

What is the unit of analysis? Accounts, users, deals, subscriptions, or something else? This determines which table or data source is the starting point for your query. It also determines the grain of the result set - one row per account, one row per user, or one row per deal.

2. Define the Metric

What are you measuring about each entity? Revenue, usage, conversion, health score, or something else? Be precise about the calculation. “Revenue” could mean contracted ARR, recognized revenue, MRR, or total lifetime payments - and each comes from a different field in most data warehouses.

3. Define the Timeframe

What time period does the question cover? This quarter, trailing 90 days, since the customer started, or year-over-year? The timeframe affects both the query logic and the interpretation of results. Trailing-period metrics smooth out seasonality. Fixed-period metrics align with business reporting cycles. Lifetime metrics capture the full history but can obscure recent trends.

4. Define the Comparison

Is the question asking for an absolute value or a comparison? Most useful analyses are comparative: this period versus last period, this segment versus that segment, actual versus target. If the VP asks “how is retention?” the answer “82%” is less useful than “82%, which is 3 points below target and 5 points below same quarter last year.” Tools that support built-in period-over-period comparison make this trivially easy to include.

5. Define the Threshold

If the question involves a judgment (“at risk,” “best,” “underperforming”), what numeric threshold defines that judgment? This is often the step where the VP’s intuition gets made explicit. “At risk” might mean usage declined more than 30% month-over-month, or health score dropped below 60, or the account has not logged in within 21 days. Getting this threshold agreed upon before running the query prevents the “that does not look right” response when the results arrive.

The five-element checklist transforms a vague business question into a precise analytical specification. It takes five minutes to work through and saves hours of rework. For additional frameworks on connecting analysis to decisions, see our guide on turning data into business decisions.

Building Repeatable Query Templates

The same categories of questions come up repeatedly. Building reusable templates for the most common question types transforms a multi-day project into a same-day turnaround.

Template Structure

A good query template has four components. First, the business question it answers, stated in plain language. Second, the parameters that the analyst needs to fill in for each instance (time period, segment, threshold). Third, the query or analytical approach, with parameters clearly marked. Fourth, the interpretation guide - how to read the results and what caveats apply.

Example: The Churn Risk Template

Business question: “Which accounts are at risk of churning within the next X days?” Parameters: risk window (default 60 days), usage decline threshold (default 30%), minimum ARR (default $0 - include all). The query identifies accounts where trailing 30-day usage has declined by more than the threshold compared to the previous 30 days, filtered by accounts with renewal dates within the risk window. The output includes account name, ARR, usage decline percentage, last login date, and assigned CSM - sorted by ARR descending so the most valuable at-risk accounts surface first.

Example: The Segment Performance Template

Business question: “How does metric X compare across segments?” Parameters: metric (e.g., net revenue retention), segmentation dimension (e.g., company size), time period (e.g., trailing 12 months). The query calculates the specified metric for each value of the segmentation dimension, alongside the count of entities in each segment and the period-over-period change. This single template answers dozens of variations: NRR by company size, win rate by industry, deal velocity by source.

Building the Template Library

Start by cataloging every analytics request your team received in the last quarter. Group them by the five question categories (health, performance, forecasting, segmentation, attribution). For each category, identify the two or three most common specific questions. Build templates for those first. A library of 10 well-built templates will cover 60 to 70 percent of incoming requests.

Document the templates in a shared location that both analysts and stakeholders can access. When stakeholders can see the template library, they start framing their questions to match available templates, which dramatically speeds up the translation process. Pair this library with analytics tools that support flexible metric exploration and you give stakeholders the ability to answer simpler questions themselves, freeing analyst time for the complex translations that genuinely require expertise.

How Do You Create a Data Dictionary for Your Organization?

Start with your five to ten most important metrics. For each one, document four things: the exact definition (what counts and what does not), the calculation formula, the primary data source, and any known caveats or limitations. Store this in a shared, searchable location - a wiki page, a Notion database, or even a well-organized spreadsheet. Review it quarterly to catch drift as tracking evolves. The most common failure is writing the dictionary once and never updating it. Assign an owner for each metric who is responsible for keeping the definition current. A living data dictionary eliminates the “whose number is right?” debates that waste hours in every cross-functional meeting. See our metrics vs. analytics guide for more on building a metrics-informed practice.

Key Takeaways

Translating business questions into data queries is a skill that gets faster with practice and structure.

The best analytics teams do not just answer questions. They build systems that make questions easier to ask, faster to answer, and more likely to drive the right decision.