When the Answer Is NO… but the Client Won’t Take NO for an Answer

[#1]

At some point, we have all had to say NO to a request, a requirement, or something a client wants.

Sometimes the reason is technical: the tool does not support it, the infrastructure is not prepared for it, or the requested behavior is simply not possible. In other cases, the reason may be related to policies, security, scope, or other constraints.

In most cases, the client understands the limitation and looks for an alternative way to achieve what they need.

But what happens when the client simply won’t take NO for an answer?

What should we do? How should we proceed? And more importantly, should we change our answer just because the client does not like it?

The Situation

I faced a similar situation with a support ticket where a client requested a change to an existing process.

The challenge was that this process was shared across hundreds of projects, so making the requested change would have affected how the process worked for everyone else.

There was also an important internal policy to consider: projects could not be individually customized. This meant I could not modify the process specifically for that particular project while keeping the existing behavior for all the others.

In other words, the requested change was not something we could safely or appropriately implement.

The answer was simply: NO.

The Client Said NO to the NO

The client did not accept the initial NO and insisted on the request.

We reviewed the situation again and provided a more detailed explanation of why the change could not be implemented. The answer was still NO.

The client continued to insist and eventually escalated the ticket for further review by my team, including the relevant process owners and our team lead.

After reviewing the request, the conclusion remained exactly the same:

NO.

The Reflection

The ticket was eventually closed without implementing any changes — exactly as we had determined from the beginning.

Looking back, however, I realized that the insistence had extended the discussion without changing the outcome.

At first, I was honestly a little frustrated. I'm human, after all, and it is not easy when you feel that your professional judgment is being dismissed.

But after a few days, I started looking at the situation differently.

Maybe the question was not whether the client wanted to accept the NO.

Maybe the client simply couldn't accept the NO.

And those are two very different things.

Looking at It From the Client's Side

That led me to another question:

What if the client was simply doing their job?

Maybe they were only the person responsible for submitting the request, while their own managers expected them to find a way to make it happen. Perhaps saying “the implementation cannot be done” was not an acceptable answer on their side either.

In that case, maybe both of us were simply doing our jobs.

I was responsible for explaining why the request could not be implemented and standing by that decision. The client, on the other hand, may have been responsible for finding a way to get the requested outcome.

I had been looking at the situation entirely from my side. I had never stopped to consider what the situation might look like from the client's perspective.

And that made me wonder:

When a client won't take NO for an answer, are we looking at the situation only from our side?

Of course, this is only an assumption. Maybe the client simply disagreed with the answer, or had other reasons for insisting. I'll never know for sure.

But what if they were simply following instructions from their own organization?

What if, from their perspective, NO wasn't an answer they were allowed to take back to their managers?

The Takeaway

In the end, the technical answer was clear: the change could not be implemented, and escalating the ticket did not change that answer.

But the experience made me realize that there is more to these situations than simply deciding whether a request is technically possible or not.

Sometimes, saying NO is the right thing to do. We have to respect technical limitations, policies, scope, security, and the impact that a change could have on other users or projects.

At the same time, when a client keeps pushing after hearing NO, perhaps the first question should not be “Why won't they accept my answer?”

Maybe it should be:

“Why is this answer not acceptable for them?”

Understanding that difference does not mean changing our answer or making exceptions that should not be made. It simply means trying to understand the problem from both sides.

Maybe the client needs a different solution. Maybe there is pressure coming from their organization. Maybe they are accountable for an outcome they cannot achieve with the current limitations.

Or maybe they simply don't agree with us.

We may never know.

But perhaps that is part of being a consultant: knowing when to stand by a NO, while still taking the time to understand why the other side needs a YES.

So, how do you handle these situations?

When a client won't take NO for an answer, do you keep defending the NO, look for an alternative, or try to understand what is behind their insistence first?