I was recently privileged to work with a national environmental charity on a few separate projects, all of which were geared towards improving engagement of their activists, subscribers and donors. This was done through a virtuous circle of both improving how accurately existing engagement was measured, and then improving how these metrics could be acted upon to suit subscribers' own behaviours and preferences better.
Multiple separate projects, working to the same end
The different projects included (in order of decreasing complexity):
- Moving all subscriber mailouts to a major, third-party email provider, and drastically changing how subscriber activity was collated and then acted upon.
- Experimenting with new off-the-shelf campaign-action tools and prototyping an in-house tool.
- Moving all payment processing to Braintree, and changing how payments are passed to the CRM.
- Modifying their organization's major Drupal site, plus other applications, to accommodate the above changes.
Because these projects were separate, and had individual, separate goals, they could be managed almost entirely separately: although there was coordination between project owners and managers, each project's goal was moved towards independently. This led to a strongly agile project, which helped to permit pivoting and re-focussing of effort whenever necessary.
Separation also meant that each project could use the technology that was right for it, and this led to a slight mix of different applications, but overall coordination and good project communication avoided this becoming a menagerie: all technologies moved towards the state of well-documented maintainability.
Integrating with third-party email provision
The largest single technological integration was with an external provider of mailout and mailing-list technologies. This reoriented all communications from the charity to its supporters, to use the mailing platform.
From the perspective of charity staff, this was a great leap forwards: its web interfaces have great usability, and felt very robust. From the perspective of software development, integration with the APIs was more troublesome: documentation, especially for the newest version of the API, was patchy; functionality was substantially different between API versions, which caused problems as old versions were phased out; edge cases in the API were often buggy, and different calls to get different but equivalent information (e.g. sent timestamps versus clicked-on timestamps) would often return data differently. The data model's emphasis also meant that retrieving large quantities of activity data in bulk had performance issues.
However, all of these problems were ultimately surmounted through improved logic and data transformations in the CRM integration (see below.) One key change in the integration was moving to a strongly decoupled model, where jobs could be scheduled on the provider's servers, after which integration endpoints could detach and finish; later other, entirely separate and regularly-run endpoints would re-attach to pick up any scheduled jobs that had completed. While this didn't entirely solve the performance problems on the remote servers, it did serve to prevent the charity's in-house applications from being unduly affected by them.
CRM integration using lightweight proxies
CRM integration was effected using a large Slim application, which initially brought in a large amount of legacy logic and data storage, in order to tidy up and corral the old methods of integration. This was then rapidly developed into a much larger codebase.
However, as the code got larger, the integration between CRM and website, CRM and mail provider, and CRM and other applications, remained lightweight and separable. Small, independent proxy endpoints were provided for each different integration, and coupling between the CRM and application was therefore kept at a minimum.
A key result of this was that the website, for example, was able to "fire and forget" a request to record a donation having been made via the external provider: should there be any problems storing the record of the successful payment in the CRM, this was not made visible to the donor, who could remain confident that their payment had been recorded; meanwhile, automated alerts and other checks and balances would ensure that any problems were reported to a team who could handle the recording of the payment manually.
Custom and off-the-shelf campaign action platforms
Several off-the-shelf platforms exist, to support campaign actions: subscribing to a petition; writing to an MP or other government representative; protesting to the CEO of a large corporation; etc. However, for some time it wasn't clear which platform would both provide the kinds of actions that were essential to the charity, with sufficient functionality for e.g. looking up MP based on postcode, while also still permit comprehensive exporting of supporter activity into the CRM.
In this interim period, I was asked to develop a custom Campaign Action Tool or CAT. This would try to keep some future flexibility and extensibility, but focus strongly on the charity's needs, including complex email recipient rules. To ensure a close focus on the needs, I centred the project around domain-driven design, inviting domain experts—people who would administer the tool, knew how supporters tended to think and behave, and were closer to the domain of knowledge involved than to any technical knowledge—to contribute to a "ubiquitous vocabulary" of terms and meanings. This vocabulary would be used throughout the application code, not just the web interface; used, in fact, almost to the exclusion of any more technical jargon.
Domain-driven design ensured that CAT's programming would do "physically sensible" things: for example, a supporter would create a signature on a campaign action; signatures wouldn't be encouraged to "do their own thing", because it would make no sense within the domain, where supporters are the primary agents of change.
By the end of the project, CAT had been built using the Symfony framework, and had successfully run a number of campaign actions. At this point, the charity as a whole decided to shift focus to an off-the-shelf platform, keeping CAT available should bespoke prove more suitable to their needs.
The bottom line: huge increase in active subscribers
The moves to the new mail provider, to Braintree, and to CAT and an off-the-shelf campaign platform: each of these projects provided its own deliverable; technical debt was repaid far sooner than from a monolithic single project; technological needs were curated, aligned, and only proliferated where genuinely useful; and architecture. modelling and reporting substantially improved.
But the bottom line for the charity was: did the improved integration, tracking and measuring of activity improve their capacity to reach their supporters? The answer is, wholeheartedly; yes:
This graph is to scale, and while the total subscriber base remains confidential, it's worth mentioning that N is in six figures. What we see here is the switch on of the final, modified logic to accurately assess and report supporter activity, from which the supporter's "dormancy" is measured. Over some ten days, the different integrations were switched to use the new logic, and the changes were propagated through the system: from remote services, through the integration proxies, into the CRM; then nightly back from the CRM, through different proxies, into the remote services.
Once this nightly task had settled down, it was possible to re-measure the overall numbers of active and dormant supporters: the active supporter base had increased by 80%. While this might look like mere reclassification, it was this classification that was used, through nightly synchronization back up to the mailing lists, to define which supporters ought to receive communications. Without any change in how the charity itself classified an active supporter, some five to six figures of supporters were "rescued from obscurity" by the new system.
(By the way, if you've done your maths, you'll have spotted that the totals before and after aren't identical. This is because there are other criteria of supporter, not of interest here!)
Summary
If you use metrics to determine which of your available contacts will receive your communications, it's important to ensure those metrics are being correctly determined. It's also important that all of your communication tools are right for the job.
A major overhaul of such a large organization's communication methods was delivered using an agile, MVP approach, feature by feature. This provided incremental improvements throughout the time of the project, gradually satisfying milestone goals. Towards the end of the project, with most components in place, a soft launch of key integration changes led to an 80% increase in the measured and reachable active supporter base. This was a permanent and clear improvement, satisfying the overarching goal.
