What We Look for in a Discovery Call Before We Say Yes to a Project
In short
On a discovery call, we are listening for three things: whether the problem being described is one we have the right experience to solve well, whether there is a real decision maker in the conversation or one who will be reachable soon, and whether the timeline and expectations being described are realistic given what the problem actually requires. When one of these is clearly missing, the honest answer is often a referral elsewhere rather than a proposal, because taking on a project that starts with a mismatch rarely ends well for either side.
Key takeaways
- A discovery call is evaluating fit in both directions, not just qualifying a lead for a sale.
- A mismatch between the described timeline and what the actual problem requires is one of the clearest early warning signs on a call.
- When the right experience for a specific problem is not ours, saying so and pointing toward someone better suited is the right outcome, not a failure of the call.
- The clearest discovery calls are the ones where the person describing the problem can also describe what they have already tried.
Table of contents
Fit runs in both directions
A discovery call gets treated, from the outside, as a sales step where a prospective client is evaluated for whether to send them a proposal. That is only half of what is actually happening. The other half is us evaluating whether we are the right team for the specific problem being described, honestly enough that the answer is sometimes no.
Is this a problem we have real experience solving well
Some problems fit squarely inside the kind of work we do regularly, and it shows in how specific the questions we ask back become. Other problems sit at the edge of what we do well, close enough to sound plausible but far enough that taking it on would mean learning on the client's project rather than bringing existing judgment to it. Naming that difference honestly, on the call itself, is more useful to a prospective client than a proposal that quietly hopes the gap will not matter.
Is there a real decision maker in or near the conversation
A discovery call with someone who has genuine authority to greenlight the project, or who can get a clear answer from whoever does within a reasonable time, moves differently than one where every answer is "I would need to check." Neither situation disqualifies a project on its own, but a call with no path to an actual decision maker is a signal worth naming early, because a proposal built on assumptions nobody with authority has confirmed tends to need rework later regardless.
Does the described timeline match what the problem actually requires
The clearest early warning sign on a call is a mismatch between how the problem is described and how quickly the person describing it expects it solved. A genuinely complex integration described in a sentence, paired with an expectation of a short timeline, usually means the complexity has not been fully surfaced yet, either because it genuinely is not visible from the client's side or because it has been underestimated. Naming this gap on the call, rather than quietly accepting an unrealistic timeline into a proposal, is what actually respects the client's time.
What a good discovery call sounds like from our side
The calls that go best are the ones where the person on the other end can describe not just the problem but what they have already tried, what worked partially, and what specifically did not. That level of detail is a strong signal the problem has been genuinely lived with, not just described from a brief, and it usually means the resulting engagement starts from a real, shared understanding rather than a guess dressed up as a scope document.
When the honest answer is a referral
Occasionally the honest outcome of a discovery call is recommending the prospective client look elsewhere, because the specific problem sits outside what we do well, or because the timeline and the problem's real complexity are too far apart to close honestly. This costs us the project in the short term. It is also the only version of the call that respects the fact that a mismatched engagement tends to go badly for both sides, and a referral to someone better suited is a more useful outcome than a proposal we would not stand behind.
Frequently asked questions
No. When the problem sits outside what we have real experience solving well, or when the timeline described does not match what the problem actually requires, the more honest outcome is often a referral elsewhere rather than a proposal.
A conversation where the person describing the problem can also describe what they have already tried and what specifically did not work. That level of detail signals a real, lived understanding of the problem, not just a brief someone else wrote.
Not to speed up a sale, but because a proposal built on assumptions nobody with real authority has confirmed tends to need rework once it reaches that person, which costs everyone time a direct conversation would have saved.
We would rather say so on the call than quietly build a proposal around it. A described timeline that does not match the problem's real complexity is usually a sign the complexity has not been fully surfaced yet, and naming that early respects your time more than a proposal that avoids the subject.
Have a IT consulting project like this in mind?
Tell us what you are trying to build. We will tell you plainly what IT consulting work like this would take.
Get a quoteContact Us
Lahore, Pakistan · London, U.K · Austin TX, U.S · Toronto, Canada