We’ve just released a new feature that allows you to add “components” to your products which your customers can purchase and be charged according to the quantity chosen.  This is great for offering things like the following to your products:

  • IP Addresses – say your basic service offers 1 custom IP address for free, and extras can be purchased for $1 each
  • Extra Projects – say your project management service allows users to purchase extra “projects” a la carte.  The first 5 cost $5 each, the next 5 cost $3 each
  • Charge flat fees based on a number of customers (like how Chargify works).  0-50 customers is $0, 51-500 is $49, etc.

What the heck are components?

We’ve built a new framework that is going to give you a lot of flexibility in defining your products, and we’re calling these “components”.  If you think of the traditional “product matrix” you used to see on most websites selling a service, you would usually see their plans (or products) in the columns and row after row of optional and included things.  Well, in Chargify these “things” are called “components” – they are the building blocks of your products that you use to add options, upgrades, and add-ons to enhance your offerings.

The following simplified graphic shows what I’m talking about.

quantity based components recurring billing

In Chargify lingo, the columns (or the column headers) are “Products”, the rows are “Components”, the cells define pricing or available selections.  The whole thing taken together, that you would typically want to compare in one table, is the “Product Family”.

Quantity-based vs. Metered Components

So far, we offer 2 types of components for your products: quantity-based and metered.  What’s the difference?

Metered components are used to track usage-based items whose usage resets at the beginning of each period.  Think cell phone overage minutes.  You might be charged $0.10 per minute, and your total usage is counted up at the end of the period and you’re charged.  At that point, the numbers roll back to 0 and are ready to count your usage for the next period.

Quantity-based components, on the other hand, don’t reset to 0.  What if you requested that your account be provisioned with 3 user accounts for which you were paying $1 each, and at the beginning of the next period you suddenly had 0 user accounts?  You’d be ticked.  That’s why quantity-based components are used for those things were a certain quantity is “allocated” and it stays at that allocation until its changed.

Pricing schemes: per-unit, tiered, volume, stairstep, oh my

Quantity-based components give you the ability to charge in flexible ways, and these ways are controlled by selectable “pricing schemes”.  The documentation does a good job of explaining the differences in better detail, but for now let’s just say that you have the ability to charge different amounts for different allocated quantities if you choose.

What’s missing

I’m going to be honest and point out a few things that aren’t in this release that I suspect our dear customers will start asking for next:

  • Different component pricing for each product.  Components are defined at the Product Family level, so that they are shared with all of the Products.  There are use cases where a Free Plan won’t even offer a component, the Basic Plan will charge $2 per unit, and the Pro plan will include 10 units for free and then charge $1 per unit thereafter.  We’ll get there.
  • Setup fees for components. I talked with a customer yesterday who needs to charge one-time setup fees on their components, and it sounded like a pretty good idea to me.
  • Customer-selectable quantities.  Setting and updating allocated quantities is API-only right now.  Eventually, this will be rolled in to our hosted signup and subscription editing pages.

Where does Chargify go from here?

The component framework is going to support more than just metered and quantity-based components.  We have visions for “Options” (yes/no choices), “Selections” (choose from a list of choices and pay accordingly), “Taxes” (hey, today is tax day in the US!), and more.

We intend to support pricing setups that are fairly common and can be considered best-practices.