Cómo presentar la parte técnica de un proyecto a un cliente que no es técnico

Hay un momento en casi todas las reuniones de presentación de proyectos web en el que algo se rompe.

La agencia ha trabajado semanas en la propuesta. El diseño es bueno, la estrategia es sólida y los plazos son realistas. Y entonces llega la parte técnica: arquitectura, integraciones, decisiones de desarrollo. El cliente, que sabe mucho de su negocio pero no de tecnología, empieza a desconectar. Asiente sin entender. O peor: hace preguntas que demuestran que se ha perdido hace rato.

El problema no es el cliente. El problema es la traducción.

Por qué explicar bien la técnica genera confianza

Cuando un cliente no entiende la parte técnica, su necesidad de confiar no desaparece: se desplaza. En lugar de confiar en la solución, confía (o desconfía) en quien la presenta.

Si quien habla lo hace con claridad, con ejemplos concretos y conectando cada decisión técnica con un beneficio que el cliente reconoce en su negocio, la confianza crece. Si habla con jerga, con abstracciones y con la actitud implícita de «esto es complejo, no esperes entenderlo del todo», la confianza cae.

La paradoja es que hay agencias y desarrolladores con un trabajo técnico excelente que pierden proyectos, o generan fricciones innecesarias durante la ejecución, precisamente porque no saben comunicar ese trabajo a quien no tiene formación técnica. El problema no es la calidad de la solución. Es la brecha de comunicación.

El error más común: hablar del «cómo» en lugar del «qué» y el «para qué»

Cuando un desarrollador presenta una solución técnica, el instinto natural es explicar cómo funciona: la arquitectura, las tecnologías elegidas, el proceso de integración, las capas del sistema.

Para otro desarrollador, eso es información útil. Para una directora de marketing o un gerente de operaciones, es ruido.

Lo que el cliente no técnico necesita entender es:

• Qué problema resuelve esta decisión técnica concreta.
• Qué implicaciones tiene para él: tiempo, coste, dependencias, riesgo.
• Qué pasa si no se hace: por qué es necesaria y no opcional.

Todo lo demás, el «cómo» técnico, puede quedar bien documentado aparte (aquí explicamos cómo documentar decisiones técnicas para que no se pierdan). No tiene que protagonizar la presentación.

El marco de 3 capas para presentar decisiones técnicas

Capa 1: el problema en su idioma

Antes de explicar cualquier solución técnica, hay que nombrar el problema en términos que el cliente reconozca como suyos. No: «Necesitamos una integración vía API REST entre ambos sistemas».

Sí: «Ahora mismo, cuando llega un pedido nuevo, alguien de tu equipo tiene que meterlo a mano en 2 sitios. Eso lleva tiempo y genera errores. Lo que vamos a construir elimina ese paso».

Si el cliente asiente aquí, estás hablando su idioma. Si no asiente, el problema todavía no está bien definido, y conviene resolver eso antes de pasar a la solución.

Capa 2: la solución en términos de resultado

La solución se presenta por lo que consigue, no por cómo está construida: «Vamos a conectar tu tienda online con tu sistema de inventario para que el stock se actualice solo, en tiempo real, sin intervención manual».

El cliente no necesita saber si eso se hace con webhooks, con una cola de mensajes o con una consulta periódica a la API. Necesita saber lo que va a notar: que el problema desaparece.

Si hay varias opciones técnicas posibles, se presentan en términos de ventajas e inconvenientes que el cliente pueda evaluar: «Podemos hacerlo más rápido de implementar pero con más mantenimiento, o más lento de implementar pero más robusto. ¿Qué encaja mejor con tus planes?» Así la decisión es suya, con información suficiente para tomarla.

Capa 3: las implicaciones que necesita gestionar

Aquí es donde muchas presentaciones fallan por omisión. El cliente necesita saber:

• Qué se le va a pedir a él: accesos, decisiones, validaciones, tiempo de su equipo.
• Qué cambia en su día a día: procesos que desaparecen, herramientas nuevas, formación necesaria.
• Qué riesgos existen y cómo se gestionan, sin alarmismo.

No es para asustarlo. Es para que llegue al proyecto con expectativas realistas. Un cliente que sabe de antemano que habrá una semana de validación de datos no se sorprende cuando esa semana llega. Un cliente al que no se le dijo nada la vive como un problema inesperado.

Un ejemplo: explicar una integración con un ERP

Pongamos una agencia que presenta a una empresa de distribución la integración entre su web de pedidos y su ERP. La primera presentación son 20 minutos de diagramas y nombres de tecnologías, y el cliente sale más confundido que al principio.

En la segunda reunión, el responsable técnico cambia el enfoque por completo. Empieza con una sola pregunta: «¿Cuánto tiempo dedica tu equipo ahora mismo a pasar pedidos de la web al sistema de gestión?»

La respuesta: 2 horas al día.

«Lo que vamos a hacer es que esas 2 horas pasen a cero. Los pedidos van a llegar solos al sistema, sin que nadie tenga que hacer nada».

El cliente entiende en 30 segundos lo que no había entendido en 20 minutos. El resto de la reunión gira en torno a plazos, accesos necesarios y cómo validar que todo funciona antes del lanzamiento. No en torno a la tecnología.

Es un patrón que se repite mucho: la misma información técnica, ordenada a partir del problema del cliente, cambia por completo la reunión. Lo mismo vale cuando el objetivo es automatizar el reporting de un ERP sin cambiar de sistema: al cliente le importa tener sus informes a tiempo, no cómo se extraen los datos.

Checklist: antes de presentar la parte técnica

• ¿Puedo explicar cada decisión técnica en una frase sin jerga?
• ¿Sé cuál es el coste concreto del problema que resuelve cada parte de la solución?
• ¿Tengo claro qué se le va a pedir al cliente durante el proyecto?
• ¿He anticipado las preguntas más probables y tengo respuestas en su idioma?
• ¿La presentación conecta cada elemento técnico con un beneficio reconocible para el negocio?
• ¿He dejado claro qué pasa si algo no sale según lo previsto y cómo se gestiona?

Preguntas frecuentes

¿Hasta qué punto debo simplificar la explicación técnica?

No se trata de simplificar, sino de traducir. El objetivo no es que el cliente entienda cómo funciona la tecnología, sino qué resuelve, qué implica para él y por qué se eligió esa solución. Puedes ser técnicamente preciso y claro para una persona no técnica al mismo tiempo.

¿Qué hago si el cliente hace preguntas muy técnicas que van más allá de lo que necesita saber?

Respóndelas con honestidad y brevedad, y vuelve al nivel que le resulta útil: «Eso se resuelve con X, que es la forma más estable en este contexto. Lo que eso significa para vosotros es que…» La pregunta técnica casi siempre esconde una preocupación de negocio. Encuéntrala y responde a esa.

¿Cómo gestiono a un cliente que quiere entender todos los detalles técnicos aunque no tenga formación?

Es una buena señal: está implicado y quiere tomar decisiones informadas. Dale documentación técnica detallada aparte y ofrécele una sesión específica para profundizar. No intentes cubrirlo todo en la reunión general.

En Baqueiro sabemos que el trabajo técnico solo tiene valor si el cliente lo entiende y confía en él.

También puede interesarte:

• Por qué tu agencia pierde proyectos sin saberlo
• Qué preguntas hacer en la primera llamada para saber si el cliente encaja
• Cuándo subcontratar y cuándo decir «esto no lo hacemos»

Si tienes un proyecto complejo y necesitas presentarlo con claridad a tu cliente final, en Baqueiro trabajamos como partner tecnológico de agencias, también en modalidad white-label. Cuéntanos tu caso.