Pular para o conteúdo 
— A primeira chamada é unha entrevista mutua: ti avalías ao cliente mentres el avalía á túa axencia.
— As preguntas correctas revelan orzamento real, urxencia, decisores ocultos e compatibilidade cultural.
— Un bo proceso de descubrimento nesta fase evita proxectos problemáticos meses despois.
Hai anos investín vinte horas nunha proposta detallada para un proxecto que soaba perfecto. O cliente tiña orzamento, necesidade clara e dispoñibilidade inmediata. Cando lle enviei a proposta, respondeu en corenta minutos: “Crin que sería a metade de prezo”.
Nunca falamos de orzamento na primeira chamada. Asumín que “temos orzamento” significaba que os nosos números encaixarían. Equivoqueime.
Esa proposta foi a última que preparei sen facer primeiro unha entrevista sistemática. Hoxe, a nosa primeira chamada dura entre trinta e corenta e cinco minutos, e remata cunha decisión clara: traballamos xuntos ou non?
A estrutura da primeira chamada
A chamada ten dous obxectivos simultáneos: entender o proxecto e avaliar ao cliente. Non funciona se só fas unha das dúas cousas.
A estrutura que seguimos:
1. Contexto do cliente (5-10 min)
2. O problema real (10-15 min)
3. Proceso e expectativas (10 min)
4. Viabilidade e seguinte paso (5-10 min)
Cada sección ten preguntas específicas que nos permiten tomar unha decisión informada ao final.
1. Contexto: entender quen está ao outro lado
Antes de falar do proxecto, necesitas saber con quen falas. Estas preguntas parecen simples pero son reveladoras:
“Podes contarme brevemente que fai a túa empresa e cal é o teu rol?”
Non é para o seu LinkedIn. Quero saber se este contacto ten contexto técnico, se entende de negocio, ou se é un intermediario. Un CEO que describe a súa empresa en termos técnicos é moi diferente dun CEO que só fala de visión estratéxica. Ambos poden ser bos clientes, pero requiren comunicación diferente.
“Traballaches antes con axencias ou desenvolvedores externos?”
A resposta revela expectativas. Alguén que nunca externalizou desenvolvemento terá unha curva de aprendizaxe. Alguén que tivo malas experiencias previas pode ser desconfiado ou, peor, pode ter aprendido patróns tóxicos (micromanagement, cambios constantes sen custo, etc.).
Se di que si, pregunto como foi. Se foi mal, pregunto que saíu mal desde a súa perspectiva. Isto dime que situacións debo evitar e se esas situacións foron culpa do provedor anterior ou do propio cliente.
“Tes equipo interno de tecnoloxía ou marketing?”
Un cliente con equipo técnico propio pode ser marabilloso (entenden limitacións, procesos claros) ou un inferno (queren micromanexar, cuestionan cada decisión). Un cliente sen equipo algún pode ser fácil de xestionar ou pode ter expectativas irreais porque ninguén lles dixo o contrario.
2. O problema real: ir máis aló da solución pedida
Os clientes chegan con solucións en mente. “Necesito unha web con WordPress”, “Quero unha app”, “Necesito integrar isto co ERP”. O meu traballo é descubrir o problema que cren que esa solución resolverá.
“Que te levou a buscar isto agora?”
O “agora” é crucial. Se a resposta é “levamos anos querendo facer isto”, hai falta de prioridade ou orzamento. Se é “perdemos un cliente importante porque non tiñamos X”, hai urxencia xenuína e orzamento probablemente dispoñible.
“Que pasa se non facedes este proxecto?”
A resposta ideal involucra diñeiro perdido, clientes que se van, ou regulación que se cumpre. A resposta preocupante é “pois nada, seguiríamos como estamos”. Se non hai consecuencia real de non facelo, o proxecto non é prioritario e paralizarase en canto xurda calquera outra cousa.
“Como o estades facendo agora?”
Gústame entender o estado actual. Ás veces descubres que o “proceso manual” que queren automatizar é unha folla de Excel que usan dúas veces ao mes. Iso cambia completamente o ROI do proxecto.
“Quen máis está involucrado na decisión?”
O contacto inicial rara vez é o único decisor. Necesito saber quen máis ten voto: CEO, CFO, equipo de IT, departamento legal. Cada un engade complexidade e potencial bloqueo. Se hai cinco decisores, o proxecto será lento independentemente do que fagamos nós.
3. Proceso e expectativas: aliñar realidades
Esta sección é onde máis proxectos se descartan. Se as expectativas non se aliñan aquí, non se aliñarán nunca.
“Tes unha data concreta en mente?”
“O antes posible” non é unha data. Necesito saber se hai un evento real (lanzamento de produto, fin de financiamento, caducidade de licenza) ou só impaciencia. As datas irreais son sinal de alerta, especialmente se o cliente non quere discutir prioridades.
“Tes un rango de investimento previsto para isto?”
Non pregunto por orzamento exacto. Pregunto por rango, e fágoo directamente. “Para que saibamos se encaixamos, estamos a falar de cinco mil, quince mil, ou cincuenta mil?”
A forma de responder é informativa. O cliente que o sabe pero non quere dicilo pode ser negociador duro ou pode simplemente desconfiar. O cliente que realmente non ten idea necesita educación previa sobre que custan as cousas. O cliente que di “canto menos, mellor” e ri probablemente non é o noso cliente.
“Que nivel de implicación queres ter durante o desenvolvemento?”
Algúns clientes queren ver cada pantalla cada día. Outros prefiren que lles avisemos cando estea todo. Ningunha opción é incorrecta, pero deben coincidir con como traballamos nós. Un cliente que quere revisar cada commit nun equipo que non ten ese proceso é un conflito garantido.
4. Viabilidade: a decisión
Ao final da chamada, teño suficiente información para decidir. Non necesito días para pensalo; necesito cinco minutos de reflexión honesta.
Avaliamos catro dimensións:
Viabilidade técnica. Podemos facer isto ben coa nosa stack e equipo actual? Se require aprender tecnoloxías novas desde cero ou subcontratar áreas que non controlamos, o risco é alto.
Viabilidade económica. O orzamento do cliente cobre o valor que necesita entregar? Non falo de se poden pagar os nosos prezos; falo de se investir X lles vai xerar suficiente retorno. Un cliente que gasta a metade do necesario e obtén un produto mediocre non está contento, aínda que pagase puntualmente.
Viabilidade de proceso. Podemos traballar xuntos? Se o cliente necesita reunións diarias e nós traballamos con check-ins semanais, hai un problema. Se o cliente ten cinco decisores e nós necesitamos respostas en 48 horas, hai un problema.
Viabilidade temporal. Podemos encaixar isto na nosa planificación actual sen sacrificar outros proxectos? Ás veces o proxecto é perfecto pero o timing é malo. Mellor rexeitar ou propoñer unha data posterior que comprometerse ao imposible.
Como pechar a chamada
Se a avaliación é positiva, remato con:
“Grazas pola chamada. Creo que encaixamos ben e que podemos aportar valor. Enviaréiche unha proposta nos próximos días co alcance e o investimento. Paréceche ben se falamos o [data] para revisala?”
Se a avaliación é negativa, remato con:
“Grazas pola chamada. Estiven pensando mentres falabamos, e creo que este proxecto non encaixa ben coa nosa forma de traballar por [razón específica: timing, tecnoloxía, orzamento]. Recomendaríache falar con [contacto alternativo se o teño]. Deséxoche moita sorte co proxecto.”
O rexeitamento inmediato sorprende a algúns, pero é máis respectuoso que facerlles esperar unha semana para dicir o mesmo. E ás veces, ao explicar por que non encaixa, o cliente ofrece axustar o proxecto para que encaixe. Iso tamén é válido.
Erros comúns que cometei antes de sistematizar isto
Falar máis que escoitar. Nas primeiras chamadas, explicaba a nosa axencia, o noso proceso, os nosos casos de éxito. O cliente aburríase e eu non aprendía nada. Agora falo menos do 30% do tempo.
Non preguntar por orzamento por medo. Pensaba que preguntar por diñeiro era “vendedor” e pouco profesional. Era parvo. Perdía tempo preparando propostas para clientes que nunca ían pagar o que custaba facer o traballo ben.
Aceptar vaguedades. “O antes posible”, “o que sexa necesario”, “flexibles co orzamento”. Aprendín a traducir: “Non o sei” ou “Non quero dicilo”. Cando un cliente non pode concretar na primeira chamada, raramente concreta mellor durante o proxecto.
Non preguntar pola historia do cliente. Os proxectos non existen no baleiro. Un cliente que vén dunha relación traumática co seu provedor anterior necesita un proceso diferente ao dun cliente que está ampliando algo que xa funciona.
Preguntas frecuentes
E se o cliente non quere facer unha chamada e prefire correo?
Aceptamos correo para información básica, pero para proxectos de certa envergadura, insistimos na chamada. Explicamos que necesitamos entender o contexto para facer unha proposta útil, e iso require conversa. Se se negan sistematicamente, adoita ser sinal de que non valoran o proceso de descubrimento.
Debería cobrar por esta chamada de descubrimento?
Para proxectos pequenos, é marketing. Para proxectos complexos que requiren varias horas de análise antes de poder propoñer nada, consideramos unha fase de auditoría paga. Isto filtra aos curiosos e demostra compromiso do cliente.
Que pasa se a chamada vai ben pero logo o cliente non responde á proposta?
Pasa constantemente. Seguimos un protocolo de seguimento similar ao de proxectos paralizados: recordatorio aos 3 días, chamada á semana, e peche do pipeline se non hai resposta en dúas semanas. Non personalizamos o rexeitamento; ás veces as prioridades do cliente cambian inesperadamente.
Conclusión
A primeira chamada non é unha formalidade previa á proposta. É o filtro máis importante do teu pipeline. Unha boa entrevista nesta fase afórrache semanas de traballo en propostas que non van a ningures e meses de sufrimento en proxectos mal encaixados.
Se queres revisar o teu proceso de descubrimento ou tes dúbidas sobre como avaliar clientes potenciais, podemos falalo. Ás veces unha soa pregunta que non estás facendo revela información que cambia completamente a viabilidade dun proxecto.
— La primera llamada es una entrevista mutua: tú evalúas al cliente mientras él evalúa a tu agencia.
— Las preguntas correctas revelan presupuesto real, urgencia, decisores ocultos y compatibilidad cultural.
— Un buen proceso de descubrimiento en esta fase evita proyectos problemáticos meses después.
Hace años invertí veinte horas en una propuesta detallada para un proyecto que sonaba perfecto. El cliente tenía presupuesto, necesidad clara y disponibilidad inmediata. Cuando le envié la propuesta, respondió en cuarenta minutos: “Creí que sería la mitad de precio”.
Nunca hablamos de presupuesto en la primera llamada. Asumí que “tenemos presupuesto” significaba que nuestros números encajarían. Me equivoqué.
Esa propuesta fue la última que preparé sin hacer primero una entrevista sistemática. Hoy, nuestra primera llamada dura entre treinta y cuarenta y cinco minutos, y termina con una decisión clara: ¿trabajamos juntos o no?
La estructura de la primera llamada
La llamada tiene dos objetivos simultáneos: entender el proyecto y evaluar al cliente. No funciona si solo haces una de las dos cosas.
La estructura que seguimos:
1. Contexto del cliente (5-10 min)
2. El problema real (10-15 min)
3. Proceso y expectativas (10 min)
4. Viabilidad y siguiente paso (5-10 min)
Cada sección tiene preguntas específicas que nos permiten tomar una decisión informada al final.
1. Contexto: entender quién está al otro lado
Antes de hablar del proyecto, necesitas saber con quién hablas. Estas preguntas parecen simples pero son reveladoras:
“¿Puedes contarme brevemente qué hace tu empresa y cuál es tu rol?”
No es para su LinkedIn. Quiero saber si este contacto tiene contexto técnico, si entiende de negocio, o si es un intermediario. Un CEO que describe su empresa en términos técnicos es muy diferente de un CEO que solo habla de visión estratégica. Ambos pueden ser buenos clientes, pero requieren comunicación diferente.
“¿Has trabajado antes con agencias o desarrolladores externos?”
La respuesta revela expectativas. Alguien que nunca ha externalizado desarrollo tendrá una curva de aprendizaje. Alguien que ha tenido malas experiencias previas puede ser desconfiado o, peor, puede haber aprendido patrones tóxicos (micromanagement, cambios constantes sin coste, etc.).
Si dice que sí, pregunto cómo fue. Si fue mal, pregunto qué salió mal desde su perspectiva. Esto me dice qué situaciones debo evitar y si esas situaciones fueron culpa del proveedor anterior o del propio cliente.
“¿Tienes equipo interno de tecnología o marketing?”
Un cliente con equipo técnico propio puede ser maravilloso (entienden limitaciones, procesos claros) o un infierno (quieren micromanagear, cuestionan cada decisión). Un cliente sin equipo alguno puede ser fácil de gestionar o puede tener expectativas irreales porque nadie les ha dicho lo contrario.
2. El problema real: ir más allá de la solución pedida
Los clientes llegan con soluciones en mente. “Necesito una web con WordPress”, “Quiero una app”, “Necesito integrar esto con el ERP”. Mi trabajo es descubrir el problema que creen que esa solución resolverá.
“¿Qué te ha llevado a buscar esto ahora?”
El “ahora” es crucial. Si la respuesta es “llevamos años queriendo hacer esto”, hay falta de prioridad o presupuesto. Si es “perdimos un cliente importante porque no teníamos X”, hay urgencia genuina y presupuesto probablemente disponible.
“¿Qué pasa si no hacéis este proyecto?”
La respuesta ideal involucra dinero perdido, clientes que se van, o regulación que se cumple. La respuesta preocupante es “pues nada, seguiríamos como estamos”. Si no hay consecuencia real de no hacerlo, el proyecto no es prioritario y se paralizará en cuanto surja cualquier otra cosa.
“¿Cómo lo estáis haciendo ahora?”
Me gusta entender el estado actual. A veces descubres que el “proceso manual” que quieren automatizar es una hoja de Excel que usan dos veces al mes. Eso cambia completamente el ROI del proyecto.
“¿Quién más está involucrado en la decisión?”
El contacto inicial rara vez es el único decisor. Necesito saber quién más tiene voto: CEO, CFO, equipo de IT, departamento legal. Cada uno añade complejidad y potencial bloqueo. Si hay cinco decisores, el proyecto será lento independientemente de lo que hagamos nosotros.
3. Proceso y expectativas: alinear realidades
Esta sección es donde más proyectos se descartan. Si las expectativas no se alinean aquí, no se alinearán nunca.
“¿Tienes una fecha concreta en mente?”
“Lo antes posible” no es una fecha. Necesito saber si hay un evento real (lanzamiento de producto, fin de financiación, caducidad de licencia) o solo impaciencia. Las fechas irreales son señal de alerta, especialmente si el cliente no quiere discutir prioridades.
“¿Tienes un rango de inversión previsto para esto?”
No pregunto por presupuesto exacto. Pregunto por rango, y lo hago directamente. “Para que sepamos si encajamos, ¿estamos hablando de cinco mil, quince mil, o cincuenta mil?”
La forma de responder es informativa. El cliente que lo sabe pero no quiere decirlo puede ser negociador duro o puede simplemente desconfiar. El cliente que realmente no tiene idea necesita educación previa sobre qué cuestan las cosas. El cliente que dice “cuanto menos, mejor” y se ríe probablemente no es nuestro cliente.
“¿Qué nivel de implicación quieres tener durante el desarrollo?”
Algunos clientes quieren ver cada pantalla cada día. Otros prefieren que les avisemos cuando esté todo. Ninguna opción es incorrecta, pero deben coincidir con cómo trabajamos nosotros. Un cliente que quiere revisar cada commit en un equipo que no tiene ese proceso es un conflicto garantizado.
4. Viabilidad: la decisión
Al final de la llamada, tengo suficiente información para decidir. No necesito días para pensarlo; necesito cinco minutos de reflexión honesta.
Evaluamos cuatro dimensiones:
Viabilidad técnica. ¿Podemos hacer esto bien con nuestra stack y equipo actual? Si requiere aprender tecnologías nuevas desde cero o subcontratar áreas que no controlamos, el riesgo es alto.
Viabilidad económica. ¿El presupuesto del cliente cubre el valor que necesita entregar? No hablo de si pueden pagar nuestros precios; hablo de si invertir X les va a generar suficiente retorno. Un cliente que gasta la mitad de lo necesario y obtiene un producto mediocre no está contento, aunque pagara puntualmente.
Viabilidad de proceso. ¿Podemos trabajar juntos? Si el cliente necesita reuniones diarias y nosotros trabajamos con check-ins semanales, hay un problema. Si el cliente tiene cinco decisores y nosotros necesitamos respuestas en 48 horas, hay un problema.
Viabilidad temporal. ¿Podemos encajar esto en nuestra planificación actual sin sacrificar otros proyectos? A veces el proyecto es perfecto pero el timing es malo. Mejor rechazar o proponer una fecha posterior que comprometerse a lo imposible.
Cómo cerrar la llamada
Si la evaluación es positiva, termino con:
“Gracias por la llamada. Creo que encajamos bien y que podemos aportar valor. Te enviaré una propuesta en los próximos días con el alcance y la inversión. ¿Te parece bien si hablamos el [fecha] para revisarla?”
Si la evaluación es negativa, termino con:
“Gracias por la llamada. He estado pensando mientras hablábamos, y creo que este proyecto no encaja bien con nuestra forma de trabajar por [razón específica: timing, tecnología, presupuesto]. Te recomendaría hablar con [contacto alternativo si lo tengo]. Te deseo mucha suerte con el proyecto.”
El rechazo inmediato sorprende a algunos, pero es más respetuoso que hacerles esperar una semana para decir lo mismo. Y a veces, al explicar por qué no encaja, el cliente ofrece ajustar el proyecto para que encaje. Eso también es válido.
Errores comunes que cometí antes de sistematizar esto
Hablar más que escuchar. En las primeras llamadas, explicaba nuestra agencia, nuestro proceso, nuestros casos de éxito. El cliente se aburría y yo no aprendía nada. Ahora hablo menos del 30% del tiempo.
No preguntar por presupuesto por miedo. Pensaba que preguntar por dinero era “vendedor” y poco profesional. Era bobo. Perdía tiempo preparando propuestas para clientes que nunca iban a pagar lo que costaba hacer el trabajo bien.
Aceptar vaguedades. “Lo antes posible”, “lo que sea necesario”, “flexibles con el presupuesto”. Aprendí a traducir: “No lo sé” o “No quiero decirlo”. Cuando un cliente no puede concretar en la primera llamada, raramente concreta mejor durante el proyecto.
No preguntar por la historia del cliente. Los proyectos no existen en vacío. Un cliente que viene de una relación traumática con su proveedor anterior necesita un proceso diferente al de un cliente que está ampliando algo que ya funciona.
Preguntas frecuentes
¿Y si el cliente no quiere hacer una llamada y prefiere correo?
Aceptamos correo para información básica, pero para proyectos de cierta envergadura, insistimos en la llamada. Explicamos que necesitamos entender el contexto para hacer una propuesta útil, y eso requiere conversación. Si se niegan sistemáticamente, suele ser señal de que no valoran el proceso de descubrimiento.
¿Debería cobrar por esta llamada de descubrimiento?
Para proyectos pequeños, es marketing. Para proyectos complejos que requieren varias horas de análisis antes de poder proponer nada, consideramos una fase de auditoría pagada. Esto filtra a los curiosos y demuestra compromiso del cliente.
¿Qué pasa si la llamada va bien pero luego el cliente no responde a la propuesta?
Pasa constantemente. Seguimos un protocolo de seguimiento similar al de proyectos paralizados: recordatorio a los 3 días, llamada a la semana, y cierre del pipeline si no hay respuesta en dos semanas. No personalizamos el rechazo; a veces las prioridades del cliente cambian inesperadamente.
Conclusión
La primera llamada no es una formalidad previa a la propuesta. Es el filtro más importante de tu pipeline. Una buena entrevista en esta fase te ahorra semanas de trabajo en propuestas que no van a ningún lado y meses de sufrimiento en proyectos mal encajados.
Si quieres revisar tu proceso de descubrimiento o tienes dudas sobre cómo evaluar clientes potenciales, podemos hablarlo. A veces una sola pregunta que no estás haciendo revela información que cambia completamente la viabilidad de un proyecto.
— The first call is a mutual interview: you evaluate the client while they evaluate your agency.
— The right questions reveal real budget, urgency, hidden decision-makers, and cultural fit.
— A good discovery process at this stage prevents problematic projects months later.
Years ago, I spent twenty hours on a detailed proposal for a project that sounded perfect. The client had a budget, a clear need, and immediate availability. When I sent the proposal, they replied in forty minutes: “I thought it would be half the price.”
We never talked about budget on the first call. I assumed “we have a budget” meant our numbers would match. I was wrong.
That proposal was the last one I prepared without first conducting a systematic interview. Today, our first call lasts between thirty and forty-five minutes, and ends with a clear decision: do we work together or not?
The structure of the first call
The call has two simultaneous objectives: understanding the project and evaluating the client. It doesn’t work if you only do one of the two things.
The structure we follow:
1. Client context (5-10 min)
2. The real problem (10-15 min)
3. Process and expectations (10 min)
4. Feasibility and next step (5-10 min)
Each section has specific questions that allow us to make an informed decision at the end.
1. Context: understanding who is on the other side
Before talking about the project, you need to know who you’re talking to. These questions seem simple but are 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 if this contact has technical context, understands business, 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 require 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 before may be distrustful or, worse, may have learned toxic patterns (micromanagement, constant changes without cost, etc.).
If they say yes, I ask how it went. If it went badly, I ask what went wrong from their perspective. This tells me what situations to avoid and if those situations were the fault of the previous provider or the client themselves.
“Do you have an internal 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, question every decision). A client without any team can be easy to manage or may have unrealistic expectations because no one has told them otherwise.
2. The real problem: going beyond the requested solution
Clients come with solutions in mind. “I need a website with WordPress,” “I want an app,” “I need to integrate this with the ERP.” My job is to discover the problem they believe that solution will solve.
“What has led you to seek this now?”
The “now” is crucial. If the answer is “we’ve been wanting to do this for years,” there’s a lack of priority or budget. If it’s “we lost an important client because we didn’t have X,” there’s genuine urgency and probably available budget.
“What happens if you don’t do this project?”
The ideal answer involves lost money, customers leaving, or compliance with regulations. The concerning answer is “well, nothing, we’d continue as we are.” If there’s no real consequence of not doing it, the project is not a priority and will stall as soon as anything else comes up.
“How are you doing it 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 twice 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 say: CEO, CFO, IT team, legal department. Each adds complexity and potential blockage. If there are five decision-makers, the project will be slow regardless of what we do.
3. Process and expectations: aligning realities
This section is where most projects are discarded. If expectations don’t align here, they never will.
“Do you have a specific date in mind?”
“As soon as possible” is not a date. I need to know if there’s a real event (product launch, end of funding, license expiration) or just impatience. Unrealistic dates are a red flag, especially if the client doesn’t want to discuss priorities.
“Do you have a planned investment range for this?”
I don’t ask for an exact budget. I ask for a range, and I do it directly. “To know if we fit, are we talking about five thousand, fifteen thousand, or fifty thousand?”
The way they respond is informative. The client who knows but doesn’t want to say may be a tough negotiator or may simply be distrustful. The client who really has no idea needs prior education on what things cost. The client who says “the less, the better” and laughs is probably not our client.
“What level of involvement do you want to have during development?”
Some clients want to see every screen every day. Others prefer to be notified when everything is done. Neither option is wrong, but they must match how we work. A client who wants to review every commit in a team that doesn’t have that process is a guaranteed conflict.
4. Feasibility: the decision
At the end of the call, I have enough information to decide. I don’t need days to think about it; I need five minutes of honest reflection.
We evaluate four dimensions:
Technical feasibility. Can we do this well with our current stack and team? If it requires learning new technologies from scratch or outsourcing areas we don’t control, the risk is high.
Economic feasibility. Does the client’s budget cover the value they need to deliver? 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 necessary and gets a mediocre product is not 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 five decision-makers and we need responses in 48 hours, there’s a problem.
Temporal 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 decline or propose a later date than to commit to the impossible.
How to close the call
If the evaluation is positive, I end with:
“Thanks for the call. I think we fit well and can add value. I’ll send you a proposal in the coming days with the scope and investment. Does it sound good if we talk on [date] to review it?”
If the evaluation is negative, I end with:
“Thanks for the call. I’ve been thinking while we talked, and I think this project doesn’t fit well with our way of working due to [specific reason: timing, technology, budget]. I would recommend talking to [alternative contact if I have one]. I wish you the best of luck with the project.”
Immediate rejection surprises some, but it’s more respectful than making them wait a week to say the same. And sometimes, by explaining why it doesn’t fit, the client offers to adjust the project to make it fit. That’s also valid.
Common mistakes I made before systematizing this
Talking more than listening. In early calls, I explained 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. It was silly. I wasted time preparing proposals for clients who were never going to pay what it cost to do the job well.
Accepting vagueness. “As soon as possible,” “whatever it takes,” “flexible with the 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 from a traumatic relationship with their previous provider needs a different process than a client expanding something that already works.
Frequently Asked Questions
What if the client doesn’t want to have 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 requires conversation. If they systematically 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 require several hours of analysis before proposing anything, we consider a paid audit phase. This filters out the curious and demonstrates client commitment.
What if the call goes well but then the client doesn’t respond to the proposal?
It happens constantly. We follow a follow-up protocol similar to stalled projects: reminder at 3 days, call at a week, and close the pipeline if there’s no response in two weeks. We don’t personalize the rejection; sometimes the client’s priorities change unexpectedly.
Conclusion
The first call is not 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 suffering on poorly matched projects.
If you want to review your discovery process or have questions about how to evaluate potential clients, we can talk about it. Sometimes a single question you’re not asking reveals information that completely changes the feasibility of a project.