Writing business reports

Congratulations you’re a data scientist! You’ve got the tech skills, the maths skills, the stats skills… and now you need to write a business report(s) and nobody ever took five minutes to show you the basics.

That’s what this post is about: the basics of writing for business.

Business reporting is hugely varied – the most important thing to consider is who your audience is and write for them. This is never a one-sizes-fits-all situation and the minute you try to make it one, you will end up with a low-quality product.

Here are some thoughts to help you on your way.


Business reports can be a lot more free-flowing and variable than you might think. The term ‘report’ encompasses a huge range of documents. Here I’ll talk about a formal, structured document – but remember this isn’t always the best approach. Tailor the document to the stakeholder, always!

There are a number of elements to the formal business report and I’ll pick out a few I think need better understanding.

Executive summary

Executive summaries come first after title pages, but before your table of contents and introduction. This is the most important part of the report – the tl;dr (tl;dr: too long, didn’t read).

Most reports suffer from tl;dr. The executive summary is your chance to make an impact in spite of that. It’s not the same as an introduction – it’s almost a mini report.

The executive summary should include what you did, how you did it, what you found out doing so and if there are any limitations or caveats on the doing.

Sometimes an executive summary can feel like a bunch of lists: things you did, things you thought, things you investigated, things you found out. If you need to list off a bunch of things – use bullet points to make that list easier on your reader.

Infographics are also a really useful way to convey information to an audience that doesn’t have the time or capacity to read the details. The advantage of this is they get the surface-level overview – and know where to come back for detail when/if they need it. (For more info on infographics see here.) Infographics are also really shareable which means your work may get wider currency than it would otherwise.


This looks the same as an executive summary on the surface. It’s often confused by many as almost the same: it’s not!

The introduction provides the baseline for the report’s readers. It should include some context (why are we here?) and in some circumstances a basic run down of results and methods is also relevant (what did we find out from being here and how did we find it out?). However, in shorter business reports, these may be best left to their own sections. It’s always a matter of judgement.

It should also include a road map for the report’s readers, so they know where the critical information lies. Something like Section 1 discusses the context of internet access in rural NSW while Section 2 outlines the methods used in this study.

The introduction comes after the table of contents and the executive summary.


This is the main action of your report. Its structure depends on what you’re doing and who you’re doing it for. You may need a methods section – or it may be best relegated to an appendix if you have a non-technical audience. You may need a section on context – or the audience may understand the context already. It all depends.

The trick to structuring your report is to think about what it is your audience needs to take away from reading it: what is the purpose here? What was the purpose of the work in the first place? Start there.

Structure is essentially a drafting problem – see some tips below for help on that.


A poor cousin of the executive summary – this can usually be reasonably brief compared to the rest of the report. It should outline what has been done and its outcome.  This is not the section to introduce anything new!

Including analyses

We’re data scientists and analysts: of course there’s going to be analyses. How do you decide which ones though?

Be aware of the temptation to ‘throw everything in there’ to show everyone what a wonderfully thorough job you did. Does it add to the purpose and structure you defined above? If not, it stays out.

Brag to your twitter pals about the fantastic model you built, though, at least you know they’ll care.

The finer points of tables and figures

Most of our analyses end up in reports as tables and figures. There are a couple of really simple points that are widely unknown about using them. But like many simple things, they’re only simple if somebody has taken the time to tell you about them.

The following applies to a formal report, other formats may have different restrictions. Your company or organisation may have its own style guide and this should always take precedence over the following:

  • Tables and figures should be numbered and labelled. When referring to them specifically, they are proper nouns and should be capitalised, e.g. Table 1 shows some uninteresting statistics, while Figure 427 shows another bar chart. Use the caption option where you can for your chosen tool.
  • Ideally tables and figures should have their own lists at the beginning of the report, like a table of contents. These are generally easy to insert and generate automatically.
  • In a table, column and row headings are often treated as proper nouns and capitalised – consider the overall style of your document.

Colour is a whole series of posts in itself, but I use the following as rules of thumb:

  • If the company or organisation has a colour palette, use that for preference.
  • Be aware of colour vision deficiencies among your readers. Here’s some thoughts on that.
  • Less is usually more when it comes to colour in charts and definitely when it comes to colour in tables.


Writing is well a very difficult skill to master. I should know, I was so bad at it when I started grad school that I bought my Ph.D. supervisor a box of red pens for Christmas one year because he had used so much red ink on my work!

Luckily for me he has a great sense of humour. Even luckier for me, he spent a lot of time helping me develop this skill that has stood me in good stead my whole career.

You won’t be a great technical writer overnight – and that’s OK. But when you’re just starting out or are unsure, here’s what helped me get better.

  • Whenever I’m trying to draft something difficult, I start out with bullet points. It helps me structure an argument without getting lost in the writing part.
  • I started out writing in present tense wherever possible. I used to mix my tenses a lot and it made it hard to understand my work. Where it was sensible/possible, sticking to present tense gave me one less thing to manage. You could do the same for past tense if that works better for your context.
  • Sentences should be reasonably short. I had so many ideas when I was starting out. They’d expand into subclause on subclause then another one .. and before you knew it I had sentences 10 lines long. To this day, an essential part of my writing pattern is going back through my writing and shortening as many sentences as I can.
  • Paragraphs should also be reasonably short in general. Got a paragraph that goes for half a page? Time to break it up!
  • A first draft is your best aid to writing well. Let me also be clear: a first draft is also generally a steaming pile of… let’s call it ‘junk’. It’s a good way of helping your brain organise its ideas. If you’re stuck, write a terrible first draft and bin it. The next will be better!
  • After you’ve spent a lot of time on a document, you need to put it down in order to see the flaws. Take breaks, go work on something else and then come back to it. You’ll be mildly horrified at everything you find that’s bad. But nobody else saw those errors before you did – great!
  • Another technique to find errors or bad writing is to read the draft backwards: sentence by sentence. This is time consuming, but it helps me find the details that need fixing.

What to write in?

When writing technical material Rmarkdown rocks my world. I export to Word when working collaboratively with non-technical people and then build back into the Rmarkdown document. It’s not ideal, but it works.

There’s a whole bunch of reasons why we write – so choose the tool that’s going to work best for you, your team and go for it.

References and Citations

Definitely worth the time – both for your own knowledge and reference but also to build on the work of those you’re using. Remember to cite your packages too. I haven’t always done this in the past! But it’s important to acknowledge the open source contributors whose work we are using – it’s now part of my routine.

And we’re done

That’s a brief overview of some of the things that have helped me with writing for business. Good luck!