Acronyms can be corny, right grin?

Sorry that this post is so long! It covers 3 years of experience, as well as my recent journey with some great folks to help provide a solution to a problem that’s been affecting entrepreneurs, web startups, and SMBs over the past few years.

The businesses I’ve been involved in since 2006 are all about billing the same customer repeatedly. The product never “ships”. Instead, the product is something that flows continuously from us to our customer, and money flows back to us.

Consequently, billing customers involves more than it used to.

BAM!

The activities that surround recurring billing touch many parts of a business. These activities, added together, can be seen as a business unit, just like Marketing or Human Resources. As a business unit, BAM can include all of these things:

  • Basic billing settings (ie, billing cycle, proration settings)
  • Products
  • Pricing
  • Customer sign-up & product selection
  • Interaction between billing & provisioning systems
  • Recurring billing, usually to a credit card
  • Resolution of nonpayments (ie, credit card declines)
  • Customer management of payment details & history
  • Reporting on customer/product/price activity

What’s interesting is that most of us start out thinking that recurring billing is all there is, but you can see that it’s just part of the picture.

Engine Yard

In 2006, I co-founded Engine Yard. We had something people wanted and they started signing up before we had much to sell.

We were busy racking servers, integrating layers of very new software and hardware, negotiating data center space, trying to hire people, raising money from friends, etc. We didn’t think about how we’d approach BAM.

When it came time to take customers, we just took their credit card info and put it in Quickbooks and Authorize.net with their initial monthly recurring charge.

Buried in BAM

Over the course of a few years, we grew from 0 customers to 1,000. And slowly but surely, probably by month 6 or 12, we got burried in BAM. We had a combination of software & people involved every day just to keep up.

That’s very expensive in terms of operational costs, plus customer dissatisfaction, plus the inability to report on all of that activity.

Engine Yard started reining in these costs in 2009, but I wish a better solution had existed earlier.

How We Got Buried

Here’s what happened. I think it’s pretty typical:

  • It’s easy to get started with tools like Quickbooks and Auth.net to set up simple recurring billing of ‘x’ dollars per month on a customer’s credit card. When you just want to get a customer set up, this is quick and simple, but the simplicity is short-term because…
  • Customers add & remove products, so you need to prorate charges for products they added or removed. Someone can figure out how much to prorate for the current month and run a special charge/credit for it. Whether or not you bother with proration for the current month, you need to change the automatic recurring amount in whatever system it exists.
  • You’ll change pricing over time. We did so 4 times over a couple of years. We gave existing customers 1 year of grandfathered pricing, which added another layer of complexity to pricing when customers added/removed products.
  • Some customers get special pricing because they’re in a special group, such as a charity, school, or reseller. Another layer of pricing.
  • Credit cards get declined or expire, so someone needs to resolve these issues. I later learned that this process is called “dunning”.
  • As you figure out what your customers really want, you’ll change your products. We offered different kinds of slices, as well as a la carte pricing of things like RAM and bandwidth.
  • This is where “metered billing” comes into play. Unlike pre-paid flat-rate plans mentioned so far in this story, this is where customers pay ‘x’ amount per ‘y’ widgets used in the previous billing cycle. Metered billing is growing in popularity – we barely heard about it in Q4 2009 but now we’re hearing of more customers planning metered plans along with flat-rate plans.
  • As your business grows and you get a finance person, you’ll discover that some charges must be “recognized” over different periods of time. We found out that set-up fees are supposed to be recognized over the expected life of the customer. I had never heard of “revenue recognition”. Wouldn’t it be nice if your BAM system could help with things like this?

As you can see, Engine Yard quickly outgrew the systems we started with, and we had almost no ability to report on all of this activity because the data was either spread across different systems or just didn’t exist.

We were paying a lot for a bad BAM system.

Seeking Salvation

Sometime in late 2008, we sought salvation. We wanted something that had at least most of the things I defined above as BAM.

I assumed that someone like 37signals offered something like “Basecamp for BAM”, that it would cost a few hundred dollars a month, and that it would be easy to sign up anytime and get going. I envisioned defining our products and pricing, then manually entering customers until our developers integrated the app’s full-featured API.

I may have literally dreamt about it!

Well, it didn’t exist as I envisioned. It did exist, but targeted at larger enterprises. We chose a vendor and started on the road to finalizing a deal and doing the integration. Meanwhile, some of our internal development teams created a new cloud hosting offering and built a lot of their own BAM features, too.

I left Engine Yard on very friendly terms in May 2009, so I don’t honestly know exactly how everything turned out. I think it turned out okay. My only complaint would be time and costs. Remember, my original vision was for something done in weeks or months at relatively low cost.

After Engine Yard…Chargify

After I left, I reflected on the major pain points that we experienced running our business. I realized that the whole BAM thing was a huge pain for us *and* for many of our customers, who were also going with the recurring revenue model in their businesses.

Everyone was re-creating the wheel! Most were probably avoiding it altogether until the last minute, just like we had in 2006.

I spent the month of July thinking about the problem and a potential solution. Then, at the end of the summer, I heard about a small startup called Chargify. They were based in Boston, so I hopped on a flight and spent a couple of days getting to know the people and their technology.

They had made good decisions going back 6 years! Chargify was an offshoot of Grasshopper, which had a track record of business success *and* it involved complex billing.

Chargify was a greenfield app, meaning it was all new technology, but with wisdom gained from Grasshopper. The best of both worlds!

I liked what I saw and presumably they did, too, because we struck a deal after I returned home. I joined as co-founder and CEO in November 2009.

Charging into 2010!

I’ve seen small teams before that are enthusiastic and can really execute on a great idea. Our team is that! And the team is growing – we added team members over the holidays and are continuing to do so.

Customer response is incredibly strong. I’m really impressed by the sheer quantity of beta customers and the enthusiasm with which they’ve helped us shape the product.

We’re part of a larger trend of outsourcing non-core parts of ones business to someone for whom it *is* core. For instance, Chargify uses Basecamp, Campfire, Prefinery, Survey Monkey, Tender, and Tracker. This allows us to focus on BAM while those other services get better and better.

We’re planning to use this new blog as a resource for information about BAM and about related entrepreneur, startup, and business ideas. If you have suggestions for this blog or for Chargify, please let us know.

Thanks!