A Practical Whitepaper for UK Charities & Not-for-Profits
Implementing a New CRM
Without the Usual Regrets
Most charity CRM projects don’t fail on the technology. They fail on the data, the people, and the leadership around it. This guide sets out the seven phases, the pitfalls that derail each one, and the hard-won lessons that make the difference.
Read the free guide ↓Whitepaper
Implementing a New CRM
Without the Usual Regrets
Seven phases · 12 hard-won lessons · 4 practical templates
What’s inside
The seven phases of a CRM implementation
A clear, sector-specific route from “should we even do this?” to a system your teams actually use.
Decide
Should you really do this — and how to own the benefits top-down.
Define
Requirements, not wish-lists, and who owns the process.
Select
Choosing a partner who navigates, not a supplier who sells and leaves.
Prepare
Data, people and governance — where projects are quietly won.
Build
Waterfall the foundation; be agile on top. Go live as an MVP.
Migrate
The hot/cold storage reframe that unlocks a stuck migration.
Embed
Adoption through executive ownership and trusted evangelists.
A taste of the hard-won lessons
Three ideas you can use today
Hot vs cold storage
Don’t fight teams over deleting data. Migrate only actively-engaged records into the CRM (hot), and move everything else to a data lake (cold) — still held, still available. Nobody loses their data; the CRM stays fast and clean.
Make directors the sponsors, not their teams
Consensus produces a fog of local wish-lists. Put each Executive Director on the hook for the benefits in their portfolio, and orchestrate the experts through them. Decisions get strategic fast.
Waterfall the foundation, be agile on top
A CRM is a foundational data capability, not a feature backlog. Get the data model, migration and integrations right up front with rigour — then iterate on everything you build above it.
Read the full guide
Enter your email and the complete guide unlocks on this page immediately — all seven phases, twelve lessons and four templates. No PDF to wait for, nothing to download.
Unlocked — the full guide is below.
Start reading ↓Before you begin
Why charity CRM projects go wrong
In fifteen years of these programmes, I have almost never seen one fail because the software couldn’t do the job. They fail on data nobody owns, decisions nobody makes, and adoption nobody drives.
A CRM is not a piece of software you install. It is a change to how your organisation understands the people it exists to serve — and that change is organisational long before it is technical. The sector-specific difficulty is that charities carry decades of accumulated data across fundraising, membership, services, campaigns and volunteering, held by teams with genuinely different needs and no single owner.
What follows is the route I use. Seven phases, and the specific pitfall that derails each one.
Phase 1
Decide — should you really do this?
The most valuable thing this phase can produce is a decision not to proceed yet. A CRM replacement is one of the largest changes a mid-sized charity will undertake, and doing it for the wrong reason is expensive in a way that is difficult to reverse.
Bad reasons to replace your CRM
- The current system is unpopular, but nobody can articulate what it fails to do
- A new director arrived and this was on their previous organisation’s roadmap
- The supplier is discontinuing support, and the migration deadline is driving the strategy
- Data quality is poor — a new system will not fix data nobody maintains
Good reasons
- A specific, named business outcome that the current system structurally prevents
- Fragmentation that demonstrably costs money — duplicate processing, missed Gift Aid, gone-aways
- A regulatory or compliance requirement you cannot meet as things stand
- Growth that the current architecture genuinely cannot absorb
Lesson 1 — Write down the benefit before you write the requirements
If you cannot express the benefit as a number with a name attached to it, you do not yet have a business case — you have a wish. “Increase Gift Aid income by 15% by removing duplicate records, owned by the Director of Fundraising” is a business case. “Improve our data” is not.
Lesson 2 — Make directors the sponsors, not their teams
Consensus across teams produces a fog of local wish-lists, each individually reasonable and collectively unaffordable. Put each Executive Director personally on the hook for the benefits in their portfolio, and orchestrate the subject-matter experts through them. Decisions get strategic quickly, and the trade-offs get made by people who can actually make them.
Phase 2
Define — requirements, not wish-lists
The classic failure here is a requirements document assembled by asking every team what they want. You will receive four hundred requirements, all marked essential, and no basis on which to choose between them.
Define instead by process. Walk the journey a supporter, member or beneficiary actually takes through your organisation, and describe what has to happen at each step. Requirements that do not attach to a real process are usually preferences.
Template 1 — The process ownership grid
List your core processes down the left, then complete the three columns for each one. If you cannot fill a cell, that is your next conversation — not a requirement. The processes below are a starting point; yours will differ.
| Process | Owner (named person) | What good looks like | How we’ll measure it |
|---|---|---|---|
| Donation to receipt | |||
| New supporter onboarding | |||
| Gift Aid declaration & claim | |||
| Service referral to outcome | |||
| Volunteer recruitment to placement | |||
| Consent capture & withdrawal |
Lesson 3 — A requirement without an owner is a preference
Before a requirement enters the specification, someone must be willing to have their name against it and be accountable for the benefit it delivers. This single discipline typically removes somewhere between a third and half of a requirements list, and the removed items are almost never missed.
Lesson 4 — Separate “must work on day one” from “must exist eventually”
Most requirements lists conflate the two, which inflates scope and delays go-live by months. Anything that is not needed to operate on day one belongs in a post-launch backlog. You will discover that some of it was never needed at all.
Phase 3
Select — a navigator, not a salesperson
You are choosing two things, and most organisations only evaluate one. The platform matters less than the implementation partner, because a competent partner will make a mediocre platform work and a poor partner will make an excellent one fail.
Questions that reveal more than a demo
- “Tell me about an implementation of yours that went badly, and what you changed afterwards.” A partner with no failures either has no experience or no candour.
- “Which of our requirements would you push back on?” Anyone who says none is selling.
- “Who specifically will be on our project, and what else are they working on?” The team in the pitch is frequently not the team that arrives.
- “What happens to your involvement after go-live?” Adoption is where value is realised, and it happens after most contracts end.
- “How many charities of our size and shape have you done this for?” Sector experience matters here more than in commercial implementations, because the data model is genuinely different.
Lesson 5 — Reference calls, not reference sites
Ask to speak to a client whose project was difficult, not the showcase one. Ask them what they would do differently and where the partner pushed back. A partner who will not facilitate that conversation has told you something important.
Phase 4
Prepare — where projects are quietly won
This is the least visible phase and the one that decides the outcome. Preparation means data, people and governance — and it is where budget and patience are usually thinnest, because nothing appears to be happening.
Template 2 — Data readiness assessment
Score each dimension one to five before you build anything. Anything scoring two or below needs work first, not migration.
| Dimension | Question to answer honestly | Score 1–5 |
|---|---|---|
| Completeness | What proportion of records have the fields we actually need? | |
| Accuracy | When did we last verify addresses against a gone-away file? | |
| Duplication | Do we know our duplicate rate, or are we guessing? | |
| Consent | Can we evidence lawful basis for every marketing contact? | |
| Ownership | Is there a named person accountable for each data domain? | |
| Retention | Do we have a retention policy, and is it actually enforced? |
Lesson 6 — Fix consent and retention before migration, not after
Migrating records you have no lawful basis to hold simply moves a compliance problem into a shiny new system, where it is more visible and no less unlawful. A retention policy that is written but not enforced is worse than none, because it evidences that you knew.
Lesson 7 — Appoint data owners by domain, not by team
Supporter data, service data and financial data each need one accountable owner across the whole organisation — not one per department. Departmental ownership is precisely how you arrive at four versions of the same person’s address.
Phase 5
Build — waterfall the foundation, be agile on top
There is a fashionable argument that everything should be agile. For a CRM, that argument is wrong in one specific respect: the data model, the migration design and the integrations are foundational. Iterating on a foundation means rebuilding everything above it each time.
Get the foundation right up front, with rigour and proper design review. Then be genuinely agile on everything built on top of it — screens, workflows, reports, automation.
Lesson 8 — Waterfall the foundation, be agile on top
A CRM is a foundational data capability, not a feature backlog. Get the data model, migration and integrations right up front — then iterate on everything you build above it. Teams who agile their way through a data model spend the following year paying for it.
Lesson 9 — Go live as a minimum viable product, deliberately
The temptation is to launch complete. Resist it. A smaller go-live that works builds the confidence and the goodwill you need for everything that follows; a large one that half-works spends both. Agree explicitly what is deferred, and publish that list so nobody feels ambushed.
Phase 6
Migrate — the reframe that unlocks a stuck migration
Migration stalls for a predictable reason: you ask teams what data can be deleted, and the answer is always none. Every record is somebody’s relationship, and no fundraiser will volunteer to lose a lapsed donor who might come back.
The argument is unwinnable because both sides are right. The CRM needs to be clean and fast; the teams genuinely do not want to lose anything. So stop having the argument.
Lesson 10 — Hot vs cold storage
Migrate only actively-engaged records into the CRM — the hot data. Move everything else to a data lake or archive: cold, still held, still retrievable, still reportable. Nobody loses their data, so nobody fights you. The CRM stays fast and clean, so it stays usable. Define “actively engaged” explicitly with the teams — a date range, an interaction type, a giving history — and let them own that definition.
This one reframe has unstuck more migrations for me than any technical intervention.
Template 3 — Hot / cold migration decision rules
Agree these rules with the data owners before migration begins, and have each one signed off by name. The rules below are a worked example to argue with, not a recommendation — your definition of “actively engaged” should come from the teams who own the relationships.
| Record type | Hot if… | Cold otherwise | Owner sign-off |
|---|---|---|---|
| Individual supporters | Interaction within last 36 months | Archive, retrievable on request | Dir. Fundraising |
| Members | Current or lapsed within 24 months | Archive | Dir. Membership |
| Service users | Open case, or closed within retention period | Per retention policy | Dir. Services |
| Volunteers | Active or available | Archive | Head of Volunteering |
| Corporate contacts | Live relationship or active pipeline | Archive | Dir. Partnerships |
Lesson 11 — Migrate in rehearsals, and count the failures
Run the full migration at least three times before the real one, and record the exact number of records that fail and why. If that number is not falling between rehearsals, you are not ready — and a go-live weekend is the worst possible time to discover it.
Phase 7
Embed — adoption is the only measure that matters
A CRM nobody uses is not a partial success. It is a total failure with a large invoice attached. Yet adoption is routinely the smallest line in the budget and the first thing cut when the build overruns.
Adoption is not training. Training tells people which button to press. Adoption changes what they believe about whether the system helps them — and that is won by trusted colleagues, not by a supplier’s trainer.
Template 4 — Adoption tracker
Set a target against each measure before go-live, then report them monthly to the same director who sponsored the benefit in Phase 1. Measures nobody reports on stop being measured.
| Measure | Why it matters | Target at 90 days |
|---|---|---|
| Active weekly users as % of licensed | The simplest truth about whether it’s used | |
| Records created in CRM vs outside it | Shadow spreadsheets are the warning sign | |
| Data quality score, tracked monthly | Proves the new discipline is holding | |
| Support tickets per user, trending | Should fall; if flat, training didn’t land | |
| The named benefit from Phase 1 | The only measure the board actually asked for |
Lesson 12 — Find your evangelists and give them status
In every organisation there are two or three people whose opinion others actually follow, and they are rarely the most senior. Identify them early, involve them in the build so they have genuine ownership, and give them visible status as the people to ask. Adoption travels through trusted colleagues far faster than through any communications plan.
In summary
The pattern behind all twelve lessons
Read them together and one theme runs through: almost every failure mode is a failure of ownership. Data nobody owns. Requirements nobody is accountable for. Benefits nobody has their name against. Adoption nobody is measured on.
The technology is the straightforward part. What determines whether your CRM programme succeeds is whether named people are accountable for named outcomes — and whether someone senior is willing to hold that line when the timeline gets tight.
If you are at the start of one of these, or in the middle of one that has stalled, I am happy to have a conversation about it with no expectation attached. Sometimes an hour with someone who has seen the pattern before is all that is needed.
No cost, no obligation
Talk it through with someone who has done it
I recovered and delivered a major charity CRM and data transformation, cutting technology incidents by 75% and lifting Gift Aid and membership income by 40%. If that sounds like the problem you have, get in touch.
You’re reading the summary
There are nine more lessons below this line
The full guide covers all seven phases in detail, twelve numbered lessons, and four templates you can use in your own project — including the hot/cold storage reframe that has unstuck more migrations than any technical fix I know.
- Why most charity CRM projects fail on ownership, not technology
- The four questions that reveal more about a partner than any demo
- A data readiness assessment to run before you migrate anything
- How to go live as an MVP without anyone feeling ambushed
- An adoption tracker your board will actually ask about
One email address. Unlocks instantly on this page. No PDF, no waiting, no sales call unless you ask for one.