TL;DR
— 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.