Qué debe definir un acuerdo de mantenimiento web

Un acuerdo de mantenimiento web debe identificar los sistemas cubiertos, los horarios de atención y cuándo empieza y termina cada plazo de servicio. “Soporte rápido” no se puede medir. Comprometerse a responder tampoco equivale a prometer la recuperación del sitio. Esta es una lista operativa para comparar propuestas, no asesoría contractual ni legal.

Delimite el servicio y los accesos necesarios

Enumere dominios, entornos, componentes del CMS, cuentas de alojamiento, integraciones y puntos de monitoreo. Indique qué organización controla cada cuenta. Un proveedor no puede recuperar de forma autónoma un sistema si nadie le ha autorizado acceso a su infraestructura o respaldos.

Separe mantenimiento rutinario, atención de incidentes y mejoras solicitadas. Aclare si las actualizaciones, pruebas de restauración, cambios de contenido y revisiones de dependencias están incluidos, se programan aparte o consumen horas disponibles. Defina cómo se estima y aprueba trabajo adicional antes de ejecutarlo.

Documente dependencias externas, como pagos o correo. El equipo de mantenimiento puede diagnosticar y escalar una falla sin poder repararla directamente. Ese límite debe conocerse antes de una interrupción, junto con el contacto del cliente autorizado para aprobar alternativas temporales.

Explique la gravedad y los plazos sin ambigüedad

Clasifique según el impacto, no según quién abre el ticket. Una propuesta posible es:

Situación	Tratamiento operativo
Sitio caído o tarea crítica bloqueada sin alternativa	Escalamiento de incidente
Función importante degradada con alternativa utilizable	Soporte prioritario
Defecto visual o cambio de contenido planificado	Cola programada

Es una clasificación propuesta, no un estándar universal. Acuerde qué constituye una tarea crítica para su sitio. Un formulario de donaciones podría importar más que un filtro del archivo histórico.

Defina por separado acuse de recibo, investigación, mitigación y recuperación. Aclare si el tiempo corre continuamente o solo dentro de las horas cubiertas. En equipos de Costa Rica y Estados Unidos, especifique zona horaria y calendario de feriados; “horario laboral” no resuelve esas diferencias.

Ejemplo hipotético fuera del horario de cobertura

Supongamos una propuesta con acuse de recibo en una hora cubierta, durante días hábiles. El formulario principal falla un viernes por la noche, después del horario de atención. Son condiciones hipotéticas. Sin cobertura de guardia contratada por separado, el plazo podría empezar en el siguiente período cubierto.

Ese esquema puede servir para algunos sitios. No sirve si las transacciones del fin de semana son centrales para el negocio. Pida al proveedor explicar quién recibe la alerta, quién puede mitigar el problema y cuándo llegará la siguiente actualización.

No confunda confirmación de recepción con recuperación. La primera reconoce el reporte; la segunda requiere un servicio utilizable. Si existe un objetivo de recuperación, identifique sus dependencias y la evidencia con que se dará por cumplido.

Solicite evidencia operativa y una entrega ordenada

Pida registros de incidentes, historial de actualizaciones, resultados de restauración y riesgos pendientes. La guía de procedimientos operativos de AWS recomienda documentar herramientas, permisos y manejo de errores. El entregable útil es un procedimiento que otra persona autorizada pueda ejecutar, no solo un total de actividades mensuales.

Incluya una lista de entrega con propiedad de cuentas, acceso a respaldos, registros de configuración y tickets abiertos. No guarde secretos directamente en los informes.

Antes de escoger un plan, envíe a cada proveedor el mismo escenario de falla fuera de horario y compare las respuestas escritas. El servicio de soporte y mantenimiento de 5e Labs permite conversar sobre esos requisitos frente a los sistemas que necesita cubrir.