IP Applications Billing and Payments blog

Welcome to the IPA company blog. You'll see opinions here from a number of IPA employees on topics ranging from general SaaS and cloud happenings to specifics on PCI compliance and other subscriber management and recurring payments topics.
Tag >> Session Control

I wrote another post the other day about the key questions facing SaaS marketers.  I talked about Consumer versus Enterprise billing and about Direct versus Channel marketing models.  Overlaid on all of these choices, we have the concept of Session Control.

We implement Session Control through a component of our application called the "Session Manager".  It's an optional service but virtually all of our existing clients use it.

If you're a do-it-yourselfer and your application keeps track of users and sends data to the billing application (wherever it is), session management is done by the application itself.  If a customer doesn't pay their bill, someone in a place of authority has to take action to disable access to the application until they pay. 

If you have a small number of customers, the "someone" is probably in your accounting department and they call or email someone at the hosting company to pull the plug for a while.  It's a workable model for a small business, or if you don't care about timely payment.  It may sound odd, but if the customer has a perpetual license, for instance, or it's your corporate parent there's no payment to wait for and session management is unnecessary.  Manual control doesn't scale beyond a few customers, though - it becomes pretty labor-intensive as you grow.

What our Session Manager does is automate the control process and close the loop on payments.  After an account is set up for a new customer, the application and the Session Manager constantly swap messages about who's using the system (is this user that just logged in an authorized user?) and tracking the necessary billing data.  The Session Manager also monitors the payment queue to track whether the account is up to date.

The real value of the Session Manager becomes evident on that fateful day that a customer doesn't pay their bill.  Then the Session Manager uses the client's business rules to decide how to respond.  If the rules say that the customer is supposed to get daily "payment due" reminders and be allowed 30 days to catch up, then the Session Manager sends advisory messages to your administrative managers and implements that strategy without human intervention. 

At 31 days, if the account is still delinquent, an eerie silence descends on the freeloading users as the service is suspended pending settlement of the outstanding account.  While payment-due notices always get attention, a service suspension usually gets a response that a whole blizzard of notices just can't summon.

For any business model where customers pay on a monthly pay-as-you-go basis, session control makes a lot of sense.  It's one less administrative task for the accounting group, and one more control that keeps you from giving your stuff away through inattention to administrative detail.


One of the challenges we faced as we set about bringing our SaaS billing product to market was how to explain our application's wide range of capability to potential customers.  It sounds simple but it's not.  We've already found that companies who've built their own billing solution are far more interested in our solution than those who haven't tried it yet.  The latter think billing's easy, the former have enough experience to know better.

After talking to a range of software companies and reflecting on the billing and subscriber management business we already do, we concluded that every client has different needs.  Our application is an integrated billing system.  At the start of the exercise, our application was like a restaurant with one prix-fixe menu.  Even if all you want is the salad course, the fish course and desert, we'll still bring you the beef tartare, the duck breast and the cheese.  Of course, our application is flexible enough that you don't have to take or pay for all of its functions, but they'll be there every time you look at it, whether you're using them or not.

We figured that to make it more attractive we'd have to make the presentation simpler so we set about clustering the application components into logical groups.  The prix-fixe analogy still works but now we have three separate menus - the short one, the medium one and the complete one that includes flights of wine.

There are three questions to aim you at the right menu:

1) Do you need Enterprise billing or Consumer billing?  "Enterprise" means we produce one complex invoice covering a collection of end user.  "Consumer" means one simple invoice per end user.

2) Are you going to operate with or without Session Control?  "With Session Control" means that unpaid bills automatically suspend service.  "Without Session Control" means that unpaid bills have to be handled manually outside the application.  Each is appropriate for some categories of client.

3) Are you marketing through a channel or direct?  Channels are structured ecosystems that are complex to bill and administer.  However, many software companies find they can make more money that way.

We're pretty confident that as the SaaS business matures, most vendors will follow Time-Warner's lead and host their customer and user records with a billing service and use its application and its business logic to manage their SaaS business.  I'm using Time-Warner for this example because over the last five years they've worked with us to implement a top-notch subscription and billing management application that we own and that they run a sizeable chunk of their internet business on.  There isn't a lot they don't know about subscription marketing and delivery. 

So, if SaaS delivery is part of your product plans, spend the time pondering the three questions and figuring out your whole go-to-market problem.  Read everything you can find and talk to lots of people who've already done it before you set your developers to work.