|Dan Baker Blog|
Billing As Enabler for the Next Killer Business Model
"Capital isn't so important in business. Experience isn't so important. You can get both of those things. What is important is ideas. If you have ideas, you have the main asset you need, and there isn't any limit to what you can do with your business and your life."
— Harvey Firestone, founder of Firestone Tire (1868 – 1938)
With all due respect to Harvey Firestone, a great idea or killer app can’t stand alone. It needs to work hand-in-hand with a killer business model and supporting systems.
Google and Facebook made billions by taking standard Web applications and wrapping great business models and systems around them.
Search engines and online advertising used to be ho-hum, low-margin businesses. Then Google came along and combined the two to create a killer product – Google Ads. Several years later, Facebook did Google Ads one better by allowing the user to choose which ads he or she considers relevant.
But is Google Ads an application or a billing system? It’s both, really. It combines: 1) search engine and Web-ad insertion applications; and 2) advertiser invoicing and Web-click-tally (usage) billing functions.
Now at the time, Google knew little about billing: It was an expert in search engines. Yet the billing requirements for Google Ads were unique: Buying something off-the-shelf wasn’t an option because no one had ever asked for something like this before.
So Google built its own, and that billing system enabled the killer business model we now know as Google Ads.
Billing as business-model-enabler is a theme that Scott Swartz, CEO of Metratech, knows something about. Scott’s been preaching that theme ever since he founded the billing company in 1998. From the start, Scott chose to focus on companies that need to bill for "non-standard" business models (as well as a few standard business models too!). In fact, the more innovative and challenging the requirements, the more MetraTech stands apart.
Now, your company may not be experiencing new competitive forces that demand new billing functionality today or tomorrow, but your perspective on billing's future will certainly be sharpened by reading my conversation with Scott, who explains his company’s unique business model and why the business world we’re entering needs all the billing flexibility it can muster.
Dan Baker: Scott, the niche your company addresses is highly complex billing. But I’m curious how you differentiate yourself when there are so many billing vendors who excel in rating.
Scott Swartz: Complexity alone does not explain our niche. There are really two issues here: complexity and an architecture-breaking business model … the kinds of conditions we are seeing now in highly dynamic industries like Cloud Services, Financial Services, and Smart Grid. For example, when you have a one-to-many relationship such as 1-800-BUY-A-FORD and you want to send sales leads to individual regions and bill the regions separately – that’s simple in concept but it broke all the other billing systems who tried it.
A simple 800-number like 1-800-444-XXXX belongs to one company and every charge goes to that one account. But in the case of 800-BUY-A-FORD, the 800-number belongs to 60 organizations, and based on the originating area code, we're going to dynamically route that call to the place it should go.
If the call comes from a New Jersey area code, the call is routed to the Ford dealer in New Jersey and they will also pick up the bill for those calls.
The company we supplied that solution had some very nice Web software that monitored the call volume for these vanity 800-numbers, and that allowed them to deliver a nice campaign management program to their clients. After a while, you could start to correlate the effectiveness of certain advertisements to call volume. They could even tell you how many times the phone rang before it was picked up and so forth.
All of this was enabled by changing the billing-systems architecture. Now this isn’t something I would call highly complex. But it certainly is a unique requirement. If your solution doesn't fit in the box, you can't serve the customer. You're either in the box or out of the box. It's as if your solution fits in the box perfectly except for a pole stick out on one end – namely a special requirement you can't easily meet.
That’s an architecture-breaking requirement. And to solve that problem requires you to flex your business process dynamics.
DB: Can you characterize what sorts of companies are attracted to your kind of nontraditional billing solution?
SS: Many of the billing solutions today were designed for a particular vertical market such as how wireless business should work or how an airport should work.
These solutions are designed to fulfill the generic needs of 95 percent of a customer type in a certain industry. But if an innovator comes along and wants to do something different or the business becomes complex, you hit a wall. The largest telecom billing vendors have very strong capabilities. They manage many simple tasks very well. But as you start to get into the complex requirements, that’s where they are challenged. It's when you need to do lots fancy stuff in rating, price plans, partner compensation, customer hierarchies, ICBs, different currencies, and discounting.
Now a telecom might be selling bundles, but if it’s based on basic subscriptions, it's really not complex. However, if it includes some crazy cross-product discount and the billing is rated dynamically, then that's our kind of complexity. We look for companies in a dynamic or high-velocity business mode.
Microsoft, for example, figured it needed to increase the velocity of its billing processes, and they needed that in 18 months, so they did a bake-off that ultimately selected Metratech against a large billing competitor. Another customer of ours grew from 100 to 150 million customers in one year organically. Using their prior system, they were bleeding $80,000 a day. The business was based on a simple $9.95 per month credit-card-based subscription, but they also wanted to sell to large corporations and faced some complex business model dynamics around settlements.
The CFO told me: "If I wanted to solve only today's problem, I would have bought from somebody else, but I'm buying for the problem I'm going to have."
DB: It’s kind of hard to determine whether billing is getting simpler or more complex. On one hand you have services like the iPhone wireless broadband that’s billing in the U.S. at a flat rate. On the other side, you have things like cloud computing where the number of ecosystem players suggests billing will be very complex.
SS: Often the difference comes down to where the billing complexity occurs. For instance, a free service is often “advertising-based," which entails settlements in the background that could be with multi-party, usage based – even dynamically priced.
So billing’s like that. Simplicity in consumer billing might mean an increase in complexity at the ecosystem or distribution channel layers.
One area where complexity seems to grow is enterprise billing.
Telecom-to-enterprise billing is largely an unsolved problem. Enterprise customers are disappointed in its inaccuracy and lack of flexibility. Hierarchies are very hard to sort out. Some customers say: “Bill me for service X on the 14th and bill me for service Y on the 23rd – all at one customer. Then there are different bills going to different cost centers.
DB: Billing has certainly come a long ways. When TRI wrote its first billing research report in 1995, most of the billing systems were custom-built and hard-coded systems written by an Andersen Consulting (Accenture) or AMS (CGI). Then the first commercial-off-the-shelf (COTS) systems appeared from folks like Kenan Systems (Comverse) and that changed the game.
SS: I agree. The COTS solutions revolutionized billing. Perhaps the most enduring thing they accomplished was to create a new role – the offer administrator – a non-technical person who could sit down at a GUI and write calling plans and rates without writing code. And the mechanism for accomplishing that was moving the pricing and service bundles into a relational database where prices and simple bundling became table driven.
However, if you want to change the data model or business model, the COTS solution will be challenged. With 3 or 4 million lines of code, if you want to disassociate a telephone number from an account, you can't do that because the logic is hard-wired. So if having an innovative business model is important to you, a COTS solution often takes you no further than a custom system.
Ideally, the business analyst should be involved in the billing architecture from the beginning, but instead they're now relegated to a secondary role and are forced to ask the developer: "Can you do it this way? What's that going to take?" And the developer typically comes back and says something like: "Well, this is going to take three to six months to implement."
So if you can empower the business analyst, you can change the underlying data model – the GUIs, APIs and workflow – on the fly.
Now, IT can still make the changes to the system, but the answer to "when can I get this change implemented" will be no longer than six months. And this means you're able to do things that would normally require the massive coding a new release of software.
DB: What’s the technical “secret sauce" that makes your billing solution different?
SS: In a word, it’s “metadata." Everyone has got some level of metadata, but Metranet makes pervasive use of it. The metadata drives what the real data looks like.
We basically encapsulate the billing process at a lower level – namely the data architecture level. What we do is allow the business analyst to define what that reference data looks like.
So a company like the City of Chicago comes to us and says: “We need to model take-off and landing charges to the airlines." But their system never had that capability before. Well, our system allows a business analyst to come in and design a new service called www.OHareAirport.com/landingcharge.
And that service is going to have reference data such as Flight_Number, MTOFF for Maximum TakeOff Rate, NUM_Passengers for Number of Passengers on board the plane, NUM_Landing_Time for the time landed and so forth. All of these are new requirements that are inadequately modeled in the original COTS or custom billing system. So a new data model is needed, and that means the database, processing engine, GUI and API you originally designed are no longer good enough.
When you think about it, any kind of enterprise software needs 4 critical elements: 1) a consistent scheme for storing data; 2) some sort of transaction processing – it could be ordering, taxing, etc.; 3) a GUI is also needed to present the data; and lastly, 4) APIs are needed because you have to integrate with other systems. If you can do those four things, you're good to go.
The only trouble with a traditional architecture maintains a fairly fixed schema for representing phone numbers and other foundational metadata. But what our metadata system does is create the database schema on the fly. So it creates all the fields you need on the fly and our engine wasn't pre-defined to tell what those particular fields mean and how they should interact.
Scott Swartz is the CEO of Metratech. Prior to founding MetraTech in 1998, he was director of Product Marketing and Business Development at NetCentric, a provider of carrier-class Internet fax systems. He holds a Bachelor's degree in electrical, computer and systems engineering from Harvard.