El mantenimiento de software a medida no es un lujo opcional: es la diferencia entre un sistema que sigue funcionando cuando algo falla y uno que se cae un viernes sin que nadie lo note hasta el lunes. Para un responsable de marketing o un equipo técnico que depende de una plataforma propia —un ecommerce, un CRM interno, una app de gestión— la pregunta no es si contratar mantenimiento, sino qué nivel de respuesta necesita cada sistema. Ese nivel se define con SLA, tiempos de respuesta por severidad y horario de cobertura, no con buenas intenciones.
Un contrato de mantenimiento de software a medida fija tres cosas por escrito: cuánto tarda el proveedor en responder según la gravedad de la incidencia —desde menos de una hora si el sistema está caído hasta 24 horas para consultas menores—, en qué horario cubre esa respuesta y cuántas horas de trabajo incluye cada mes.
Qué cubre el mantenimiento de software a medida
El contrato típico separa dos bloques que conviene no mezclar: la corrección de errores y las actualizaciones de seguridad por un lado, y el desarrollo de funciones nuevas por otro. Solo el primero entra de verdad en el mantenimiento de software a medida; el segundo suele presupuestarse aparte, como ya se detalla en el precio por proyecto de un desarrollo a medida.
Lo que entra en la bolsa de mantenimiento, en la práctica:
- Corrección de errores detectados en producción.
- Actualizaciones de seguridad del lenguaje, el framework y las librerías de terceros.
- Copias de seguridad periódicas y comprobación de que restauran bien.
- Monitorización del sistema y aviso antes de que lo note el usuario final.
- Un número de horas al mes para cambios menores: textos, ajustes de formulario, pequeños informes.
Lo que normalmente NO entra: nuevas integraciones, rediseños o migraciones de plataforma. Si el contrato no lo distingue, la discusión llega el día que hace falta. Conviene exigir que el soporte técnico detalle por escrito qué incidencia cubre cada hora incluida.
Niveles de severidad del contrato de mantenimiento
No todas las incidencias valen lo mismo, y tratarlas igual es el error más común de un contrato mal escrito. La convención del sector clasifica cada aviso por severidad, y esa clasificación fija cuánto puede tardar la respuesta.
Un SLA (Service Level Agreement) es el documento que fija, en tiempo y por escrito, cuánto tarda el proveedor en responder y en resolver cada tipo de incidencia, no una promesa genérica de «atención rápida».
Incidente crítico, el sistema de producción caído
Es la categoría que de verdad justifica pagar por un SLA alto: la tienda online no procesa pedidos, el CRM no guarda datos o la plataforma de reservas está caída para todos a la vez. Aquí el tiempo de respuesta se mide en minutos. AWS, que publica sus tiempos, se compromete a responder a un sistema de producción caído en menos de una hora en su plan Enterprise, y en menos de 30 minutos ante un sistema de misión crítica en su plan Business Support+. Un proveedor que no pueda igualar ese orden de magnitud para tus sistemas críticos no vende mantenimiento de verdad: vende buena voluntad.
Incidente de impacto medio, una función degradada
Aquí entra lo que molesta sin paralizar: el buscador interno va lento, un informe no exporta bien, un formulario falla solo con un tipo de archivo concreto. Hay un bloqueo real, pero existe un rodeo —rellenar el formulario de otra forma, pedir el dato por otra vía— mientras se resuelve. El tiempo de respuesta razonable aquí se mueve entre dos y cuatro horas en horario laboral, no 24 horas después ni, por supuesto, en cinco minutos: tratar esto como crítico encarece el contrato sin necesidad, y tratarlo como consulta general lo deja sin fecha.
Tabla comparativa de SLA de mantenimiento
Estos son los cuatro niveles de severidad que más se repiten en el desarrollo a medida, con tiempos de respuesta razonables para cada uno. Son una referencia de partida, no una norma cerrada: cada proveedor y cliente los ajustan a su caso.
| Severidad | Ejemplo típico | Tiempo de respuesta | Cobertura horaria |
|---|---|---|---|
| Crítica (P1) | El sistema de producción está caído para todos | Menos de 1 hora | 24×7 |
| Alta (P2) | Una función clave falla, pero hay un rodeo | De 2 a 4 horas | Horario laboral ampliado |
| Media (P3) | Un fallo puntual con impacto en pocos usuarios | Hasta 24 horas | Horario laboral |
| Baja (P4) | Dudas, peticiones de informe, mejoras cosméticas | Hasta 72 horas | Horario laboral |
El salto que más se nota en el presupuesto no es entre P4 y P3, sino entre tener cobertura 24×7 o no tenerla: pasar a guardia permanente multiplica el coste, porque obliga a tener personal disponible fuera de jornada.
¿Te ayudamos con esto?
Cuéntanos tu caso
Si esto te afecta, escríbenos en dos líneas y te respondemos por email con una valoración concreta.
Cuando el proveedor no cumple el SLA
Aquí está la letra pequeña que casi nadie negocia. Hasta las plataformas más grandes dejan claro que su tiempo de respuesta es un objetivo, no una garantía absoluta: AWS advierte en su documentación que hará «todo esfuerzo razonable» por cumplir esos plazos, sin obligarse a compensación automática si no llega.
Con un proveedor pequeño o mediano eso se puede —y conviene— pactar de otra forma: con una cláusula de crédito de servicio que descuente horas o importe de la factura si el tiempo de respuesta se incumple de forma reiterada, no por una causa justificada puntual. Firmar un SLA ambicioso sin consecuencias si no se cumple equivale a no tener SLA.
Conviene revisar también quién responde fuera del horario pactado: si la cobertura nocturna depende de una sola persona, el SLA vale lo que valga su disponibilidad ese día, y eso es un riesgo que el mantenimiento de servidores bien dimensionado cubre con un equipo, no con un héroe.
Cuánto cuesta no tener mantenimiento contratado
El argumento que de verdad convence a dirección no suele ser técnico, es económico. Según Cisco, el coste total del tiempo de inactividad no planificado para las grandes empresas del Global 2000 alcanzó los 600.000 millones de dólares anuales en 2026, un 50% más que dos años antes, con un coste medio de 15.000 dólares por minuto de caída.
Esas cifras son de multinacionales y no se trasladan tal cual a una empresa de Barcelona, pero la lógica sí: cada hora caída tiene un coste —pedidos que no se cierran, citas que no se agendan, un comercial sin acceso al CRM— y ese coste no desaparece por no tener mantenimiento, solo se vuelve impredecible. La diferencia no es tener o no tener incidencias, porque los sistemas fallan igual: es saber de antemano cuánto tardará en resolverse y a qué hora puede llamar alguien.
Para un comercio electrónico o una clínica con agenda online, ese cálculo suele bastar para justificar el salto de un nivel de SLA aunque el presupuesto apriete.
Cómo elegir el nivel de mantenimiento que necesitas
No todos los sistemas de una misma empresa necesitan el mismo nivel. Una tienda online que vende las 24 horas no puede esperar al lunes si se cae en sábado; un informe interno que se consulta una vez al mes puede esperar 24 horas sin que nadie lo note. Clasificar cada sistema por lo que de verdad pierde la empresa si falla —no por lo que costó construirlo— es el criterio a aplicar antes de fijar el SLA, no después.
En la práctica: ¿quién depende de este sistema fuera del horario de oficina?, ¿hay un respaldo manual si falla un día?, ¿cuánto puede estar caído antes de que un cliente lo note desde fuera? Una consultora que gestiona a sus clientes desde un CRM propio necesita un SLA distinto al de un comercio con web de catálogo y venta física: en el primer caso el sistema ES el negocio en horario comercial; en el segundo, es un canal más entre varios.
Conviene revisar esta clasificación cada vez que el desarrollo de software para empresas añade una función que pasa a ser crítica sin que nadie actualice el contrato: es el motivo más habitual por el que un SLA antiguo se queda corto.
Preguntas frecuentes sobre el mantenimiento de software a medida
¿Cuántas horas de mantenimiento necesita una empresa pequeña?
Depende del sistema, pero una referencia habitual para una plataforma de tamaño medio es entre 5 y 10 horas al mes de soporte correctivo, sin contar incidencias críticas. Si el consumo real supera esa cifra mes tras mes, suele ser señal de que el sistema necesita una revisión de fondo.
¿El mantenimiento incluye las actualizaciones de seguridad?
Debería, y conviene que el contrato lo diga con esas palabras: actualizar el lenguaje, el framework y las librerías de terceros evita que una vulnerabilidad conocida se quede sin parchear meses. Si el contrato solo habla de «soporte» en genérico, esa parte suele quedar fuera y nadie se entera hasta que falla.
¿Qué diferencia hay entre mantenimiento y evolutivo?
El mantenimiento mantiene lo que ya existe funcionando igual de bien; el evolutivo añade funciones que no estaban en el alcance original. Mezclarlos en la misma bolsa de horas hace que las mejoras compitan con las urgencias, y estas siempre ganan: por eso el evolutivo se presupuesta aparte.
¿Tiene sentido un SLA de 24×7 para una empresa pequeña?
Solo si de verdad hay negocio fuera de horario laboral: un ecommerce que vende de noche o un servicio con usuarios en otra zona horaria. Para el resto, pagar cobertura permanente encarece el contrato sin reducir un riesgo que casi nunca ocurre fuera de las 9 a 18 horas.
Fuente: AWS Support Plans
