ServerVultr

Data storytelling isn’t complicated. Great Power BI report structure starts with one simple idea: every good report should have a beginning, a middle, and an end.

Storytelling in data is simpler than people think

At this point in the series, people often assume that “data storytelling” means something complicated.

Something creative.
Something fluffy.
Something subjective.

It doesn’t. It starts with something very simple. Every good story has three parts:

• A beginning
• A middle
• An end

We instinctively understand this structure in films, books, and conversations. If someone starts a story halfway through, we feel lost. If they never finish it, we feel frustrated.

And yet the moment we open Power BI, we abandon that structure entirely. Most reports are all middle, with little if any beginning or end.

The problem: reports with no beginning

Open most dashboards and what do you see?

• Metrics
• Charts
• Comparisons

Straight away. No context. No framing. No explanation of why this page exists or what decision it supports.

It’s as if someone walked into a cinema, skipped the opening scenes, and pressed play in the middle of the film. The audience is immediately working harder than they should be.

They’re asking:

• What am I looking at?
• What timeframe is this?
• What problem are we trying to solve?
• Why does this matter now?

If your report forces the audience to orient themselves before they can think, you’ve already created friction. The beginning of a report should answer one simple question:

Why should I care?

The middle: where most reports live

The middle is where analysis happens. This is where you explore:

• What’s happening
• What’s driving it
• where the patterns are
• What’s surprising

And this is where most dashboards stop. They present the data. They present the breakdowns. They present the trends. And then they leave the room. No conclusion. No implication. No direction.

It’s the analytical equivalent of someone explaining a problem in detail and then walking away mid-sentence. Technically correct. Structurally incomplete.

The missing ending

Here’s the uncomfortable truth, If your report doesn’t have an ending, it isn’t finished. No matter how accurate the data is. The ending is where you make the implication clear.

It answers:

• So what?
• What does this mean?
• What should we do?

Without an ending, dashboards create discussion instead of decisions. And discussion is not the goal. The goal is clarity.

Power BI report structure should follow stories

A good Power BI report should function like this:

The beginning

Set context. Define the scope. Explain the decision.

Answer: Why should I care?

The middle

Explore the drivers. Surface the patterns. Highlight what matters.

Answer: What’s happening and why?

The end

State the implication. Reduce ambiguity. Point toward action.

Answer: What do we do next?

That structure isn’t creative writing.

It’s cognitive alignment.

Let’s try it on my football report

�

Why we abandon structure in analytics

There’s a reason most dashboards are all middle.

• We’re trained to build models.
• We’re trained to calculate measures.
• We’re trained to visualise data.

We’re rarely trained to structure thinking. So dashboards become containers for metrics rather than vehicles for decisions. They’re built as analytical canvases instead of narrative flows. And that’s why they feel dense. Not because the data is wrong. Because the structure is missing.

The spreadsheet mindset

Spreadsheets don’t have beginnings or endings. They have rows and columns. They’re designed for exploration, not persuasion. When we treat Power BI like an interactive spreadsheet, we get exploration-heavy dashboards that rely on the audience to assemble meaning. But business stakeholders don’t need more exploration. They need clarity. That requires structure.

Structure reduces cognitive load

When a report follows a beginning–middle–end structure:

• The audience knows where to start.
• They understand what matters.
• They aren’t left wondering what the conclusion is.

Structure removes interpretation work. It guides attention. It makes insight land. Without structure, even good visuals feel fragmented. With structure, even simple visuals feel powerful.

A practical test

I’ll use this story telling framework with my FPL dashboard in the next post. But try this on one of yours. Open one of your key reports and ask:

• Where is the beginning?
• What page establishes context?
• Where does the report clearly end?
• Is the implication explicit?

If the report simply stops after analysis, it’s unfinished.

If it doesn’t answer “what now?”, it’s incomplete. Storytelling in analytics isn’t about creativity. It’s about finishing the thought.

In the next post, we’ll use this framework and apply it to my FPL report. And in subsequent posts we’ll explore how the “hero’s journey” reframes your role as the report author — and why you’re not the hero in this story.

Related: Decision-Driven Analytics in Practice: A Fantasy Football Example

Start the series: Dashboards Don’t Drive Decisions (And That’s the Real Analytics Problem)

FPL Captain Choice with Power BI: A Story-Structured Report

If you’ve been following my series on data-driven storytelling, particularly the last post on structuring reports with a beginning, middle, and end, you’ll know I’ve been building toward something practical.

So now it’s time to apply that framework to my own FPL report.

Because if the structure works, it should work where the stakes are obvious: picking the right captain each week in your fantasy premier league team.

Turning My FPL Report Into a Story: Beginning, Middle, End

Your FPL captain choice is the most important decision you make each gameweek. This post applies the beginning–middle–end report framework to my Fantasy Premier League Power BI report and shows how to design it to deliver a clear recommendation.

Power BI report structure should follow stories

In the last post, I argued that a Power BI report should follow the same structure as a story:

Not because it sounds nice. Because it reduces cognitive load and improves decisions. So let’s apply that properly. Not in theory. In Fantasy Premier League.

The beginning: why should I care?

In FPL, there is one decision each week that matters more than any other:

Who is my captain?

Get it right and you double the points of your highest-performing player. So you get the score of your best player twice! If you make the right selection.

Get it wrong and you can drop thousands of places overnight.

This isn’t just another metric. It’s the highest leverage decision in the game. So the beginning of the report must frame that explicitly.

Not:

• “Gameweek Overview”
• “Player Metrics”

But:

Who should I captain this week?

That is the context. That is the scope. That is the decision. Everything that follows exists to reduce uncertainty around that one question.

If the opening page of the report doesn’t make that obvious within seconds, it’s not doing its job. As you can see from the screen shot below of the report page aptly named Beginning – Which player should I captain this week� the data suggested based on estimated points next week that the captain should be Cole Palmer or Nico Reily with a bit of Power BI Co-pilot for a bit of fun too.

The middle: what’s happening and why?

Once the decision is framed, we move into the middle.

This is where most dashboards live. But in a story structure, this part has a job: to build confidence in the decision.

In FPL terms, that means analysing:

• high form players
• high projected points
• strong historical scorers
• good value players
• position-based comparisons

But here’s the discipline: We only include what influences the captaincy or transfer decision. Not everything.

1) High form players

Form is one of the clearest short-term signals in FPL. If a player has scored well in the last 3–5 gameweeks, that’s meaningful momentum. So the report should clearly surface:

• Top  players by form
• With context (position, price, minutes played)

Not buried in a table with rows and rows of data. It should be highlighted. Because form directly influences captain confidence.

2) High projected points (EP_Next)

Projected points matter because captaincy is a forward-looking decision, you have heard it all before, “Past performance does not mean future returns”. Your report should clearly show:

• Top projected points overall
• And top projected points by position

This is where the story narrows. We’re not asking “Who is interesting?” We’re asking:

Who is most likely to deliver points this week?

So our middle section, page one of two aptly named Middle – Top Players by Form EP and Position�looks like this

3) High scoring but cheap – Good ROI for the business people out there

Transfers matter too. Let’s not forget that. The middle section should also surface:

• players with high total points
• relative to their cost
• with strong recent form

That’s how you identify value.

A £5.5m defender averaging 6 points per game might be a better transfer than a £7.5m underperforming midfielder.

The report should help answer:

• If I need a transfer this week, where is the value?
• Which positions offer upside?

This builds the case. This builds the confidence.

The end: what do we do next?

Now comes the part most dashboards miss. The ending. The implication. The recommendation.

Based on:

• form
• projected points
• value
• position comparisons

The report must land on:

This is the captain.

And optionally:

These are the top alternatives by position.

So one of the previous post in this series made Brent Ozar’s newsletter, it was the one called Data Overload Is Killing Decision-Making  and he added comment in his newsletter about my post that said “Gethyn Ellis says Data overload is killing decision-making, and I’ll add this one of the reasons people are leaning harder on AI to distill stuff” So I did, for my ending I got Power BI Copilot describe based on my data the best team this week. Here it is if you want it for Friday’s deadline

This doesn’t remove nuance. It removes ambiguity. It gives the manager clarity.

Why this works

This structure works because it aligns with how the brain processes decisions.

Beginning: Why should I care? → Captaincy decision.

Middle: What’s happening and why? → Form, projections, value.

End: What do we do next? → Captain selection + alternatives.

That’s not creative writing. It’s cognitive alignment.

What this means for business analytics

Now zoom out. Replace:

“Who should I captain?”

With:

• Which supplier should we renegotiate with?
• Which product should we prioritise?
• Which region should we invest in?

The structure is identical. Most business dashboards stop in the middle. The FPL example makes it obvious because the stakes are visible and immediate. If I publish an FPL dashboard that never tells me who to captain, it’s useless. The same should be true in business.

The real test

If someone opens your Power BI report and asks:

“So what should we do?”

Then your story hasn’t finished. In FPL, that costs you rank.

In business, it costs you clarity, speed, and alignment. That’s why structure matters.

Want to apply this beyond FPL?

Fantasy Premier League makes the stakes obvious.

Get the captain wrong and you drop rank. Get the decision wrong in business and you lose time, money, and momentum. The structure is the same.

Inside the Data Accelerator, we work with teams to move from reporting to decision support — starting with the decision, structuring reports with intent, and making the implication explicit.

If you’re serious about turning your Power BI reports into decision tools, not just dashboards, that’s exactly what we focus on.

In the next post, we’ll look at something even more uncomfortable: you are not the hero of the report — the audience is.

Related: Power BI Report Structure: Beginning, Middle, End

Example: Decision-Driven Analytics in Practice: A Fantasy Football Example

With the release of Microsoft SQL Server 2025, one of the most important, and most missed changes, isn’t about performance, security, or AI features. It’s about reporting. And SQL Server Reporting Services in particular.For years, organisations have relied on SQL Server Reporting Services (SSRS) for on-premises operational reporting, invoices, statements, regulatory extracts, and those “must-print” pixel-perfect outputs.In SQL Server 2025, released at the end of last year, Microsoft has drawn a clear line in the sand: SSRS is no longer moving forward as a standalone product, and on-premises reporting is now consolidated under Power BI Report Server.This post explains what’s changed, what’s bundled (and what isn’t), and how to think about your next steps.

A quick recap: what SSRS used to be

SSRS has long been the default Microsoft option for on-premises, server-hosted reporting. It’s best known for paginated reports (RDL): highly formatted, page-based reports designed for printing, exporting to PDF, or distributing by email.

It has been the workhorse for operational reporting in countless SQL Server estates, and for good reason: it’s reliable, mature, and fits well into traditional IT governance.

However, Microsoft has confirmed that SSRS 2022 is the final release of SSRS, and that there is no SSRS “version” shipping with SQL Server 2025.

Reference:

Reporting Services consolidation FAQ (Microsoft Learn)

So what replaces SSRS in SQL Server 2025?

The consolidated on-premises reporting platform is now Power BI Report Server (often referred to informally as “Power BI Reporting Services”).

Power BI Report Server is an on-premises server product that supports:

• Paginated reports (RDL) — the same report type SSRS was built for
• Interactive Power BI reports (PBIX) hosted on-premises
• A modern web portal experience, security integration, and standard report management capabilities

In other words: rather than shipping and maintaining two separate on-premises products (SSRS for RDL and Power BI for interactive reporting), Microsoft has aligned the on-premises story around a single report server.

Reference:

SQL Server 2025 announcement (Microsoft Tech Community)

Is SSRS and Power BI Report Server “bundled into the same product”?

Not as two separate installs. The practical change is this:

• SSRS is not included with SQL Server 2025 as a new, updated SSRS release.
• Power BI Report Server is the consolidated on-premises reporting product going forward.
• Power BI Report Server supports both RDL (paginated) and PBIX (interactive) reports on-premises.

So if your question is: “Do I now have one on-premises reporting platform that covers both SSRS-style paginated reporting and Power BI-style interactive reporting?”  the answer is effectively yes, via Power BI Report Server.

If your question is: “Is SSRS still bundled as its own separate reporting feature in SQL Server 2025?” — the answer is no.

Why this matters for organisations running SSRS today

If you’re currently using SSRS heavily, you do not need to panic, but you do need a plan.

SSRS 2022 remains supported under its lifecycle, but Microsoft’s direction is clear: future on-premises reporting investment is centred on Power BI Report Server.

This matters because many estates still treat SSRS as a default dependency, embedded in operational workflows, tightly coupled with SQL Agent jobs, triggered exports, scheduled subscriptions, and business-critical PDF pipelines.

The good news is that RDL and paginated reports remains a first-class citizen in the on-premises world via Power BI Report Server,  you’re not being forced to redesign everything as dashboards overnight.

What should you do next?

Here’s a sensible, low-risk approach:

1. Catalogue your SSRS reports and classify them (operational/regulatory / management / ad-hoc).
2. Identify the “hard” ones: complex subscriptions, custom extensions, unusual authentication, or legacy dependencies.
3. Stand up Power BI Report Server in a test environment and validate a representative set of RDL reports.
4. Decide your target model: on-premises PBIRS, cloud Power BI, or a hybrid approach.

Reference:

Power BI Report Server overview (Power BI)

Conclusion

SQL Server 2025 marks a clear change in Microsoft’s reporting roadmap. SSRS as a standalone product isn’t moving forward in new SQL Server releases, and Power BI Report Server is now the consolidated on-premises reporting platform that supports both paginated (RDL) and interactive Power BI reporting.

If you’re responsible for an on-premises SQL Server estate, now is the time to understand the shift, assess your SSRS footprint, and plan your reporting future in a controlled way, before the change becomes urgent in a few years time.

Need help migrating from SSRS?

If you’re running SQL Server and relying on SSRS for operational reporting, now is the time to plan your next move.

We help organisations:

• Audit and rationalise SSRS estates
• Design and deploy Power BI Report Server environments
• Migrate reports safely with minimal disruption
• Modernise reporting architecture (on-premises, cloud, or hybrid)
• Improve performance, security, and governance

Whether you need a structured migration plan, hands-on technical support, or strategic guidance on your reporting roadmap,
we can help you move forward with confidence.

Book a Reporting Strategy Call

---

Useful Links