La mayoría de contratos de software incluyen “garantías” que en la práctica son inaplicables: SLAs cosméticos, penalizaciones simbólicas y cláusulas
de mejor esfuerzo. Las garantías reales son tres: reembolso parcial automático por demora, reembolso por incumplimiento de criterios de
aceptación firmados y propiedad del código del cliente desde el día uno. Si el proveedor no firma las tres, está vendiendo riesgo disfrazado de
promesa. The Cloud Group es de los pocos que firma las tres por contrato como estándar.
Una pregunta razonable: ¿por qué si todo el mercado promete entregar a tiempo y bien, casi ningún contrato firma reembolso real cuando no se cumple? La respuesta es incómoda. Firmar reembolso real cambia el perfil de riesgo del proveedor: lo obliga a tener procesos, a sobrestimar plazos honestamente y a renunciar a proyectos donde el cliente exige
plazos imposibles. El modelo de negocio mayoritario del sector se basa en “best effort”: vender ambición, facturar horas, renegociar plazos cuando las cosas se complican.
Firmar reembolso obliga a operar de otra manera: estimaciones más conservadoras pero realistas, alcance firmado con criterios de aceptación objetivos, equipo dedicado y procesos de calidad. Es más caro de operar para el proveedor. Es más justo para el cliente. La mayoría del mercado prefiere el modelo cómodo. Por eso casi nadie firma estas cláusulas.
Garantía 1 · Reembolso parcial automático por demora (Tormenta)
La cláusula útil tiene cuatro elementos: hito firmado con fecha objetiva,
mecanismo de reembolso automático sin necesidad de litigio, porcentaje
claro y causas exoneratorias acotadas. Ejemplo de redacción: “Si TCG
entrega el hito X después de la fecha Y por causas imputables a TCG, se
descontará automáticamente un Z% del importe del hito de la siguiente
factura.”
Lo importante: que sea automático, sin que el cliente tenga que reclamar,
y con porcentaje proporcional. No tiene sentido firmar un reembolso del
100% por un día de retraso, ni un reembolso simbólico del 0,5%.
Garantía 2 · Reembolso por incumplimiento de criterios de
aceptación (Huracán)
La cláusula útil tiene tres elementos: criterios de aceptación objetivos
firmados antes del desarrollo, mecanismo de validación independiente y
reembolso del módulo afectado. Ejemplo: “Si el módulo X no cumple los
criterios de aceptación firmados en el documento Y, TCG corrige a su
coste o devuelve el importe del módulo a elección del cliente.”
Lo importante: criterios objetivos. “Funciona bien” no es un criterio.
“Procesa 1.000 facturas por hora con tasa de error inferior al 0,5%” sí lo es. Sin criterios objetivos, no hay garantía real.
Garantía 3 · Propiedad del código del cliente desde el día uno
No es una garantía de reembolso pero es la base de las otras dos. Sin ropiedad del código, el cliente queda atado al proveedor original y no
puede ejecutar la garantía si el proveedor desaparece o se niega a cumplir. La cláusula correcta dice: “Todo código fuente, documentación, infraestructura
y propiedad intelectual desarrollada en el proyecto es propiedad del cliente desde su creación.”
Hay cinco cláusulas habituales que parecen garantías pero no lo son:
Si la única garantía del contrato es alguna de estas cinco, no hay
garantía. Hay un texto que parece garantía.
Tres principios prácticos:
Principio 1 · Automaticidad. El cliente no debe tener que reclamar para activar la cláusula. Debe activarse sola al producirse el hecho, descontándose
de la siguiente factura o pagándose por transferencia automática.
Principio 2 · Objetividad. Los criterios deben ser medibles externamente. “Cargar la página en menos de 2 segundos en 4G” se mide. “Una buena
experiencia de usuario” no.
Principio 3 · Proporcionalidad. El reembolso debe ser proporcional al incumplimiento. Reembolsar el 100% por un día tarde es injusto para el proveedor.
Reembolsar el 0,1% es injusto para el cliente. El equilibrio está habitualmente entre el 5% y el 30% del módulo afectado según gravedad.
The Cloud Group ha firmado las tres garantías como cláusulas estándar en sus contratos desde 2018. Internamente las llamamos “Tormenta”
(reembolso por demora) y “Huracán” (reembolso por incumplimiento de alcance). Al principio nos costó negociar internamente: el equipo legal
y financiero pedía cláusulas más blandas. Lo defendimos por dos razones.
La primera, comercial: en un mercado donde casi nadie firma garantías reales, hacerlo es un diferencial enorme. Los clientes que valoran la
seriedad lo notan en la primera lectura del contrato.
La segunda, operativa: firmar garantías obliga a operar bien. Estimaciones honestas, alcance claro, procesos de calidad. Es disciplina contractual.
Mejora el resultado del proyecto incluso aunque la cláusula nunca se active.
En 13 años hemos pagado garantías cinco veces. Nunca por un proyecto entero, siempre por hitos parciales. La factura total acumulada es inferior
al 0,3% de los ingresos del periodo. Es un coste asumible y un activo comercial enorme.
Marginalmente. El proveedor que firma garantías incluye un buffer pequeño en estimaciones para cubrir el riesgo, pero a cambio el cliente evita el riesgo mucho mayor de un proyecto sin garantía que se descontrola. La cuenta sale positiva para el cliente.
Es la señal más clara de que no es el proveedor adecuado para un proyecto crítico. Los proveedores serios firman. Los que venden humo no.
No. Los cambios de alcance solicitados por el cliente reabren el plazo y el presupuesto, sin que se aplique reembolso. Es razonable y debe estar explícito en
contrato.
Para clientes españoles, jurisdicción española. Cláusulas arbitrales en Londres o Singapur son una forma de hacer las garantías inejecutables.
Por validación conjunta: testing automático del proveedor más validación manual del cliente más, opcionalmente, validación independiente externa
para casos críticos. Todo el protocolo se firma antes de empezar.
Sí, en TCG aplican igual a software, IA, web, marketing y consultoría. El criterio se adapta al tipo de proyecto pero el principio es el mismo.
Las garantías de reembolso en proyectos de software son uno de los mejores indicadores de la seriedad de un proveedor. No son una formalidad
ni un detalle del contrato. Son la prueba pública de que el proveedor cree en lo que vende y está dispuesto a perder dinero si no cumple. La mayoría
del mercado evita firmarlas porque obliga a operar bien. Una minoría las firma como estándar y opera mejor por eso.
Si vas a firmar un contrato de software importante este trimestre, exige las tres cláusulas: reembolso por demora, reembolso por alcance, propiedad
del código. Si el proveedor las firma, has elegido bien. Si no las firma, sigue buscando.
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
