Most leadership teams don't have an information problem. They have a compilation problem.
The numbers exist. They're in the finance system, the CRM, a few spreadsheets, a Teams channel and someone's inbox. Getting them into one place takes a person half a day, every week, and by the time the report lands the conversation has already moved on.
That's the operational cost worth looking at first, before anyone mentions technology.
Where the time actually goes
In most SMB organisations the reporting cycle looks something like this. A manager exports data on a Monday morning. Someone else reformats it. A third person chases the missing figures. The pack gets emailed round on Wednesday. Half the meeting is then spent agreeing whether the numbers are right.
The problems that follow are familiar:
- Decisions get made late, or on out of date figures
- Skilled people spend hours on copy and paste rather than analysis
- Every report looks slightly different depending on who built it
- Nobody has a clear view between reporting cycles
None of that is a technology failure. It's a process that grew up one workaround at a time. Business process automation is simply the work of removing the steps that shouldn't be there.
What Microsoft 365 already gives you
If you're paying for Microsoft 365, you're likely paying for more capability than you're using. Two parts matter here.
Power Automate handles the repeatable mechanics: pulling data on a schedule, moving files, formatting documents, posting notifications, updating a record. It's workflow automation for the steps a person shouldn't be doing by hand.
Microsoft Copilot helps with the part that needs judgement and language: summarising a set of figures, drafting commentary, pulling the themes out of a long thread. It works against the content your organisation already holds in Microsoft 365, within the permissions each person has.
Used together, they take a reporting process that depends on someone's Monday morning and turn it into something that runs whether that person is on holiday or not.
A practical example
Take a 90 person distribution business. Their monthly board pack pulled sales figures from Business Central, service performance from the helpdesk, and a commentary section written by the operations director.
Before, it took roughly a day and a half of combined effort and usually landed the evening before the meeting.
The rebuilt process works like this. A scheduled flow in Power Automate collects the source data on the first working day of the month and drops it into a single SharePoint workbook in a fixed format. A second flow generates the pack from a template and files it in the board's document library. The operations director opens the draft, uses Copilot to summarise variances against the previous quarter, then writes the commentary that actually needs a human view. A final flow posts the completed pack to the leadership Teams channel and logs the actions agreed at the meeting into a tracker.
The pack now arrives four working days earlier. The operations director spends her time on the commentary rather than the compilation. And because the format is fixed, month on month comparison is genuinely comparable.
That's the outcome to aim for: less manual work, faster executive reporting, better visibility between meetings, and more capacity from the team you already have.
Being clear about what this needs
There's a version of this story that makes it sound as though anyone can type a sentence into a chat window and set business processes running. That isn't how it works, and it isn't how you'd want it to work.
Triggering a flow from Copilot requires that flow to be built, tested and deliberately made available to the right people. Someone has to define what it does, what data it touches, what it's allowed to change, and who can run it. That's a configuration exercise, not a switch.
The same applies to accuracy. Copilot drafts well, but a summary going to a board still needs a person to check it. Automation should remove the typing, not the judgement.
Security and governance
Permissions and controls in these processes depend on how they're built. It's a reasonable design goal for an automated action to operate within the boundaries of the person who requested it, but that's an outcome of configuration rather than something you get by default.
A flow can be set to run under a service connection with broader access than the person triggering it. That's occasionally the right choice, and occasionally a serious problem. The difference is whether someone made the decision deliberately.
Before anything goes live, be clear on:
- Which account each flow runs as, and what that account can reach
- Who's permitted to trigger it, and how that list is maintained
- Which Data Loss Prevention policies apply to the connectors involved
- What the audit trail records, and who reviews it
- What happens when a flow fails, and who gets told
Microsoft 365 gives you the controls. Deciding how to apply them to your business is the part that needs doing properly.
Where to start
You don't need a transformation programme. Process optimisation works best in small, provable steps.
Pick the report that causes the most friction. Map how it's produced now, honestly, including the chasing. Identify the steps that are pure mechanics. Automate those first, leave the judgement with people, and check the output for a couple of cycles before moving on to the next one.
Then repeat. Most organisations find that three or four automated processes remove a surprising amount of the weekly grind.
Talk to us about how the work gets done
We help organisations work out which parts of their reporting and admin are worth automating, and which are better left alone. Sometimes the answer is a set of flows. Sometimes it's fixing the process before any technology gets involved. We'll tell you honestly which one you're looking at. You can read more about our approach to managed intelligence.
If your team is spending more time producing reports than acting on them, that's a good place to start a conversation.