Designing a seamless subscription experience for our B2C market

We started the process with some preliminary research because there were big questions to address before properly shaping the solution. These are two of the most relevant ones, along with the answers from the team:

Q. Can socios have a 30-day trial without requiring a credit card upfront?

A. Not through the App Store, which forces users to enter their credit card and accept a paid subscription when enrolling into the trial. When the trial expires, we must redirect socios to a web-based service like Stripe.

Q. Can we create coupon codes through the stores? (this was a request from marketing to engage potential customers through social media and in-person events.)

A. It was possible to do this through the stores, but it was fairly complex to do it how the business needed it.

The answer to both questions was "yes, but it is not that easy." The first one, in particular, required us to take the users out of the app to pay on the web and then go back—a series of actions that were particularly difficult for our low-tech savvy profile to perform. We discussed and decided to keep the project short since B2C is not our primary business model.

The pitch

At Misalud, we follow the Shape Up product development process, which has been truly effective. The first step is to write the pitch, which contains the problem (which I described in the Overview above), the description of the solution, the appetite, the team, the rabbit holes, and the no-gos.

Rabbit holes and no-gos

A no-go is a piece of functionality left out of the scope. A rabbit hole is a place you don't want to get into to avoid the risk of not meeting the appetite. Some of the no-gos and rabbit holes of this project were the following:

• We wouldn't support payments through the web, only through the stores
• Refunds would be handled manually
• Promo codes were not part of this first version
• If a user schedules a consultation and then their subscription expires, we would cancel the consultation manually in our system

Appetite and team

The appetite is the time we want to spend on the project, which is decided by our Chief Product Officer. In this case, it was six weeks because even though we didn't want to spend a lot of time, the functionality was complex, along with all the testing we needed to do before sending it to production. As for the team, we assigned a team of one designer, two frontend engineers, one backend engineer, and one QA engineer.
‍

Solution

I met with the Design Lead and two engineers to whiteboard the solution together. These are the scenarios we came up with:

‍
Scenario 1

A user creates an account and is automatically enrolled into a 30-day trial:

1. The user will see a non-intrusive banner at the top of the home screen, letting them know they are on the trial period
2. A paywall will be displayed when tapping on that banner
3. They will be able to choose a plan and pay through the stores
4. They will also see a section in the profile section indicating the status of the subscription: trial or active (one month, six months, or one year)
5. They could start the same process to pay for a subscription from the profile as well

Scenario 2

A user has an active trial that will expire in 5 days:

1. The banner will change to a reddish color to give a sense of urgency, along with a label that indicates the days left in the trial
2. After every consultation, the user will see a drawer inviting them to choose a plan

‍
Scenario 3

A user has a subscription already and wants to cancel:

1. They can go to the profile section, tap on the membership menu item, and see a list of steps to follow for canceling through the store (Android or iOS)

‍
Scenario 4

A user's subscription is about to renew automatically:

1. We will send an email five days before the renewal to let them know and remind them about the benefits of their current plan
2. One day before, we will send an SMS with the basic information about the renewal

Metrics

I defined the _events_ we will send to Mixpanel to measure the solution's effectiveness and observe our socios' behavior. These are some of the metrics I suggested to implement:

• Payment flow: started: triggered when the socio opens the paywall
  - triggered_from: a property that tracks where the event is triggered from (home screen, profile, or post-consultation)

• Payment flow: plan selected: triggered when the socio taps on one of the plans
  - membership_length: a property that tracks the plan they selected (one month, six months, or one year)
• Payment flow: payment successful: triggered after the socio pays through the store
• Payment flow: subscription canceled: when canceled from the stores
• Payment flow: subscription renewed: after automatic renewal
• Payment flow: subscription updated: when changed to another plan through the stores
• User traits: besides the events and their properties, we attached (or updated) properties to the user profile based on the status of their subscription:
  - membership_status: subscription active, trial active, trial expired, membership expired
  - membership_length: one month, six months, or one year
  - user_type: B2C or B2B

These metrics would allow me to create reports, funnels, and flows in Mixpanel to understand where users typically drop, from which touchpoint they subscribe the most, and which plans they choose.

I presented the pitch to the stakeholders, got a thumbs up, and kicked off the project.

‍
The project

‍
We kicked off the project during one meeting and then kept track of its progress in Notion. Even though we do Shape Up, we use Notion instead of Basecamp because we prefer to centralize the documentation for projects and non-related projects. A few months ago I was able to create a template with all the sections we needed (along with a great tool from the Zero Mile and we use it for every project since then.

‍

The developers could start coding from day one because the pitch and the whiteboard were clear and specific. They didn't need mocks to make things work. They could use non-styled components and basic layouts while I worked with the designer to finalize the user interface. QA engineers also had everything they needed to start writing test cases.

We encountered many discovered tasks during the project and had to cut some corners. Testing was also a big chunk of the six weeks, but we anticipated this by testing the scopes that were ready instead of leaving everything for the end. We were able to release the project in six weeks with no delays.

‍

We waited several months to measure the results of our efforts. After a couple of quarters, we started seeing a positive trend in our B2C subscribers. These are some of the data points we collected:

• 13% of the socios who create an account start the subscription flow
• From those socios, 1% end up paying
• 85% of socios choose the monthly subscription over the other two options
• 68% of the subscribers come from iOS
• 47% of the socios who subscribed attended at least two consults before paying

Remember that these behaviors are entirely organic; no marketing efforts were behind them—just word of mouth.

‍
Next steps

The data allowed us to come up with potential ideas for improving the B2C long-tail:

• Referral programs for employees
• Test different lengths for the trial period
• Make the trial period consult-based instead of time-based, e.g., charge after the second consult
• Test different subscription lengths
• Allow socios to pay per consult

Still, our primary focus didn't change. We would continue to serve our B2B clients and their employees while keeping an eye on organic customer acquisition.

‍