NPO & Social Impact · Systems & Operational Improvement
The CRM was not unavailable — everyone was just working around it
Communications needed manual queueing, donations and debit-order receipts were captured by hand, complete giving histories were hard to follow, recurring and lapsed donors were not visible, and campaign and funder information sat in fragments. The platform existed and the licences were paid. The operating model did not.
- 7
- operating failures diagnosed
- 4
- solution routes assessed
- Live
- signed off and populated
- 45.3%
- annual licence-cost reduction
Proof context: A donor-funded non-profit organisation
Engagement type
This was a retained, chargeable professional-services mandate approved at executive level — not a contingency engagement funded from savings identified. KuTh was not the software vendor. The role was to represent the client-side outcome: define the problem, assess solution routes, evaluate providers, govern delivery and stay with it through adoption.
The situation
A CRM can fail without ever being unavailable
The more common failure is that users still build manual workarounds around it. The platform existed, licences were paid, support was in place and communications could be sent — yet core relationship work stayed manual.
- Outgoing communications. A material number of messages were not being viewed.
- Manual queueing. Every outbound batch required a custom manual queue, adding labour, inconsistency and the risk of omissions.
- Generic sender logic. Automated queues went out from a generic sender rather than the relevant regional person, detaching relationship ownership from the operating team.
- Manual donation and debit capture. Receipts had to be captured by hand rather than flowing from payment activity, delaying recognition, reporting and follow-up.
- No consolidated donor history. Duration, value and giving activity had to be tracked individually — a relationship database that does not show the lifecycle of the relationship.
- Weak categorisation. The system could not easily correlate a donor to the type or value of their donation, making segmentation and portfolio management difficult.
- Impersonal coding. Outbound email subject lines opened with a donor number.
What KuTh did
Four routes compared before any platform was chosen
Scroll table sideways →
| Route | Operating position | Assessment logic |
|---|---|---|
| A — Retain current environment | No resolution of the documented issues | Lowest disruption, but leaves the problem intact |
| B — Rebuild with current provider | Potential redesign on the same platform | Required paying the incumbent again for functionality not achieved the first time |
| C — New provider, same platform | Improvement through a different implementation partner | Less retraining, but still constrained by the same platform economics and architecture |
| D — New provider, alternative platform | Improvement plus broader functional redesign | Best opportunity to reset process, data, provider capability and functionality together |
The engagement did not begin from a predetermined platform answer. The selected route moved the client to a cloud CRM built around donor relationship management, rather than attempting another incremental repair of the incumbent arrangement.
The result
A configured system, and then a populated one
The primary result was a functioning donor relationship-management environment covering the full lifecycle: individual and organisational donor profiles, complete giving history, recurring and lapsed donor visibility, pledges, gifts in kind, campaign attribution, communication preferences, stewardship activity, tax receipts, reporting and dashboards, with controlled user access. The configuration comprised 70 custom fields, 15 workflows, 20 validation rules, 20 reports and 5 dashboards.
The implementation supplier’s scope excluded data migration, import and clean-up — and a configured CRM without usable data is not an operating result. The client signed the engagement off as complete on 2 July 2019; KuTh stayed involved through 18 July for export, cleaning, sorting and import, closing the gap between a configured system and one the organisation could actually use.
Additional commercial benefit
Licence governance, applied after the operating problem was solved
Scroll table sideways →
| Control | Before | After |
|---|---|---|
| Paid user licences | 32 | 17 retained after observed-use review |
| Users with no recorded login | — | 15 across the three-month review window |
| Annual licence cost index | 100 | 54.7 |
| Annual licence cost reduction | — | 45.3% |
The reduction is measured on annual licence cost, not seat count. Access was not removed simply because a user was inactive in one short window: a mature review asks whether the role still needs access, whether activity is seasonal, whether the person has left or changed role, and whether a lower-cost permission set would meet the need. Here the usage evidence was clear enough to support the reduction.
Current context
The compliance environment has tightened since 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.
Relationship-management systems also process personal information, and POPIA places security-safeguard obligations on responsible parties, with operator arrangements needing to address confidentiality, security measures and breach notification. In practical CRM design that makes user profiles, access levels, data minimisation, secure integrations, provider contracts and auditability governance requirements rather than optional technical refinements.
Evidence and publication boundary
Published as a completed, client-signed-off retained service. The operating result was the donor relationship-management environment; the 45.3% annual licence-cost reduction was a further benefit created by applying the same evidence-led discipline to actual platform usage, and is not the definition of the service.
Client identity, provider identities, licence rates and the underlying rand values are withheld. Engagement period March to July 2019.
Supporting documents