As part of Abio’s transition to a Software as a Service (SaaS) company, we needed to develop a consistent, transparent, and fair pricing model that could work for clients of all sizes. The challenge we ran into was that Abio is not just one service but many interconnected services in a single platform. These services complement one another; for instance, if you use Abio to generate and send out estimates, your estimate generates the budget for the job, allowing you to avoid duplicating your work.

We want to encourage all of our clients to use more of our features so that rules out some common SaaS pricing models. Many SaaS companies divide their services into tiers, so users can buy additional functionality for additional money. Doing this would make Abio significantly less valuable to some clients, and we didn’t want to do that.

Charging everyone the same flat price is a total non-starter. Doing so would either mean pricing out smaller companies or losing money on bigger ones. So the clear answer is to charge by usage. Simple, right?

It’s not so simple.

Since Abio is a bundle of services, it’s not clear what kinds of usage clients should pay for. Charge for every kind of usage and we end up nickel-and-diming clients. This conflicts with our goals of making prices transparent and of encouraging clients to use all of our service’s functionality. On the other hand, if we just charge for one or two services, the system becomes gameable. Someone could strategically use all the free parts of the software and pay us next to nothing while eating up our resources.

The solution we came up with was to bundle the services together into packages and charge each client for the number of packages they use in a month. Effectively, this means you pay for the service you use the most. So one package can grant you A unique users, B workers on payroll, C paycheques, D quotes, etc. all for X dollars.

Yeah, get out your pencils. This blog post is a word problem now!

Given that we’re going to be selling our product in packages, the question is what should a package contain and how much should it cost. This is where market research is important. If we charge more than competing services, we’ll have trouble finding clients. If we charge too little, we’ll have trouble earning a profit.

The challenge is that most construction enterprise software providers do not have their prices openly displayed on their websites. Transparent pricing is not standard in this industry, with many companies choosing to negotiate a price with each new client. The one competing product that openly advertises its price is Payworks. Payworks isn’t construction enterprise software, it just does payroll. Many construction companies pay for enterprise software, then they export their payroll data to a paid service like Payworks in order to send out all the paycheques.

Abio is one of very few construction enterprise software packages in Canada to incorporate this functionality. So rather than paying for two services, our clients can have one that does both. And since we do what Payworks does, we can use them as a guide to what companies are willing to pay to send out paycheques.

So knowing what Payworks charges and knowing what some of our current and former clients pay for enterprise software, we can add them together for a ballpark figure for the current market value of our services. This is the upper bound of where we want to set our prices.

What we ultimately came up with was for a single CA$99 package to include the following services for a single month:

  • 1 active Abio user
  • 5 employees
  • 25 paycheques
  • 650 purchase items
  • 350 billing items
  • 80 quotes
  • Unlimited access to all other Abio features

 

We started this with the number of employees and paycheques and calibrated the other amounts to what is typical for our clients. This means that for a client who is extensively using one part of the software (e.g. the payroll system) the other parts are effectively free (e.g. quotes). We set out with the goal of encouraging clients to use more parts of the software to get the maximum value out of it, and this pricing model does so by making under-used parts of the software effectively free.