Mullets, Mood Rings, and On-Premise Billing Software

Two years and 60,000 lines of code—that was my first exposure to billing software. It was the late 1980s, the days of mood rings, mullets, and giant on-premise billing systems custom-built by dedicated teams of programmers. Thankfully the mullets and mood rings are gone, but many of the old billing systems are still in use, though their days are numbered.

80s server

In the 80s and 90s, custom billing system builds were common. Companies had teams of programmers supporting home-grown solutions. As time went by, many companies questioned whether or not billing should be one of their core competencies, and the industry transitioned from home-grown to large on-premise package solutions.

Many of those packages were initially developed by the telco industry, which has one over-riding requirement—processing large volumes of transactions very quickly. In fact, one vendor recently bragged that with a relatively modest hardware setup, their solution was capable of rating every mobile phone call on the planet in real time. Impressive, but not really something we all need to do.

These solutions are big, fast, and expensive to deploy and operate. They’re also highly functional and flexible, with more than one vendor claiming that their system can bill any product or service based on any metric. That might be true, assuming you can find an available rocket scientist to set up and manage your product catalog. The more functionality you use, the more complex the deployment.

And for most organizations, a degree of complexity was an acceptable trade-off, but only in an environment where business models were static. You could customize a system to work a certain way, then turn it on and let it go. And if it required occasional IT intervention and long lead times to set up new business models, new types of products, or new pricing models, that’s just the way it was. Our on-premise systems were reliable, they met performance requirements, and businesses generally had enough flexibility to get by.

But in the last three or four years we’ve reached an inflection point where just getting by isn’t enough to remain competitive. New technologies like cloud and mobile have changed the way consumers purchase and consume products and services. New business models are emerging very quickly, creating a growing demand for business agility.

Many of us learned the hard way that flexibility and agility are two very different things. It’s not enough just to be able to bill anything—I need to be able to bill anything today, not six or nine months from now. I need to be able to quickly get to market with new offerings, run A-B tests, and make business adjustments on the fly, without getting IT involved. This requires a new approach to billing.

Startups get this almost intuitively. They know their survival is based on speed. Enterprises, on the other hand, generally struggle with the idea that their multi-million-dollar billing system no longer meets all of their business needs. That’s not an easy conversation to have with your CFO (I still have the scars).

But to stay competitive, you need to move forward. There’s a new generation of SaaS billing providers that understand this reality, providing direct support for today’s most commonly used business models (subscription, usage, subscription plus usage hybrids, etc.), but more importantly, providing the agility for your business to change directions and try new things.

So what are your options? I see three:

  1. Keep doing what you’re doing while the world passes you by
  2. Replace existing package billing solutions with agile SaaS solutions
  3. Augment your existing on-premises solution with SaaS billing, providing agility for new business while extending the life of your existing billing system investments

That custom billing system I worked on over 25 years ago is still running. So are the on-premise packages I helped that same company deploy. But that company is evolving, and has introduced a SaaS based solution into several new business ventures. We’ll talk more about how that strategy can work for you in my next post.