# ¿Cómo explicas a tu cliente por qué el proyecto tardó más de lo previsto? Source: https://baqueiro.es/la-sala-de-maquinas/como-explicar-cliente-retraso-proyecto/ Published: 2025-07-30T07:05:00+00:00 Updated: 2025-07-30T07:05:00+00:00 Author: Baqueiro Desarrollo Web Language: es Usage: Atribución requerida: se permiten citas con un enlace visible hacia atrás --- **TL;DR** - Un retraso mal comunicado daña más la relación con el cliente que un error técnico: el error se corrige, la desconfianza cuesta mucho más repararla. - El método tiene 3 pasos: anticipar antes de que el cliente lo note, explicar con contexto y sin jerga, y comprometerse con un plan concreto. - Al final tienes una plantilla de email lista para adaptar. Los retrasos en desarrollo son tan frecuentes que hasta tienen ley propia. La ley de Hofstadter dice que todo proyecto tarda más de lo previsto, incluso cuando tienes en cuenta la ley de Hofstadter. Que sean frecuentes no los hace menos incómodos de comunicar. Y la forma de comunicarlos decide, más a menudo de lo que parece, si el cliente se queda o se va. ## Por qué los retrasos destruyen más relaciones que los errores técnicos Cuando aparece un bug importante, el cliente lo vive como un problema técnico. Hay frustración, pero también un marco claro: hay un problema, alguien lo está resolviendo y existe un proceso para hacerlo. Cuando el proyecto se retrasa y nadie avisa, ese marco desaparece. El cliente no siente que haya un problema técnico, siente que ha perdido el control. Algo que esperaba para una fecha no va a llegar, y nadie le había dicho que eso podía pasar. Esa sensación de pérdida de control suele provocar una reacción más intensa que cualquier bug. Además, los retrasos tienen consecuencias reales. El lanzamiento se mueve, la campaña de marketing se aplaza, la formación del equipo hay que reorganizarla. ## Los 3 errores más comunes al comunicar un retraso ### Error 1: esperar a que el cliente lo note El peor momento para comunicar un retraso es cuando el cliente pregunta. La conversación arranca desde la frustración y cualquier explicación suena a justificación, no a transparencia. Un retraso que comunicas antes de que el cliente lo detecte transmite control. El mismo retraso, comunicado después, transmite que esperabas que nadie se diera cuenta. ### Error 2: explicar el retraso en términos técnicos «La integración con la API de terceros ha tenido un comportamiento inesperado en el entorno de staging y hemos tenido que refactorizar parte del módulo de autenticación.» Técnicamente preciso. Para el cliente, inútil. El cliente no sabe qué es staging ni qué significa refactorizar, así que no puede valorar si el motivo es grave o trivial. Una explicación técnica que no entiende provoca 2 reacciones igual de malas: o la interpreta como una excusa, o siente que le hablas sin querer que te entienda. Más ideas en nuestra guía sobre [cómo presentar la parte técnica de un proyecto a un cliente que no es técnico](https://baqueiro.es/la-sala-de-maquinas/como-presentar-parte-tecnica-cliente-no-tecnico/). ### Error 3: dar un nuevo plazo sin explicar por qué es más fiable que el anterior Si el primer plazo no se cumplió, ¿por qué debería el cliente creerse el segundo? Si no explicas qué ha cambiado (qué información nueva tienes, qué medidas has tomado), el nuevo plazo parece otra cifra optimista que probablemente tampoco se cumplirá. ## El método de 3 pasos ### Paso 1: anticipar, comunicar antes de que el cliente lo note En cuanto el equipo detecta que un plazo no se va a cumplir, el aviso debe llegar en horas, no en días. No esperes a tener todos los detalles resueltos. Comunica que hay un retraso, da una estimación del impacto aunque sea aproximada y comprométete a dar más información en un plazo corto y concreto. > «Estamos viendo que la entrega del módulo de reservas que teníamos prevista para el jueves va a necesitar 2 días más de lo planificado. Te lo cuento ya para que tengas margen de ajustar cualquier plan que dependa de esa entrega. Mañana a las 10 te confirmo la nueva fecha exacta y lo que podemos hacer para reducir el impacto.» Este mensaje tiene 3 elementos: reconoce el problema, estima el impacto y se compromete con un siguiente paso concreto. No hay excusas técnicas ni promesas de soluciones que todavía no existen. ### Paso 2: explicar con contexto, sin excusas y sin jerga La explicación tiene que responder a la pregunta que el cliente tiene en la cabeza pero casi nunca formula: «¿Esto es síntoma de un problema mayor o algo puntual?» Si es puntual: > «El retraso viene de una dependencia externa que no controlábamos. La pasarela de pagos que estamos integrando tuvo una incidencia en su sistema que bloqueó nuestras pruebas durante 2 días. No es algo que podamos evitar del todo, pero tampoco es un patrón que hayamos visto antes con este proveedor.» Si es sistemático: > «Siendo sinceros, subestimamos la complejidad de esta parte del proyecto. Lo que parecía una integración estándar tiene más capas de las que vimos en el análisis inicial. Hemos cambiado la forma de estimar este tipo de trabajo para que no vuelva a pasar.» La segunda respuesta cuesta más darla, pero a largo plazo genera más confianza que una explicación que el cliente percibe como una excusa elaborada. Y si el origen está en atajos técnicos que se tomaron antes, conviene decirlo: la [deuda técnica](https://baqueiro.es/ingenieria-sin-atajos/que-es-deuda-tecnica-destruye-proyectos/) está detrás de muchos retrasos que parecen salir de la nada. ### Paso 3: comprometerse con un plan concreto, no con buenas intenciones Un plan tiene fechas, acciones concretas y, cuando hace falta, lo que necesitas del cliente para cumplirlo. > «La nueva fecha de entrega del módulo de reservas es el próximo martes. Para cumplirla necesitamos que nos confirmes los textos de los emails de confirmación antes del viernes. Si los tenemos el viernes, podemos comprometernos con el martes. Si quieres incorporar algún cambio de alcance antes de la entrega, este es el momento. A partir del lunes, cualquier cambio pasa a la siguiente fase.» Este tipo de mensaje consigue 2 cosas: le da al cliente un plan en el que puede confiar y lo implica en que se cumpla. Cuando el cliente forma parte de la solución, su forma de vivir el retraso cambia. ## Plantilla de email para comunicar un retraso Adáptala a cada caso. Lo que está entre corchetes es lo que tienes que personalizar. > **Asunto:** Actualización sobre [nombre del proyecto]: nueva fecha de entrega > > > > Hola, [nombre]: > > > > Quiero contarte directamente que la entrega de [elemento concreto] que teníamos prevista para el [fecha original] se va a retrasar [número de días o semanas]. > > > > El motivo es [explicación en lenguaje claro, sin jerga técnica]. No afecta al resto del proyecto, pero sí a [qué afecta exactamente]. > > > > La nueva fecha de entrega es el [fecha concreta]. Para cumplirla, [si necesitas algo del cliente: qué exactamente y para cuándo; si no necesitas nada: «no necesitamos nada por tu parte, la pelota está en nuestro tejado»]. > > > > Sé que esto puede afectar a [consecuencia concreta para el cliente, si la hay]. Si es así, dímelo y vemos cómo reducir el impacto. > > > > Para cualquier duda, llámame o escríbeme. > > > > [Nombre] Lo que hace que esta plantilla funcione es lo que no tiene: ni excusas largas, ni promesas vagas, ni jerga técnica, ni tono defensivo. Es directa, concreta y va a la solución. ## Qué hacer cuando el cliente reacciona mal Incluso con la mejor comunicación, algunos clientes reaccionarán con frustración. No intentes eliminarla: reconócela y sigue adelante. **Lo que no funciona:** ponerte a la defensiva, dar más detalle técnico para demostrar que el retraso no es culpa del equipo o prometer que «no va a volver a pasar» sin un plan detrás. **Lo que funciona:** > «Entiendo que esto os crea un problema y lo siento. Lo que puedo ofrecerte ahora mismo es [acción concreta]. Si hay algo más que pueda hacer para reducir el impacto, dímelo.» Esa respuesta no elimina la frustración, pero lleva la conversación de la queja a la solución, que es el único sitio desde el que la relación puede recuperarse. ## Preguntas frecuentes **¿Hay retrasos tan pequeños que no hace falta comunicarlos?** Depende del contexto. Medio día de retraso en un proyecto de 3 meses rara vez merece una comunicación formal. Medio día de retraso cuando el cliente tiene un lanzamiento esa misma tarde hay que comunicarlo de inmediato. El criterio no es el tamaño del retraso, sino su impacto para el cliente. **¿Y si el retraso es consecuencia de algo que hizo el cliente, como feedback tardío, cambios de alcance o aprobaciones lentas?** Es una situación delicada. Tienes que ser honesto sin sonar acusatorio. Presenta los hechos de forma objetiva: > «El retraso de una semana se debe a que los textos que necesitábamos llegaron 10 días después de la fecha acordada. Hemos podido absorber parte del impacto, pero esa semana no ha habido forma de recuperarla.» No hay reproche, pero la relación entre causa y efecto queda clara. Ayuda mucho que el [contrato de desarrollo](https://baqueiro.es/seguridad-y-juridico/clausulas-tecnicas-contrato-desarrollo-web/) deje escrito desde el principio qué pasa con los plazos cuando el cliente se retrasa en sus entregas. **¿Cuántos retrasos aguanta la relación con un cliente antes de romperse?** No hay un número fijo. Depende de la magnitud de los retrasos, de cómo se comunican y de lo sólida que sea la relación. Una serie de retrasos comunicados tarde y con excusas desgasta la relación mucho más rápido que la misma serie comunicada con antelación y con planes concretos. Gestionar bien las expectativas no elimina el problema, pero cambia mucho cómo se percibe. En Baqueiro trabajamos con protocolos de comunicación definidos para situaciones como esta, porque forma parte de lo que significa ser un [partner técnico y no un simple proveedor de horas](https://baqueiro.es/la-sala-de-maquinas/partner-tecnico-vs-proveedor-horas/). Si quieres saber cómo gestionamos la comunicación en los proyectos que llevamos, [hablamos](https://baqueiro.es/contacto/).