InboMarket
Volver a Legal

Acuerdo de Nivel de Servicio (SLA)

Última actualización: 21 de junio de 2026

ACUERDO DE NIVEL DE SERVICIO (SLA) — InboMarket

Última actualización: [FECHA_LAUNCH] Versión: 1.0

Este SLA define los compromisos de disponibilidad técnica, tiempos de respuesta de soporte, créditos por incumplimiento, y exclusiones aplicables. Es parte integrante del MSA.

⚠️ Importante: este SLA aplica únicamente a la disponibilidad técnica de la Plataforma. NO garantiza resultados comerciales del Tenant (leads, ventas, visitas) ni la calidad del contenido publicado.


1. Compromiso de Disponibilidad (Uptime)

1.1 Objetivo por plan

PlanUptime objetivo mensualDowntime máx permitido/mes
Trial $0Best-effort (sin SLA)N/A
Agent $3999.5%~3h 39min
Agency $9799.5%~3h 39min
Condominium $8999.5%~3h 39min
Combo $34999.7%~2h 11min
Enterprise99.9% (negociable hasta 99.95%)~43min

1.2 Cálculo de uptime

Uptime % = (Tiempo Total del Mes - Downtime Excluido - Downtime Computable) / (Tiempo Total - Downtime Excluido) × 100
  • "Tiempo Total" = minutos en el mes calendario
  • "Downtime" = períodos en que el endpoint principal /api/health retorna error 5xx >3 minutos consecutivos confirmado por monitoreo externo (UptimeRobot / Pingdom / equivalente)

2. Créditos por Incumplimiento

2.1 Tabla de créditos (plan Agent/Agency/Condominium/Combo)

Uptime mensual realCrédito sobre el cargo mensual del plan
≥ 99.5%0% (compromiso cumplido)
99.0% – 99.49%10%
95.0% – 98.99%25%
< 95.0%50% (máximo)

2.2 Enterprise (uptime objetivo 99.9%)

Uptime mensual realCrédito
≥ 99.9%0%
99.5% – 99.89%10%
99.0% – 99.49%25%
< 99.0%50%

2.3 Reglas de aplicación

  • Crédito calculado sobre el cargo del mes afectado (no acumulativo año entero)
  • Crédito aplicado como descuento en factura del siguiente ciclo
  • Tope máximo: 50% del cargo mensual del mes afectado
  • No reembolsable en efectivo: solo crédito
  • Reclamo dentro de 30 días del incidente — luego prescribe
  • Procedimiento: ticket a sla@inbomarket.com con evidencia técnica

2.4 Régimen de excepción Enterprise

Tenants Enterprise pueden negociar SLA bilateralmente. Si el contrato firmado contradice este SLA estándar, prevalece el contrato.


3. Servicios y endpoints cubiertos

3.1 Cubiertos por SLA

  • Aplicación web (dashboard Tenant)
  • API REST (/api/v1/*)
  • Marketplace público (lectura listings)
  • Webhooks de salida (mejor esfuerzo de entrega)
  • Generación de PDF (presupuestos, contratos)
  • Emisión e-CF Tx1 on-demand (cuando aplique)
  • Mensajería interna (queue) — best-effort latencia <2s

3.2 NO cubiertos por SLA (best-effort)

  • Trial gratuito
  • Sandbox / ambientes de prueba
  • Funcionalidades en beta (etiquetadas "BETA" en UI)
  • Asistente IA — sujeta a SLA del proveedor externo aguas arriba
  • Tour 360 — depende de proveedor de hosting de tours
  • e-CF Tx2 emisión hacia DGII — sujeto a disponibilidad DGII/Alanube
  • Reportes pesados (>10 min ejecución)
  • Importaciones masivas batch
  • Integraciones con sistemas del Tenant (CRM externo, calendarios)

3.3 No imputables (Excluidos del cálculo)

Los siguientes eventos NO computan como downtime:

  • Mantenimiento planificado anunciado con ≥48h de antelación (máximo 4h/mes en ventana 02:00-06:00 GMT-4)
  • Mantenimiento de emergencia por vulnerabilidad crítica (notificado al momento)
  • Fallas de proveedores externos aguas arriba (AWS, GCP, Stripe, Azul, BHD, CardNet, DGII, telcos)
  • Caso fortuito o fuerza mayor: huracanes, terremotos, disturbios, decisiones gubernamentales
  • Ataques DDoS masivos mientras Cloudflare/AWS Shield mitigan
  • Falla del lado del Tenant: red local, configuración DNS propia, navegador obsoleto, problema con su PSP
  • Tenant en estado SUSPENDED por mora o violación AUP
  • Acciones forzosas por requerimiento de autoridad
  • Datos / configuraciones erradas del Tenant que rompan funcionalidad

3.4 Mantenimiento planificado

  • Ventana habitual: domingos 03:00-05:00 GMT-4 RD (sábado por la noche en USA Pacific)
  • Notificación: email + banner dashboard ≥48h antes
  • Excepción: emergencias de seguridad → notificación al momento

4. Soporte — Tiempos de Respuesta (SLA Support)

4.1 Severidad de incidentes

SeveridadDefiniciónEjemplo
S1 CríticaServicio inoperativo total para el TenantDashboard no carga, API 100% down
S2 AltaFuncionalidad principal degradada, sin workaroundNo se puede crear listings
S3 MediaFuncionalidad secundaria afectada, hay workaroundReporte exportable falla en formato Excel pero CSV funciona
S4 BajaPregunta, mejora menor, cosméticoBug visual en mobile en una pantalla

4.2 Tiempos de respuesta inicial (no resolución)

PlanS1S2S3S4
Agent $394h hábiles8h hábiles1 día hábil3 días hábiles
Agency $972h hábiles4h hábiles1 día hábil3 días hábiles
Condominium $892h hábiles4h hábiles1 día hábil3 días hábiles
Combo $3491h2h8h2 días hábiles
Enterprise30 min1h4h1 día hábil

4.3 Horario de soporte

  • Horario estándar: lunes a viernes 08:00-18:00 GMT-4 (RD)
  • Combo / Enterprise: cobertura extendida sábados 09:00-13:00
  • Enterprise con add-on 24/7: contratación adicional

4.4 Canales de soporte

CanalDisponible paraSLA
Help Center / Knowledge BaseTodosAuto-servicio
Ticket vía dashboardTodosSegún matriz 4.2
Email soporte@inbomarket.comTodosSegún matriz 4.2
Chat dentro del productoAgency+Horario hábil
WhatsApp Business soporteCombo+Horario hábil
Llamada telefónicaEnterpriseBajo agendamiento
Account Manager dedicadoEnterpriseComunicación directa

4.5 Tiempos de resolución (objetivos no contractuales)

Los tiempos de resolución dependen de la naturaleza del incidente y son orientativos:

  • S1: < 8h hábiles
  • S2: < 2 días hábiles
  • S3: < 5 días hábiles
  • S4: backlog priorizado

InboMarket informará progreso al menos cada 4h en S1 hasta resolución.


5. Reportes de Servicio

5.1 Status Page público: status.inbomarket.com con histórico 90 días.

5.2 Reporte mensual disponible bajo solicitud al Account Manager (Enterprise): incluye uptime real, incidentes, tickets resueltos.

5.3 Post-mortem público para incidentes S1 con duración >30 min, dentro de 7 días.


6. Política de Backup y Recuperación

ConceptoCompromiso
RPO (Recovery Point Objective)≤ 24h (V1) / ≤ 4h (V1.1+ Enterprise)
RTO (Recovery Time Objective)≤ 8h (V1) / ≤ 4h (V1.1+ Enterprise)
Retención backups30 días estándar / 90 días Enterprise
UbicaciónMulti-AZ (V1) / Multi-region (V1.1+)
Verificación restauraciónMensual interna (cuarterly público V1.1+)

Detalle en DISASTER_RECOVERY_PLAN_v1.md.


7. Seguridad

7.1 Compromisos mínimos:

  • Cifrado en tránsito TLS 1.2+
  • Cifrado en reposo AES-256
  • MFA disponible para todos los planes; obligatorio en roles admin
  • Pen-test anual independiente (V1.1+)
  • Reporte SOC 2 Type I (V1.2+) → Type II (V2.0+)

7.2 Notificación de brecha al Tenant ≤24h (cláusula DPA).


8. Modificaciones al SLA

8.1 InboMarket puede actualizar este SLA con ≥30 días de notificación.

8.2 Cambios que reduzcan materialmente compromisos requieren consentimiento del Tenant para Enterprise y se ofrecen como mejora opcional para los demás.


9. Exclusiones específicas adicionales

9.1 Beta features: sin SLA.

9.2 Funcionalidades de IA: sujetas a SLA del proveedor (OpenAI / Anthropic) aguas arriba. InboMarket NO compromete uptime para cuotas IA si proveedor externo falla, sin perjuicio de implementar fallback "best-effort".

9.3 Capa proxy IA (Issue #715): si la capa proxy se cae pero el dashboard sigue arriba, NO computa downtime del dashboard.

9.4 Reportes complejos > 10 min: no garantía de tiempo de ejecución.

9.5 Disponibilidad de gateways de pago del Tenant (Azul, BHD, CardNet) — InboMarket no responsable.


10. Procedimiento de reclamo de crédito

  1. Tenant abre ticket en sla@inbomarket.com dentro de 30 días del incidente
  2. Aporta evidencia: timestamps, screenshots, logs si tiene
  3. InboMarket investiga (≤10 días hábiles)
  4. Decisión: crédito aplicado, ajustado, o denegado con justificación
  5. Apelación: 7 días al Account Manager
  6. Crédito aplicado en factura siguiente

11. Contacto SLA

  • Reclamos SLA: sla@inbomarket.com
  • Status Page: status.inbomarket.com
  • Account Manager (Enterprise): según asignación contractual

⚠️ Avisos para revisión y validación operativa

Pre-requisitos técnicos para cumplir este SLA:

  1. Setup Status Page (Statuspage.io o equivalente) ANTES del launch
  2. Monitoreo externo (UptimeRobot mínimo, Pingdom recomendado)
  3. Plan DR documentado (DISASTER_RECOVERY_PLAN_v1.md)
  4. Runbook de incidentes (SECURITY_INCIDENT_RESPONSE_PLAN_v1.md)
  5. Procedimiento post-mortem público (template + canal)
  6. Team rotación on-call (V1.1+, V1 puede operar best-effort)
  7. Métricas RPO/RTO probadas
  8. Sistema de tickets con SLA tracking automático

Pendientes legales:

  1. Validar que 99.5% es alcanzable con la infraestructura actual antes de comprometerlo
  2. Revisar si Enterprise puede contractualmente negociar 99.95% sin penalidad económica desproporcionada
  3. Definir umbral mínimo de crédito ("si < USD 5, no procede")
  4. Si TINA estima que MVP no puede sostener 99.5% mes 1-3, considerar lanzar con 99% durante "estabilización" trimestre

Decisión PO pendiente: ¿Lanzar con 99.5% comprometido desde día 1, o con 99% en cláusula "estabilización inicial 90 días post-launch" + escalar a 99.5%?