Un acuerdo de nivel de servicio para Moodle sirve para una sola cosa: que institución y proveedor sepan, antes del primer problema, qué se va a hacer, en cuánto tiempo y quién responde. Todo lo demás es redacción. Somos el Moodle Certified Partner del Perú.

Qué es y qué no es un SLA

Flujo de atención definido por un SLA de soporte Moodle
Un SLA claro conecta prioridad, tiempo de respuesta, resolución y evidencia de cierre.

Un SLA no es una promesa de que nada fallará. Es un contrato operativo que describe el comportamiento del proveedor frente a incidentes, consultas y mantenimiento. Cuando una propuesta comercial confunde ambas cosas, la institución termina con un documento vistoso y sin herramientas para reclamar.

El buen SLA se reconoce porque cualquier persona del equipo puede leerlo y saber qué hacer un viernes a las seis de la tarde cuando la plataforma no responde.

Alcance: lo que sí y lo que no cubre

El alcance es la cláusula que evita el 80% de las discusiones. Debe listar explícitamente qué entra: la plataforma Moodle y sus plugins aprobados, la infraestructura donde corre, los respaldos, las actualizaciones de seguridad y la atención a administradores.

Y debe listar qué no entra: creación de contenido de cursos, capacitación a estudiantes finales, desarrollos nuevos, integraciones no contempladas y fallas originadas en sistemas de terceros. Excluir no es restar valor; es evitar expectativas que el contrato no paga.

Conviene definir también a quién atiende el proveedor. Un soporte dirigido a los administradores de la institución tiene un volumen manejable; uno abierto a todos los usuarios es otro servicio y otro precio.

Severidades y tiempos de respuesta

Las severidades traducen el impacto a prioridad. Un esquema que funciona:

  • Crítica: la plataforma no está disponible o una evaluación en curso está afectada.
  • Alta: una funcionalidad esencial falla y no hay alternativa (no se puede calificar, no se pueden subir tareas).
  • Media: una falla con alternativa temporal o que afecta a un grupo reducido.
  • Baja: consultas, ajustes de configuración y mejoras.

Cada nivel necesita dos tiempos distintos: el de respuesta (cuándo alguien toma el caso y comunica un diagnóstico inicial) y el de solución o mitigación. Comprometer un tiempo de solución fijo para cualquier falla es poco serio: hay causas que dependen de terceros. Lo razonable es comprometer respuesta y dedicación continua hasta resolver, con comunicación periódica.

Horarios y ventanas críticas

Define el horario base de atención y su zona horaria. En nuestro caso es lunes a viernes de 9:00 a 18:00 (GMT-5), y lo decimos tal cual porque un horario cumplido vale más que uno amplio e incumplido.

Sobre ese horario base se pactan ventanas reforzadas para los momentos en que la institución no puede permitirse una interrupción: semana de matrícula, temporada de exámenes, lanzamiento de un programa. Esas ventanas se acuerdan con fecha en el calendario anual, no por correo el día anterior.

Escalamiento y contacto responsable

El escalamiento responde a una pregunta simple: si nadie contesta, ¿a quién llamo después? El contrato debe nombrar un contacto operativo, un responsable de servicio y un nivel gerencial, con canal y plazo para cada paso.

Del lado de la institución también hace falta una lista corta de personas autorizadas a reportar y a aprobar cambios. Sin esa lista, el proveedor recibe pedidos contradictorios y la responsabilidad se diluye.

Mantenimiento preventivo y ventanas

El soporte reactivo solo no basta. El SLA debe incluir las tareas preventivas y su frecuencia: aplicación de parches de seguridad, revisión de respaldos y de su restauración, monitoreo de espacio y rendimiento, y limpieza de datos.

Las ventanas de mantenimiento programado se avisan con antelación acordada y se ejecutan en horario de baja actividad. Si el mantenimiento implica indisponibilidad, debe quedar claro que ese tiempo no cuenta como incidente.

Para profundizar, revisa nuestro artículo sobre soporte y mantenimiento de Moodle.

Reportes y evidencia verificable

Un compromiso que no se mide no existe. Exige un reporte periódico con el detalle de tickets, severidad, tiempos, tareas preventivas ejecutadas y recomendaciones abiertas. Exige también acceso al historial de tickets, no solo un resumen.

Ese reporte es lo que permite renovar el contrato con argumentos, ajustar el alcance y sustentar el presupuesto del siguiente año ante la administración.

Penalidades y salida del contrato

Las penalidades por incumplimiento sostenido tienen sentido cuando son proporcionales y fáciles de calcular; las que exigen una auditoría para aplicarse nunca se aplican. Un descuento sobre la mensualidad del periodo afectado suele ser suficiente incentivo.

Más importante que la penalidad es la cláusula de salida: formato y plazo de entrega de la base de datos y los archivos, acompañamiento en la transición, y plazo de eliminación de la información en poder del proveedor. Negociarla al inicio cuesta poco; al final, mucho.

Señales de alerta al comparar propuestas

Desconfía de porcentajes de disponibilidad sin método de medición, de tiempos de solución garantizados para cualquier severidad, de "soporte 24/7" sin turnos identificados y de alcances redactados en una sola línea. También de propuestas sin plan de respaldos ni entrega de datos al término.

Si vas a comparar proveedores, nuestra checklist de SLA de soporte te deja todas las propuestas en la misma tabla, y el artículo sobre cómo elegir un partner Moodle cubre el resto de criterios.