From Business Request to Evidence-Based Recommendation

Hello, and welcome. This course is designed to build the practical workflow expected of an entry-level data analyst: framing a business problem, working with data in Excel and SQL, building reports in Power BI, and communicating decisions clearly.

Before tools and formulas matter, an analyst needs a reliable way to turn a broad request into an evidence-based recommendation. This lesson introduces that workflow. By the end, you should be able to explain what an analyst does at each stage, why the stages matter, and how data becomes a proposed business action rather than just a spreadsheet or chart.

---

From a request to a decision

A stakeholder rarely begins with a perfectly formed analytical question. They may say:

“Sales are down. Can you look into it?”

That is a business request, not yet an analysis plan. It does not identify which sales measure matters, when the decline started, which customers or products are involved, or what decision the stakeholder is trying to make.

The analyst’s first responsibility is to clarify the decision behind the request. For example, the real need may be:

• Decide whether to change pricing, promotion, or sales outreach.
• Identify which product category needs attention.
• Determine whether a reported decline is real or a reporting issue.
• Decide where to allocate next month’s marketing budget.

The analyst is not simply a person who “finds numbers.” The role is to reduce uncertainty around a decision.

A useful end-to-end view is:

1. Understand the business problem and decision.
2. Define success and decide what evidence is needed.
3. Obtain, clean, and validate the data.
4. Explore the data and test plausible explanations.
5. Communicate what the evidence shows.
6. Recommend an action and define how its impact will be monitored.

Different organizations use slightly different names and orderings for these stages. The important point is the underlying responsibilities, not memorizing a rigid sequence. In real work, analysis is iterative: an early chart can reveal a data-quality issue, a stakeholder can clarify the goal midway through, and a finding can lead to a new question.

The Harvard framework is a useful concise model of this process.

---

1. Frame the problem before touching the data

A sound analysis starts with alignment. The analyst needs enough context to know what problem is important, who will use the answer, and what they can actually decide.

Suppose an online retailer says: “Repeat purchases have fallen. Find out why.”

An analyst should turn that into a brief problem statement such as:

Decision: Determine whether the company should change its customer follow-up strategy for recent buyers.
Objective: Improve repeat purchases without increasing support costs or discounting excessively.
Audience: CRM manager and marketing director.
Scope: Customers who made their first purchase during the last six months.
Decision deadline: Before next month’s campaign plan is finalized.

This framing prevents a common beginner mistake: beginning with whatever data happens to be available. A large dataset can encourage unfocused exploration, producing many charts but no answer that someone can use.

At this stage, an analyst clarifies five things:

Element	What it establishes
Business objective	What the organization wants to improve or understand
Decision owner	Who will act on the result
Decision to support	What choice the analysis should inform
Scope and constraints	Relevant period, population, budget, deadline, privacy, and operational limits
Success measure	The KPI or outcome that indicates improvement

A KPI, or key performance indicator, is a defined measure used to track progress toward a business objective. For repeat purchasing, a KPI might be the percentage of first-time customers who make a second purchase within 60 days.

The next lesson will focus on translating requests into precise analytical questions and measurable KPIs. For now, recognize the key principle:

A useful analysis begins with a business decision and works backward to the evidence required.

---

2. Prepare evidence that deserves to be trusted

Once the objective is clear, the analyst identifies the data needed to answer it. In the retailer example, relevant information may include:

• Customer identifier
• First purchase date
• Subsequent purchase dates
• Product category
• Acquisition channel, such as paid search, social media, or email
• Marketing messages received
• Discount amount
• Customer support contacts
• Region or device type, if relevant and available

The analyst then asks whether the data is fit for purpose. This includes checking:

• Coverage: Does the data include the relevant customers and time period?
• Definitions: Does “repeat purchase” mean a second order, a second delivered order, or a second order above a minimum value?
• Completeness: Are important values missing?
• Accuracy: Are dates, prices, categories, and customer IDs plausible?
• Consistency: Are the same labels and formats used throughout?
• Granularity: Does each row represent an order, a customer, a website visit, or something else?

This work is often called data preparation, processing, or wrangling. It includes cleaning errors, standardizing formats, removing inappropriate duplicates, joining related tables, and organizing data for analysis.

The principle is simple: an impressive chart cannot repair unreliable source data. If customer IDs are missing, dates are inconsistent, or a sales table includes canceled orders without a clear status field, any conclusion may be misleading.

A professional analyst documents important assumptions rather than silently making them. For instance:

“Repeat-purchase rate is calculated using customers whose first order was at least 60 days ago, so every included customer had a full 60-day opportunity to return.”

That short statement makes the metric interpretable and allows someone else to reproduce or challenge the work constructively.

---

3. Analyze with a question, not just curiosity

With prepared data, an analyst explores patterns and evaluates possible explanations.

A hypothesis is a testable proposed explanation. In the retailer case, possible hypotheses might include:

• Customers acquired through a particular channel have lower repeat-purchase rates.
• A change in product availability reduced the likelihood of a second purchase.
• Customers receiving a post-purchase email are more likely to return.
• The apparent decline comes from a change in how orders were recorded rather than a real behavioral change.

A hypothesis gives the work direction, but it is not a conclusion. Analysts must be especially careful not to confuse a pattern with proof of cause.

For example, imagine this result:

Customer group	Repeat-purchase rate
Customers who received a follow-up email	22%
Customers who did not receive one	15%

This is an important finding: the two groups have different repeat-purchase rates. But it does not automatically prove that sending an email caused the improvement. Perhaps the company intentionally emailed customers who were already more engaged, or perhaps one group bought different products.

A careful analyst would investigate further. They might compare similar customer groups, look at results over time, check whether the email program changed, or recommend a controlled test. Good analysis progressively rules out weak explanations and quantifies what remains uncertain.

The first pass is often descriptive:

• What changed?
• When did it change?
• Which products, customer segments, or regions contributed most?
• Is the pattern widespread or concentrated in one group?

Then the work may become diagnostic:

• What factors are associated with the change?
• Is the change consistent with a data issue?
• Which plausible explanations are supported or weakened by the data?

Analysts use tables, calculations, visualizations, and sometimes statistical tests for this work. The tools will change as you progress through this course, but the reasoning does not: compare relevant groups, test assumptions, check for alternative explanations, and preserve an audit trail from raw data to result.

This short video presents the workflow in a job-focused way, emphasizing the need to define business success before collecting and analyzing data.

---

4. Turn results into an insight and a recommendation

Analysts often use the words finding, insight, and recommendation interchangeably. For job interviews and workplace communication, separating them makes your work much clearer.

• A finding is an evidence-based observation from the data.
• An insight explains why that observation matters to the business.
• A recommendation proposes a specific action based on the insight.

Using the repeat-purchase example:

Level	Example
Finding	The 60-day repeat-purchase rate fell from 24% to 18%. The decline is concentrated among customers acquired through paid social media.
Insight	The overall decline is not distributed evenly across customers. The paid-social segment is a priority for investigation and may be driving much of the business-level decline.
Recommendation	Run a controlled post-purchase onboarding campaign for newly acquired paid-social customers, compare results with a similar holdout group, and monitor repeat-purchase rate and discount cost over 60 days.

Notice the care in this recommendation. The analysis did not claim that a missing onboarding message caused the decline. Instead, it proposed a focused, measurable action that can generate stronger evidence.

A recommendation is most useful when it states:

1. What action to take
   For example, test a post-purchase onboarding campaign.

2. Who and where it applies to
   For example, newly acquired customers from paid social media.

3. Why the action is justified
   Link it directly to the finding and business objective.

4. What result is expected or being tested
   For example, improve the 60-day repeat-purchase rate.

5. How success and risk will be monitored
   Track the target KPI, cost per retained customer, unsubscribe rate, or other relevant guardrails.

This is what makes a recommendation evidence-based. It does not mean the analyst can guarantee the action will work. It means the recommendation follows logically from the best available evidence, makes assumptions visible, and includes a way to learn whether the action created value.

---

5. Communicate for the person making the decision

An analysis is not complete when a query runs or a chart is created. It is complete when the stakeholder can understand the evidence well enough to make an informed decision.

A clear stakeholder summary usually follows this structure:

1. Context: What business problem was investigated?
2. Method: What data and time period were used? What important assumptions or limitations apply?
3. Key findings: What are the few results that matter most?
4. Interpretation: Why do these findings matter for the business?
5. Recommendation: What should happen next?
6. Measurement plan: How will the organization know whether the action worked?

A concise example might read:

Repeat purchase within 60 days decreased by 6 percentage points during the last quarter. Most of the decline came from recently acquired paid-social customers, whose repeat rate fell by 11 percentage points; rates for other acquisition channels were broadly stable. This pattern identifies paid-social customers as the priority segment, but the available data does not establish the cause. We recommend testing a targeted onboarding campaign with a holdout group and measuring repeat-purchase rate, discount cost, and opt-outs after 60 days.

That is much more useful than showing ten charts without a conclusion. It is also more credible than saying, “Paid social caused the decline,” when the evidence only demonstrates association.

Communication should be adapted to the audience. A manager may need a short summary, a dashboard, and a recommended action. Another analyst may need definitions, SQL logic, cleaning decisions, and a data-quality record so they can validate the work. Strong analysts provide the appropriate level of detail without hiding uncertainty.

Finally, the process continues after the recommendation. If the business implements an action, the analyst measures the outcome, compares it with the baseline or a control group when possible, and refines the next recommendation. Analysis supports an ongoing decision cycle, not a one-time report.

---

A reusable analyst workflow

For early projects, use this compact checklist before presenting any work:

Stage	Analyst deliverable
Frame	A clear problem statement, stakeholder, decision, scope, and deadline
Measure	Defined KPIs and an outline of the data needed
Prepare	Clean, validated, documented analysis-ready data
Analyze	Comparisons, trends, hypotheses, findings, and limitations
Communicate	A focused narrative and visuals tied to the original question
Recommend	A concrete action, rationale, owner, and measurement plan

The technical skills in the rest of the course—Excel formulas, SQL queries, Power BI measures, and Python analysis—will support each of these stages. But technical output alone is not the endpoint. The endpoint is a decision that is better informed than it was before.

---

Key takeaways

A data analyst moves from request to recommendation by first clarifying the business decision, defining what success means, preparing trustworthy data, investigating patterns and hypotheses, and communicating a focused conclusion.

Keep these distinctions in mind:

• A business request is often broad and needs clarification.
• Data must be checked and prepared before it can serve as evidence.
• A finding states what the data shows.
• An insight explains the business significance of that finding.
• A recommendation proposes a specific, measurable next action.
• Evidence can support a recommendation without proving causation; uncertainty and limitations should be stated plainly.

Next, you will practice the most important early step in this workflow: translating a business request into a precise analytical question and a measurable KPI.