Donor CRM & Relationship Management Systems Improvement · Technical White Paper
Donor CRM & Relationship Management — Technical White Paper
Problem diagnosis, expertise required, route assessment, solution design, migration control and delivery governance on a retained donor-CRM replacement.
Engagement type and publication boundary
A retained, chargeable professional-services mandate approved at executive level — not contingency work. KuTh was not the software vendor; the role was independent client-side problem definition and delivery governance.
Client identity, provider identities, licence rates and underlying rand values are withheld. Engagement period March to July 2019; the regulatory context below is current and did not apply at the time of delivery.
1. The problem
When a CRM exists but the operating model does not
A CRM can fail without being unavailable. The more common failure is that users still have to build manual workarounds around it. The platform existed, licences were being paid, support was in place and communications could be sent — yet core relationship-management activities remained manual or poorly connected.
If staff describe their CRM mainly in terms of exports, manual lists, spreadsheet corrections, duplicated capture, one-off workarounds and unexplained licence charges, the problem is not software configuration. It is a process-and-systems problem requiring an operating model, a data model, governance and an adoption response.
2. Expertise required
Several disciplines at once — because the client already had software
Scroll table sideways →
| Expertise area | Application in the engagement |
|---|---|
| Operational diagnosis | Translate seven operating failures into specific system and workflow requirements |
| Requirements and process design | Define how donor records, transactions, communications, approvals, campaigns and reporting should work |
| Provider and platform evaluation | Compare four strategic routes; interrogate competence, references, commercial terms and platform fit |
| Commercial modelling | Compare licence structures and identify reduced-rate or concession opportunities |
| Data architecture and migration | Define records, fields, relationships, validation rules, cleansing needs and import sequence |
| Workflow and automation | Replace manual steps with controlled workflows, approvals, recurring processes and standardised outputs |
| Testing and quality assurance | Support user acceptance testing, defect correction and go-live readiness |
| Training and adoption | Prepare users and internal champions so the configured solution becomes an operating system, not shelfware |
| Delivery governance | Keep supplier scope, milestones, dependencies and client decisions aligned |
A platform vendor is paid to configure its platform. The retained adviser is paid to ensure that the platform, provider, process, data and implementation actually solve the client’s problem.
6. Data migration
The work that determines whether go-live is real
The implementation supplier’s formal scope excluded migration, import and clean-up. A configured CRM without usable data is not an operating result, so KuTh remained involved after formal sign-off.
- Scope the data. Not every legacy field or historic record needs to move — a migration should begin with the future operating model.
- Clean and standardise. Names, emails, organisation records, transaction data and coding need consistent formats.
- De-duplicate. Duplicate contacts undermine relationship history, reporting and user trust.
- Preserve relationships. Donors, organisations, gifts, campaigns and transactions must remain connected after import.
- Test before production. Sample imports expose field mapping and validation issues before they affect the live environment.
- Reconcile after import. Counts, totals and key relationships should be compared back to the controlled source set.
7. Communications
A CRM communications problem is not automatically a CRM software problem
One of the original complaints was that a substantial portion of outbound messages appeared not to be viewed. The historic record linked this to the existing mail environment as well as to awkward queue creation and generic sender constraints.
Campaign automation and email deliverability are separate control layers. Workflow design can schedule a message, but domain authentication, sender reputation, list quality and unsubscribe handling determine whether it reaches the inbox. Current bulk-sender guidance from the major mailbox providers requires SPF and DKIM, and for higher-volume senders also DMARC, valid DNS, TLS, low spam rates and one-click unsubscribe where applicable. These sit outside the CRM record but belong in the diagnosis.
8. Donor relationship lifecycle
From contact database to fundraising operating system
The requirement was never merely to store donor names. The organisation needed relationship duration, giving history, donation value and type, recurring commitments, campaign interaction and the sequence of engagement over time. That is the difference between a contact database and a donor relationship-management system.
A donor-focused design distinguishes individual donors from organisational funders, preserves household and organisation relationships, records communication preferences and suppression rules, supports recurring-gift exceptions and failed-payment follow-up, attributes gifts to campaigns, and gives management a live view of retention, lapse, upgrade and pipeline activity. CRM design should therefore begin with the donor journey and stewardship model — how supporters are acquired, acknowledged, cultivated, retained, upgraded, re-engaged and reported on — rather than with the software menu.
The value of the CRM is the continuity of the relationship record: staff should not have to reconstruct a donor story from inboxes, spreadsheets and payment exports.
9. Licence governance
A bonus to the main result, not the definition of the service
The licence review examined three months of observed usage against the paid user base. Thirty-two user licences were being paid, and fifteen users showed no logins across the review period. Aligning the retained base to observed use reduced annual user-licence cost by 45.3%.
The principle is not to remove access simply because someone was inactive in one short window. A mature review asks whether the role still requires access, whether activity is seasonal, whether the user has left or changed role, and whether a lower-cost permission set or licence type would meet the need. Here the usage evidence was clear enough to support a material reduction.
11. Current operating context
More demanding now than in 2019
For organisations issuing Section 18A receipts, SARS requires IT3(d) third-party data submissions covering prescribed donor and donation information. From 1 March 2026 the mandatory set expanded to include the donor’s income-tax reference number and information relating to donations of property in kind. Structured donor records, controlled receipting and reliable data extraction matter more today than when this CRM was implemented.
Relationship-management systems process personal information, and POPIA places security-safeguard obligations on responsible parties; operator arrangements should address confidentiality, security measures and breach notification. In practical design terms, user profiles, access levels, data minimisation, secure integrations, provider contracts and auditability are governance requirements, not optional refinements.
12. What to test in your own environment
Before assuming you need new software
- Can staff describe what the CRM does for them, or only the workarounds they have built around it?
- Does one donor profile connect giving history, recurring gifts, gifts in kind, campaign attribution and stewardship activity?
- Are recurring and lapsed donors visible without someone assembling a list by hand?
- Is your outbound mail authenticated — SPF, DKIM, DMARC — before you conclude the CRM is at fault for low engagement?
- Does your paid licence base reflect observed usage, or the headcount at the time of purchase?
- Who owns migration, cleaning and import? If the implementation scope excludes it, go-live will not produce a usable system.
- Can you extract the donor and donation fields SARS now requires for IT3(d) submissions?