Cuando revendes una plataforma IoT con tu propia marca, el cliente firma el acuerdo de nivel de servicio contigo y con nadie más. Tu logo está en los dashboards, tu nombre está en la factura y tu teléfono suena cuando los datos dejan de llegar a las 2 de la mañana. Pero la infraestructura no la operas tú, y ese único hecho crea la regla que toda cláusula de tu SLA debe respetar: no puedes prometer a tu cliente más de lo que la plataforma te promete a ti.
Cada compromiso que pones por escrito está respaldado por un compromiso del proveedor o lo absorbes tú como riesgo sin precio. La mayoría de los SLA de reventa fracasan porque se copiaron de plantillas escritas para empresas que son dueñas de sus servidores. El tuyo tiene que construirse al revés, partiendo del documento que te entrega tu proveedor.
El problema del traspaso
Pon el SLA del proveedor sobre la mesa antes de escribir una palabra del tuyo. Si la plataforma se compromete a un 99,9 por ciento de disponibilidad y tú prometes un 99,95 a un cliente, has asumido personalmente la diferencia: unos 21 minutos de exposición cada mes, sin infraestructura que arreglar y sin ningún crédito del proveedor llegando cuando falla.
Asumir esa brecha a propósito, con su precio dentro de tu tarifa, puede ser una decisión comercial legítima, y cómo pones precio al servicio gestionado es donde se resuelve esa decisión. Asumirla porque nadie hizo la resta es la forma en que los revendedores acaban pagando créditos de servicio con su propio margen.
Por eso también el SLA del proveedor entra en tu lista de criterios para elegir plataforma. TagoIO publica su SLA en tago.io/sla y cuenta con certificación ISO 27001, lo que da al revendedor una base auditada sobre la que construir en lugar de una garantía verbal. Si todavía estás eligiendo sobre qué construir, las plataformas que los integradores revenden de verdad son las que publican sus números.
Define la disponibilidad antes de prometerla
Un porcentaje de disponibilidad sin definición es adorno. Tres parámetros le dan sentido.
La ventana de medición va primero. Un 99,9 por ciento medido mensualmente permite unos 43 minutos de caída al mes, mientras que la misma cifra medida anualmente deja que una única caída brutal de ocho horas desaparezca entre once meses tranquilos. La ventana honesta es la mensual.
Segundo, qué cuenta como caída: ¿solo la caída total, o también el servicio degradado? Si la API responde en 30 segundos en lugar de 300 milisegundos, tu cliente vive una caída, lo admita tu definición o no.
Tercero, quién mide y cómo se informa. Un compromiso que el cliente no puede verificar genera disputas, así que nombra la fuente de monitorización y comprométete a informar de las incidencias en lugar de esperar a que te pregunten. La detección independiente es además lo que permite gestionar la caída de la plataforma como proveedor de servicio gestionado en vez de enterarte por tu propio cliente.
La durabilidad de los datos no es disponibilidad
Estas dos se confunden constantemente y son promesas distintas con consecuencias distintas. La disponibilidad es si el servicio responde ahora. La durabilidad es si los datos sobreviven.
Una plataforma puede estar una hora caída sin perder nada, y tu cliente recibe una disculpa y un crédito. Un dato perdido es otra categoría de fallo, a menudo irrecuperable y a veces una brecha de cumplimiento.
Tu SLA debe llevar texto separado para cada cosa: un porcentaje de disponibilidad con las definiciones de arriba y una cláusula de durabilidad que cubra periodo de retención, frecuencia de copias de seguridad y qué pasa con los datos que quedan en búfer durante una caída. Hazle la pregunta del búfer directamente a tu proveedor, porque el comportamiento de la ingesta durante una caída es donde la durabilidad se convierte sin ruido en un problema de disponibilidad.
Niveles de soporte: comprométete con la respuesta, apunta a la resolución
El tiempo de respuesta es lo rápido que se implica alguien cualificado. Eso lo controlas con la plantilla, así que comprométete con firmeza. El tiempo de resolución depende de dónde esté el fallo, y cuando está en la plataforma, el arreglo ocurre en una infraestructura que no operas. Mantén la resolución como objetivo declarado.
Ata las dos cosas a la severidad. Una incidencia de Severidad 1, servicio caído para todos los usuarios, puede llevar respuesta en una hora a cualquier hora del día y un objetivo de restablecimiento de cuatro horas. La Severidad 2, degradado pero funcionando, recibe respuesta en cuatro horas laborables. La Severidad 3 cubre dudas y defectos menores en un día laborable.
Fija números que tu equipo pueda cumplir en una mala semana, porque un compromiso incumplido cada mes cuesta más confianza que un compromiso nunca asumido. Poner los límites por escrito es además lo que hace sostenible el soporte cuando pasas de diez clientes.
Ventanas de mantenimiento y condiciones de salida
El mantenimiento planificado y anunciado con antelación queda fuera del cálculo de disponibilidad, y tus ventanas anunciadas deben caber dentro de las de tu proveedor, para que su mantenimiento nunca cuente contra ti. Comprométete a 72 horas de aviso o más.
Las condiciones de salida son las cláusulas que los compradores recuerdan. Declara que el cliente puede exportar sus datos en un formato documentado y legible por máquina durante el contrato y al terminarlo, fija el plazo y fija el coste, idealmente cero. En una plataforma con APIs completas esta cláusula cuesta casi nada de honrar, y gana negociaciones frente a competidores cuyo silencio sobre la salida lo dice todo. Ignorar el coste de salida hasta el momento de salir es uno de los errores más caros que cometen los integradores, y la misma pregunta está en el centro del bloqueo con el proveedor.
Modelos de cláusula que puedes adaptar
Son patrones de redacción para entregar a tu área legal, no asesoramiento jurídico. Algunas formas que funcionan:
“Porcentaje Mensual de Disponibilidad significa el total de minutos del mes natural, menos los minutos de Indisponibilidad, dividido por el total de minutos del mes. El Mantenimiento Programado anunciado con al menos 72 horas de antelación queda excluido de la Indisponibilidad.”
“Las incidencias de Severidad 1 reciben respuesta de personal técnico cualificado en el plazo de una hora desde el aviso, 24 horas al día, siete días a la semana. Los objetivos de restablecimiento son metas, no garantías.”
“Los datos del Cliente siguen siendo propiedad del Cliente. En un plazo de 30 días desde la terminación, el Proveedor pondrá todos los datos del Cliente a disposición para su exportación en un formato documentado y legible por máquina, sin coste adicional.”
“Los créditos de servicio se calculan como porcentaje de la cuota mensual, con un tope del 100 por cien de una cuota mensual, y constituyen el único remedio ante fallos de disponibilidad.”
Constrúyelo en espejo
El método es mecánico. Pon el SLA del proveedor y tu borrador uno al lado del otro y, para cada cláusula tuya, escribe el nombre de la cláusula del proveedor que la respalda o el margen que la pone en precio. Lo que no tenga ninguna de las dos es una donación a tu cliente.
Revisa ese emparejamiento cada año, porque las condiciones de tu proveedor, tu plantilla y el tamaño de tu flota se mueven todos. Es además el documento que cambia cuando pasas de proyectos puntuales a servicios recurrentes, ya que una suscripción es una promesa que se renueva cada mes.
La distancia entre lo que recibes y lo que prometes nunca desaparece. Un buen SLA la acorta, la pone en precio y deja tu nombre solo en lo que controlas. Empieza desde una base publicada: el SLA de TagoIO está en tago.io/sla. Agenda una demo o empieza gratis.
