Comments for SaaS Blogs http://www.saasblogs.com Understanding the Software as a Service Revolution Sun, 06 Jul 2008 19:13:47 +0000 http://wordpress.org/?v=2.5 Comment on When Should Software be Sold Pay Per Use? by Richard Chetwynd http://www.saasblogs.com/2008/07/02/when-should-software-be-sold-pay-per-use/#comment-51307 Richard Chetwynd Thu, 03 Jul 2008 13:42:19 +0000 http://www.saasblogs.com/?p=214#comment-51307 We've also just been through a pricing overhaul and considered the per use model. We ended up sticking with a per user model though, mainly due to our users accessing the service on pretty much a daily basis. The product is an online training/elearning system, that makes life easier for companies wanting to move their training online. One big change that we have made recently is to do away with user bundle pricing and just charge a flat fee per user. This gives the customer more flexibility and they don't get that feeling that they are paying for X amount of users but only using 75% of them. Getting the revenue model right really can make or break a SaaS offering. We’ve also just been through a pricing overhaul and considered the per use model. We ended up sticking with a per user model though, mainly due to our users accessing the service on pretty much a daily basis.

The product is an online training/elearning system, that makes life easier for companies wanting to move their training online.

One big change that we have made recently is to do away with user bundle pricing and just charge a flat fee per user. This gives the customer more flexibility and they don’t get that feeling that they are paying for X amount of users but only using 75% of them.

Getting the revenue model right really can make or break a SaaS offering.

]]> Comment on When Should Software be Sold Pay Per Use? by Sinclair Schuller http://www.saasblogs.com/2008/07/02/when-should-software-be-sold-pay-per-use/#comment-51300 Sinclair Schuller Thu, 03 Jul 2008 12:49:11 +0000 http://www.saasblogs.com/?p=214#comment-51300 Paul, All good points - especially the fact that how cost-conscious your industry is important in the decision. Yves, Thanks for the rundown on your decision making process when it came to pricing. One comment you made is important "It will makes less money at the end, but the benefit of having your users satisfied is priceless..." This is very true from a revenue sense, but one benefit of the pay per use mechanism is that it generally carries higher margins, so your net income % could be healthier than when using a recurring model. Of course, this is not always the case, but the "a la carte" aspect can carry a premium. Paul,

All good points - especially the fact that how cost-conscious your industry is important in the decision.

Yves,

Thanks for the rundown on your decision making process when it came to pricing. One comment you made is important

“It will makes less money at the end, but the benefit of having your users satisfied is priceless…”

This is very true from a revenue sense, but one benefit of the pay per use mechanism is that it generally carries higher margins, so your net income % could be healthier than when using a recurring model. Of course, this is not always the case, but the “a la carte” aspect can carry a premium.

]]> Comment on When Should Software be Sold Pay Per Use? by Yves Hiernaux http://www.saasblogs.com/2008/07/02/when-should-software-be-sold-pay-per-use/#comment-51290 Yves Hiernaux Thu, 03 Jul 2008 12:28:20 +0000 http://www.saasblogs.com/?p=214#comment-51290 Hello Sinclair, Having been in the process of defining the pricing of a new SaaS Business Application, I went through the same kind of considerations. My associate and I had the feeling that people should pay for what they get and use. In our case, we deliver a Timesheet, Expense Management and Invoicing SaaS application. There is one particularity, which is that each feature can be used separately. When it comes down to define a price per use, you need of course the price but also the unit you will use for your pricing. Looking back at our example, you could imagine that the unit for timesheet is a timesheet record, the unit for expense is an expense record and the unit for invoicing is an invoice. It makes sense to pay more if you are a call center company using intensively the timesheet application to keep track of all your calls for example. But take a small company of 10 consultants in IT. They will probably have 20 timesheet records per person per month, 4 or 5 expenses per person per month and the company will probably have like 5 or 6 invoices per month. So, when you start presenting your price per use, you will get something like a very small price per timesheet record, a middle price per expense record and a big price in comparisons with the 2 others for invoices. The first conclusion was indeed that the “per use” model is quite difficult to apply when quantities are low. The difference between the numbers doesn’t give a “sexy” look to the global pricing and we thought to take Invoicing out of the per use model. The second conclusion came by comparing this model with what the others do. (Usually a price per user/per month in packages). Again, it wasn’t giving some kind of “Wow!” effect. The pricing should directly be attractive for the future customers. In a few seconds he needs to know if he will makes some profit or not. If the web site visitor arrives on the pricing page and start counting how much his employees will enter timesheet records, how much expenses, … well he will probably be away before knowing the answer. The conclusions was that it is difficult to apply the per use model if the competition doesn’t do it. People cannot compare easily then. So, I have abandoned the idea of applying the per use model to the pricing for now but not completely. My plan is to reintroduce it but not in the pricing page of the application but as a service to my customers. If I discover that certain customers could pay less changing their pricing model to a per use model, I will propose them the switch. It will makes less money at the end, but the benefit of having your users satisfied is priceless. Of course this is still only on paper and future will tell me soon if we are on the right path. Hello Sinclair,
Having been in the process of defining the pricing of a new SaaS Business Application, I went through the same kind of considerations.
My associate and I had the feeling that people should pay for what they get and use.
In our case, we deliver a Timesheet, Expense Management and Invoicing SaaS application. There is one particularity, which is that each feature can be used separately.
When it comes down to define a price per use, you need of course the price but also the unit you will use for your pricing.
Looking back at our example, you could imagine that the unit for timesheet is a timesheet record, the unit for expense is an expense record and the unit for invoicing is an invoice.
It makes sense to pay more if you are a call center company using intensively the timesheet application to keep track of all your calls for example.
But take a small company of 10 consultants in IT. They will probably have 20 timesheet records per person per month, 4 or 5 expenses per person per month and the company will probably have like 5 or 6 invoices per month.
So, when you start presenting your price per use, you will get something like a very small price per timesheet record, a middle price per expense record and a big price in comparisons with the 2 others for invoices.
The first conclusion was indeed that the “per use” model is quite difficult to apply when quantities are low. The difference between the numbers doesn’t give a “sexy” look to the global pricing and we thought to take Invoicing out of the per use model.
The second conclusion came by comparing this model with what the others do. (Usually a price per user/per month in packages). Again, it wasn’t giving some kind of “Wow!” effect.
The pricing should directly be attractive for the future customers. In a few seconds he needs to know if he will makes some profit or not.
If the web site visitor arrives on the pricing page and start counting how much his employees will enter timesheet records, how much expenses, … well he will probably be away before knowing the answer.
The conclusions was that it is difficult to apply the per use model if the competition doesn’t do it. People cannot compare easily then.
So, I have abandoned the idea of applying the per use model to the pricing for now but not completely.
My plan is to reintroduce it but not in the pricing page of the application but as a service to my customers.
If I discover that certain customers could pay less changing their pricing model to a per use model, I will propose them the switch.
It will makes less money at the end, but the benefit of having your users satisfied is priceless.
Of course this is still only on paper and future will tell me soon if we are on the right path.

]]> Comment on When Should Software be Sold Pay Per Use? by Paul Wilkinson http://www.saasblogs.com/2008/07/02/when-should-software-be-sold-pay-per-use/#comment-51283 Paul Wilkinson Thu, 03 Jul 2008 11:02:55 +0000 http://www.saasblogs.com/?p=214#comment-51283 SaaS vendors, such as BIW, in the UK construction collaboration technology market mainly deliver their solutions to customers on a fixed monthly or quarterly subscription. As the solutions are used to promote collaboration among a fragmented, multi-company supply chain, having a single paying customer (usually either the ultimate owner/operator of the built asset, or the main contractor or project manager) is simpler. Moreover, in an incredibly cost-conscious industry like construction, this payment model (unlimited users, unlimited amount of data) also encourages take-up and use of the software. Paying on a per-seat or per-use basis could well lead to supply chain companies trying to avoid using the system (perhaps setting up parallel, unauditable systems), or sharing logins, with a resulting direct impact on the quality and integrity of the stored information and managed business processes. SaaS vendors, such as BIW, in the UK construction collaboration technology market mainly deliver their solutions to customers on a fixed monthly or quarterly subscription. As the solutions are used to promote collaboration among a fragmented, multi-company supply chain, having a single paying customer (usually either the ultimate owner/operator of the built asset, or the main contractor or project manager) is simpler.

Moreover, in an incredibly cost-conscious industry like construction, this payment model (unlimited users, unlimited amount of data) also encourages take-up and use of the software. Paying on a per-seat or per-use basis could well lead to supply chain companies trying to avoid using the system (perhaps setting up parallel, unauditable systems), or sharing logins, with a resulting direct impact on the quality and integrity of the stored information and managed business processes.

]]> Comment on Merging Local Data Acquisition with SaaS by Sinclair Schuller http://www.saasblogs.com/2008/06/24/merging-local-data-acquisition-with-saas/#comment-51234 Sinclair Schuller Thu, 03 Jul 2008 02:02:29 +0000 http://www.saasblogs.com/?p=213#comment-51234 Landon, I think this is the sort of innovation I would expect from the startup community. It's one of the ways to get a leg up on incumbents. In terms of building competence, I would do it via partnerships. I would expect SaaS providers to look to firms like Symbol (now a Motorola product line) or more specialized providers that interface measurement equipment with PC infrastructures. The SaaS provider should focus on adapting the data and safely integrating it into the SaaS offering, and not specifically on the hardware end of things. Landon,

I think this is the sort of innovation I would expect from the startup community. It’s one of the ways to get a leg up on incumbents.

In terms of building competence, I would do it via partnerships. I would expect SaaS providers to look to firms like Symbol (now a Motorola product line) or more specialized providers that interface measurement equipment with PC infrastructures. The SaaS provider should focus on adapting the data and safely integrating it into the SaaS offering, and not specifically on the hardware end of things.

]]> Comment on Merging Local Data Acquisition with SaaS by Landon Hoover http://www.saasblogs.com/2008/06/24/merging-local-data-acquisition-with-saas/#comment-50897 Landon Hoover Mon, 30 Jun 2008 14:29:47 +0000 http://www.saasblogs.com/?p=213#comment-50897 Sinclair, Do you see this as a market opportunity for incumbent SaaS providers, like Salesforce, or a microsoft, or startups? As well, what steps would a company go through to develop such a competency? I know of SaaS support companies, like eVapt; however, I thought there might be other resources or experts with a more specific knowledge of local data acquisition. Sinclair,

Do you see this as a market opportunity for incumbent SaaS providers, like Salesforce, or a microsoft, or startups?

As well, what steps would a company go through to develop such a competency? I know of SaaS support companies, like eVapt; however, I thought there might be other resources or experts with a more specific knowledge of local data acquisition.

]]> Comment on SaaS 101: The Drawbacks by John from Credit Card Debt Reduction Services http://www.saasblogs.com/2007/10/16/saas-101-the-drawbacks/#comment-50694 John from Credit Card Debt Reduction Services Sat, 28 Jun 2008 22:38:41 +0000 http://www.saasblogs.com/2007/10/16/saas-101-the-drawbacks/#comment-50694 I think SaaS should work off-line but we have to be honest here, I live in Portugal and it's not that advanced in terms of broadband and internet penetration as the USA, but nowadays you can have a 3G connection in many places, and in a very recent future it will be almost a 100% coverage area. That will benifit SaaS for sure! I think SaaS should work off-line but we have to be honest here, I live in Portugal and it’s not that advanced in terms of broadband and internet penetration as the USA, but nowadays you can have a 3G connection in many places, and in a very recent future it will be almost a 100% coverage area.

That will benifit SaaS for sure!

]]> Comment on Merging Local Data Acquisition with SaaS by Sinclair Schuller http://www.saasblogs.com/2008/06/24/merging-local-data-acquisition-with-saas/#comment-50351 Sinclair Schuller Thu, 26 Jun 2008 10:21:19 +0000 http://www.saasblogs.com/?p=213#comment-50351 Hi Kevin, You're spot on with reducing the amount of intelligence on the premise side of things. In any scenario like the one painted in this post, I would highly recommend limiting premise side "agents" to collector and measurement roles. Sending that data to a SaaS aggregator via XML (just a protocol choice, clearly other formats would be valid) is where the intelligence would kick in. Hi Kevin,

You’re spot on with reducing the amount of intelligence on the premise side of things. In any scenario like the one painted in this post, I would highly recommend limiting premise side “agents” to collector and measurement roles.

Sending that data to a SaaS aggregator via XML (just a protocol choice, clearly other formats would be valid) is where the intelligence would kick in.

]]> Comment on Merging Local Data Acquisition with SaaS by Yves Hiernaux http://www.saasblogs.com/2008/06/24/merging-local-data-acquisition-with-saas/#comment-50318 Yves Hiernaux Thu, 26 Jun 2008 06:02:55 +0000 http://www.saasblogs.com/?p=213#comment-50318 Hi Kevin, Why for you is sending an XML on the premise side too expensive ? With the democratization of browser enabled mobile phones or mini-pc you could have simple interface to submit any information, or even consider automated events such as geo-localization. An example is companies trying to find the best way from one point to another for transport trucks. You have one central system gathering information from the internal DB (customer information), Traffic information and local information from the truck drivers. Traffic information are obtained through API and drivers information are obtained through mobile phone. Another example, mobile ads based on your localization. Information are coming from internal DB (your profile) and your geo-localization (iphone like). You could even think about a simple interface to explain when you arrive in a shopping center the kind of goodies you are looking for. XML is just one way of sending information but it is becoming quite common. Hi Kevin,

Why for you is sending an XML on the premise side too expensive ?

With the democratization of browser enabled mobile phones or mini-pc you could have simple interface to submit any information, or even consider automated events such as geo-localization.

An example is companies trying to find the best way from one point to another for transport trucks.

You have one central system gathering information from the internal DB (customer information), Traffic information and local information from the truck drivers.

Traffic information are obtained through API and drivers information are obtained through mobile phone.

Another example, mobile ads based on your localization. Information are coming from internal DB (your profile) and your geo-localization (iphone like). You could even think about a simple interface to explain when you arrive in a shopping center the kind of goodies you are looking for.

XML is just one way of sending information but it is becoming quite common.

]]> Comment on Merging Local Data Acquisition with SaaS by Kevin Doherty http://www.saasblogs.com/2008/06/24/merging-local-data-acquisition-with-saas/#comment-50299 Kevin Doherty Thu, 26 Jun 2008 02:28:23 +0000 http://www.saasblogs.com/?p=213#comment-50299 Sinclair, An interesting idea but I don’t think S+S is what you are looking for. In this solution you would need maybe an E&M port on a router with special IOS software on it to report shorts or some other electrical notification that indicates an alarm condition. I have seen other similar solutions that use this same structure to key radios remotely etc. If you add too much intelligence on the premise side, the solution quickly becomes too costly and, therefore, cost prohibitive. I think you’re on the right track. This is probably one of the more interesting conversations I’ve seen on the blogosphere recently regarding SaaS and future applications. Thanks! Kevin Doherty, CEO Phase 2 International Sinclair,

An interesting idea but I don’t think S+S is what you are looking for.

In this solution you would need maybe an E&M port on a router with special IOS software on it to report shorts or some other electrical notification that indicates an alarm condition. I have seen other similar solutions that use this same structure to key radios remotely etc.

If you add too much intelligence on the premise side, the solution quickly becomes too costly and, therefore, cost prohibitive. I think you’re on the right track. This is probably one of the more interesting conversations I’ve seen on the blogosphere recently regarding SaaS and future applications. Thanks!

Kevin Doherty, CEO
Phase 2 International

]]>