En resumen
- Los clientes no necesitan saber cómo funciona. Necesitan saber cuánto cuesta, cuánto tarda, qué riesgo hay y qué cambia para ellos.
- Enseña el efecto en pantalla, como la página lenta o el checkout roto, en lugar de describirlo.
- Una analogía del mundo del cliente ayuda; di dónde deja de funcionar.
- Da dos o tres opciones con su coste, plazo y riesgo, y recomienda una.
- No enseñes nunca código que el cliente no haya pedido, ni credenciales.
Para explicar decisiones técnicas a clientes que no son técnicos, habla de lo que cambia para ellos, no de cómo funciona: cuánto cuesta, cuánto tarda, qué pasa si no lo haces y qué cambia para su equipo. Enseña el problema en pantalla en lugar de describirlo, ofrece dos o tres opciones con sus pros y contras, y recomienda una. Una grabación de pantalla corta es un buen formato para esto, porque el cliente ve con sus propios ojos la página lenta o el botón que no funciona.
Esta guía está pensada para desarrolladores freelance y equipos de agencia que necesitan que un cliente decida algo que no puede valorar por su cuenta.
Habla de resultados y de compromisos
A tu cliente no le importan el framework, la base de datos ni el plugin. Le importan cuatro cosas:
- Coste: cuánto ahora y cuánto cada mes a partir de ahí.
- Plazo: cuánto tarda y si retrasa la publicación.
- Riesgo: qué pasa si no lo hacemos.
- Cambio: qué será distinto después para él y para su equipo.
Traduce cada punto técnico a esos términos antes de explicarlo:
| Lo que le dirías a un compañero | Lo que el cliente necesita oír |
|---|---|
| «El plugin de reservas está abandonado». | «El sistema de reservas ya no va a recibir parches de seguridad. Hoy funciona, pero cada mes que siga ahí, el riesgo aumenta». |
| «Deberíamos añadir caché». | «Las páginas cargarán más rápido. Cuando edites una página, el cambio puede tardar unos minutos en aparecer». |
| «Pasemos a un CMS headless». | «Más libertad en el diseño, pero dos sistemas que mantener en lugar de uno, y un coste mensual más alto». |
| «Hay mucha deuda técnica». | «Los atajos de antes hacen que cada nueva función sea más lenta y más cara de desarrollar». |
Si una frase sigue necesitando una palabra técnica para entenderse, explica la palabra una vez, de pasada, y sigue.
Enseña, no cuentes
«La página va lenta en el móvil» es una opinión. Una grabación de la página tardando una eternidad en mostrar las fotos de producto en una ventana del tamaño de un móvil es un hecho que el cliente puede ver. El vídeo es la forma más fácil de enseñar un problema técnico a alguien que no está delante de tu pantalla:
- El problema tal como lo ve el cliente final: el botón del checkout que no hace nada en Safari, el formulario que pierde lo que has escrito.
- El antes y el después: la página antigua y la más rápida, una al lado de la otra.
- La pantalla que va a usar: el panel de administración después del cambio, para que «un editor nuevo» deje de ser algo abstracto.
Rodea la parte que importa mientras hablas. Dibujar en la pantalla durante la grabación lo resuelve bien; lee cómo dibujar en la pantalla mientras grabas en el Mac.
Usa las analogías con cuidado
Una buena analogía del mundo del propio cliente hace que una decisión se entienda a la primera. Algunas que suelen funcionar:
- El mantenimiento y las actualizaciones son como las revisiones del coche: si te las saltas, sigue andando, hasta que deja de hacerlo.
- La deuda técnica es como la cocina de un restaurante que no se limpia entre servicio y servicio: cada servicio es más lento que el anterior.
- Las copias de seguridad son como un seguro, solo que conviene comprobar que funcionan antes de necesitarlas.
Usa una por decisión, no una por frase. Y di dónde falla: «a diferencia de un coche, alguien puede aprovechar un agujero de seguridad antes de que se note nada raro». Una analogía que esconde un coste o un riesgo es peor que ninguna.
Da opciones con su coste
La mayoría de las decisiones técnicas tienen más de una respuesta. Presenta dos o tres, incluida la de «no hacer nada» cuando sea una opción real, y ponlas una al lado de la otra:
| Opción | Plazo | Coste continuo | Riesgo |
|---|---|---|---|
| Dejarlo como está | Ninguno ahora | Ninguno | Crece cada mes sin parches |
| Sustituirlo por un plugin mantenido | Unos dos días | Una licencia anual | Bajo; las reservas se migran |
| Desarrollar un formulario de reservas a medida | Unas dos semanas | Nuestro tiempo de mantenimiento | Bajo, pero hay más que mantener |
Un ejemplo hipotético: los plazos y los costes dependen del proyecto.
Después recomienda una y di por qué, en una frase: «Lo sustituiríamos por el plugin mantenido: dos días de trabajo, y el riesgo desaparece». Los clientes deciden más rápido cuando tú ya has pensado y ellos solo tienen que estar de acuerdo. Para la parte económica, presentar un presupuesto a un cliente en vídeo sigue el mismo enfoque.
Una estructura para la explicación
Tanto si grabas un vídeo como si escribes un email, este orden funciona:
- La decisión en una frase. «Tenemos que decidir qué hacemos con el sistema de reservas».
- Por qué ahora. Qué pasa si esperáis, en sus términos.
- Enséñalo. El problema en pantalla, treinta segundos o menos.
- Las opciones, con plazo, coste y riesgo.
- Tu recomendación y el motivo.
- La petición, con fecha. «¿Me dices antes del viernes qué opción prefieres?»
Decisión técnica: un plugin abandonado
De un desarrollador freelance al cliente, un pequeño negocio · Unos 3 minutos
Hola, Marta, necesito que decidas algo sobre el sistema de reservas. Hoy no hay nada roto, pero el plugin que lo hace funcionar ya no tiene mantenimiento, así que no va a recibir más parches de seguridad.
Esta es la página de reservas tal como la ven tus clientes. Hay tres opciones: dejarlo, que ahora no cuesta nada pero cada mes es más arriesgado; sustituirlo por un plugin mantenido, unos dos días de trabajo más una licencia anual; o desarrollar nuestro propio formulario, unas dos semanas. Yo me quedaría con la segunda: elimina el riesgo y tu equipo no va a notar el cambio. ¿Me dices algo antes del viernes?
Envíalo también con la petición por escrito, para que Marta pueda responder desde el móvil sin volver a ver el vídeo:
Hola, Marta, tres minutos sobre el sistema de reservas. No hay nada roto, pero el plugin ya no va a recibir parches de seguridad. Te recomiendo sustituirlo (unos dos días de trabajo). ¿Me dices antes del viernes qué opción prefieres?
https://justrec.app/v/k3f9Qa
Qué no enseñar
Una grabación de pantalla para un cliente no es una revisión de código. Deja fuera:
- El código. Salvo que el cliente lo haya pedido, el código solo transmite «esto es complicado».
- Las credenciales. Contraseñas, claves de API, archivos de entorno, el historial del terminal con tokens. Envía los accesos con un gestor de contraseñas, nunca en un vídeo.
- Los logs con datos de clientes. Los registros de errores suelen contener nombres, emails y datos de pedidos.
- Los proyectos de otros clientes. La barra lateral de tu editor y las pestañas del navegador pueden mostrarlos.
- El chat interno sobre el cliente o el problema.
Cuándo explicarlo en directo
Algunas decisiones técnicas son demasiado grandes para un vídeo solo: rehacer la web, cambiar de plataforma, cualquier cosa que cambie mucho el presupuesto. Envía el vídeo como material previo y decidid en una llamada corta. Explicamos dónde está la frontera entre las dos cosas en cuándo no enviar un vídeo a un cliente.
Y guarda las explicaciones para más adelante. Cuando termina el proyecto, el mismo enfoque sirve para una buena entrega: entregar una web al cliente con un vídeo le enseña cómo funciona sin una sola línea de código. La guía completa del vídeo asíncrono con clientes lo junta, y nuestra página para freelancers muestra cómo encaja JustRec en un negocio de una sola persona.
Preguntas frecuentes
¿Cómo se explica una decisión técnica a un cliente que no es técnico?
Empieza por lo que cambia para él: coste, plazo, riesgo y trabajo del día a día. Enseña el problema en pantalla, ofrece dos o tres opciones con sus pros y contras, recomienda una y pide una decisión con fecha.
¿Debo enseñarle código a un cliente?
Casi nunca. A un cliente no técnico, el código le dice que algo es complicado, no por qué importa. Enséñale en su lugar la página, el error o la pantalla de administración que va a usar.
¿Son buena idea las analogías para explicar temas técnicos?
Sí, de una en una y del mundo del cliente. Di dónde deja de funcionar la analogía, para que no esconda un coste o un riesgo.
¿Y si el cliente pide los detalles técnicos?
Dáselos, brevemente, después del resultado. Algunos clientes tienen a una persona técnica de su parte que los va a querer; ofrécele una nota breve por escrito para esa persona.
¿Las decisiones técnicas se explican mejor en vídeo o en una reunión?
Un vídeo corto sirve para la mayoría de las decisiones, porque el cliente puede ver el problema y volver a ver las opciones. Para las decisiones grandes o caras, envía primero el vídeo y decidid en una llamada.
