Un plan útil describe tareas y límites, no sólo una mensualidad
Mantenimiento web es el trabajo acordado para conservar un sitio operativo y atender cambios o incidencias dentro de un alcance. Puede incluir revisión, actualizaciones, copias, recuperación, monitoreo y una capacidad de cambios; no todos los planes incluyen todo.
Un sitio estático, un CMS editorial y una tienda con pedidos tienen dependencias diferentes. Antes de comparar mensualidades, identifica la tecnología, las cuentas, el volumen de cambios, la criticidad y quién responde después de una alerta.
Ponerlo en prácticaExplora el ejemplo o pliega este espacio para seguir leyendo.
¿Cuidado, contenido o una función nueva?
Compara tres solicitudes antes de asumir que caben en el mismo ticket. Son ejemplos, no horas ni precios comprometidos.
Publicar un horario que ya fue aprobado
Texto final, páginas afectadas, fecha de publicación y persona que aprueba.
Cambio publicado, lectura móvil revisada y registro del resultado.
Qué cambia en la prácticaPide una capacidad editorial explícita; no supongas cambios ilimitados.
Actualizar una dependencia que afecta el formulario
Identificar versión, copia recuperable y recorrido de prueba.
Comprobar envío, recepción y estados de error; documentar o recuperar si falla.
Qué cambia en la prácticaInstalar la versión no equivale a confirmar que la función sigue operativa.
Agregar reservas, cupos y pagos
Queremos que los clientes reserven y paguen desde el sitio.
Disponibilidad, roles, estados, cancelaciones, integración y pruebas.
Qué cambia en la prácticaEs una evolución funcional que requiere alcance y estimación, aunque llegue en un único email.
Tres trabajos que suelen mezclarse en una misma palabra
Cuidado técnico, gestión de contenido y evolución funcional se relacionan, pero no son equivalentes. Publicar una noticia no es lo mismo que corregir una incompatibilidad; conectar un ERP no es un ticket editorial breve.
| Trabajo | Ejemplo | Qué acordar |
|---|---|---|
| Cuidado técnico | Actualizar dependencias y comprobar el sitio. | Sistemas cubiertos, frecuencia, respaldo, pruebas y escalamiento. |
| Gestión de contenidos | Cambiar un horario o publicar texto entregado. | Capacidad, formatos, insumos, revisiones y tiempos de atención. |
| Evolución funcional | Agregar reservas o una nueva integración. | Descubrimiento, estimación y propuesta adicional. |
| Incidente | Formulario que dejó de recibir solicitudes. | Canal, cobertura, prioridad y condiciones del servicio. |
Un respaldo sólo ayuda si puede recuperarse
Define qué se copia: archivos, base de datos, medios y configuración según la arquitectura. Un export de contenidos puede no reconstruir todas las funciones; una copia en el mismo entorno afectado puede no cubrir ciertos incidentes.
La prueba de recuperación debe realizarse de forma controlada y documentar qué se restauró y qué quedó fuera. En una tienda, volver a un respaldo antiguo sin considerar pedidos nuevos puede perder información: el procedimiento necesita evaluar ese riesgo antes de ejecutarse.
Para WordPress, la documentación oficial diferencia archivos y base de datos como partes del respaldo. En otro stack las piezas cambian; no se asume que instalar un plugin sea la solución universal.
Actualizar es una secuencia, no un clic sin comprobación
Antes de intervenir, identifica dependencias y cambios que puedan afectar formularios, plugins, pagos o contenido. Después, prueba los recorridos relevantes y registra el resultado. Si el riesgo lo exige, utiliza un entorno de revisión antes de publicar.
Una política razonable distingue correcciones de seguridad, versiones mayores y cambios incompatibles. No promete que toda actualización sea automática ni posterga indefinidamente una vulnerabilidad conocida; el tratamiento debe corresponder al alcance y al riesgo.
| Antes | Durante | Después |
|---|---|---|
| Identificar versión, respaldo y recorrido de prueba. | Aplicar cambios en el entorno acordado. | Comprobar pantallas y operaciones relevantes. |
| Definir responsable y ventana si se necesita. | Registrar errores o incompatibilidades. | Dejar evidencia y un camino de recuperación. |
Qué debería significar “un ticket”
Un ticket es una solicitud trazable, no una unidad universal de horas o complejidad. Para que un plan sea comparable, debe explicar qué tipo de cambio cabe, qué insumos necesitas entregar y qué ocurre cuando una petición supera la capacidad.
Ejemplo de cambio acotado: reemplazar un horario y un enlace ya definidos, revisar móvil y publicar. Ejemplo que requiere estimación: crear un sistema de reservas con disponibilidad, pagos y notificaciones. Agruparlo en un solo correo no lo convierte en un ticket breve.
Monitorear no equivale a atender 24/7
Una alerta puede informar caída, vencimiento o fallo de una comprobación. La respuesta depende del horario, canal, prioridad y compromiso de atención contratado. Un monitor encendido no implica que haya una persona disponible en todo momento.
Distingue tiempo de primera respuesta y tiempo de resolución: no dependen de lo mismo. Un proveedor puede necesitar acceso, confirmación del cliente o recuperación de un tercero. Si existe un SLA, pide sus condiciones por escrito; si no existe, no lo supongas.
Cada cambio también puede modificar el recorrido de datos
Agregar un chat, un píxel o un formulario requiere revisar los datos y proveedores que incorpora. En el alcance de cuidado conviene comprobar los componentes intervenidos y documentar lo que necesita una revisión adicional.
Eso no convierte un plan de mantenimiento en una auditoría legal de toda la organización. Si se desconocen los sistemas históricos, puede acordarse un inventario y auditoría técnica de privacidad separados.
Cómo comparar y recibir el servicio
Pide un registro comprensible de tareas realizadas, cambios publicados, pruebas y pendientes. El informe debe distinguir “alerta recibida”, “intervención realizada” y “problema resuelto”. No basta con mostrar una lista automática de versiones.
Antes de contratar, confirma qué cuentas quedan a nombre del negocio, cómo se entregan accesos y qué procedimiento se usa al terminar la relación. La continuidad del sitio no debería depender de que una sola persona recuerde las contraseñas.
- Plataforma y sistemas cubiertos; terceros excluidos.
- Capacidad de cambios y forma de tratar solicitudes adicionales.
- Canal y horario de atención; prioridad y SLA si se contrata.
- Copias, pruebas y condiciones de recuperación.
- Responsables, acceso a cuentas y entrega de evidencia.