Finding the right point in your UX to trigger a paywall
Most SaaS products have a freemium model that allows users to get a basic sense of how the product works and lets them see what additional benefits they gain by subscribing to the paid version of the product.
However it can be tricky sometimes when users are not able to understand what the paid plan offers until they actually give their credit card information and subscribe to the paid plan.
Even if one has a system where the user can give their payment information but won’t be charged until the free trial is over, it would cause some users to churn because they are not even sure if they want the free trial without knowing what the product offers.
We faced a similar problem while building our product which is a Shopify app, so we started looking at how other Shopify apps are doing this and we got to know that most of them trigger a paywall the moment you install the application without even letting you see what the UI looks like.
This did not seem right to us. We wanted every user to get onboarded into our product and let them see all the features that we have to offer and trigger the paywall only if they display an intent to use the product. We achieved this by following these methods:
- Onboarding email: An automated email consisting of information about all the paid plans sent at the time of installation.
- Landing page after installation: A page with the option of continuing with free plan or subscribing to paid plan right after installation.
- Upgrade banner: Display a banner on top of all the pages within the product that belong to the paid version nudging the user to subscribe.
- Allow read operations & block write operations: Letting the users navigate through the whole product and triggering a paywall only when they attempt to perform an action that would involve a write operation in the database.
- Informative pricing page: A crips pricing page that lets the user know what they're getting in the free/paid plans.
Onboarding email
It is common practice to send an email introducing a user to the product when they install it. We tried to tweak this email a bit further to inform the users about the paid plans that are available to them and what they can gain from them.
At the end of this email we include a link which takes the users to our pricing page from where they can upgrade to the paid plan.
Landing page after installation
While we were totally against triggering a paywall right in the landing page after a user installs the app, if your users know what they are looking for, sometimes it might be better to let them pick their plan upfront so as to skip the dance.
So it made sense to display a version of the pricing page right after installation where the user can either choose to continue with the free plan and not enter any payment information or upgrade to the paid plan right there.
The key thing here is to make sure that there is a sure shot way for the user to skip this step and go straight to the app but at the same time, it should not be too easy for them to do this.
Adding this additional step boosted our trials initiated by almost 50%.
Upgrade banner
Our product is segregated into pages where each page represents a particular feature of the product and each feature could either belong to the free plan or the paid plan. You can navigate to any page using a side navigation bar.
When the user navigates to a page with free plan features, they don’t see any visible change and can continue configuring and using the product, but when they navigate to a page with paid plan features, they see a banner on the top of the page that is not subtle but at the same time does not hamper user experience.
This banner contains a CTA button which takes the users to our pricing page where they can choose their plan and authorise payment. This banner disappears from all pages once they subscribe to the paid plan while the rest of the product remains as it is.
Allow read operations and block write operations
When the user is on a free plan there is no harm in letting them navigate to pages with paid features and let them see how it works. In fact you can let them use the product the same way a paid plan user would use it.
The only harm occurs when a free user tries to configure something which can only be done by paid plan users. This can be prevented by automatically redirecting them to the pricing page whenever they click on a button or perform any action that they are not supposed to.
In other words if any action within the product triggers a write operation in the backend, instead of allowing that to happen, send the users to the pricing page if they are on a free plan.
Informative pricing page
Since we are redirecting users to a page that is specifically designed for them to authorise a payment, we use this page to display all the features that are offered in the free version and paid version of the product.
At the moment we have only one paid plan but if there are multiple paid plans, the same page can be used to display all features of all the plans along with the pricing and any discount if applicable. For instance we are currently running a discount due to Covid-19.
This page can also be used to provide some information about the company with a small message about your vision and why you built this product. For indie hackers such as ourselves this really resonates with our target audience who are mostly SMBs and have similar problems as us.
Closing notes
None of these optimisations matter without some numbers to back them up, so here are the numbers for our product
- Number of installs/leads: 3k to 5k per month
- Number of paid trials initiated: 500 to 600 per month (10% of installs)
- Number of users retained after trial completion: 250 to 300 per month (50% of trials initiated)
Apart from the above numbers we get very minimal support tickets regarding pricing and features included in the paid plan. This system sort of runs on its own.