Actually Data Analytics Limited

Somewhere in most charities, someone spends the first Monday of the month rebuilding the same report by hand. Export, paste, reconcile, format, send.

That report is the best brief you will find for a first Power BI dashboard. Everyone already agrees it matters, and someone can tell you exactly what it costs to produce. Decide up front what success looks like: the manual version switched off and those hours back.

We wrote recently on the ADA blog about getting started with Power BI:

How to Get Started with Power BI for Non‑Profits - Actually Data Analytics How to Get Started with Power BI for Non‑Profits Analytics

A charity we work with held off starting a Power BI build for four months, waiting for their data to be "ready". Duplicate records, a few gaps, inconsistent naming for the same campaign.

We started the build anyway. The first dashboard flagged the duplicates within a week, because now someone had a reason to go looking. Perfect data isn't a precondition for getting value from it, starting is often what shows you where the imperfections are.

We wrote recently on the ADA blog about putting imperfect data to work instead of waiting on it:

Unlocking the Power of Imperfect Data - Actually Data Analytics Unlocking the Power of Imperfect Data CRM

An income report that looks like it's dropped isn't always bad news. Sometimes it's just a missing field: a blank gift date pushing income into the wrong month, or a blank campaign source making a channel look quieter than it was.

Completeness, are the fields your reporting depends on actually filled in, is the first and most overlooked data quality check.

We wrote the fuller case, and six more checks worth running, on the ADA blog:

7 Essential Data Quality Checks for Reliable Reporting - Actually Data Analytics 7 Essential Data Quality Checks for Reliable Reporting CRM

Excel is genuinely good. Flexible, familiar, and everyone already knows how to use it.

It just was never built to be a database, and once an organisation's data grows past what one careful spreadsheet can hold together, the cracks start to show: different versions of the same file, inconsistent entries, GDPR rules getting harder to manage.

Excel still earns its place for testing ideas and quick fixes. It should not be running the day to day management of supporter data.

Full piece on the ADA blog:

Why Excel Isn’t a Database (But Why We Still Love It) - Actually Data Analytics Excel isn’t a database. It was never built to be one, and that’s where charities run into trouble.

Two questions for anyone looking after a charity database.

How recent is your last clean backup? And how long would a restore actually take?

Most of us can answer the first one roughly. Very few can answer the second, because it has never needed answering on an ordinary day. It is a much harder question to face when something has been failing quietly for three days.

A response plan is not a big project. It is a handful of decisions made in advance, while everyone is still calm.

Our five step incident response plan for database managers:

https://actuallydataanalytics.com/the-database-managers-incident-response-plan/

If it takes longer than it should, it's usually because EN data lives in several different places and someone has to stitch it together every month.

That's exactly the problem Engaging Networks Essentials is designed to fix. One view. No spreadsheet archaeology. Link in comments.

We've been doing a lot of work on web forms integration into . So I decided to write my thoughts about how good forms are a potentially under-utilised data capture tool. Read more here: https://substack.com/home/post/p-191060011

Further to the piece I wrote earlier today, If you’ve ever been involved in selecting a new CRM or reporting tool, what was harder: the technical comparison or getting internal agreement on what you actually needed?

I always say that CRM is actually made up of several different moving parts:
1. People
2. Data and Processes
3. Systems
4. Domain Knowledge

Systems and Processes are normally the easier part of the equation, but what have been your experiences? Have you included all of these different things or is it just about the data and the system?

Yesterday I wrote about how responsibility grows around charity data roles. A related pattern I see, particularly during procurement support, is the instinct to reach for a new system before clarifying the underlying need.

Sometimes a new CRM is absolutely the right move. I’ve helped a number of charities navigate that process. But without clarity about what “good” looks like, technology tends to amplify existing confusion rather than resolve it.

CRAFT isn’t a substitute for proper procurement or project support. It’s designed to strengthen the thinking that sits underneath those decisions, so that when you do invest in systems, you do so from a clearer position.

If you're looking for a guide on whether your organisation is ready for a CRM then this might help.

In the post this morning I mentioned how responsibility tends to expand quietly in data roles.

I’m interested in how that shows up for you. When new reporting requests arrive, does something else come off your plate or does everything just get absorbed? Is it discussed in your 1-1's or do you just juggle the requests?

No judgement. Just trying to understand the range of experiences.