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.

When you create your pricing table, it is good to consider the following points:

• All elements should have a design consistent with the overall design of your website.
• Visually separate plans with using alternating background colors. When used sparingly, you can attract attention the plan you want the user to buy.
• Utilize different font sizes and colors for elements you want to stand out: titles, prices, headlines, etc.
• Always show the price of your plans and be aware that if places at the top or the bottom, they might not be visible to users if they start scrolling a long table. As a solution, you might want to consider placing titles and prices at both the top and bottom of the pricing table.
• Do not forget to mention the currency of your prices.

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.

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.