Declining membership numbers

De Consumentenbond (a Dutch consumer advocacy organization) used the same membership model for years. This membership consisted of 2 membership variants:

• Consumentenbond Basic – full access to the website
• Consumentenbond Extra – full access to the website plus the paper magazine ‘Consumentengids’

This membership model was OK, but had some drawbacks:

• It wasn’t possible to offer different price points
• It wasn’t possible to serve groups with a need in one particular area
• The organization offered a wide variety of services, but you always needed to buy the all-in-one package

As a result, the memberships were declining year on year since 2005. The chart below is based on data from Consumentenbond annual reports.

Back in 2006, Consumentenbond started a strategic push to offer more services (comparing energy contracts, comparing health insurance contracts, comparing mobile phone contracts, comparing mortgages). This allowed Consumentenbond to diversify its revenue streams and grow its income between 2006 and 2016. From 2017 onwards, the revenues of the Consumentenbond started to decline. They were not able to compensate lost revenues due to declining memberships anymore by adding more and more services. Something had to change.

Towards a modular membership model

Consumentenbond was ready to change in a big way. No longer would it offer a one-size-fits-all membership model. Instead the organization wanted to take a modular approach. This would allow the organization to offer value to its members in the areas that they wanted to use and wanted to pay for. And this allowed the organization to give their members the ability to change their membership just as easy as it is to adjust your Netflix membership.

In February 2019, a team of business stakeholders started working on the design of the new membership model, aided by a well known pricing consultancy bureau. This bureau investigated how our organization was perceived in the market and how our future membership model would be received by our current and future customers. In June 2019 the concept of the new membership model was shared within the organization. The new model was based on a modular system with 4 new membership variants.

A new Architecture was needed

In July 2019 a team of IT stakeholders started to design the revamped architecture for this new membership model. As an Architect, I worked together with the Business Analyst, our ERP expert and our Agile development team. We wanted to design the Architecture as a collaborative effort. There were 3 areas that were heavily impacted:

• Providing access to online services
• Selling/changing/cancelling membership contracts online
• Selling/changing/cancelling membership contracts via our customer service

After a careful review of our current ERP implementation, middleware services and CMS capabilities, it became clear that our current IT environment couldn’t handle the job. Our CMS was able to handle only 2 access levels (public access / restricted access) and had no Role Based Access Control that we could use. It was connected to our ERP system by a legacy back-end service that was not based on Enterprise Integration Patterns Best Practices. And we were struggling with an old way of creating sales documents in the ERP system that worked fine within the ERP system, but caused problems for the CMS and CRM systems. We soon realised that this involved changing almost everything:

• A new authorization mechanism in the CMS
• A new IAM service for authentication and authorization
• A new Selling service that could be accessed by both the CMS and our CRM system
• A new product structure in the ERP system
• Changes to the CRM system to work with the new product structure
• Changes to the Data Warehouse to work with the new product structure

We decided that we wanted to use the contracts in our ERP system as the basis for determining who has access to online services. This meant connecting the CMS to the IAM service to the ERP system.

Selling/changing/cancelling membership contracts is possible both online and offline. This required 3 data objects: a Relation, a Product and a Contract. This meant that the CMS needed to have information on both the product and the relation, before it can sell/change/cancel a contract. The same is true for the CRM system that is used by our customer service.

All contracts are eventually registered in the central ERP system. This system handles the monthly invoicing and the payment processing. Our Data Warehouse is connected to both our CRM and ERP systems to enable daily reporting.

In October 2019 we presented our Architecture in Draft and one month later we presented the 1.0 version. We used December to write the user stories, refine them and put them on the backlog. We were ready to start building in January 2020.

A changing scope

Then a lot of things started changing. Our business stakeholders had used the same time period (July-December 2019) to work out what they really needed from the new membership model. They started introducing new requirements:

1. The ability to offer free trial periods for all new membership variants
2. The ability for our partners to register new memberships
3. Single Sign-on integration for our complaints service ‘Klachtenkompas’

Change #1 required big changes to the business logic of the Selling service. Change #2 required us to build new API’s for our partners and connect these API’s to our internal services. Change #3 actually fitted in the new Architecture design and was just ‘more work’. This required our team of IT stakeholders to adjust the envisioned Architecture, while at the same time continuing to build the new systems. The changes didn’t stop there. In Q1 2020 our Finance department started to look into the Architecture and added 2 new requirements:

4. A combined invoice for the customer
5. Unbundling of the ‘Add-on’ (the paper magazine Consumentengids) so this would be a separate transaction in our ERP system

Finding a solution for Change #4 took several weeks, because we needed this to work for all groups of customers. Change #5 involved stakeholders from all disciplines to come together to discuss the consequences of changing the envisioned Architecture. This was a very intensive process of 4 weeks, in which we evaluated 5 very different solutions. In the end we chose a solution that was very close to our original Architecture and wouldn’t cause too much rework.

When comparing the scope of the original Project Start Architecture v1.0 (November 2019) and the scope of the changed Project Start Architecture v1.1 (June 2020), the scope of the program was expanded by an additional 50% of work.

A phased release

While the scope of the program expanded, the deadline for the project remained fixed. Which obviously didn’t work. So we focused on what was really essential. We decided to split the program in 3 phases:

1. Conversion of the current members to new membership variants. Plus the ability to order the new membership variants online. Plus the ability to offer free trial periods online. Plus the ability to cancel the new / migrated membership variants online. Plus the ability for our partners to register new memberships via APIs.
2. Introducing the ability to upgrade and downgrade memberships online. Plus unbundling of our ‘Add-on’.
3. Optimizations of our online flows. Plus optimizations of our APIs. Plus SSO integration for our complaints service ‘Klachtenkompas’.

This enabled us to release phase 1 very close to the original deadline (which was set 1 year in advance). And it allowed us to release the full scope of the program in a gradual manner. We took a different approach for each phase. The features from phase 1 will be combined in a ‘big bang’ release. The features from phase 2 will be released using a ‘feature toggle’. This allows us to go back to our regular release process, but hold back on the actual go-live of these features. So we can go-live when we are 100% sure that everything checks out. The features from phase 3 will be released via the regular release process and will go-live after each sprint.

The phase 1 go-live

The week before the go-live, we had to freeze our ERP system. This meant that all systems that send information to our ERP system, including systems of our partners needed to be put in read-only mode. And it also meant that we stopped all our advertising campaigns on the web and on social media.

In the week before the go-live, we actually already put things in production. Most of this wasn’t visible to our customers. We migrated every contract from the old membership model to the new membership model in our ERP system. We deployed our changed CMS code into production. However we didn’t move the code changes from the CMS staging area to the CMS production area. We prepared all content related to the new membership model in our CMS staging area. We deployed the new API’s for our partners to production. We changed the marketing campaigns in our CRM system. And we put the new Data Warehouse reports into production. We had prepared the project well and at the end of the week we were ready for the go-live on Monday.

On Monday 10 August 2020, the new membership model of Consumentenbond was released to the general public. We had one trick upon our sleeves: production testing. Our test coordinator had prepared some essential production tests, that would allow us to check if the go-live was going as planned. We scheduled these production tests directly after the go-live. This allowed us to find remaining issues immediately, so that they could be tackled as soon as possible. At the end of the day, we had tackled all major issues.

After this go-live, we were not done yet. We now had to synchronize all changed contracts from our ERP system to our CRM and Data Warehouse systems. This was the only thing that took longer than expected. We needed to send the upload to the CRM system twice (this took 4 days in total) and it took our ERP system 10 days to create the upload to our Data Warehouse.

The phase 2 go-live

In the weeks before the go-live we were testing the upgrade and downgrade functionalities heavily. We have encountered some strange test results, but most were related to testing data (which was manually entered into our ERP system). The code that we have put into production did stand the test. Of course we did find and fix some issues. The biggest issues were related to our CRM e-mail messages that needed some fine-tuning.

A couple of days before the go-live we updated the relevant content in our CMS. And on Monday 23 November 2020 we switched the toggles. Like the phase 1 go-live, our test coordinator had prepared some essential production tests. And again, this helped us find and fix some remaining issues and inconsistencies.

In conclusion

I am very grateful to have been part of this big achievement for Consumentenbond. This project was a true team effort. There were so many people in the organization involved!

We have provided Consumentenbond with a new membership model. And this new model has already exceeded our expectations in terms of new memberships in the last few months. Many challenges remain, but we will surely tackle the optimization of this new membership model in 2021.

I also find it very gratifying that we have managed to go-live twice, without needing to roll-back the technology. I think that is the true proof of technology that works invisible, to improve our customers lives.

Published: 4 September 2020
Updated: 27 November 2020