How, When & Why to Refund a Web Design Client

Chalk one up for transparency. Well here it goes. I gave a client a sizable refund last week. It doesn’t happen often, but it was the right thing to do. What makes it right? I’ll get to that.

What happened

A client came to us in 2010 and was very excited about their project. It was an online business idea. The project involved a unique and original way to market a product and the project required some custom e-commerce programming.

Web Design Refund cartoon

Business as usual

We have the client in for the discovery meeting, the design meeting, a custom programming meeting, we get our approvals – and we’re in production. Then all goes quiet. Email and calls to the client go unanswered. When the client does contact us, its to increase the scope of the project by adding more custom programmed e-commerce features and capabilities.

We inform client that increasing the scope of the project will increase the cost. We invoice for the additional work – and all goes quiet again. This cycle happens again a few months later. We receive requests for additional functionality and we again outline the requests and send an additional scope modification document and invoice to the client.

At this point the client has an approved custom website design built and ready for custom programming (the crux of the web project) and two sets of invoices from us, both detailing the increase in scope the client requested.

Festering Frustration

At this point we have a client that is frustrated because his ideas and needs have grown larger than the project’s budget. We also have a client on the books for over a year. And we know the longer it takes a project to get completed – the higher the client dissatisfaction. It doesn’t matter if the client is responsible or not.
Prolonged build-outs = client dissatisfaction.

Ideally, we want the client satisfied and if possible – happy enough to enthusiastically recommend our company to others. But the relationship is now strained and the client says he doesn’t want to pay for features he “originally envisioned” – even though the documented project has clearly outgrown its original specifications. We thought it wise to work toward a parting of the ways with this particular client. So what to do? Two choices:

  • Build out the client’s project, the way they want it, eat the cost and hope they don’t “originally envision” any additional features along the way. On this project, we’d stand to lose quite a bit of time and money.
  • Calculate the hours invested and offer a refund on the balance of the unused hours.

We offered the second plan and the client agreed. Along with the refund check, we included a disk with the design and development work completed (and paid for) up to this point, so the client could take the project to another web developer if he so desired.

I wish I could tie this all up with a cute little bow, but I can’t. Writing a refund check is kind of sucky, but exiting a less-than-mutually beneficial client relationship is preferred and most profitable in the long run.