How to Write a Data Insights Report (With a Template)

Someone on your team spent two days pulling numbers, built nine charts, wrote four pages, and sent it to the leadership channel at 6pm on a Thursday. Three people reacted with a thumbs up. Nobody did anything differently the following week. That report was not badly researched. It was badly structured, which in data analysis and reporting is the same thing as being wrong, because a finding nobody acts on has exactly the same business value as a finding nobody found.

The difference between a report that changes behaviour and one that decorates an inbox is almost never the quality of the analysis. It is the order of the sentences, the presence of an owner, and whether the writer had the nerve to say what the data cannot tell you. This guide gives you a fixed structure, an insights report template you can copy, and the specific discipline that separates a data insights report from a data dump with a title page.

What separates data analysis and reporting from a data dump

A data dump answers the question "what happened". A data insights report answers "what happened, why it probably happened, what it means for a decision we are about to make, and who is going to do something about it". Everything in this article is machinery for getting from the first to the second.

The failure is easy to spot once you know the shape. Data dumps lead with methodology, present metrics in the order the source systems happened to export them, use hedged language throughout, and end with a section called "next steps" that contains no names. Reports that get acted on lead with the single most consequential thing the writer learned, spend the middle explaining the shape of it, and end with a small number of recommendations each attached to a human being.

Notice that the right column is not longer. It is usually shorter. Length is the most common substitute for judgement in analytics analysis, because listing everything you found feels safer than choosing what mattered. It is not safer. It transfers the work of deciding what matters onto a reader who has less context than you do and less time.

Step one of data analysis and reporting: earn the numbers before you interpret them

Before structure, provenance. The fastest way to destroy a report is to have someone in the room say "that revenue number does not match what I see in the billing system", because from that moment on nobody is discussing your recommendation, they are discussing your spreadsheet.

Four things to settle before you write a word:

Define the metric in one sentence, in writing, at the top. Not "revenue" but "recognised revenue, excluding refunds issued in the same period, from the Stripe charges table, in the customer's billing currency converted at month-end rates". If you cannot write that sentence, you do not yet know what you are measuring.

Name the source for every number. Every figure in the report should be traceable to a system and, ideally, a filter or query. This is the single highest-leverage habit in reporting, because it converts arguments about trust into arguments about definitions, which are resolvable.

Fix the window and the comparison basis. Month over month, same month last year, and trailing twelve months tell three different stories about the same data, and picking the flattering one is the most common form of quiet dishonesty in internal reporting. Choose the comparison before you see the result.

Look at the raw distribution once. Averages hide almost everything interesting. Before you summarise, spend twenty minutes actually looking: distributions, outliers, missing values, the handful of records doing all the work. That habit has a name and a method, and the steps in Exploratory Data Analysis: Steps, Methods, and Examples are worth doing before every report you write, not just the big ones.

If you are assembling this by hand from CSV exports, be honest about how much of your week that consumes and whether the spreadsheet has quietly become the system of record. The tradeoffs of moving off it are covered in Alternatives to Excel for Data Analysis and Reporting, and the answer is not always to move.

The five-part structure that makes a report actionable

Every good data insights report I have seen uses some version of the same five moves, in this order. The order is the point. It is inverted-pyramid journalism applied to analytics: the reader who stops after paragraph one still gets the thing that matters most.

1. Headline finding. One sentence. The most consequential thing you learned, stated as a claim with a number in it.
2. Trend. The shape over time. Is this new, accelerating, reverting, or seasonal noise you nearly mistook for a signal?
3. Top and bottom performers. Where the movement concentrates. Which segments, channels, products, reps, or cohorts are carrying it.
4. Anomalies that need attention. The things that do not fit the story, including the ones that undercut your headline.
5. Recommendations tied to an owner. A short list, each with a name and a date.

Then a sixth section that is not part of the narrative but belongs in every serious report: confidence and limitations. What you are sure of, what you are guessing at, and what this dataset structurally cannot answer.

1. The headline finding

Write it as a claim, with a number, that a reasonable person could disagree with. "Q2 was a mixed quarter" is not a finding, it is a weather report. "Self-serve signups grew 22 percent while activation fell 9 points, so we are buying more users who never reach value" is a finding, because it asserts a mechanism and invites challenge.

Test it three ways. Could it be false? If not, it is a description, not a finding. Does it point at a decision? If the honest answer to "so what" is "nothing changes", it belongs in an appendix. Would you say it out loud to the person it implicates? If you have softened the sentence to protect a team, you have written PR.

One headline per report. If you have three findings of equal weight, you have three reports, or one report with a genuinely hard editorial choice that you should make rather than avoid.

2. The trend

A single-period number is almost always misleading. The trend section answers whether the headline is a break in pattern or the pattern continuing. This is what people mean when they ask for a performance trends report: not a chart of everything over time, but the specific time series that establishes whether the headline finding is new.

Three things worth stating explicitly:

• Direction and rate. Not just "declining" but "declining roughly 2 points per month for five months".
• When it started. Naming the inflection point is what makes causal investigation possible. "It turns from the second week of March" is a lead. "It has been getting worse" is not.
• Seasonality check. Compare to the same period last year before you claim a change. An enormous share of internal panic is August behaving like August.

One chart here, at most two. If the trend needs five charts to see, it is not a trend yet.

3. Top and bottom performers

Aggregate movements are nearly always concentrated. A 6 percent drop across the business is usually not 6 percent everywhere, it is 40 percent in one segment and flat in the rest, and the entire value of your report may be the sentence that identifies which.

Present both ends. The bottom performers tell you where to intervene; the top performers tell you what an intervention should look like, and they are the half most reports skip. If one region is holding its renewal rate while four are sliding, the report writes itself: go find out what that region is doing.

A working rule: for any aggregate movement, decompose by two dimensions before you write about it. Usually one of them explains most of it. If neither does, that is itself a finding, because a genuinely broad-based movement points at a systemic cause rather than a local one.

4. Anomalies that need attention

This section is where credibility is won or lost. It holds the things that do not fit: the segment moving the wrong way against your story, the week the data looks impossible, the metric that changed when a tracking script was updated rather than when customer behaviour did.

Include three categories:

Data anomalies. Gaps, duplicates, sudden definitional changes. If a number tripled because someone changed a filter in the source system, say so plainly rather than discovering it in the meeting.

Business anomalies. Real movements that contradict the headline. Naming them yourself is not weakness, it is the thing that makes the rest of the report believable.

Unresolved anomalies. Movements you noticed and could not explain. Write them down with what you tried. Half of them turn out to matter next quarter, and the note you left is what lets someone pick it up.

Some anomalies do not belong in a monthly document at all, because by the time it ships the moment has passed. Those are one-off, time-boxed questions with a shelf life of days, and the triage approach in Ad Hoc Reporting: How to Answer One-Off Data Questions is the right lane for them.

5. Recommendations tied to an owner

A recommendation without a name is a wish. The format that works:

Recommendation. Move the January enterprise cohort into a proactive save motion before their renewal window opens. Owner. Priya (Customer Success). Because. That cohort accounts for roughly two thirds of the renewal decline and their support ticket volume is double the base rate. Check date. Review at the next monthly on the 14th. What would change my mind. If ticket volume is driven by a single integration bug rather than product fit, the right motion is engineering, not CS.

Three to five recommendations, maximum. Each must be something a specific person can start on Monday. "Improve onboarding" fails that test. "Rewrite the first-run email sequence for the self-serve funnel, draft by the 20th" passes.

Do not skip the "what would change my mind" line. It is the single clearest signal that you did analysis rather than advocacy, and it protects you when the data turns out to have been pointing at something else.

Stating confidence and what the data cannot tell you

Every dataset has a boundary. Reports that pretend otherwise get caught, usually in the worst possible room.

Use a simple three-level scale and apply it per claim, not to the report as a whole:

Then a short, blunt list of what the data cannot answer. Common entries: we cannot see why customers who never contacted support churned; attribution beyond last click is not instrumented; the CRM stage field is filled inconsistently by two of the four teams, so pipeline velocity below stage three is unreliable; anything before the March migration is not comparable.

That last category is worth dwelling on, because pipeline and revenue data almost always carry structural limits that reporting inherits from the underlying systems. The gaps in what customer and finance records actually capture are laid out in Financial CRM Software: What It Does and What It Misses, and knowing them stops you from writing a confident sentence about a field nobody maintains.

Writing limitations down has a second benefit: it converts a vague sense of unreliability into a specific instrumentation backlog. Two quarters of these lists is a data roadmap.

The insights report template

Copy this. It is deliberately short. A one-page insights report template that gets read beats a twelve-page one that gets skimmed.

TITLE: [Metric or area] insights, [period]
AUTHOR / DATE / DATA AS OF: [name] / [date] / [data cutoff timestamp]

HEADLINE FINDING
[One sentence, with a number, that a reasonable person could dispute.]

WHY IT MATTERS
[Two sentences on the decision this affects and the cost of ignoring it.]

TREND
[Direction, rate, inflection point, seasonality check. One chart.]

WHERE IT CONCENTRATES
Top performers: [segment, metric, what they seem to be doing differently]
Bottom performers: [segment, metric, suspected cause]

ANOMALIES AND THINGS THAT DO NOT FIT
- [Data anomaly, and whether it invalidates anything above]
- [Business anomaly that contradicts the headline]
- [Unexplained movement, what was tried, what to check next]

RECOMMENDATIONS
1. [Action] | Owner: [name] | Check date: [date] | What would change my mind: [condition]
2. ...
3. ...

CONFIDENCE
High: [claims]
Medium: [claims]
Low: [claims]

WHAT THIS DATA CANNOT TELL US
- [Structural limitation]
- [Instrumentation gap]

SOURCES
[Metric] = [system, table or report, filter, date range]

Two rules for using it. First, fill the headline last even though it sits first, because you will not know what the finding is until you have done the middle. Second, if a section is empty, delete it rather than padding it. An honest four-section report is better than a complete-looking one with a paragraph of filler under "anomalies".

Cadence: how often to write one

Not every question deserves a document. Match the artefact to the decision rhythm.

The quarterly row carries most of the value and is the one teams skip. Reopening the last quarter's recommendations and marking each as done, dropped, or wrong is uncomfortable, and it is the only mechanism that turns reporting into a learning loop rather than a ritual. A report nobody is ever held to becomes decoration within two cycles.

Where Skopx fits in data analysis and reporting, and where it does not

Start with what is not true. Skopx is not a dashboard builder, not a business intelligence platform, not a data warehouse, and not an ETL tool. It will not design your report, choose your headline finding, or decide which recommendation is worth someone's quarter. If you need governed semantic models and a chart library, buy a BI tool.

What it does is compress the part of the work that eats the most hours and produces the least insight: assembling defensible numbers from systems that do not talk to each other. Skopx is an AI workspace that connects nearly 1,000 tools a company already uses, including Gmail, Slack, Stripe, HubSpot, QuickBooks and Google Analytics. You ask in chat, and answers come back with citations pointing at the underlying records, which is what makes the sources block at the bottom of the template cheap to fill instead of a half-day of copying query filters into a doc.

Three concrete fits. The insights engine surfaces risks and anomalies across connected tools, which feeds the anomalies section with things you were not looking for, which is exactly the category humans are worst at catching. The morning brief keeps the trend line in view between reporting cycles, so a monthly report is confirming a shape you already noticed rather than discovering it three weeks late. And workflows, which you build by describing them in chat, can assemble the recurring numbers block on a schedule so the writing starts from a populated draft.

Monthly insights report prep

First business day, 08:00

Runs on the reporting calendar, not on demand

Pull the metric set

Revenue, pipeline, traffic and support volume from the connected tools, each with a link back to the source record

Compare to prior period and same period last year

Both comparisons, so seasonality is visible before anyone writes a sentence

Flag movements past threshold

Decomposed by two dimensions so concentration shows up

Assemble the numbers and sources block

Fills the template's trend, concentration and sources sections only

Send to the report author

A populated draft, not a finished report

Where it does not fit: if your reporting problem is that data lives in twelve systems and needs to be reconciled into one modelled warehouse on a schedule, that is a pipeline problem, and the options are compared in Cloud Integration Platforms (iPaaS) Compared for 2026. If your reporting is regulated disclosure with audit requirements, the controls in ESG Reporting Software: How to Choose the Right Platform are the shape of what you actually need. And if the real bottleneck is that a report triggers a multi-team approval chain, you are looking at a process problem, covered in BPM Software vs Workflow Automation: Which One You Need.

On cost, because it is a fair question when a tool sits next to reporting spend: Skopx is $5 per month for Solo and $16 per seat per month for Team, and it runs on your own AI key with zero markup, so model spend is billed to you directly rather than resold. The pricing page has the detail.

The judgement stays with the writer. A tool can hand you a populated draft with citations and a list of things that moved unusually. Only a person can decide which of those movements is the story, what it means for a decision the company is about to make, and who should own the response. That is the actual job, and it is why an actionable insights report is still a piece of writing rather than an export.

Frequently asked questions

How long should a data insights report be?

One page for weekly, two to three for monthly, and longer only when the appendix carries detail nobody needs to read in the meeting. The constraint that matters is the headline finding fitting in the first two sentences. If a reader has to reach page two to learn what you found, the structure is wrong regardless of total length.

What is the difference between reporting and analysis?

Reporting delivers agreed metrics on a cadence and answers "what happened". Analysis interrogates those metrics to answer "why, and what should we do". A data insights report is the artefact where analysis is delivered, which is why it needs a headline claim and an owner rather than a grid of numbers. Most teams do plenty of the first and call it the second.

How do I write an insights report when the data is incomplete?

Write it anyway, and put the gaps in the limitations section explicitly rather than hedging every sentence. State what you can say with high confidence, what is a medium-confidence inference, and what the data structurally cannot answer. A report that clearly marks its own boundaries is more useful than one that waits for perfect data, which never arrives.

Should the report include charts or just text?

One chart per claim, and no chart without a claim. The most common mistake in analytics analysis is producing a chart for every available metric, which forces the reader to do the interpretation you were hired to do. If you cannot write the sentence a chart supports, delete the chart.

How do I make sure people actually act on the report?

Attach a name and a date to every recommendation, keep the list to three to five, and revisit the previous cycle's recommendations at the start of the next one. The revisiting step is what creates accountability. Without it, recommendations accumulate unread and the report becomes a ritual, which is the most common way a good reporting habit dies.

Can AI write a data insights report for me?

It can do the assembly: pulling numbers from connected systems, comparing periods, flagging outliers, and drafting a first pass with sources attached. It cannot reliably decide which finding matters to your business this quarter, which recommendation is politically viable, or when a number is technically correct and practically meaningless. Treat generated drafts as a populated template, then do the editorial work yourself, and check every cited figure before it goes out under your name.