The project

Mautic needed a way to both allow newcomers to Mautic to spin up an instance and 'kick the tyres', while also developing a revenue stream to support the open source project's financial sustainability. The initiative we are considering here involved providing a free 14 day trial which could be converted into a paying subscription with a revenue share coming back to the open source community.

This would allow people an opportunity to 'try before you buy' without needing to set up your own server and configure everything properly - a common blocker to people getting started with Mautic or demonstrating it to their team who are often marketers rather than developers and may not have server management skills.

The plus side is that, if the trial customers do decide to become a paying customer, they can be confident in the knowledge that in doing so, they're also supporting the open source project's growth.

Writing the project brief

The first, and most important part of the process, was in writing a proposal.

This is what your potential partners are going to be reviewing to determine whether they are capable of providing the service you wish to commission, so it should ideally aim to answer as many questions as possible, and provide all the pertinent information upfront.

DIY or collaborative?

I mostly wrote the actual brief myself as the Project Lead because I was pretty clear what I wanted to see in a proposal and what the community needed.

You might want to form a working group or team to put it together more collaboratively - we did this after I'd written the first draft - just ensure you explain upfront what the process is about and make sure that nobody involved has the potential to influence or be a contributor to any companies who might tender a proposal.

I made it clear that if anyone in our small working group was approached to assist with a proposal they should declare that straight away and step out of the process - this made it easy for one person to do just that very early on in the process before proposals were received, when they were asked to advise on a specific area of expertise for a company who was intending to submit a proposal.

Even though the consulting requested of the team member mentioned earlier was in a very small way, it's important that the ethical integrity of your team is watertight, and it's important that you don't make it a big deal for someone to step out of the team if they have reason to do so.

Be clear what you're asking for (and giving)

Potential partners need to be able to assess the opportunity from many angles - technical competencies, professional experience, likely profit margins (don't underestimate the 'what's in it for me' angle) and so forth.

Ensure that you've done your research and can present the case clearly, explaining exactly what they will need to do if they were the successful provider. Also be clear if there are responsibilities which fall on your shoulders and how you plan to fulfil them.

In our case, we were up front that we expected a 14 day free trial during which time we (the open source community's marketing team and the provider) would work to convert those trial customers into a paying customer of the provider once the trial concludes.

We laid out from the start that we expected at least a 40% revenue share, and that once the trial customer converted, they became a customer of the provider. We deliberately left it open for them to propose how they would manage both the revenue share and the customer journey, because we wanted to see their thinking, cost estimations and creativity.

It' s also important that you're clear what publicity the provider can expect - will you do a joint press release? Are you going to list them on your website? If so, where? How long for? What will the listing say?

Outline key deliverables and metrics early

In Mautic's case we set specific parameters around the things that mattered to us upfront in the RFP brief - such as:

  • the time to spin up an instance,
  • duration of the trial,
  • minimum proposed revenue share.

We wanted to be clear about this from the outset, so that we could be sure that the provider would understand the areas that we felt were important to us.

In our case, however, we also acknowledged that the estimates we were making for the potential market size, the conversion funnel and so forth were best guesses, so it did not make sense to create hard-and-fast performance metrics off the bat.

We enabled providers to review our publicly shared Open Startup Reports and GSheet and make their own proposals. If you have very specific performance indicators then it's important to state them here, so the providers are clear what is expected.

Calling for proposals

Give a clear timeline

The timeline is important, because it reduces the number of contacts you will have asking for an update throughout the course of the RFP.

We found that a time-boxed period of a couple of weeks from the release of the RFP for people to submit questions was helpful, as it focused the minds of interested parties. We then provided answers within a few days of the closing date.

The only date we missed in our process was the final announcement and this was largely due to vacations and legal contract reviews meaning this stage ended up taking more time than anticipated!

Here's the timings we used:

  • Release RFP: Monday, June 19, 2023
  • Deadline for questions: Friday, June 30, 2023 (2 working weeks)
  • Responses to questions provided: Monday, July 3, 2023
  • Deadline for proposals: Friday, July 21, 2023 (3 working weeks from question responses)
  • Evaluation of proposals: Monday, July 24 - Friday, August 4, 2023 (2 working weeks)
  • Feedback provided to all bidders: Monday, August 7, 2023
  • Contract negotiation and award: Tuesday, August 8 - Friday, August 18, 2023

Offer a Q&A period with responses shared publicly

Make it clear from the outset that questions and their responses will be shared publicly (we used a Google Sheet for this purpose) and ensure that they are distributed to everyone who responded (we did this via a BCC email to everyone who had submitted a question). We kept these anonymised and where there was duplication we combined where possible into a single question with a response which covered all the questions.

Sharing it publicly means everyone learns from all the questions posed and the answers received (even if they come across the RFP after the deadline for questions has passed), everybody gets the same response, and you only have to reply once!

⚠️ Be careful with your ethics here - I had people reaching out to me to ask for a personal conversation about questions they had relating to the proposal, but we were clear as a team all questions had to come through the formal channels so that it was fair to all parties. I explained this to potential providers, that I would happily have a call to chat about Mautic, but I would not be able to discuss anything to do with the RFP process or answer questions about it, and directed them to submit via the stated method.

Promote, promote, promote

The next step is one we probably could have done better, and that is to promote the opportunity widely.

Internal promotion

We promoted well internally - our Slack community, on the forums with an announcement post which emails every member, and on all our social media channels.

This was very effective both at generating interest in the RFP process, but also because the community got very excited at what we were proposing to implement, and what it means for Mautic.

External promotion

We didn't promote as well externally - 'outside the Mautic bubble' - for example we could have made more use of our mailing list and promoted ads on social channels to reach a wider audience. If it's a particularly large project you might also want to consider some of the databases of RFPs which you could submit your project to.

That being said, we did still have a strong response and quite a few good quality proposals to review!

Decide if you are going to make 'personal invitations'

I did not do this formally - although it regularly came up in conversation with potential providers when we were engaging on other topics - because I felt it was unfair to directly point some potential providers to the RFP and not others (leaving it open to bias somewhat), but you might want to directly invite organisations you think could be interested in submitting a proposal.

It's an interesting dilemma really - we wanted organisations who were active enough in our community to come across those announcements to be the ones who applied, but we received some feedback after the announcements about the selected proposal were made that some felt 'put out' that they weren't personally made aware of the opportunity.

Transparency among the team

We set up a private Slack channel to deal with the incoming questions and proposals. I also connected the email account we set up specifically for this purpose to that channel, so everybody could see in Slack the content of every email coming into the account.

I blind copied in every email to the same address, so they saw all the outgoing emails, too.

We delegated access to the team so they could manage and send on behalf of that account, although in practice it was mostly me replying. This meant that I wasn't a key person dependency in the process in case anything meant I wasn't available.

We used threads to discuss the answers to the questions that were received, and come up with an answer that we all felt was appropriate. We also used threads to decide how to reply to emails.

Use a scoring matrix

We adopted a scoring matrix that we use for assessing events we might want to attend, to be used for reviewing the RFP submissions.

There were several areas we scored them on, all of which came from the expectations we laid out in the brief.

The following were scored from 1-10 by each member of our panel, after which we totalled the scores and ranked them to find the overall winner.

  • Are they active in the community?
  • How confident are you that they have sufficient background and experience with hosting Mautic at scale?
  • How confident are you that they have sufficient experience and involvement with the Mautic project and community?
  • How confident are you that they can spin up the instance consistently within 20 mins
  • How confident are you that they have explored adequetely in the proposal the plugins, themes and any limitations that would be imposed?
  • How confident are you that they will be able to mitigate against abuse effectively?
  • How confident are you that they are capable of managing a trial for 14 days?
  • How confident are you in the detail provided about how they will onboard and support people during the trial period?
  • How clearly have they explained how they will provide worldwide support?
  • Are you confident in their capacity to manage this effectively?
  • How confident are you in how they have proposed to convert leads into ongoing customers?
  • How do you feel about the proposed price range for the paid service?
  • How reasonable is the proposed revenue share model?
  • How well have they explained how they will create and publish a public-facing dashboard of metrics?
  • How confident are you in the way they propose to allow data portability?
  • How much do the value adds that they bring to the proposal benefit the customer?
  • How beneficial are the other services that they might offer to customers?
  • Does the company have any credentials such as ISO or any practices which support professional and secure processes to give confidence to trial users?
  • How confident are you that they have in place good data protection processes?
  • How feasible do you believe their proposal to be?
  • How much do you think Mautic will benefit from this provider being selected?

Thanking and giving helpful feedback

We were clear from the start that we wanted to be able to provide helpful feedback to anyone who took the time to submit a proposal, so we took the information that we gathered from the scoring matrix and wrote a personalised email to each provider.

We highlighted what they did well, and we flagged up the things that we felt they did not do so well on or that we felt their proposal lacked, framing the feedback in a positive and constructive way.

We also made sure to reiterate our gratitude to them for taking the time to participate in the process and willingness to support Mautic, and acknowledged the effort that had gone into the proposal (where this was the case - we had a few where it wasn't!)

Contract negotiations

It makes sense to give more time to this than you expect it to take!

We had a base template prepared, but it's always something of a negotiation process to get to a point of agreement. We used a collaborative doc to do this, and when both parties were happy with the contract we sent it to a lawyer for final review and sign off before it was completed.

We work with the lawyers that Open Source Collective recommend and have found them to be excellent in their understanding of open source projects.

You can use an open source tool for doc signing, like Documenso, or there are many proprietary tools out there that do the job well enough!

And of course, now the summit of the mountain is in view and we're approaching the next, exciting step: get building! I'll report back once we're through that phase with the key learnings!

Conclusion

And there you have it – a snapshot into the journey of bringing to life an RFP project the Mautic way!

In conclusion, launching a large-scale project or long-term collaboration within an Open Source setup can be daunting, but with the right approach, it can be an exciting adventure.

Our experience with Mautic provided valuable insights into managing such projects, chiefly the importance of clarity and openness in communication, due diligence in preparation, the utility of robust evaluation tools like scoring matrices, and the need for constructive feedback along with ethical integrity.

Navigating through the proposal, negotiation, and implementation stages can be intricate, but with the appropriate scaffolding of processes, timelines, and community engagement, large-scale projects can be a unique opportunity for innovation, revenue generation, and community-building while fostering Open Source values.

I hope that this might be helpful for other projects considering entering into an RFP process - feel free to leave a comment if you're reading this!