March 15, 2017

The perverse incentive of support contracts

Okay, sorry... one more thing about guarantees.

Let’s say Alice does a $10k custom website build for Bob.

Once the site launches and everyone is happy, Alice offers Bob a $300/mo month support contract under which she’ll fix any bugs.

Think about this.

Alice now wants some bugs to crop up.

If they don’t, Bob’s not going to want to keep paying her $300 per month.

Perversely, Alice might have even subconsciously lowered her QA standards during the project knowing that she’d be paid to fix things later.

Let’s say bugs start cropping up, and Alice fixes them under the terms of the support contract.

Bob will perhaps be satisfied that Alice is keeping up her end of the bargain regarding support, but what’s he going to think about Alice’s level of quality for the initial build?

Bob could easily start to feel like he’s being nickel and dimed.

You can imagine a thought like this crossing his mind:

“We have a brand new website - why is it so buggy?!”

Now...

Imagine that instead of Alice charging $10,000 for the build and $3,600 (paid monthly) for 12 months of support, she charged $13,600 for the build and included a 12-month unconditional bug-fix guarantee.

With the guarantee approach, Alice is incentivized to have zero bugs.

The perverse incentive of the support contract disappears.

Bob is happier, because he doesn’t have to make an economic decision every month (and of course, because he there are fewer bugs annoying the prospects and customers on his website).

And in all likelihood, Alice could charge a premium for the project (say, $25,000) because unlike any of her competitors, she stands behind her work with an unconditional guarantee.

This would mean that she would be charging more for doing less, AND making her client happier in the process.

Sounds like a no-brainer to me.

Yours,

—J