Pricing Annual Technical Support

Several years ago, I made my biggest business mistake.  One of our clients asked us to change how we billed our ongoing technical support.  And without thinking through the second- and third-order effects, I did.

We were billing by the hour, but only sending out invoices quarterly.  This led to unpredictable charges.  From one quarter to the next, our invoices would swing wildly from low to high.  Our client asked us to switch to a single annual price.  

That's exactly what we did.  But we priced it too low.

Why Did I Do It?

Several circumstances contributed to my error.

Inexperience

I had just started making business decisions as I transitioned from employee to owner.  Like most inexperienced consultants, I was terrified of pricing myself out of a job.  I use the word "job" intentionally.  I wasn't really running a business (at least not in my head).  Sure, I was technically the owner of a privately held corporation, but I was still acting like an employee who just happened to sign his own paychecks.

The last thing I wanted to do was risk losing revenue from one of our biggest clients.  

Which brings me to my next point.

Whales

We only had a couple of big clients.  We had been working for these clients for decades.  They provided a steady stream of ongoing maintenance work and regular feature and program requests.  We were treated like an internal development team.  But that's because we acted that way.

We weren't doing work for them.  We were working for them.

This was a "whale client" for us.  They probably accounted for about 40% of our annual revenue at the time.  We had software in several different departments.  The "whale client" was actually more of a parent to many "sub-clients."  But the demand to change our billing practice was coming from the "whale."

Because so much of our revenue was tied up in this one client, I had a strong incentive not to risk losing the client's business.  This is the danger with whale clients in general.  We probably wouldn't have changed our business practices to please a smaller client.

The wrong kind of "fair"

I try to treat people and clients fairly.  If we had charged a department an average of $5,000 per year for the previous three years, then I felt it would be unfair to charge them more than $5,000 as an annual price.  

But that thinking did not account for the difference in risk between the two models.  Under the hourly model, our client bore all the risk.  Under the fixed price model, the risk shifted to us.  

In business, risk has tangible value.  Businesses will pay good money if you can reduce their risk.  As Jonathan Stark points out, "There’s a word for taking on risk for another party: Insurance. And there’s a word for what people pay for insurance: A premium. When you take on risk for your client, you are entitled to charge a premium."

It would have been perfectly fair, then, for me to charge well over $5,000 a year as an annual price.  

Why Didn't I Fix it?

If I knew this three years ago, why did I wait so long to fix it?  

My personality

I'm a very non-confrontational person.  The thought of haggling with someone over prices makes me sick to my stomach.  

I'm also a people pleaser.  I love to help people.  I hate to disappoint them.  This is not some humble brag ("My biggest weakness?  Gosh, I'm just too darn nice."); it's borderline pathological.  Don't think "nice."  Think "doormat."

I would make a terrible negotiator.

Monopoly consciousness

Almost all of our ongoing support work is for programs that we wrote.  It would be very difficult for our client to bring in other third parties to provide this support.  Given that, I'm conscious of the fact that we have a practical monopoly on this business.

Of course, if I tried to exploit this monopoly by charging exorbitant fees, then our client would have an incentive to seek alternative support providers or different software altogether.

But, because I was so conscious of this "monopoly" dynamic, I felt bad suddenly raising my rates.  It felt like I was issuing an ultimatum.  To borrow a line from the Godfather, I'd feel like I was presenting my client an "offer they couldn't refuse."

How Did I Fix It?

This part took awhile.  For all the reasons above, I was hesitant to make any changes to the status quo.  It wasn't until I started noticing that I was beginning to resent helping my clients that I realized I was on a very unhealthy path.

Addressing my concerns

What's the best way to avoid issuing ultimatums?  Give your clients a choice.  Instead of offering a single, take-it-or-leave-it annual price, I could give them a choice between the all-inclusive upfront option or the pay-as-you-go hourly option.

I still had one more problem.  I was drastically underpricing my all-in-one support prices.  But my clients had grown accustomed to them over time.  With few exceptions, I had never increased the annual price more than about 10%, year over year.  Suddenly increasing that price by 80% in a single year would have generated major pushback.  And you know how I feel about confrontations.

The other thing that troubled me was that I was only offering two options.  When offering clients choices, three is the magic number.  Two options feels limiting.  Four or more options leads to analysis paralysis.  Three is just right.  I needed a third option.

My third option became a hybrid of the first two.  Option 1 was the straight hourly rate.  Option 2 was the all-inclusive, pay one price upfront model.  Option 3 was a prepaid number of hours offered at a discounted rate (~80% of the normal hourly rate).

Examples

To make the math easy, let's say our hourly rate is $100 per hour.  Last year I billed the client $4,000 for our annual support.  I would offer the following three options:

1. Hourly support at $100 per hour
2. All-inclusive unlimited support for the year, $7,000
3. 50 hours of prepaid support for $4,000 ($100 per hour over 50)

Here's how these options play out in four scenarios with a varying number of total support hours for the year.  The first dollar amount is the client's out-of-pocket costs for the year.  The second number is our effective hourly rate:

10 support hours used

1. $1,000 ($100/hr)
2. $7,000 ($700/hr)
3. $4,000 ($400/hr)

50 support hours used

1. $5,000 ($100/hr)
2. $7,000 ($140/hr)
3. $4,000 ($80/hr)

100 support hours used

1. $10,000 ($100/hr)
2. $7,000 ($70/hr)
3. $9,000 ($90/hr)

200 support hours used

1. $20,000 ($100/hr)
2. $7,000 ($35/hr)
3. $19,000 ($95/hr)

Properly priced risk

I explicitly state in my proposal that Option 1 is the highest risk option for the client but the lowest risk option for us.  The three examples above bear this out.  We make an effective hourly rate of $100/hr for Option 1 in all four scenarios.  But look at the client's total cost.  It swings from $1,000 in the first scenario to $20,000 in the last scenario.

I then point out that Option 2 is the lowest risk option for the client and the highest risk option for us.  Our effective hourly rate ranges from $700/hr down to $35/hr in the scenarios above.  But the total cost for the client is $7,000 in all four cases.

I close by explaining that the hybrid model allows us to share the risk.  For the client, it's usually not the cheapest, but it's never the most expensive.  It provides them with budgetary stability, so long as they keep their support requests under control.  To help with that part, I agree to provide the client with monthly updates of their hours used and how many hours still remain before they have to start paying additional fees.

Key to success

The most important part of this exercise is identifying the best case, worst case, and likeliest case for total annual support hours.  

I erred on the side of making my option 2 number too large.  This avoids the possibility of an absurdly low effective hourly rate.   And even if that number is too high for the client to really consider, it acts as an anchor to make the Option 3 number more appealing.

I recommend multiplying your worst-case total support hours by your hourly rate to calculate an Option 2 price.  For Option 3, I recommend adding about 20% to the likeliest case and using that as the number of prepaid support hours.  Then set the price so that your effective hourly rate is 75% - 80% of your normal hourly rate.

Alternatively, for Option 2, you can do what I did for this year.  Start with the upfront price and divide that by 80% of your hourly rate to come up with the number of prepaid support hours.  I only recommend this, though, if you have some reason to use a specific upfront price.

Untested concept

Now that I've spent over fifteen hundred words patting myself on the back, I suppose it's as good a time as any to admit that I have not actually proven this concept yet.  I implemented this new approach less than a week ago.  I still haven't heard back from most of my clients on which option they've picked.  

And yet, I have already noticed a change in my attitude dealing with support requests.  I no longer feel like I'm going to be taken advantage of.  Even if a client purchases an unlimited support package, I've built enough buffer into it that I won't feel like every call and email is costing me money.

Will this work?  Who knows.  The only thing I know for sure is that it's got to be better than what I was doing before.

[NARRATOR]: Nothing guarantees it will be better than what he was doing before...

Image by Alessandro Squassoni from Pixabay