# Como presentar a parte técnica dun proxecto a un cliente que non é técnico Source: https://baqueiro.es/gl/la-sala-de-maquinas/presentar-parte-tecnica-cliente-non-tecnico/ Published: 2026-01-08T08:47:00+00:00 Updated: 2026-01-08T08:47:00+00:00 Author: Baqueiro Desarrollo Web Language: gl-ES Usage: Atribución requirida: permítese a cita cunha ligazón visible de volta --- **TL;DR** - Explicar ben a parte técnica xera confianza e reduce friccións durante o proxecto. - O cliente non precisa entender como funciona a solución: precisa entender que resolve e que implica para el. - Un marco de 3 capas (problema, resultado, implicacións) funciona en case calquera presentación técnica para persoas non técnicas. Hai un momento en case todas as reunións de presentación de proxectos web no que algo se rompe. A axencia traballou semanas na proposta. O deseño é bo, a estratexia é sólida e os prazos son realistas. E entón chega a parte técnica: arquitectura, integracións, decisións de desenvolvemento. O cliente, que sabe moito do seu negocio pero non de tecnoloxía, comeza a desconectar. Asente sen entender. Ou peor: fai preguntas que demostran que hai tempo que se perdeu. O problema non é o cliente. O problema é a tradución. ## Por que explicar ben a técnica xera confianza Cando un cliente non entende a parte técnica, a súa necesidade de confiar non desaparece: desprázase. En lugar de confiar na solución, confía (ou desconfía) de quen a presenta. Se quen fala o fai con claridade, con exemplos concretos e conectando cada decisión técnica cun beneficio que o cliente recoñece no seu negocio, a confianza medra. Se fala con xerga, con abstraccións e coa actitude implícita de “isto é complexo, non esperes entendelo de todo”, a confianza cae. O paradoxo é que hai axencias e desenvolvedores cun traballo técnico excelente que perden proxectos, ou xeran friccións innecesarias durante a execución, precisamente porque non saben comunicar ese traballo a quen non ten formación técnica. O problema non é a calidade da solución. É a fenda de comunicación. ## O erro máis común: falar do “como” en lugar do “que” e o “para que” Cando un desenvolvedor presenta unha solución técnica, o instinto natural é explicar como funciona: a arquitectura, as tecnoloxías escollidas, o proceso de integración, as capas do sistema. Para outro desenvolvedor, iso é información útil. Para unha directora de márketing ou un xerente de operacións, é ruído. O que o cliente non técnico precisa entender é: - **Que problema resolve** esta decisión técnica concreta. - **Que implicacións ten para el**: tempo, custo, dependencias, risco. - **Que pasa se non se fai**: por que é necesaria e non opcional. Todo o demais, o “como” técnico, pode quedar ben documentado á parte (aquí explicamos [como documentar decisións técnicas para que non se perdan](https://baqueiro.es/gl/ingenieria-sin-atajos/como-documentar-decisions-tecnicas/)). Non ten que protagonizar a presentación. ## O marco de 3 capas para presentar decisións técnicas ### Capa 1: o problema no seu idioma Antes de explicar calquera solución técnica, hai que nomear o problema en termos que o cliente recoñeza como seus. Non: *“Necesitamos unha integración vía API REST entre ambos os sistemas”.* Si: *“Agora mesmo, cando chega un pedido novo, alguén do teu equipo ten que metelo a man en 2 sitios. Iso leva tempo e xera erros. O que imos construír elimina ese paso”.* Se o cliente asente aquí, estás a falar o seu idioma. Se non asente, o problema aínda non está ben definido, e convén resolver iso antes de pasar á solución. ### Capa 2: a solución en termos de resultado A solución preséntase polo que consegue, non por como está construída: *“Imos conectar a túa tenda en liña co teu sistema de inventario para que as existencias se actualicen soas, en tempo real, sen intervención manual”.* O cliente non precisa saber se iso se fai con webhooks, cunha cola de mensaxes ou cunha consulta periódica á API. Precisa saber o que vai notar: que o problema desaparece. Se hai varias opcións técnicas posibles, preséntanse en termos de vantaxes e inconvenientes que o cliente poida avaliar: *“Podemos facelo máis rápido de implementar pero con máis mantemento, ou máis lento de implementar pero máis robusto. Que encaixa mellor cos teus plans?”* Así a decisión é súa, con información suficiente para tomala. ### Capa 3: as implicacións que ten que xestionar Aquí é onde moitas presentacións fallan por omisión. O cliente precisa saber: - **Que se lle vai pedir a el**: accesos, decisións, validacións, tempo do seu equipo. - **Que cambia no seu día a día**: procesos que desaparecen, ferramentas novas, formación necesaria. - **Que riscos existen** e como se xestionan, sen alarmismo. Non é para asustalo. É para que chegue ao proxecto con expectativas realistas. Un cliente que sabe de antemán que haberá unha semana de validación de datos non se sorprende cando esa semana chega. Un cliente ao que non se lle dixo nada vívea como un problema inesperado. ## Un exemplo: explicar unha integración cun ERP Pensemos nunha axencia que lle presenta a unha empresa de distribución a integración entre a súa web de pedidos e o seu ERP. A primeira presentación son 20 minutos de diagramas e nomes de tecnoloxías, e o cliente sae máis confundido ca ao principio. Na segunda reunión, o responsable técnico cambia o enfoque por completo. Comeza cunha soa pregunta: *“Canto tempo dedica agora mesmo o teu equipo a pasar pedidos da web ao sistema de xestión?”* A resposta: 2 horas ao día. *“O que imos facer é que esas 2 horas pasen a cero. Os pedidos van chegar sos ao sistema, sen que ninguén teña que facer nada”.* O cliente entende en 30 segundos o que non entendera en 20 minutos. O resto da reunión xira arredor dos prazos, dos accesos necesarios e de como validar que todo funciona antes do lanzamento. Non arredor da tecnoloxía. É un patrón que se repite moito: a mesma información técnica, ordenada a partir do problema do cliente, cambia por completo a reunión. O mesmo vale cando o obxectivo é [automatizar os informes dun ERP sen cambiar de sistema](https://baqueiro.es/gl/codigo-que-trabaja-por-ti/automatizar-informes-erp-sen-cambiar-sistema/): ao cliente impórtalle ter os seus informes a tempo, non como se extraen os datos. ## Lista de verificación: antes de presentar a parte técnica - Podo explicar cada decisión técnica nunha frase sen xerga? - Sei cal é o custo concreto do problema que resolve cada parte da solución? - Teño claro que se lle vai pedir ao cliente durante o proxecto? - Anticipei as preguntas máis probables e teño respostas no seu idioma? - A presentación conecta cada elemento técnico cun beneficio recoñecible para o negocio? - Deixei claro que pasa se algo non sae como estaba previsto e como se xestiona? ## Preguntas frecuentes ### Ata que punto debo simplificar a explicación técnica? Non se trata de simplificar, senón de traducir. O obxectivo non é que o cliente entenda como funciona a tecnoloxía, senón que resolve, que implica para el e por que se escolleu esa solución. Podes ser tecnicamente preciso e claro para unha persoa non técnica ao mesmo tempo. ### Que fago se o cliente fai preguntas moi técnicas que van máis alá do que precisa saber? Respóndeas con honestidade e brevidade, e volve ao nivel que lle resulta útil: *“Iso resólvese con X, que é a forma máis estable neste contexto. O que iso significa para vós é que…”* A pregunta técnica case sempre agocha unha preocupación de negocio. Atópaa e responde a esa. ### Como xestiono un cliente que quere entender todos os detalles técnicos aínda que non teña formación? É un bo sinal: está implicado e quere tomar decisións informadas. Dálle documentación técnica detallada á parte e ofrécelle unha sesión específica para profundar. Non intentes cubrilo todo na reunión xeral. En Baqueiro sabemos que o traballo técnico só ten valor se o cliente o entende e confía nel. **Tamén pode interesarche:** - [Por que a túa axencia perde proxectos sen sabelo](https://baqueiro.es/gl/la-sala-de-maquinas/por-que-a-tua-axencia-perde-proxectos-sen-sabelo/) - [Que preguntas facer na primeira chamada para saber se o cliente encaixa](https://baqueiro.es/gl/la-sala-de-maquinas/preguntas-primeira-chamada-cliente-encaixa/) - [Cando subcontratar e cando dicir “isto non o facemos”](https://baqueiro.es/gl/la-sala-de-maquinas/cando-subcontratar-e-cando-dicir-non/) Se tes un proxecto complexo e precisas presentalo con claridade ao teu cliente final, en Baqueiro traballamos como socio tecnolóxico de axencias, tamén en modalidade white-label. [Cóntanos o teu caso](https://baqueiro.es/gl/contacto/).