Perspectives - Service Billing is Hard

Sunday, February 15, 2009

Service billing is hard. It’s hard to get invoicing and settlement overheads low. And billing is often one of the last and least thought of components of a for-fee online service systems. Billing at low overhead and high scale takes engineering and this often doesn’t get attention until after the service beta period. During a service beta period, you really don’t want to be only working out the service kinks. If you have a for-fee service or up-sell, then you should be beta testing the billing system and the business model at the same time as you beta test the service itself. It’s hard to get all three right, so get all three into beta testing as early as possible.

Billing being hard is not new news. The first notable internet service billing issue I recall was back in 1997 (http://news.cnet.com/MSN-faces-billing-problem/2100-1023_3-230402.html?tag=mncol) during which MSN was unable to scale the billing system and collect from users. Services weren’t interrupted but revenue certainly was. Losses at the time where estimated to be more than $22m.

One way to solve the problem of efficient, reliable, and low-overhead billing is to use a service that specializes in billing. It was recently announced that Microsoft Online Services (includes Exchange Online, Sharepoint Online, Office communicator online, and Office Live Meeting) has decided to use Metratech as billing and partner settlement system. The scope of partnership and whether it includes all geographies is not clear from the press release: Microsoft Online Services Utilizes MetraTech’s Billing and Partner Settlement Solution.

I suspect we’ll see more and more sub-service categories popping up over time and the pure own-the-entire stack, vertically integrated services model will only be used by the very largest services.

--jrh

James Hamilton, Amazon Web Services

1200, 12^th Ave. S., Seattle, WA, 98144
W:+1(425)703-9972 | C:+1(206)910-4692 | H:+1(206)201-1859 | james@amazon.com

H:mvdirona.com | W:mvdirona.com/jrh/work | blog:http://perspectives.mvdirona.com

Sunday, February 15, 2009 6:45:16 PM (Pacific Standard Time, UTC-08:00)

Comments [12] - Trackback
Services

Monday, February 16, 2009 7:23:41 AM (Pacific Standard Time, UTC-08:00)

yo james, not sure if you've seen these guys, but opsource is a hosting provider that provides billing services: http://www.opsource.net/billing.php. they're very popular among saas/cloud companies.

jeff

Monday, February 16, 2009 1:36:21 PM (Pacific Standard Time, UTC-08:00)

I hadn't come across them before Jeff. Thanks for the pointer.

--jrh
jrh@mvdirona.com

James Hamilton

Tuesday, February 17, 2009 5:17:38 PM (Pacific Standard Time, UTC-08:00)

OpSource purchased LeCayla billing for their billing solution:
http://blogs.zdnet.com/SAAS/?p=453

They also had (may still have) a billing relationship with Aria Systems as well.

Another company worth looking at is http://www.zuora.com/ which is backed by several ex SFDC execs.

Cheers,
Kris

Kristoffer Sheather

Wednesday, February 18, 2009 5:33:03 AM (Pacific Standard Time, UTC-08:00)

James. You are right. It is hard!, and while it is critical for ISVs it isn't core to their business.

We'd love to give you a demo of the solution.

Best,

--john
OpSource, Inc.

john rowell

Wednesday, February 18, 2009 4:43:10 PM (Pacific Standard Time, UTC-08:00)

James, I couldn’t agree more. Having a billing system that runs in parallel with your business objectives is much harder than it looks. Particularly when dealing with flexible reoccurring monthly bills. For example attempting to meter usage by a variable (say per GB) becomes inordinately complex for a company that is worrying about its core competency.

Here at IP Applications our paramount concern is to take care of billing and subscription management automation so our customers can focus on their main product.

vraniga

Thursday, February 19, 2009 6:28:44 AM (Pacific Standard Time, UTC-08:00)

Opsource and IP Application, thanks for making me aware of your services. I've checked out both of your web sites. Thanks.

--jrh
jrh@mvdirona.com

James Hamilton

Monday, March 09, 2009 8:57:08 PM (Pacific Standard Time, UTC-08:00)

eVapt is another company in this space.
Website : http://www.evapt.com

Divakar Jandhyala

Thursday, March 12, 2009 3:55:59 AM (Pacific Standard Time, UTC-08:00)

The problem with billing on its own is that it creates a disconnect between the underlying cost management model (resource metering) and the performance management model (quality at a cost).

A Unified Approach to Performance Management and Cost Management for Cloud Computing
http://www.jinspired.com/products/jxinsight/meteringthecloud.html

William

William Louth

Thursday, March 12, 2009 5:33:54 AM (Pacific Standard Time, UTC-08:00)

William, I actually see some value in there being a clear architectural boundary between metering and billing. I 100% agree that they need to work well together -- I'm just arguing that clear separation between billing and metering is a good thing.

Thanks for the comment William.

--jrh
jrh@mvdirona.com

James Hamilton

Thursday, March 12, 2009 10:21:58 AM (Pacific Standard Time, UTC-08:00)

Hi James,

After working on various billing engines for telecommunication companies I would agree that they are indeed separate systems though I would argue that any billing should be based largely by the cost model, the service (software) activity levels of users, and the quality aspects of the service delivered (I think this is extremely important especially for some social/networking companies trying to figure out a business model that is viable and sustainable).

I did publish a small article on how to apply this in practice though I did not dig deep into the various challenges in creating a ABC model irrespective of data collection techniques.

ABC for Cloud Computing
http://williamlouth.wordpress.com/2009/01/27/abc-for-cloud-computing/

That said I should point out that in some companies there are at least two billing models/solutions. One actual (and subsidized) and another that models much more closer the actual cost structure and ignores strategic objectives (grab market share) - "I wish we could charge a users this way".

This second one is used to justify future enhancements of services by way of an internal (and future/planned) pricing model. Cost benefit analysis is much easier for accountants here as it is much more concrete.

William

William Louth

Thursday, March 12, 2009 10:59:18 AM (Pacific Standard Time, UTC-08:00)

Some other points to bear in mind.

One persons billing (or pricing though they can be different) model is another persons cost model (at least partially). Will become more so with commoditization.

What one views as an metered activity another views as a priced resource. This is especially through when costing/metering/pricing/billing different layers on the software stack.

William

William Louth

Friday, March 13, 2009 6:24:04 AM (Pacific Standard Time, UTC-08:00)

I agree William. Prices should very closely model costs. If there are differences in how you price, developers will find the nooks, crannies, and inconsistencies and they will be exploited. My first rule of billing is you should price the units that drive your costs. The further they diverge, the greater the risk that users will find inconsistencies and exploit them.

I also agree that prices layer upward and each subsequent layer has, as costs, the prices of the layer below.

--jrh
jrh@mvdirona.com

James Hamilton

Comments are closed.