Compromiso de servicio

Este documento describe con qué nivel de servicio operamos Zetta: qué vigilamos, qué objetivo nos ponemos, cuándo hacemos mantenimiento, cómo respaldamos los datos y en cuánto tiempo respondemos un pedido de soporte.

Los componentes que monitoreamos son:

• La aplicación web del ERP y la API que la sostiene.
• La base de datos PostgreSQL de cada empresa.
• Las tiendas online y el portal de clientes.
• La integración con AFIP y la integración con Mercado Pago, en la parte que depende de nosotros.
• El envío de correo transaccional.
• El sitio institucional.

El objetivo de disponibilidad mensual de la aplicación y de la API es del 99,5 %, excluidas las ventanas de mantenimiento avisadas con anticipación y las interrupciones causadas por terceros.

Objetivo mensual

99,5 %

Margen que eso implica

3 h 36 min en un mes de 30 días

Ventana de medición

Mes calendario, hora de Argentina

Excluido del cálculo

Mantenimientos avisados y fallas de terceros

Es un objetivo de operación, no una garantía contractual con penalidades automáticas. Si el dueño del servicio decide sumar créditos por incumplimiento, se agregan a este documento y se avisan.

Contamos como indisponibilidad el tiempo en que la aplicación o la API no responden, o devuelven error, para todas las empresas o para una empresa entera. Se mide con las verificaciones automáticas del servicio y con los registros centralizados de la plataforma.

No cuentan como indisponibilidad:

• Las ventanas de mantenimiento avisadas con anticipación.
• Las fallas de servicios de terceros: AFIP, Mercado Pago, Cloudflare, Vercel o el proveedor de correo.
• Los problemas de conectividad, de red local o de equipos del lado del usuario.
• Los bloqueos de seguridad activados por el propio comportamiento de la cuenta o de la IP.
• Los casos de fuerza mayor.

Las actualizaciones habituales se despliegan sin cortar el servicio. Cuando una tarea sí requiere interrumpirlo —una migración pesada de base de datos, un cambio de infraestructura— usamos una ventana programada.

Horario habitual

De 00:00 a 06:00, hora de Argentina

Aviso previo

Por correo, con al menos 48 horas

A quién se avisa

A los usuarios responsables de cada empresa

Publicación

También en /estado

Una intervención de emergencia por un problema de seguridad puede hacerse sin preaviso. En ese caso avisamos apenas el sistema esté estable y explicamos qué pasó.

• Frecuencia: una copia completa diaria, de madrugada.
• Cifrado: cada copia se cifra con age y la clave privada no vive en el servidor, así que quien acceda al servidor no puede leer los backups.
• Dónde: en un bucket separado del que usa la aplicación.
• Retención: 7 copias diarias y 35 días de copias semanales.
• Prueba: una restauración de prueba por semana. Un backup que nunca se restauró no es un backup.

RPO — pérdida máxima de datos

24 horas

RTO objetivo — tiempo de recuperación

8 horas desde la decisión de restaurar

El RPO surge de la frecuencia diaria: ante una restauración completa, lo cargado desde el último backup se pierde. El RTO es un objetivo, no una garantía: depende del tamaño de los datos y de la causa del incidente.

El soporte se atiende por correo en hola@zetta.ar, de lunes a viernes de 9 a 18, hora de Argentina, excepto feriados nacionales. Fuera de ese horario atendemos incidentes críticos con el mejor esfuerzo.

Los tiempos de la tabla son objetivos de primera respuesta de una persona, no de resolución: el tiempo de solución depende de la causa.

Escribí a hola@zetta.ar. Cuanto más preciso sea el reporte, más rápido se resuelve:

1. Empresa y usuario con el que estabas operando.
2. Qué pantalla o qué operación estabas haciendo.
3. Qué esperabas que pasara y qué pasó.
4. Fecha y hora aproximadas, y el texto exacto del error si aparece uno.
5. Si le pasa a una persona sola o a toda la empresa.

Cuando un incidente afecta a varias empresas, lo publicamos en /estado y avisamos por correo a los usuarios responsables.

Parte de lo que hace Zetta depende de servicios de terceros. Cuando uno de ellos falla, lo informamos y acompañamos, pero no podemos resolverlo:

• AFIP: los servicios de autenticación y de facturación electrónica tienen caídas y ventanas propias. Sin AFIP no hay CAE, y eso no es una falla de Zetta.
• Mercado Pago: disponibilidad del checkout, de los avisos de pago y de la acreditación del dinero.
• Cloudflare y Vercel: red, protección del tráfico y alojamiento de los frontends.
• Proveedor de correo: entrega del correo transaccional y su clasificación en el buzón del destinatario.
• Conectividad del cliente: internet, red local y equipos de la empresa.

En los casos en que la operación se puede seguir de otra forma —por ejemplo, dejar el comprobante en borrador y emitirlo cuando AFIP vuelva— el sistema lo permite y el soporte te guía.

Cuando no alcanzamos el objetivo de un mes, nos comprometemos a:

• Informarlo a las empresas afectadas, sin esperar a que lo pregunten.
• Enviar un análisis por escrito dentro de los 5 días hábiles del cierre del incidente: qué pasó, por qué, qué se hizo y qué se cambia para que no vuelva a pasar.
• Publicar el incidente en /estado.

Podemos actualizar este compromiso a medida que cambian la infraestructura y las herramientas de monitoreo. La fecha de la última actualización figura al comienzo.

Si un cambio baja el nivel comprometido —un objetivo menor, una ventana más amplia, un plazo de respuesta más largo— lo avisamos por correo con al menos 30 días de anticipación. Las condiciones generales del servicio están en los términos y condiciones.