How a US-based philanthropic and investment organisation automated a month-long quarterly process and fixed a CRM that couldn't be trusted

Without merging two very different business units, without a major platform replacement, and without a lengthy discovery period before results appeared.

2 business units modernised in parallel · Quarterly portfolio cycle cut from 1+ month to automated · CRM deduplicated and restructured · Internal teams trained for self-sufficiency

The bridge. A US-based philanthropic and investment organisation had a non-profit arm that couldn’t trust its own contact data, and an investment arm spending more than a month every quarter producing the reports that should have taken days. Both problems had the same root cause: data and processes that had not kept pace with the organisation. By the end of the engagement, the non-profit team had a CRM it could rely on, and the investment team had a quarterly cycle it no longer had to manage by hand. That shift is the work.

The client is a US-based organisation that operates across two fundamentally different mandates. Its non-profit arm focuses on social impact work, managing relationships with a wide network of partners, grantees, and community organisations. Its investment arm manages a portfolio of for-profit companies, producing the performance reporting and board materials that leadership needs to make capital allocation decisions each quarter.

Both divisions had accumulated a different kind of data problem. The non-profit arm’s CRM was unreliable. The investment arm’s quarterly reporting process consumed far more time than any organisation could sustain as it grew.

SeidrLab worked across both divisions simultaneously, treating them as separate problems that happened to share a client.

---

How we cleaned and restructured the non-profit arm’s CRM

The CRM problem had been building quietly. Ongoing system changes had introduced inconsistencies: records that referred to the same person or organisation in different formats, duplicates that had accumulated across imports and updates, fields used inconsistently across the team. The result was a database that was difficult to trust for outreach, reporting, or relationship management. The team had learned to work around it rather than through it.

We conducted a full data clean and restructure, working through the record set systematically. Deduplication was not a simple merge operation: many duplicate and near-duplicate records required matching logic that could identify the same entity across different spellings, address formats, and record histories without collapsing records that were genuinely distinct. We developed record-matching algorithms designed for long-term sustainability, not just a one-time clean.

The framework was built to maintain integrity as the database continued to grow. Internal processes were updated to prevent the same problems from recurring: data entry standards, import validation, and governance processes that addressed the root causes rather than just the symptoms. The goal was a CRM the team could trust without requiring ongoing remediation work.

Key takeaway. A database clean is not complete until the processes that caused the problem are addressed. Fixing the data without fixing the intake is a timed exercise: the same problems return.

---

How we automated the investment arm’s quarterly portfolio analysis

The quarterly portfolio analysis had become an organisational drag. Producing the reports that leadership needed each quarter required assembling performance data from multiple sources, applying risk analysis, and generating board-ready outputs. The process was taking more than a month each cycle, consuming analyst time and delaying the decisions the reports were meant to support.

We reviewed the existing workflow in detail: where data was coming from, what transformations were being applied, where the manual effort was concentrated, and what the output actually needed to contain to be useful for the leadership team. The review revealed that a significant portion of the time was spent on work that could be automated, and a smaller but meaningful portion was spent on judgment calls that required human input.

The rebuilt process separated those two categories. Machine learning models were introduced to handle the data assembly, initial risk modelling, and portfolio performance analysis that previously required manual work. Intelligent automation handled the report generation: pulling the current quarter’s data, applying the risk framework, and producing board-ready outputs in the format leadership needed. The steps that required human judgment remained human. Everything else ran automatically. A cycle that had previously stretched beyond a month came down to under a few weeks.

Key takeaway. The goal of automation is not to replace the analyst: it is to give the analyst the prepared inputs they need so their time goes to interpretation and decision-making rather than data assembly.

---

How we built for self-sufficiency

Both engagements included a deliberate investment in internal capability. The client’s teams needed to be able to maintain and extend the systems SeidrLab built, without requiring ongoing external support for routine operation.

For the non-profit arm, this meant documenting the data governance processes, training the team on the deduplication framework, and ensuring that the record-matching logic was understood well enough to be extended as the database grew. For the investment arm, it meant ensuring that the automated reporting pipeline was legible to the analysts who would work with its outputs, and that the risk model parameters could be adjusted by the team as the portfolio evolved.

Internal training was built into the engagement from the start, not added at the end. The continuity plans we developed addressed what would happen when team members changed, when new data sources needed to be incorporated, and when the reporting requirements shifted. The goal was an organisation that owned its systems.

Key takeaway. Continuity planning is not documentation: it is the work of making sure that the organisation’s operational capability does not depend on any single person or external partner knowing how the systems work.

---

What changed

Before. The non-profit arm was managing a CRM it could not fully trust: inconsistent records, duplicates, and data quality problems that made reliable outreach and reporting difficult. The investment arm was spending more than a month each quarter on a manual process to produce portfolio analysis and board materials, with analysts’ time consumed by data assembly rather than analysis. Both divisions were working around their data problems rather than solving them.

After. The non-profit arm had a clean, structured CRM with sustainable deduplication and record-matching logic in place. The framework meant the database would remain reliable as it continued to grow. The investment arm’s quarterly portfolio analysis ran automatically: data assembled, risk modelling applied, board-ready outputs generated without manual intervention. Leadership could focus on the analysis and decisions the reports were meant to support. Both divisions had trained internal teams capable of owning and maintaining the new systems independently.

---

Does this fit your situation?

If your CRM has become a source of uncertainty rather than confidence, or your quarterly reporting process is consuming more analyst time than the decisions it produces are worth: those are solvable problems, and they are often solved at the same time.

Book a discovery call →