4 min read

Is It Really Out of Scope? Your Client Doesn't Think So.

They're sure it was included. You're sure it wasn't. Both of you are being honest, and neither of you can prove it — which is how a scope question turns into a trust problem. Here's how to stop having this conversation.

Is it really out of scope? Your client doesn't think so.

The email arrives on a Tuesday.

“Just checking in on the reporting export — we’d assumed that was part of this phase. When do you think we’ll see it?”

And your stomach drops slightly, because you’re fairly sure it isn’t part of this phase. You remember it coming up. You remember someone saying it’d be a later thing.

You’re fairly sure. Not certain. And “fairly sure” is a terrible place to be arguing from with a client you like and want to keep.

Both of you are telling the truth

This is the part that makes it so uncomfortable, and it’s worth saying plainly: your client is almost never trying to get free work out of you. And your team is almost never trying to quietly cut something. Two people leave the same call with different memories of it, and both memories are honest.

Usually it traces back to one sentence. Someone says:

“Yeah, we can look at that in a later phase.”

To the client, that sounds like yes — it’s coming, just not first. To your team, it sounds like no, not in this budget. Same eleven words. Two completely different meanings, and nobody writes either one down.

Three months later there’s no record. No line in a doc, no ticket, no email. So what was agreed comes down to who remembers more confidently — and a scope question has quietly become a trust question, which is a much worse conversation to be in.

And it happens again next quarter, on a different project, over a different sentence.

Why the contract doesn’t save you

The instinct is to blame the statement of work. Be more specific next time. Add an exclusions list.

It helps a little, and it can’t fix this. The SOW gets written before anyone knows where the ambiguities are. The reporting export isn’t a known unknown in week one — it comes up in week six, in a discussion about something else, and gets a soft answer because at the time it genuinely is a “we’ll see” thing.

You can’t write a contract that covers a sentence nobody has said yet.

The fix is boring: write it down when it’s said

Every team that gets out of this pattern does the same unglamorous thing. They capture “not this phase” the moment it’s said — not in someone’s head, not in a note nobody revisits, but somewhere the whole team and the client can point at later.

The catch is that this never survives contact with a busy week. Whoever’s taking notes is capturing action items and decisions. “We’ll look at that later” isn’t an action item, so it doesn’t get captured — even though it’s often the most expensive sentence in the entire call.

So it has to happen automatically, or it doesn’t happen.

What Spectr does about it

When Spectr processes a meeting, it doesn’t only pull out what you agreed to build. It also pulls out what was pushed back, excluded, or deferred — from the same conversation, at the same time.

Those land in a simple list for the project. Each one arrives as a suggestion, not a verdict, and someone on your team decides what it is:

  • Confirm it — yes, that’s genuinely out of this phase
  • Defer it — it’s in, but later
  • Dismiss it — the AI misread the room, this was never a scope question
  • Approve it back in — we’ve decided to do it after all

Nothing is confirmed automatically. The AI isn’t adjudicating your contract; it’s making sure the sentence gets written down at all, so a human can rule on it while the call is still fresh.

Then it stays useful. If a story turns up later that looks like it belongs to one of those deferred items, Spectr links the two and flags it — so out-of-scope work shows up marked, instead of quietly sliding into a sprint because it seemed small.

What this actually buys you

Not ammunition. That’s the wrong goal, and clients can smell it.

What it gives you is a dated line — “deferred to a later phase, from the March 14 call” — and that changes the shape of the conversation completely:

“Good catch — here’s where that came up and what we captured at the time. It looks like it landed as a later-phase item, which is probably why it’s not in this sprint. Want to talk about pulling it in? Here’s what that would mean for the timeline.”

That’s a scope change conversation. Concrete, calm, forward-looking, and about a shared record rather than duelling memories. Your client can disagree with the record — but now you’re both looking at the same thing, and disagreeing about a decision instead of about who’s remembering correctly.

Nine times out of ten that email isn’t a fight. It’s someone genuinely unsure, and the fastest way to defuse it is to be able to answer immediately and specifically.

The point

Your client isn’t wrong for remembering it differently. Human memory is just not a project management system, and it was never going to be.

You’re not trying to win the argument. You’re trying to never have it.


Spectr captures what was deferred or excluded from a meeting alongside everything else it pulls out — so three months later, “is this in scope?” has an answer with a date on it. Free tier available. Try it at spectr.pm.

Published byCrowdlinker
Try Spectr free
Was this useful?