How to Say No to a Client
Saying no is not a failure to sell. On a long enough timeline it is most of the job.
Nobody hires a WordPress shop because the shop agrees with them. They hire it because they want the thing to work, and sometimes the fastest route to that is a conversation where somebody says the plan is wrong. That conversation is uncomfortable every single time. It is also the most valuable thing in the engagement, and it gets skipped constantly, usually by people who are afraid the client will walk.
There are three moments where a no is required. The brief is wrong. The project is wrong. Or the client is wrong. They look similar from a distance and they need completely different handling.
When the client cannot name what they need
Early on at previous company we had a client arrive with the best documentation we had ever seen. Flow charts. Wireframes. Every screen mapped. We looked at it and thought, she has really thought this through.
So we picked up our common sense and chucked it out the window, and built exactly what she asked for.
When she reviewed it, she told us it was not at all what she needed. That genuinely caught us off guard, which in hindsight is the embarrassing part. We got on a call, went through the project properly, and ended up throwing out the original spec and rewriting it from scratch. All of which should have happened before anyone wrote a line of code.
What followed was a month of rebuilding, an argument about cost because the real requirement was substantially more complicated, and a pile of frustration that was entirely avoidable.
Here is the part worth sitting with. When we went back through her original documentation afterward, we found place after place where we should have raised a flag and suggested a different route. The information was there the whole time. We had it in hand before we started. The mistake was not that she gave us a bad spec. The mistake was that we did not ask enough questions, because the spec looked too good to question.
I had learned this lesson already and forgotten it. At the job I held before starting the company, it was just me and my boss for a long stretch. He could sell anything. Everything technical landed on me. He would explain what he wanted, I would go away and build it, and the bulk of whatever success I had there came down to listening carefully to what he asked for and then building the thing that would actually accomplish his goal instead.
His wants and his needs were almost never the same thing. Neither are your client’s. A detailed brief is a description of a want. Your job is to find the need underneath it, and the only tool for that is questions.
When the client is the problem
The first two are project problems. This one is not, and it needs to be handled differently.
Not every project goes smoothly. Sometimes that is on you. Sometimes something goes wrong and nobody is specifically at fault. When it does, whoever is to blame, it helps enormously to be working with someone reasonable.
Reasonable does not mean unemotional. If a client gets upset when something goes wrong on a thing they have spent real money on, that is a human being behaving like a human being, and it is fair. Upset and unreasonable are different. One passes. The other is the relationship.
Firing a client is not something to take lightly. Over five years at previous we did it twice, and I hated it both times, largely because I will go a long way to avoid confrontation. That tendency has a cost. It meant I let clients get away with things I should not have put up with, for longer than I should have.
Most difficult relationships never need the nuclear option. Every client comes with a personality and not every personality is one you can work with, and ideally you find that out on the calls that happen before anyone signs anything. But people change over the course of a project. Where someone started out fine and turned unpleasant, the usual move is to finish the work as quickly as we can and move on. If they come back with more work afterward, we decline politely. No harm, no foul.
Two things to be clear about.
Firing a client is not an escape hatch for your own bad estimate. If you underbid and the client is holding you to the quote you gave them, that is on you. The contract and the statement of work protect them as much as they protect you. That is the entire point of them.
There is a shortcut a client can take to get there faster. When someone is rude or disrespectful to the people I work with, my patience shortens considerably. You see this in every kind of business. The client is charming with the owner and insufferable with the staff. That one moves quickly.
Otherwise the real threshold is this: you have gone above and beyond, and you have arrived at the conclusion that there is no pleasing them. Calls start escalating into raised voices. The relationship has picked up a layer of tension beyond the ordinary pressure of delivering for a demanding client. That is the point to consider parting ways.
The gauge
Here is the cheapest diagnostic I know.
You are at your desk. You are not busy. The phone rings, you check the caller ID, you see it is a client, and your first instinct is to send it to voicemail.
That is your answer. It arrives well before you are ready to act on it, which is exactly why it is worth paying attention to.
Where this comes from
In 2014 I gave a ten minute lightning talk at WordCamp Minneapolis covering a set of lessons I wished somebody had told me before I started my company, then a longer version at WordCamp Tampa later that year. The response to both is why any of this got written down.
The previous company started on October 1st, 2009 with two friends, out of a corporate job I had loved for nine of the ten years I was there. The plan was nights and weekends for a year to see whether it would work. We had all quit our day jobs within three months. It somehow still included nights and weekends.
Several hundred clients later, most of what I know about this came from getting it wrong first.
