Before you automate a charity report, trace the whole process.

A charity should start reporting automation with one recurring report. Trace where its information comes from, who checks it, where it waits, what happens when something is wrong and how much work it takes today. That gives the team enough evidence to choose a useful first change without committing to a large system replacement.

Start with the last report, not the software

A finished funder, impact or trustee report may look like one document. Producing it can involve exports from several systems, spreadsheets maintained by different teams, narrative updates sent by email and figures that someone has to reconcile by hand.

When the process becomes difficult, the first response is often another template, another spreadsheet, more reminders or a new dashboard. Some of those changes help. Some move the work to a different place. The earlier attempts are useful because they show what the team can maintain and which parts of the problem have resisted a quick fix.

Pick one report your team has already produced and follow it from beginning to end.

You do not need a perfect process map. Ask the people who prepared the last report to walk through what they did, including the workarounds and corrections that never appear in the final document.

Five questions to ask before building anything

1. Where does the information come from?

List every source used in the report. This may include a CRM export, finance data, programme records, survey results, case notes or updates from delivery teams. Record who owns each source and how the information reaches the person preparing the report.

2. Which checks catch mistakes?

Ask how the team spots missing entries, duplicated records, incorrect project codes and totals that do not match. A useful workflow needs to preserve these checks or make them clearer. Moving data faster does not make unreliable data accurate.

3. Where are the hand-offs?

Look at the spaces between systems and people. Who exports service data? Who confirms finance figures? Who supplies narrative updates? Who approves the final version? Delays often sit in these hand-offs rather than inside one system.

4. What happens when something fails?

Find the exceptions. A project code may be missing, two teams may define an outcome differently, or a late correction may arrive after review has started. The workflow needs a visible way to handle these cases. Otherwise the team will return to email and private spreadsheets when the first exception appears.

5. How will you know whether the change helped?

Record the preparation time, repeated steps, corrections, late submissions and versions circulated for the last report. Choose the measures that matter to the people doing the work. Those figures become the baseline for any pilot.

• Source systems and file owners
• Manual copying, reconciliation and reformatting
• Checks, approvals and decision owners
• Common exceptions and recovery steps
• Preparation time and corrections before sign-off

What the answers tell you

The walkthrough may uncover an automation opportunity. It may also show unclear ownership, inconsistent definitions or source data that needs attention first. Each result gives the team a concrete next step.

A repeated export and reconciliation step may suit a controlled data flow. Missing contributions may need a clearer submission process and reminders. Conflicting definitions require a decision from the report owner before a tool can apply them consistently.

This is why a narrow investigation is useful. It separates the work a tool can handle from the judgement the team needs to keep.

Where Microsoft Power Platform may fit

Power Automate can collect information, move approved data and route review tasks. Power Apps or SharePoint can provide a structured place for updates. Power Query and Power BI may help prepare or present agreed reporting data. The right combination depends on the charity's existing systems, licences, access requirements and the report itself.

Microsoft's own adoption guidance recommends defining the intended business value and measures before expanding Power Platform use. It also explains that organisations may begin with capabilities included in Microsoft 365 and later need a more deliberate environment and governance approach as usage grows. See Microsoft's Power Platform adoption strategy guidance and environment strategy guidance.

Existing licences do not guarantee that every proposed workflow is covered. Connectors, data storage, users, environments and reporting tools can change the licensing requirement. Check this during scoping rather than after the build.

Compare the same report before and after

Use the same report scope for the comparison. Time how long the current version takes, note the manual steps and record how many corrections are needed. Then run the agreed workflow with the people who will operate it.

The pilot has helped if the team can produce and review the report more reliably, with a measurable reduction in the work you agreed to target. The team should also know who owns the workflow, how to handle exceptions and what to do when a source changes.

This guide describes UnflakeOps' working method for a proposed pilot. It is not a claim about completed UnflakeOps client results. Scope, feasibility, licences and success measures are agreed for the charity's actual report and systems.