|
SAGA LATAM® POLÍTICAS DE SOPORTE Y ACUERDO DE NIVELES DE SERVICIO Versión 2.0 · Vigente desde Junio 2025 · Revisión anual |
1. Propósito y Alcance
Este documento define el Acuerdo de Niveles de Servicio (SLA) entre SAGA LATAM® (en adelante EL PROVEEDOR) y sus clientes (en adelante EL CLIENTE). Aplica a todos los servicios de soporte técnico y funcional sobre la plataforma ERP contratada, ya sea SAGA ERP, Odoo Enterprise (SH) u Odoo On-Premise.
|
Definición de ERP / EL SOFTWARE Para efectos de este documento, "ERP" o "EL SOFTWARE" hace referencia a la plataforma de gestión empresarial implementada por EL PROVEEDOR, independientemente de su modalidad de despliegue: SaaS (SAGA ERP), Odoo SH (nube) u On-Premise (infraestructura propia del cliente). |
2. Definiciones
• Incidente: Evento que interrumpe o reduce la calidad del servicio ERP.
• Número de Ticket: Identificador alfanumérico asignado a cada incidente en la Mesa de Ayuda.
• Tiempo de Respuesta: Desde la recepción del ticket hasta el diagnóstico y asignación al personal. Etapa: ASIGNADO.
• Tiempo de Solución: Desde que el equipo técnico/funcional inicia hasta la resolución. Etapas: EN PROCESO → PROCESO DE CIERRE / RESUELTO / CANCELADO / TAREA DE DESARROLLO.
• Tiempo Total de Solución: Suma del Tiempo de Respuesta más el Tiempo de Solución.
• Severidad: Impacto potencial del problema no resuelto sobre la continuidad operativa del cliente.
• Horario Hábil: Lunes a viernes, 09:00–17:00 (hora Ecuador). Los SLA se miden únicamente en horario hábil, salvo contratos 24/7.
• RTO (Recovery Time Objective): Tiempo máximo para restablecer el servicio después de una falla.
• RPO (Recovery Point Objective): Período máximo de datos que puede perderse en caso de falla.
• Mantenimiento Programado: Actividad de mantenimiento planificada y comunicada previamente que puede causar interrupción del servicio.
3. Niveles de Severidad y SLA
Los tiempos se miden en horario hábil (09:00–17:00, L–V), excepto contratos 24/7 que aplican de forma continua.
|
Prioridad |
Criterio |
Indicador |
T. Respuesta |
T. Solución |
|
● Crítico |
Servicio detenido: ERP inaccesible, falla en facturación electrónica, errores en importaciones críticas. |
★★★ |
≤ 60 min |
≤ 4 horas |
|
● Alto |
Servicio parcialmente detenido: el cliente no puede ejecutar actividades principales del negocio. |
★★ |
≤ 1 hora |
≤ 24 horas |
|
● Medio |
Usuario puede trabajar: proceso ralentizado con solución temporal (workaround) disponible. |
★ |
≤ 4 horas |
≤ 48 horas |
|
○ Bajo |
Sin impacto en el negocio: dudas operativas básicas, mejoras menores de usabilidad. |
— |
≤ 8 horas |
≤ 72 horas |
|
○ Desarrollo |
Proceso completable. Requiere desarrollo o personalización adicional. |
— |
Análisis ≤ 5 días hábiles |
Según planificación |
4. Garantía de Disponibilidad (Uptime SLA)
EL PROVEEDOR garantiza los siguientes niveles de disponibilidad mensual, medidos como porcentaje de tiempo en que el servicio está accesible y operativo, excluyendo mantenimientos programados y causas de fuerza mayor:
|
Plataforma |
Uptime mensual |
Downtime máx. (mes) |
Compensación por incumplimiento |
|
SAGA ERP (SaaS) |
99.5 % |
≈43 minutos |
Crédito del 10 % en factura siguiente |
|
Odoo SH (nube) |
Responsabilidad Odoo |
N/A |
N/A |
|
On-Premise |
Responsabilidad del cliente* |
N/A |
N/A |
* Para infraestructura On-Premise, EL PROVEEDOR garantiza el SLA de soporte reactivo, pero no controla la disponibilidad del servidor del cliente.
|
Cómo se mide el uptime Se calcula como: (minutos totales del mes − minutos de downtime no planificado) / minutos totales del mes × 100. Los créditos se aplican automáticamente en la siguiente factura, previa verificación del reporte de disponibilidad. |
5. Política de Backups y Recuperación de Datos
5.1 Modalidad SaaS (SAGA ERP)
• Frecuencia de backups: diaria automática; backups adicionales bajo demanda disponibles en plan Prioritario y 24/7.
• Retención: mínimo 20 días de backups diarios.
• RTO (Recovery Time Objective): ≤ 4 horas para incidentes críticos.
• RPO (Recovery Point Objective): ≤ 24 horas (pérdida máxima de datos en caso de falla catastrofica).
• Los datos se replican en almacenamiento redundante dentro de la misma región geográfica.
• Las restauraciones de backups deben solicitarse mediante ticket de severidad Alta o Crítica.
Odoo.sh es el respobable, ofrece y parte del servicios PAAS y SAAS
5.2 Modalidad On-Premise
• EL CLIENTE es responsable de configurar y mantener su propia política de backups.
• EL PROVEEDOR puede asesorar en la configuración de backups como servicio separado.
• Se recomienda al cliente implementar backups diarios con retención mínima de 30 días.
6. Mantenimiento Programado
EL PROVEEDOR se compromete a comunicar con anticipación cualquier mantenimiento que pueda causar interrupción del servicio:
• Notificación mínima: 48 horas de anticipación vía correo electrónico al contacto designado del cliente.
• Los mantenimientos se realizan preferentemente fuera del horario hábil (noches o fines de semana).
• Duración estimada de cada mantenimiento: no debería superar 2 horas, salvo migraciones de versión.
• Los mantenimientos de emergencia (parches de seguridad críticos) se notificarán tan pronto sea posible con el menor tiempo de anticipación disponible.
• El tiempo de mantenimiento programado no cuenta para el cálculo del uptime mensual.
7. Planes de Soporte
Soporte Incluido
El soporte estándar se incluye en el paquete anual de mantenimiento por localización y está disponible durante el horario de atención establecido en este documento.
El soporte incluye consultas relacionadas con errores o bugs que afecten al servicio o provoquen comportamientos inesperados, y que no se deban a configuraciones incorrectas, personalizaciones o registros erróneos.
El soporte también cubre problemas o actualizaciones relacionados con la localización ecuatoriana.
Soporte No Incluido
No se proporciona soporte para problemas causados por errores del usuario, mala manipulación de datos, aplicaciones o desarrollos realizados por terceros, o modificaciones realizadas por el personal del cliente.
No se proporciona soporte para desarrollos realizados por SAGA LATAM®ERP que tengan más de 60 días desde su entrega o puesta en producción, problemas causados por mal funcionamiento de los equipos donde se encuentra instalado el sistema (en el caso de infraestructura propia), o solicitudes de soporte por falta de conocimiento sobre el funcionamiento de la herramienta.
En caso de que el problema no esté cubierto por las garantías, se facturará un mínimo de 1 hora y hasta el tiempo que se estime por parte del equipo de desarrollo de SAGA LATAM®ERP, previa aprobación del cliente. Es importante mantener la suscripción vigente y que las facturas estén al día para poder disfrutar de los servicios de soporte. Además, el soporte fuera del horario laboral o en días no laborables puede ser proporcionado, pero será facturado en estos casos.
SAGA LATAM®ERP se compromete a brindar un servicio de soporte de calidad y a cumplir con los SLAs y política de soporte. Para consultas o asistencia, se puede contactar a través del correo electrónico soporte@saga-lata.com
7.1 Soporte de Estabilización (post go-live)
Salir en vivo con el ERP es un logro importante. Sin embargo, los primeros 30 a 90 días de operación real son el período de mayor riesgo para cualquier empresa, independientemente de qué tan bien se haya ejecutado la implementación. A diferencia de los planes de soporte operativo continuos, este plan contempla intervención técnica profunda, incluyendo desarrollos de ajuste y corrección de datos en producción.
|
Por qué es crítico este período
Lo que ocurre en el post go-live
· Los usuarios operan el sistema por primera vez en producción real
· Aparecen escenarios de negocio no contemplados en la implementación
· Los datos migrados pueden tener inconsistencias que salen a la luz
· Se detectan ajustes de configuración y desarrollo pendientes
· El equipo de Implementación o TI interno del cliente no tiene experiencia profunda en ERP
Sin acompañamiento adecuado
· Errores de uso afectan facturas, inventario y contabilidad reales
· El equipo no sabe cómo resolverlo y frena la operación
· Reportes incorrectos, balances descuadrados, stock erróneo
· Quedan sin resolver por semanas o se resuelven incorrectamente
· Intentos de corrección sin guía generan más problemas |
El Plan Estabilización existe para que estos problemas se resuelvan en horas, no en días — con un consultor senior que ya conoce su sistema y actúa de inmediato.
• Canal: tickets + reuniones virtuales + WhatsApp preferente.
• Horario: 09:00–17:00, lunes a viernes.
• Incluye: Errores de usuario, Problemas causados por mala manipulación de datos, problemas causados por modificaciones realizadas por personal del cliente, desarrollos realizados por SAGA LATAM®ERP que tengan menos de 30 días de haber sido entregados/puestos en producción, problemas causados por mal funcionamiento de los equipos donde se encuentra instalado el sistema (Aplica para Infraestructura propia), solicitudes de soporte por falta de conocimiento sobre el funcionamiento de la herramienta..
7.2 Soporte Estándar
• Canal: exclusivamente tickets vía saga-latam.com/helpdesk_ticket. Recepción 24/7; procesamiento en horario hábil.
• Horario de atención: 09:00–17:00, lunes a viernes.
• INCLUYE: Consultas sobre errores/bugs que bloqueen el servicio o generen comportamientos inesperados no atribuibles a configuración incorrecta, y soporte de localización ecuatoriana (SRI/tributario).
• NO INCLUYE: Reuniones, errores de usuario, mala manipulación de datos, desarrollos de terceros, modificaciones del personal del cliente, desarrollos propios de SAGA con más de 60 días desde su entrega, fallas de infraestructura propia del cliente, y capacitación en uso de la herramienta.
7.3 Soporte Prioritario (8/5)
• Canal: tickets + reuniones virtuales + WhatsApp preferente.
• Horario de atención: 09:00–17:00, lunes a viernes.
• INCLUYE: Todo lo del plan estándar, más: errores de usuario, mala manipulación de datos, desarrollos de terceros, modificaciones del personal del cliente, desarrollos con más de 60 días de entrega, fallas de infraestructura propia y consultas de capacitación.
• Acceso a niveles de escalamiento 2 y 3.
• Revisión técnica trimestral del sistema (ver Sección 10).
7.4 Soporte 24/7
• Incluye todas las características del soporte prioritario.
• Disponibilidad continua los 7 días de la semana, 24 horas.
• Los SLA aplican de forma continua, incluyendo fines de semana y feriados.
• Acceso completo a todos los niveles de escalamiento.
• Notificaciones proactivas de alertas del sistema en tiempo real.
8. Tarifas de Soporte
|
Plataforma |
Hora suelta |
Estabilización /h |
Estándar 8/5 /h |
Prioritario 8/5 /h |
Prioritario 24/7 /h |
|
SAGA ERP |
$49,00 |
$32,00 |
— |
$32,00 |
$64,00 |
|
Odoo SH |
$89,00 |
$67,00 |
— |
$45,00 |
$90,00 |
|
On-Premise |
$79,00 |
$63,00 |
$63,00 |
$63,00 |
$120,00 |
- Nota: Las tarifas mencionadas pueden ser revisadas y ajustadas periódicamente para reflejar adecuadamente los costos operativos y las condiciones del mercado. Cualquier modificación será comunicada a los clientes con la debida antelación y total transparencia. Los precios detallados en la tabla de soporte corresponden a horas sueltas y planes desde 20 horas. Los planes para Odoo SH desde 20 horas mensuales están asociados a contratos anuales, con facturación mensual y cobro mensual.
Se detalla los servicios de soporte de forma genera estructurados bajo las siguientes condiciones:
• Existe planes de soporte continuo que requieren un mínimo de 10 o 20 horas mensuales, no requieren estar bajo contrato anual.
• Existe planes de soporte en Odoo SH desde 20 horas mensuales que se facturan mensualmente bajo contrato anual.
• Existe planes de 20 horas mensuales con pago anticipado anual reciben 2 meses gratis (exclusivo Odoo SH).
• El soporte fuera del horario hábil en planes no 24/7 está sujeto a disponibilidad y se factura con tarifa correspondiente.
• Las tarifas se revisan anualmente. Cualquier ajuste se notifica con al menos 30 días de anticipación.
|
Condición de acceso al soporte Para acceder a cualquier servicio de soporte, la suscripción debe estar vigente y todas las facturas deben estar al día. Todo análisis fuera del alcance de las garantías se factura con un mínimo de 1 hora. |
9. Responsabilidades de las Partes
9.1 Obligaciones de EL PROVEEDOR (SAGA LATAM®)
• Brindar soporte dentro de los tiempos y condiciones definidos en este SLA.
• Comunicar proactivamente el estado de incidentes críticos y su plan de acción.
• Notificar mantenimientos programados con al menos 48 horas de anticipación.
• Mantener la confidencialidad de los datos del cliente.
• Publicar reportes mensuales de cumplimiento de SLA a clientes con plan Prioritario y 24/7.
• Garantizar que el personal con acceso al sistema del cliente esté sujeto a acuerdos de no divulgación.
9.2 Obligaciones de EL CLIENTE
• Designar al menos un contacto técnico autorizado para la apertura y seguimiento de tickets.
• Reportar incidentes a través del portal oficial: saga-latam.com/helpdesk_ticket.
• Proveer acceso remoto al sistema cuando sea requerido para el diagnóstico y resolución.
• Responder en un plazo máximo de 3 días hábiles a solicitudes de información del equipo de soporte.
• No realizar cambios en producción sin comunicarlo previamente al equipo de soporte.
• Mantener un ambiente de pruebas (staging) para validar soluciones antes de aplicarlas en producción (recomendado para planes Prioritario y 24/7).
• Mantener la suscripción vigente y las facturas al día para acceder al soporte.
• No escalar incidentes sin número de ticket válido ni reportar como emergencias situaciones que no lo sean.
10. Soporte Proactivo y Revisión Periódica del Sistema
Disponible en planes Prioritario y 24/7. EL PROVEEDOR realiza revisiones técnicas trimestrales del sistema del cliente, que incluyen:
• Análisis de rendimiento del sistema (tiempos de respuesta, carga de base de datos).
• Revisión de configuraciones suboptimas y recomendaciones de mejora.
• Informe de actualizaciones pendientes y compatibilidad con nuevas versiones.
• Identificación de riesgos potenciales antes de que se conviertan en incidentes.
• Entrega de reporte escrito con hallazgos y recomendaciones priorizadas.
11. Proceso de Resolución de Tickets
El flujo estándar de un ticket sigue las siguientes etapas:
1. Nuevo: recepción automática con asignación de número de ticket.
2. Asignado: diagnóstico completado y asignado a técnico/funcional. Inicio del SLA de solución.
3. En Proceso: equipo trabajando activamente en la resolución.
4. Esperando Cliente: se requiere información o confirmación del cliente. El SLA se pausa.
5. Proceso de Cierre / Resuelto / Cancelado / Tarea de Desarrollo: etapas finales.
|
Cierre automático por falta de respuesta Un ticket en etapa EN PROCESO o ESPERANDO CLIENTE sin respuesta del cliente por más de 3 días hábiles pasará automáticamente a CIERRE POR FALTA DE RESPUESTA. Para retomar, abrir nuevo ticket referenciando el número anterior. |
Los tickets en etapas RESUELTO, PROCESO DE CIERRE o TAREA DE DESARROLLO no deben responderse; las respuestas no serán visibles. Los tickets clasificados como desarrollo generarán una estimación de horas; el trabajo inicia únicamente tras autorización escrita del cliente.
12. Gestión de Cambios
Se distinguen dos tipos de solicitudes, manejadas por flujos diferentes:
|
Tipo |
Incidente |
Cambio (Change Request) |
|
Definición |
Algo que funcionaba y dejó de funcionar. |
Modificación, mejora o nueva funcionalidad planificada. |
|
Canal |
Ticket de soporte normal. |
Ticket con etiqueta CAMBIO o solicitud al equipo de proyectos. |
|
Aprobación |
No requiere aprobación formal (dentro del SLA). |
Requiere estimación de horas y aprobación escrita del cliente. |
|
Ambiente |
Se puede aplicar directamente a producción en casos críticos. |
Debe validarse primero en ambiente de pruebas. |
13. Formato Aceptado para Reporte de Tickets
Para una atención eficiente, cada ticket debe incluir:
6. módulo y pestaña/informe afectado.Ubicación del error:
7. quiénes operaban el sistema al momento del error.Usuarios involucrados:
8. cómo se generó, qué se realizó, qué está ocurriendo.Descripción del proceso:
9. del proceso (no videos; no recortes parciales).Capturas de pantalla completas
10. copiar y pegar desde Odoo, no usar imágenes.Texto completo del error (si aplica):
11. (en entornos multi-compañía).Empresa afectada
12. lista detallada, comportamiento observado y comportamiento esperado.Pasos para replicar:
13. No agrupar múltiples errores en un mismo ticket.Un ticket por incidente.
14. Proceso de Escalamiento de Incidentes
14.1 Contactos
|
Nivel |
Canal |
Contacto |
Disponibilidad |
|
Nivel 1 |
Correo electrónico |
soporte@saga-lata.com |
Todos los planes |
|
Nivel 1 |
|
+593 99 286 0888 |
Todos los planes |
|
Nivel 2* |
Grupo WhatsApp |
Soporte Prioritario |
Solo Prioritario / 24/7 |
|
Nivel 3* |
Gerente de Operaciones |
luis.remache@saga-latam.com +593 99 286 0888 |
Solo Prioritario / 24/7 |
* Los niveles 2 y 3 están disponibles exclusivamente para clientes con soporte Prioritario o 24/7 activo.
14.2 Reglas de Escalamiento
• Todo escalamiento debe estar sustentado por un número de ticket válido.
• No escalar sin haber seguido el proceso regular ni reportar como emergencias incidentes que no lo sean.
• Los tickets indebidamente escalados o fuera de política serán facturados con un mínimo de 1 hora.
• En casos de emergencia crítica, contactar directamente al Gerente de Operaciones independientemente del tipo de soporte contratado.
15. Métricas de Desempeño (KPIs)
EL PROVEEDOR medirá y reportará mensualmente a los clientes con planes Prioritario y 24/7 las siguientes métricas:
• % de tickets resueltos dentro del SLA por nivel de severidad.
• Tiempo promedio de respuesta (MTAT) por nivel de severidad.
• Tiempo promedio de solución (MTTR) por nivel de severidad.
• Tasa de reapertura de tickets (índice de calidad de resolución).
• Volumen de tickets por módulo y tipo de incidente.
• Porcentaje de uptime mensual real vs. garantizado.
Los reportes se envían por correo electrónico en los primeros 5 días hábiles del mes siguiente.
16. Política de Actualizaciones del ERP
16.1 Actualizaciones de localización ecuatoriana (SRI, IESS)
EL PROVEEDOR aplica automáticamente los parches de localización ecuatoriana (cambios tributarios, actualizaciones SRI) sin costo adicional para clientes con suscripción vigente.
16.2 Actualizaciones de versión de Odoo / SAGA ERP
• Las actualizaciones menores (parches de seguridad, correcciones) se aplican dentro del ciclo de mantenimiento regular.
• Las migraciones de versión mayor (ej. Odoo 16 → 17 → 18) no están incluidas en el soporte estándar y se cotizan como proyectos de migración.
• EL PROVEEDOR notificará al cliente con al menos 90 días de anticipación cuando una versión llegue al fin de su ciclo de soporte activo.
• Se recomienda mantener el sistema en versiones con soporte activo para garantizar la cobertura del SLA.
17. Confidencialidad y Seguridad de Datos
• EL PROVEEDOR tratará toda la información del cliente como estrictamente confidencial durante y después de la vigencia del contrato.
• El personal de SAGA LATAM® con acceso al sistema del cliente está sujeto a acuerdos de no divulgación (NDA).
• Los datos del cliente son propiedad exclusiva del cliente. EL PROVEEDOR no los venderá, cederá ni utilizará con fines distintos a la prestación del servicio.
• Al finalizar la relación contractual, EL PROVEEDOR eliminará o devolverá los datos del cliente en un plazo de 30 días, previa solicitud formal.
• Las comunicaciones de soporte se realizan mediante canales seguros. Se recomienda no compartir credenciales del sistema en tickets; en su lugar, se deben crear credenciales temporales de acceso.
• Para clientes con Odoo SH, los datos se almacenan cifrados en tránsito (TLS) y en reposo. Para On-Premise, la seguridad del servidor es responsabilidad del cliente.
18. Limitaciones y Exclusiones Generales
Los servicios de soporte no incluyen, salvo indicación explícita en el plan contratado:
• Formación o capacitación en el uso de la herramienta (disponible como servicio adicional cotizable).
• Desarrollo de nuevas funcionalidades o personalizaciones (se gestiona como Tarea de Desarrollo con estimación y aprobación).
• Migraciones de versión mayor del ERP.
• Problemas derivados del uso incorrecto o modificaciones realizadas por personal no autorizado (salvo plan Prioritario y 24/7).
• Infraestructura, hardware, red o sistemas operativos del cliente (On-Premise).
• Integraciones o aplicaciones de terceros no implementadas por SAGA LATAM®.
|
Facturación por trabajo fuera del alcance SAGA LATAM® no será responsable de pérdida de datos derivada de acciones del cliente, terceros o fuerza mayor. Todo análisis que concluya estar fuera del alcance de las garantías se factura con un mínimo de 1 hora, previa comunicación al cliente. |
19. Resolución de Disputas y Terminación del Contrato
19.1 Disputas sobre el servicio
Si EL CLIENTE considera que el SLA no ha sido cumplido, debe:
14. Notificar formalmente por correo a soporte@saga-latam.com con evidencia (números de ticket, capturas de pantalla, fechas).
15. EL PROVEEDOR tendrá 5 días hábiles para revisar y responder.
16. Si no hay acuerdo, ambas partes intentarán una mediación directa con el Gerente de Operaciones.
17. De persistir el desacuerdo, se someterá a arbitraje conforme a la legislación ecuatoriana vigente.
19.2 Terminación del contrato
• El cliente puede cancelar el servicio con 30 días de aviso escrito.
• Tras la cancelación, el cliente tiene 15 días para solicitar la exportación de sus datos en formato estándar.
• Pasados 30 días de la cancelación, los datos pueden ser eliminados de los servidores de EL PROVEEDOR.
20. Vigencia y Revisión del Documento
• Este documento entra en vigencia el 1 de junio de 2025 y tiene revisión anual.
• Cualquier modificación sustancial será comunicada a los clientes con al menos 30 días de anticipación.
• La versión vigente siempre estará publicada en: saga-latam.com/politicas-de-soporte.
• Al aceptar el servicio o renovar la suscripción, EL CLIENTE acepta las políticas vigentes.
|
SAGA LATAM® Versión 2.0 · Junio 2025 soporte@saga-latam.com · +593 (4) 390 0670 · saga-latam.com |