Subscription
Problem summary
The user wants to start a subscription of a service
Example
Usage
- Use when there is only one product to buy
- Use when the product involves recurring payments
- Use when the user can possibly choose between different variances of the product (different plans)
- Use when the user needs to conduct payment at the same time as a product (plan) is chosen.
- Do not use when the user can possibly buy more than one product at a time
- Do not use when the user can possibly decide what products he or she wishes to buy in one session, and return later to conduct the actual payment
- Do not use when the purchase of a product includes shipping costs.
- Do not use when you do not have the need to offer recurring payments (subscriptions)
Solution
Subscriptions to web services is offered by Application Service Providers (ASPs), who in the most cases only have one major product to offer, but offers this product in different variants (plans).
Present the different plans of the product you are offering, let the user know how much it will cost him or her per month/quarter/year to keep the subscription running. Also inform the user about what features are included in the different variants, and how they are each limited.
The purchase process is much more specialized than the genericness found in the Shopping Cart pattern.
Rationale
Laying out the different subscription plans in a table makes it easy for the user to grasp the full product palette while being able to compare the different plans both with each other, but also with competing products.
Discussion
Selling subscriptions to web applications is very different from selling physical goods. This is also why you need to sell your subscriptions with another approach than what is found in most online webshops. There are a number of things that are radically different: there are no shipping charges, there is no warehouse to contact, the user will buy only one product at a time, and you have recurring payments (the user needs to pay for the same product once again after the payed term has expired) which keeps the payment process open and continuous for the same product.
As subscriptions to web applications often only imply one account, you are also only subscribing to the service of one account, why you will not need a Shopping Cart to let the user collect the items he wants to buy: there is only one product. The product however comes in different variants each with a separate price. The variant (or plan) with the highest cost has the most features and the less limitations than cheaper plans.
Subscriptions to web applications often depend on the activity of the user’s account. If the user uses a lot of space on the Application Service Provider’s (ASP) harddrive, the user will often need to upgrade to a higher plan (a more expensive variant). Similarly, if a user wishes to downgrade to a cheaper plan, the activity or resources used of the account would need to be put down to a lower level in order for this option to be unlocked. The latter is called a hooks, which are defined levels that determine whether the minimum plan possible.
When defining hooks, 4 different parameters can be listed:- Features More expensive plans might offer features not offered in cheaper plans.
- Resources used Maximum levels in different categories (for instance number amount of file storage used or number of posts) can be defined to push the user into upgrading as these parameters grow as the user continuously uses the system. Unlike the traffic parameter listed below, these are options, which the user can do something about: Uploaded files can be deleted to lower used file storage and old posts can be deleted to make room for new posts.
- Resources consumed Where Resources used is defined in absolute values, Resources consumed is different as it is defined by absolute values per time unit. For instance by number of posts by users or user visits (hits) per month. Resources consumed can also be defined as traffic. The user cannot do much about the traffic his service experiences as this is defined by the popularity of the service the user has bought (for instance a blog, a webcounter, or a forum). Traffic is defined by the usage of the user’s visitors. Defining plans with this parameter can be tricky, as you need an alternative to fall back on, if the user does not wish to upgrade to the plan his traffic demands. Services with plans involving this parameter often have ad-supported versions to make up for users that do not wish to upgrade. The user is everything: we do not want to loose him or her.
- Number of services A fourth parameter is the number of services allowed. For instance the amount of projects, blogs, or forums offered to each account.
More examples images of the Subscription pattern
From the basecamp signup page