When the client says “this isn't what we asked for”
By PitchDawn · August 09, 2026
The demo is four minutes old when the client interrupts.
“Stop. This isn’t what we asked for.”
Your Business Analyst opens the signed requirement. The tech lead remembers the walkthrough where this exact approach was discussed. The delivery manager can already feel the call turning into an argument about who said what.
Everyone on your side wants to prove that the team followed the brief.
That instinct is understandable.
It is also how a requirement mismatch becomes a trust problem.
The first goal is not to prove who is right
When a client rejects what they see, there may be several different failures hiding behind the same sentence.
The documented requirement may be incomplete. The client's expectation may have changed. Your team may have implemented the words correctly but missed the business intent. The right stakeholder may never have reviewed the decision. Or the demo may simply be showing the feature in a context the client does not recognise.
If you defend the artifact before identifying the mismatch, you force the client to argue harder.
The goal of the first five minutes is simpler: turn “this is wrong” into a specific, testable gap.
The RESET framework for requirement disagreements
Use five moves: Receive, Extract, Separate, Examine, Trade.
1. Receive the reaction without starting the defence
Your opening line sets the emotional direction of the call.
Not:
“This is exactly what was approved in the requirement document.”
Instead:
“I can see this is different from what you expected. Let’s isolate the mismatch before we decide what needs to change.”
You have not accepted blame. You have accepted that the expectation and the demonstration are not aligned.
That distinction matters. Acknowledging the client's experience lowers the need for them to prove that the problem is serious.
2. Extract the first observable mismatch
“It is all wrong” is not yet actionable.
Ask the client to identify the first moment where the workflow stops matching their expectation:
“At which step does this become different from the process you expected?”
Or:
“When the manager approves the request, what did you expect the system to do next?”
Do not ask five questions at once. One focused question gives the client room to describe the gap in their own language.
This is where listening discipline matters. The habit described in why engineers overtalk on client calls becomes especially costly when the team is eager to explain its reasoning.
3. Separate the outcome from the solution
Clients often describe a solution because it is the easiest way to make an outcome concrete.
They may say, “We asked for approval routing,” when the underlying need is, “Junior users must not publish without review.”
Confirm both layers:
“The business outcome is that unreviewed content cannot go live. The workflow you expected was a manager approval before publishing. Is that accurate?”
This gives the conversation room to find the best correction. The expected workflow may be necessary, or another implementation may protect the outcome with less disruption.
Without this separation, teams can spend days correcting the visible screen while leaving the original business risk unresolved.
4. Examine the evidence together
Now bring in the requirement, prototype, acceptance criteria, call note, or decision log.
The posture matters.
Not:
“Here is the email where you approved it.”
Instead:
“Let’s compare the approved flow with the outcome we just clarified and find where the interpretation separated.”
The first line uses documentation as a weapon. The second uses it as a diagnostic tool.
You may discover that the acceptance criteria covered the happy path but never described the restricted-user case. You may find that one stakeholder approved the wireframe while another owned the operating process. You may also find that the client is asking for a genuinely new capability.
Evidence should make the source of the mismatch clearer. It should not make the relationship colder.
5. Trade the next move explicitly
Once the gap is clear, state what will change—and what that change affects.
For example:
“We agree the restricted-user case is missing. We can add it before release, which moves testing by three days, or keep the current date and deliver that path in the next patch. I recommend moving testing because the control affects the core publishing risk.”
If the request is new scope, do not hide behind the phrase “change request.” Make the delivery choice visible.
If the team misunderstood the approved requirement, own it plainly:
“The approved criteria included this case, and we implemented it incorrectly. We will correct it without changing the commercial scope and confirm the revised date tomorrow.”
Clarity is more credible than a carefully worded non-apology.
What most teams get wrong
They litigate the requirement on the live call
The BA quotes a sentence. The client quotes a meeting. The tech lead explains what was technically possible at the time.
Ten minutes later, everyone has more evidence and less trust.
Use the call to define the mismatch and agree on the decision process. If the evidence needs detailed review, assign owners and a checkpoint rather than reading months of project history aloud.
They apologise before they know what failed
“Sorry, we misunderstood” may calm the moment, but it creates a commitment before the facts are clear.
Receive the impact first. Investigate the source second. Own the failure precisely once you know it.
This is the same evidence-first discipline that protects credibility when you must handle a client escalation call.
They fix the screen but not the communication system
A requirement mismatch rarely belongs to one sentence alone.
Ask what allowed it through: Was the business outcome missing? Were acceptance criteria never demonstrated? Did the decision maker skip the walkthrough? Did the team avoid challenging an ambiguous requirement?
For agency leaders, repeated mismatches across different delivery managers point to the wider consistency problem covered in why client-call quality varies across teams.
Correct the feature. Then correct the mechanism that made two groups leave the same conversation with different pictures.
Knowing RESET will not remove the pressure
The difficult moment is not reading the framework. It is hearing “your team got this wrong” while the client waits for an answer and your own colleagues begin defending the work.
That pressure changes your pace, empathy, and judgment.
PitchDawn's stakeholder and escalation modes let Business Analysts, tech leads, and delivery managers rehearse that live conversation with adaptive AI client personas. Real-time coaching flags defensive phrasing, missed concerns, and weak next steps; the debrief shows the exact moments where the conversation lost clarity. Explore the practice modes on the PitchDawn features page.