When a client asks for an estimate on the spot
By PitchDawn · August 14, 2026
The discovery call is going well.
The client has explained the new customer portal, shown two screens, and mentioned an integration that “should be straightforward.” Your team has asked useful questions. Nobody has seen the existing codebase.
Then the client says:
“Can you give me a ballpark now? I need a number for our budget meeting on Friday.”
The sales lead looks at the tech lead.
The tech lead looks at the BA.
You know that any number you say may appear in a follow-up email without the word ballpark.
But refusing to answer can make the team sound slow, overly cautious, or commercially inexperienced.
This is not a choice between guessing and saying no.
It is a communication problem: how do you give the client something useful without presenting uncertainty as certainty?
The client needs a decision, not a prophecy
When a client asks for an immediate estimate, the number is usually meant to support another decision.
They may be deciding whether the project fits this quarter's budget. They may need to compare two approaches. They may be preparing a board update, narrowing a vendor list, or checking whether the idea is commercially realistic.
If you answer the number without understanding that decision, you can be technically careful and still be unhelpful.
A useful early estimate does not pretend to be accurate. It shows the client what is known, what could materially change the answer, what range is reasonable today, and what will make the next answer stronger.
That is what the RANGE framework is for.
The RANGE framework for on-the-spot estimates
Find the decision
State what is known
Expose material unknowns
Offer a conditional range
Set the next validation
1. Reveal the decision behind the number
Do not begin with a disclaimer.
Ask what the estimate needs to help the client decide.
Not:
“It is too early for us to estimate this.”
Instead:
“I can give you a useful range. Before I do, what decision does the number need to support on Friday: budget approval, vendor selection, or the target launch?”
That question changes the conversation.
A client testing whether the project is closer to £30,000 or £100,000 does not need sprint-level precision. A client promising a date to its own customers needs a much higher standard of confidence.
The purpose of the estimate determines the precision it deserves.
2. Anchor the scope you actually understand
Repeat the known boundary before giving a number.
This is not a full requirements summary. It is a compact statement of what your estimate includes.
“Based on today's discussion, I am estimating the first release: customer registration, subscription payment, the account dashboard, and one standard CRM integration.”
Now both sides can hear the same scope.
If the client expected migration, custom reporting, and an admin workflow too, that misunderstanding can surface before the number hardens into a promise.
This is the same discipline that prevents the “this isn't what we asked for” moment later in delivery: shared language has to exist before shared expectations can exist.
3. Name only the unknowns that can move the estimate
Technical teams often respond to uncertainty with a long list.
Authentication. Hosting. Data model. API quality. Browser support. Security review. Deployment access. Test environments.
The list may be correct.
It still sounds like fog.
Name the two or three unknowns that could materially change the range, and explain their consequence in delivery language.
“Two things could move this significantly: whether the CRM has a usable standard API, and whether historical customer data must be cleaned and migrated. The first affects integration effort; the second could add a separate workstream.”
You are compressing complexity into something the client can act on, just as you should when explaining technical trade-offs to a non-technical client.
Do not hide the unknowns.
Rank them.
4. Give a conditional range, not a disguised commitment
A range without conditions is just two guesses instead of one.
Connect the range to the scope and unknowns you just named.
“For the first release as we have defined it, I would use eight to twelve weeks as the planning range. Eight assumes the CRM supports the standard integration and the data is clean. If either assumption fails, we should expect the upper end or treat migration separately.”
This answer gives the client a number.
It also gives them the logic behind the number.
Avoid false precision such as “nine weeks and three days.” Early estimates should communicate confidence honestly. A sensible range with named assumptions is more credible than an exact date produced before discovery.
5. Establish how and when the estimate becomes firmer
Do not end with the range.
End with a validation step, an owner, and a date.
“If you can give us API documentation and a sample data export tomorrow, we can run a ninety-minute technical discovery and send a refined estimate with exclusions by Tuesday.”
That turns uncertainty into a process.
It also protects both teams from remembering the early range differently. Follow the call with a written recap that repeats the scope, assumptions, range, confidence level, and next validation.
Otherwise the lower end of the range has a habit of becoming the deadline, while every assumption quietly disappears.
What a strong answer sounds like
Imagine the client asks:
“Can phase one be live in eight weeks?”
A weak answer sounds decisive:
“Yes, eight weeks should be possible.”
It creates confidence for thirty seconds and risk for the next two months.
A RANGE answer sounds like this:
“Eight weeks could be achievable for the registration, payment, and account-dashboard scope we discussed.
The two things I would not assume yet are the legacy-data migration and the CRM API. If the integration is standard and migration stays outside phase one, I would plan around eight to ten weeks. If we include data cleanup and migration, it is more likely ten to fourteen.
Is the eight-week date tied to a public launch, or are you checking whether the project fits the quarter?
If you share the API documentation and a data sample, we can validate those assumptions and give you a firmer answer on Tuesday.”
Notice what this answer does not do.
It does not refuse.
It does not promise.
It gives the client a usable planning range and a route to greater certainty.
What most teams get wrong
The magic-number reflex
Someone senior is waiting, so the team gives one number to look confident.
The problem is not that the number might be wrong. Early numbers are often wrong.
The problem is that nobody explained what would make it wrong.
Once the call ends, the number travels farther than the caveat. It appears in the proposal, the client's internal plan, and eventually the delivery team's backlog.
The defensive “it depends”
“It depends” is usually true.
It is not yet an answer.
If you say it, complete the sentence:
“It depends mainly on the CRM integration and data migration. Here is the range under each condition.”
Uncertainty becomes useful only when you structure it.
The sales promise and delivery correction
This failure is especially expensive for small software agencies.
The pre-sales team offers an optimistic number to preserve momentum. Delivery joins later and adds the missing assumptions. The client experiences the correction as a change in position, even if the new estimate is technically better.
That credibility gap is difficult to repair. It also creates the conditions for scope-creep conversations that feel defensive, because the original estimate never had a clear boundary.
Agency leaders should standardise the language around estimates, not force every person to produce the same number. Every early estimate should state the known scope, material unknowns, conditional range, confidence level, and next validation.
That is a communication standard your sales, BA, pre-sales, and delivery teams can all follow.
Reading the framework will not remove the pressure
The difficult part is not understanding RANGE while reading quietly.
It is using it when a budget-conscious CEO asks for one number, challenges your range, and waits through the silence.
PitchDawn's live voice simulations and client practice modes let client-facing IT professionals rehearse that exact pressure. An AI client can push for a commitment, interrupt your explanation, or question an assumption while real-time coaching shows where you hedge, ramble, or fail to close with a next step.
The goal is not to memorise a perfect estimate script.
It is to become the person who can make uncertainty useful while the client is still on the call.