1. Scattered data breaks trust

When different systems hold different versions of the same record:

• people get emailed twice
• donors get thanked incorrectly
• staff lose confidence in reports
• supporters lose confidence in you

Trust is fragile. Scattered data puts pressure on every interaction.

2. Scattered data damages reporting

If your income is in one system, your event attendees in another, and your opt-outs in a third, your reporting becomes a guessing game.

Teams end up spending hours each month reconciling numbers manually — and still feeling unsure.

A messy data landscape leads to:

• inconsistent totals
• late reports
• confusing dashboards
• tension between teams (“but our numbers say…”)
• wasted time

3. Scattered data creates unnecessary risk

Data stored outside controlled systems is vulnerable:

• spreadsheets get emailed around
• permissions aren’t respected
• old versions linger for years
• personal devices store sensitive information
• opt-outs aren’t applied consistently
• there’s no clear audit trail

None of this is about intentional misuse. It’s about the reality of busy people without clear guidance.

4. Scattered data makes supporter journeys feel disjointed

When teams are working from different systems:

• donors receive messages that don’t reflect their latest actions
• volunteers aren’t recognised for attending events
• people receive appeals while in the middle of complaints
• service users receive irrelevant comms

A fragmented data ecosystem leads to a fragmented supporter experience.

5. Scattered data increases duplication and inconsistency

The more places your data lives, the more versions appear — each slightly different.

Example:
“Sarah O’Connor” in the CRM
“S O’Connor” in Mailchimp
“Sarah OConnor” in Eventbrite
“Sarah O.” in a volunteer spreadsheet

Which one is correct? No-one knows — and cleaning this up later becomes a huge drain.

6. Scattered data hides problems you didn’t know you had

• Outdated records
• Missing permissions
• Fields no longer used
• Duplicates across multiple systems
• Gaps in process
• Misaligned teams

When data is scattered, problems stay hidden until they become painful.

7. And finally… scattered data erodes confidence

People stop trusting the CRM.
They rely even more on spreadsheets.
Data becomes something to avoid rather than something to support good work.

This module is about reversing that.

1. Where data enters your organisation (the “front door”)

Most data doesn’t start in the CRM. It enters through a growing number of places:

• Website forms
• Donation platforms
• Event registrations
• Advocacy actions
• Volunteer sign-ups
• Service-user referrals
• HR recruitment systems
• Email platform sign-ups
• Surveys and feedback tools
• Handwritten forms at events
• Direct emails from supporters

Each entry point touches a different team — Fundraising, Comms, Services, Volunteering, HR — and each team may have slightly different ways of capturing, storing and cleaning that information.

That’s normal. But without consistency, your CRM ends up playing catch-up.

2. How data flows through Fundraising

Fundraising is often the most obvious “data-heavy” area, but even within Fundraising, the journey isn’t linear.

Common flows include:

• A donor gives online → donation platform → CRM → Finance
• A donor signs up to an event → Eventbrite → CRM → email platform
• A donor opts out of email → email platform → CRM → selections
• A donor replies to a letter → paper form → scanning → manual entry → CRM

Each step introduces the possibility of delay, duplication or mismatch.

Fundraising relies on the CRM being accurate — but it also generates huge amounts of new data daily.

3. How data flows through Finance

Finance teams handle:

• coding income
• reconciling donations
• managing Gift Aid
• financial reports
• direct debit files
• supplier and partner payments

They often sit downstream from Fundraising data and upstream for Finance systems (e.g., Sage, Xero, Business Central).

Typical data journeys:

• CRM → Finance ledger
• Finance ledger → CRM for income corrections
• Gift Aid checks → CRM updates
• DD claim files → bank → CRM status updates

If Finance receives inconsistent or incomplete data, the whole organisation feels it.

4. How data flows through Services

Service-delivery teams often hold different types of data:

• client records
• case notes
• safeguarding information
• attendance registers
• assessments
• anonymised reporting
• consent for service delivery

Some of this must not enter the CRM.

Some should (e.g., “this supporter is also a beneficiary”).

Typical journeys:

• Referral form → service system
• Consent captured → stored in service platform
• Aggregated insight → CRM tags or reporting
• Signposting or onward referral → back into CRM

Services data requires special care because it can involve sensitive, protected information.

But understanding that journey helps avoid duplicated effort and helps the organisation understand impact holistically.

5. How data flows through Volunteering

Volunteer programmes capture:

• applications
• skills and availability
• training logs
• DBS checks
• shift attendance
• wellbeing notes
• feedback

Typical journeys:

• Volunteer form → volunteering system
• Volunteer contact info → CRM
• Training logs → internal systems
• Recognition journeys → CRM → fundraising/comms

Volunteers are often also supporters — and sometimes donors — so syncing records between volunteering platforms and CRM is essential to avoid duplicate identities.

6. How data flows through HR

HR holds:

• staff records
• emergency contacts
• compliance training
• onboarding/offboarding status
• internal wellbeing and performance data

Most HR data should never enter the CRM.
However:

• Staff sometimes appear as donors
• Staff can be volunteers
• Staff often help steward events
• Staff sometimes make tribute gifts or payroll donations

Understanding where identities overlap helps prevent duplication and confusion.

7. The “data journey” inside the organisation

A simplified charity data journey often looks like:

1. Capture

Supporter completes a form, donates, signs up, volunteers, fills in a survey, contacts your team — or a service user is referred.

2. Transfer

Data moves into a platform (CRM, email tool, service system, event system, finance system).

3. Transformation

It is cleaned, coded, merged or restructured:

• titles corrected
• postcodes validated
• duplicates merged
• preferences mapped
• finance codes added
• event tags applied

4. Storage

Ideally: CRM = supporter record of truth
Reality: multiple systems, spreadsheets, inboxes, and legacy tools.

5. Use

Teams access data for:

• selections
• journeys
• reporting
• financial reconciliation
• safeguarding
• casework
• volunteering coordination

6. Return

Updates flow back upstream:

• opt-outs to CRM
• address changes from Finance
• service-engagement summaries
• volunteer engagement hours
• corrected details from staff

Every stage is an opportunity either for clarity… or confusion.

8. Where things commonly go wrong

And why this module matters.

• Event systems don’t push data back into the CRM
• Email platforms become “shadow CRMs”
• Service user data is partially imported when it shouldn’t be
• Finance and Fundraising use different coding schemes
• Volunteer and donor records don’t match
• Staff save spreadsheets locally
• Teams use multiple forms that map differently
• Opt-outs aren’t synced
• Data enters the organisation faster than it’s maintained

These aren’t failures — they’re symptoms of busy teams without a shared picture.

This module gives you that picture.

9. The goal: One version of the truth

Not one system for everything.

But one system where:

• supporter contact details live
• permissions live
• donation history lives
• communication history lives
• supporter journey “meaning” lives

And every other system feeds into that calmly.

Your CRM is not the only data system you use — but it must be the one that ties everything together.

Step 1 — Choose one journey to map

Pick one common flow, such as:

• an online donation
• an event registration
• a newsletter sign-up
• a volunteer application
• a service-user referral
• a grant enquiry
• a complaint or feedback loop

Starting small builds confidence.

Step 2 — Draw six simple boxes

Label them:

1. Capture (where the data first appears)
2. Transfer (how it moves to other systems)
3. Transformation (who cleans, codes, merges or updates it)
4. Storage (where it lives day-to-day)
5. Use (who uses it, and for what)
6. Return (where updates flow back)

This structure works for virtually any charity process.

Step 3 — Fill in the details honestly

Under each heading, answer these questions:

Capture

• What form or system is used?
• What fields are collected?
• Do we validate any of the information?
• Does every team use the same form?

Transfer

• Is the movement automatic, manual, or occasional?
• Who is responsible for it?
• Is anything lost or changed?

Transformation

• Who checks for duplicates?
• Who corrects data or applies coding?
• Are any spreadsheets involved here?

Storage

• Where does this information live permanently?
• Are there other copies elsewhere?
• Is this actually the single source of truth?

Use

• Who needs this information?
• How often do they use it?
• Does it cause delays or frustration?

Return

• How do updates get fed back?
• Are consent changes synced?
• Is Finance aligned with Fundraising?
• Are volunteers/service users linked correctly?

Step 4 — Highlight the messy bits

Use highlighters or quick notes to indicate:

• where duplicates appear
• where spreadsheets sneak in
• where data is entered twice
• where updates don’t flow back
• where delays cause problems
• where “shadow systems” replace the CRM

This visual makes issues less personal and more practical.

Step 5 — Turn your map into three improvements

Don’t redesign everything.

Pick just three small improvements, such as:

• “Sync event registrations daily, not monthly.”
• “Add postcode validation to the web form.”
• “Train volunteers on duplicate checking.”
• “Remove old spreadsheets from the shared drive.”
• “Align coding between CRM and Finance.”

Small wins → calmer systems → better data.