- The first call is a two-way interview: you’re assessing the client while they assess your agency.
- The right questions reveal real budget, urgency, hidden decision-makers and cultural fit.
- A good discovery process at this stage prevents problem projects months down the line.
Years ago I spent 20 hours on a detailed proposal for a project that sounded perfect. The client had budget, a clear need and immediate availability. When I sent the proposal, they replied within 40 minutes: “I thought it would be half the price.”
We had never talked about budget on the first call. I assumed “we have budget” meant our numbers would fit. I was wrong.
That was the last proposal I prepared without first doing a systematic interview. Today, our first call lasts between 30 and 45 minutes, and it ends with a clear decision: do we work together or not?
How the first call is structured
The call has 2 simultaneous goals: understanding the project and evaluating the client. It doesn’t work if you only do one of them.
The structure we follow:
- Client context (5 to 10 min)
- The real problem (10 to 15 min)
- Process and expectations (10 min)
- Feasibility and next step (5 to 10 min)
Each section has specific questions that let us make an informed decision at the end.
1. Context: understanding who’s on the other end
Before talking about the project, you need to know who you’re talking to. These questions seem simple, but they’re revealing:
“Can you briefly tell me what your company does and what your role is?”
It’s not for their LinkedIn. I want to know whether this person has technical context, understands the business side, or is an intermediary. A CEO who describes their company in technical terms is very different from a CEO who only talks about strategic vision. Both can be good clients, but they need different communication.
“Have you worked with agencies or external developers before?”
The answer reveals expectations. Someone who has never outsourced development will have a learning curve. Someone who has had bad experiences may be distrustful or, worse, may have picked up toxic patterns (micromanagement, constant changes at no cost, and so on).
If they say yes, I ask how it went. If it went badly, I ask what went wrong from their point of view. That tells me which situations to avoid and whether those situations were the previous provider’s fault or the client’s own.
“Do you have an in-house tech or marketing team?”
A client with their own technical team can be wonderful (they understand limitations, clear processes) or a nightmare (they want to micromanage, they question every decision). A client with no team at all can be easy to manage or can have unrealistic expectations because nobody has told them otherwise.
2. The real problem: going beyond the requested solution
Clients arrive with solutions in mind. “I need a WordPress website,” “I want an app,” “I need to integrate this with the ERP.” My job is to uncover the problem they believe that solution will solve.
“What made you start looking into this now?”
The “now” is crucial. If the answer is “we’ve wanted to do this for years,” there’s a lack of priority or budget. If it’s “we lost a major client because we didn’t have X,” there’s genuine urgency and probably budget available.
“What happens if you don’t do this project?”
The ideal answer involves lost money, clients walking away, or regulations that need to be met. The worrying answer is “well, nothing, we’d carry on as we are.” If there’s no real consequence to not doing it, the project isn’t a priority and will stall as soon as anything else comes up.
“How are you handling it right now?”
I like to understand the current state. Sometimes you discover that the “manual process” they want to automate is an Excel sheet they use 2 times a month. That completely changes the project’s ROI.
“Who else is involved in the decision?”
The initial contact is rarely the only decision-maker. I need to know who else has a vote: CEO, CFO, IT team, legal department. Each one adds complexity and a potential roadblock. If there are 5 decision-makers, the project will be slow no matter what we do.
3. Process and expectations: aligning realities
This is the section where the most projects get ruled out. If expectations don’t line up here, they never will.
“Do you have a specific date in mind?”
“As soon as possible” isn’t a date. I need to know whether there’s a real event (a product launch, the end of a funding period, a license expiring) or just impatience. Unrealistic dates are a red flag, especially if the client doesn’t want to discuss priorities.
“Do you have an investment range in mind for this?”
I don’t ask for an exact budget. I ask for a range, and I ask directly. “So we know whether we’re a fit, are we talking €5,000, €15,000 or €50,000?”
How they answer tells you a lot. A client who knows but won’t say may be a tough negotiator or may simply be wary. A client who genuinely has no idea first needs someone to explain what things cost. A client who says “the less, the better” and laughs is probably not our client.
“How involved do you want to be during development?”
Some clients want to see every screen every day. Others prefer to hear from us when everything’s ready. Neither option is wrong, but it has to match how we work. A client who wants to review every commit, working with a team that doesn’t have that process, is a guaranteed conflict.
4. Feasibility: the decision
By the end of the call, I have enough information to decide. I don’t need days to think it over; I need 5 minutes of honest reflection.
We evaluate 4 dimensions:
Technical feasibility. Can we do this well with our current stack and team? If it requires learning new technologies from scratch or subcontracting areas we don’t control, the risk is high.
Financial feasibility. Does the client’s budget cover the value they need delivered? I’m not talking about whether they can pay our prices; I’m talking about whether investing X will generate enough return for them. A client who spends half of what’s needed and gets a mediocre product isn’t happy, even if they paid on time.
Process feasibility. Can we work together? If the client needs daily meetings and we work with weekly check-ins, there’s a problem. If the client has 5 decision-makers and we need answers within 48 hours, there’s a problem.
Timing feasibility. Can we fit this into our current schedule without sacrificing other projects? Sometimes the project is perfect but the timing is bad. Better to turn it down or propose a later date than to commit to the impossible.
How to close the call
If the assessment is positive, I wrap up with:
“Thanks for the call. I think we’re a good fit and that we can add value. I’ll send you a proposal in the next few days with the scope and the investment. Would it work for you if we talk on [date] to go over it?”
If the assessment is negative, I wrap up with:
“Thanks for the call. I’ve been thinking as we talked, and I don’t think this project is a good fit for the way we work because of [specific reason: timing, technology, budget]. I’d recommend talking to [alternative contact, if I have one]. I wish you the best of luck with the project.”
An immediate no surprises some people, but it’s more respectful than making them wait a week to hear the same thing. And sometimes, when you explain why it isn’t a fit, the client offers to adjust the project so it does fit. That’s valid too.
Common mistakes I made before systematizing this
Talking more than listening. On my early calls, I’d explain our agency, our process, our success stories. The client got bored and I learned nothing. Now I talk less than 30% of the time.
Not asking about budget out of fear. I thought asking about money was “salesy” and unprofessional. That was silly. I wasted time preparing proposals for clients who were never going to pay what it cost to do the job right.
Accepting vagueness. “As soon as possible,” “whatever it takes,” “flexible on budget.” I learned to translate: “I don’t know” or “I don’t want to say.” When a client can’t be specific on the first call, they rarely get more specific during the project.
Not asking about the client’s history. Projects don’t exist in a vacuum. A client coming out of a traumatic relationship with their previous provider needs a different process from a client who’s expanding something that already works.
Frequently asked questions
What if the client doesn’t want a call and prefers email?
We accept email for basic information, but for projects of a certain size, we insist on the call. We explain that we need to understand the context to make a useful proposal, and that takes a conversation. If they consistently refuse, it’s usually a sign they don’t value the discovery process.
Should I charge for this discovery call?
For small projects, it’s marketing. For complex projects that need several hours of analysis before we can propose anything, we consider a paid audit phase. That filters out the merely curious and shows the client’s commitment.
What if the call goes well but the client never responds to the proposal?
It happens all the time. We follow a follow-up protocol similar to the one we use for stalled projects: a reminder after 3 days, a call after a week, and we close it in the pipeline if there’s no response within 2 weeks. We don’t take it personally; sometimes client priorities change unexpectedly.
Conclusion
The first call isn’t a formality before the proposal. It’s the most important filter in your pipeline. A good interview at this stage saves you weeks of work on proposals that go nowhere and months of pain on projects that were never a good fit.
Sometimes a single question you’re not asking reveals information that completely changes whether a project is viable. If you want to review your discovery process or have questions about how to evaluate potential clients, we can talk it through.