All roads lead to membership: DoR’s journey — Part 2 (Technology)

We’ve read a lot about starting from scratch with a membership model for a media organisation. Or starting up a new product within the wider organisation that has a membership model. But there haven’t been many examples we could find of organisations shifting an already hybrid business model to prioritise reader revenue, while also aligning our existing community initiatives with industry standards around engagement and membership. The ones we could find were from large organisations who could afford the resources and had the expertise for audience research, development, special projects and experimentation.

This article is the second in a series that runs through the transformative moments at DoR in 2019. While the philosophy of membership was present from the early days, when we didn’t know what to call it, and connecting with readers was done with more instinct than method, this year has been about identifying processes and improving our tools. Read the first part here. In this part, we’ll share some insights into the process of finding technical solutions to support our ambitions. All quotes are from interviews with DoR staff.

DoR entered 2019 with a fragmented set of tools it had been using for a few years to manage online sales of the magazine, subscriptions, billing and shipping: a separate shop where orders came in, a database that had to be kept up to date manually as the orders weren’t automatically added, a billing system where bills were created manually, and a shipping processes that involved a lot of hands-on packaging and delivery work.

In addition to this rather convoluted and time-consuming process, our tools were also not enabling growth.

Aside from a newsletter we sent out weekly to our community, there was no clear online connection between those who supported DoR and our online journalism. The DoR shop, the point of entry into the community, was on a separate subdomain, creating a type of digital wall between those who supported our journalism and our content.

Meanwhile, our community was growing, and with this growth came a higher workload for order processing and shipping. Our goal was to offer more options for readers who wish to support us beyond a traditional magazine subscription, where they would receive our four issues of DoR each year, a newsletter, and occasional perks. We wanted to strengthen the links between the newsroom and the community, and we knew that in order to do so, we had to invest in better systems to create ties online as well as offline.

We also wanted to grow our community, and the fragmented process made it difficult to gather insights on how our existing customers interacted with our products. What was the real conversion rate? Where were they coming from — our website, social media? We knew there were better ways of managing this process.

We had identified our pain points, but we did not have the know-how inside the newsroom to identify and implement the right solutions. We knew we needed development resources, which come with a particular set of challenges: finding the budget to contract developers to work together on the project, and finding people who would choose DoR from the many other potential contracts they would be able to find in a market where development skills are in high demand.

We were incredibly lucky that we were planning our digital overhaul at the time that The Engaged Journalism Accelerator at the European Journalism Centre was opening up applications for grants. We applied to be part of the programme with our plan for a technology upgrade in the newsroom, and our application was successful. The issue of “How are we going to pay for this” was solved.

How we were going to execute the plan was a different issue. It was a new process to everyone in the organization, from the big picture strategic thinking, to planning, to smaller processes such as finding collaborators for development.

Our plan was to build a team of two developers in order to identify and implement as much of our dream tech solutions before mid-fall 2019, when we would launch new online membership options on the 15th of November to celebrate the 10-year anniversary of DoR.

Research led us to REMP, a suite of tools built by Dennik N that powers their own online subscription success: a great CRM that would easily integrate with the editorial platform, so you could have subscriber insights in the same place as your readers could access online membership perks, such as following their favourite writers and receiving alerts when they publish new stories, or saving articles for later. REMP is open-source, which meant we could tailor it to our needs, and it wouldn’t break the budget in the long term. (Read more about Dennik N’s strategy and tools here.)

We consulted with an existing collaborator who previously built our website throughout the process to identify skills we needed in order to rebuild our tech infrastructure. We also brought him in at the interview stages to cover the more technical aspects of the conversation.

We knew we had to work with people who could also provide solutions and help us identify the risks and benefits of the tools we considered, and we were overall successful at that. After a couple months of reaching out to potential collaborators, we started working with Mihai Ciobanu, front-end developer, who got in touch with us after we wrote about our search for developers in our community newsletter. We also hoped we would find collaborators with strong back-end development skills, and we even met with agencies to explore the possibility of working in this formula. Eventually we settled on continuing our collaboration with the developer who had helped us identify the required skills in the first place.

For the first couple of months we focused on testing and identifying the work required in order to make REMP work in our case. We reached out to Dennik N, the developers of the suite of tools, who were immensely helpful at getting us unstuck. But it soon became clear that we couldn’t make it work in time for our proposed deadline, and we couldn’t identify when we would be done if we built the entire infrastructure we wanted. We didn’t have the development resources in house, nor the time. We knew we needed to build our own integrations — payment processing, automated billing, emailing, connecting to the shipping system etc — and they were a big unknown.

So we started looking for alternatives, and while we didn’t find another ideal tool that could do everything we needed and was open-source, we settled on using WooCommerce, an e-commerce solution for WordPress that had recently updated its subscriptions and membership options. It wasn’t free, but it wasn’t prohibitively expensive for us — our current set-up costs around €2.000 a year to run, but the costs may vary in the future depending on the functionality we require.

It was a huge learning curve for the team. Here’s how we did.

What didn’t work so well:

• Finding the balance between planning and communication, says Mihai. We didn’t spend enough time on planning and as we changed the technology we were implementing, we assumed some things were already done when they weren’t. We could have been more efficient and not underestimate things so much.
• Because the process was so new for everyone, we learned along the way how to organise, which meant we didn’t know the right questions to ask in order to evaluate our progress, says Cristian Lupșa, DoR editor. We didn’t know how to set benchmarks and ask questions about where we are, whether we are moving forward fast enough, etc. It’s easy to look back and say we could’ve got where we are now a lot faster.
• We didn’t have all the stakeholders involved in the process early enough. We figured it out along the way, but if the technology is supposed to solve issues regarding distribution, billing, and community management, those actively working in those fields should be present in meetings a lot earlier than when we brought them into the process.

What worked well:

• We answered the “should we have a paywall?” question with an elegant tech solution, says Mihai. We built a Community Page with several sections that are available exclusively for members, including behind the scenes content, playlists of audio versions of our stories and reading recommendations, while keeping our journalism available to all for free on the website.
• The process was “freestyle” and this enabled us to always ask for opinions and integrate new ideas, says Mihai. Other tech projects are much more rigid. We surveyed extensively and organised focus groups with our community members, as well as tested the tools inside the newsroom.
• The shop, the community page and our own editorial sections are on the same website and smoothly integrated with a cohesive design.

Three things we wished we knew when we started:

1. It’s unlikely that there is one tool that will solve all of your problems.
2. To be more mindful of the integrations with the payment processors, billing, shipping and other services. These are things you use every day, so even if there’s a plugin that seems to be working, test and test again.
3. Ask whether you are advancing fast enough, and make decisions based on that. If you’re using a new tool, check in with others who have already implemented it. How did that process go? Where were they successful, and where did they get stuck?

Ultimately, if you’re an organisation that’s starting from scratch, with no digital membership options, check out as many tech solutions as possible. It will help you identify your needs and make better decisions about what to prioritise, where to compromise and what the deal breakers are.