When companies are developing SaaS applications, billing is a very important consideration but sometimes ends up as an afterthought, says Ed Sullivan, CEO of Aria Systems. Ed joined me for a talk about things to keep in mind on the billing front; listen to the podcast below or read the transcript.
KD: When a company wants to develop an deploy a software as a service application, one of the many considerations they must think of is billing and according to Ed Sullivan, CEO of Aria Systems, a lot of companies make critical mistakes in billing. Ed is here today to talk to us about software as a service billing and how best to handle it. Thanks for joining us today, Ed. Can you start by telling us how most providers are handling billing right now and what’s wrong with that approach?
ES: Based on what we’re seeing in both our existing customers that have come to us and prospects that we’re talking to, is that they tend to treat billing as an afterthought and cobble together maybe a PayPal account with Quicken or merchant account and don’t really, those solutions don’t really scale for one, secondly they’re not compliant with some of the, you know, the credit card industry stuff, taking personal information and thirdly, they don’t scale, they might scale, you know to a couple hundred or a couple thousand customers and you can do things manually but by treating it as kind of this cobbled-together thing, the thing they don’t automate all of the use cases throughout the customer life-cycle.
KD: All right, that makes sense. So what would you say is a better way to handle billing for SAS applications?
ES: Well, I think one of the other issues that some companies have when they’re billing a SAS application, either from an on-premise application that you’re trying to convert to SAS or a new service is that they’re still thinking in the old software paradigm where it’s kind of a one-time purchase, you either take the credit card or you prove the transaction through a CFO and a PO and then you move on. In software as a service, you’re software is not your business, but your customer experience is your business and all of the use cases throughout the customer life cycle need to be considered when building a SAS application. For instance, when somebody signs up, tracking channels and tracking resellers, integrating with something like Salesforce.com to bring the customers into the service, being able to do more than just take a one-time transaction but manage multiple transactions throughout a customer life-cycle that might extend beyond a one-time purchase, monthly, quarterly, annually for an extended period of time. So, taking the approach of understanding what all of those use cases are in a long subscription based or recurring relationship.
KD: OK, so for companies interested in putting together a SAS offering, such as ISB’s can you give a list of do’s and don’t’s that they should keep in mind when considering the billing issue?
ES: Yes, so we’re kind of seeing a convergence of really two forces, if you will. One of them is the way consumers are buying goods and services on the internet and products on the internet – songs, videos, etc. is leaking into the enterprise so what I mean, even CIOs of large companies are not willing to bear the expense of building out an entire infrastructure and go after compliance, etc. when the number of users they have is not determined yet. So, I would say, the other thing that is happening is the world – I read the book, The World is Flat but it really is, I didn’t appreciate how amazing that phenomenon is until it started happening to us here at Aria and our clients. We built our software to really for North American companies and we kind of were faced with this happy accident of having customers and end-users, in turn, in 236 countries, 16 different currencies, having to deal with not just the rigors of being able to take credit cards and manage personal information in the United States, but understanding things like the European Safe Harbor Act when a software company in the middle of America decides to sell their software over the web and somebody from Europe shows up with a Visa card and if you take that personal information and unbeknownst to that service provider they’re in violation of a treaty between the United States and the European Union when they take the citizen of the EU’s personal and financial information across a border.
There’s a whole bunch of compliance issues out there that small companies tend not to think about and even larger companies are starting a new service don’t think about that really need to be considered if you’re aiming to have a large successful business.
KD: Anything else you’d like to add on the subject of billing and SaaS software?
ES: I guess the three main things I like to talk about are that your software is not your business, making sure that you understand that unlike classical software providers your software is not your business and you’re entering into a relationship as a SaaS provider. There are different use cases throughout that life cycle. You need to consider billing before you enter into beta for your software so that you can have a really good understanding of how you can get all those interactions to scale in business. So we say billing before beta and billing is really treated as an afterthought and it should be well thought out and planned while you’re building out the application, especially for SaaS providers.
KD: Great! We’ve been talking with Ed Sullivan of Aria Systems about software as a service billing concerns. Remember if you want more blogs, white papers, news and more about software as a service and enterprise 2.0, visit www.ebizq.net. Thanks for listening and have a great day!
I am glad to see this topic being raised by Krissi of Ebiz & been addressed by Ed, who himself has had to address this situation himself as his company is daily involved in this process & I would very much like to elaborate a bit further on this topic as our company has over 9yrs experience in this sector and is anticipating increased revenue from the market as increased spending in IT is expected, and SAAS will most likely be a big consideration.
As state Ed has mentioned: billing should be addressed before beta. Currencies, laws of a particular country (e.g. privacy of client information) need to be planned & this can fluctuate or change (e.g. over a 3-5 year contract). Questions need to be addresses like: Is this solution bundled with another solution? (e.g. someone installing a mail server, but the mail security solution is a bundled SAAS one) How are we billing/How are our resellers billing? - Per user per month or per user per year? Is there set up fees? Support fees? How are new users added? Some companies might only assign only a few users at the beginning of the contract & added the bulk at a later stage or even packs of users in phases. There are even cases where a company may have sub divisions or sub companies located geographically apart, that have there own IT budgets in place and in fact be a separate account altogether. I recent case for example with regards to compliance (not quite billing thou) was with a Swiss company not been able to use our SAAS solution outside Switzerland, so we had to build a data centre in Switzerland. So to sum it up Ed’s right, it’s not the just the product we are selling, but providing solutions for our clients to best utilize our service.
Byron Graham
bgraham@groveis.com
Postini SAAS Wholesaler