In a previous role, the monthly performance report used to take about two days to put together. Most of that time went into pulling the latest data, updating the Excel workbooks, checking that the numbers reconciled and fixing whatever had broken since the previous month. The part that actually mattered, working out what had changed and why, got whatever time was left at the end. I replaced the process with automated Power BI dashboards, which saved around 14 hours a month, but the more useful change was how much less there was to look after.
The manual report worked, which made it easy to ignore
Nothing about the old process was dramatically broken. The report went out every month, the numbers were broadly right and people knew where to find what they needed. The cost was mostly hidden inside the person producing it: two days of repeating the same steps, in the same order, with the same checks, before any analysis could start.
Manual reports also get heavier over time. Someone asks for an extra cut of the data, a new tab gets added, a product moves in the hierarchy and a formula needs adjusting. Each change is small on its own, but together they turn the report into something that only works if the person who built it remembers every quirk. When the workbook breaks, the fix usually lives in someone's head rather than anywhere documented.
Automating the parts that never changed
The first step was separating the work that genuinely needed a person from the work that simply had to be done every month. Pulling data, cleaning it into a consistent shape, calculating the standard measures and laying them out the same way each time followed the same pattern month after month. I moved those steps into Power BI, where the data model refreshed rather than being rebuilt and each calculation was defined once instead of copied between workbooks.
Defining the measures in one place mattered more than it sounds. In the spreadsheet version, the same metric could quietly drift between tabs or files after someone tweaked a formula for a one-off request. With a single model, everyone was looking at the same definition, and a change only had to be made once. Plenty of reporting arguments turn out to be definition problems rather than data problems, which is why I tend to check definitions before anything else.
Less maintenance was the bigger win
The 14 hours a month is the number that fits neatly on a resume, but reduced maintenance is what made the change last. One model is much easier to look after than a collection of workbooks that each need updating, checking and occasionally rescuing. When something in the source data changed, the fix happened in one place and flowed through to every page, rather than being repeated across every file that used it.
It also made the reporting less dependent on one person. A manual process tends to belong to whoever runs it, which becomes a problem the month they are on leave or busy with something more urgent. Once the report refreshed on its own, the monthly routine shifted from producing the numbers to checking that they looked sensible.
The time went back into commentary
Taking the manual work out did not mean the report needed no human input. The time saved went into regular performance commentary explaining what had moved, what was driving it and what was worth paying attention to. Previously, that kind of interpretation was squeezed in after two days of assembly, if it happened at all. With the assembly automated, the analysis could become the main part of the job rather than the leftover part.
Self-service only works when people trust the numbers
The dashboards gave Sales, Marketing and Demand Planning direct access, so they no longer had to wait for the monthly report or send a request every time they wanted a different view. Self-service sounds simple, but it only works if people believe what they are looking at. If the dashboard disagrees with the spreadsheet someone has relied on for years, the dashboard usually loses unless someone can explain the difference.
So I treated adoption and trust as part of the product rather than something to sort out after launch. A technically correct dashboard that nobody uses is worth about as much as no dashboard, and old spreadsheets have a habit of quietly coming back when people are unsure. Being able to explain where each number came from, and why it might differ from a figure someone remembered, did more for adoption than any visual polish.
What I look for in a manual report now
If a report gets rebuilt the same way every month, with the same steps and the same checks, it is usually a good candidate for automation. The goal is not to automate for its own sake, but to remove the work that adds no judgement so there is more time for the work that does. Before rebuilding anything, I would also ask what the report is meant to help someone decide, because automating a report nobody uses just produces the same unused report faster.
Two days a month does not sound like much until you add it up across a year, along with the fixes, the version confusion and the reliance on one person. Getting that time back was useful, but the real change was turning reporting from something that had to be maintained by hand into something that mostly looked after itself, with the freed-up time going into explaining what the numbers meant.