SLI y SLO para customer journeys y activaciones
Un customer journey puede estar “encendido” y aun así fallar para el cliente. El mensaje llega tarde, el beneficio no se acredita, un evento duplicado repite una acción o una exclusión válida no se respeta. Medir únicamente disponibilidad de infraestructura deja estas fallas fuera de cuadro. Los SLI y SLO permiten describir confiabilidad desde el resultado que el recorrido debe entregar, con una población, una ventana y una fuente de medición explícitas.
Un SLI es un indicador cuantitativo del comportamiento observado. Un SLO es el objetivo que se establece sobre ese indicador. Google SRE insiste en definir con precisión cómo se mide y bajo qué condiciones. Trasladado a Customer Engagement, eso significa que “el journey funciona” debe convertirse en una proposición verificable: qué participantes eran elegibles, qué acción se esperaba, dentro de qué tiempo, con qué criterio de corrección y cómo se excluyen los casos que no correspondían.
Empiece por el resultado del recorrido
El diseño debe comenzar con la promesa operativa, no con la métrica disponible. En una bienvenida, el resultado puede ser que cada alta válida reciba la primera comunicación dentro de una ventana. En una campaña de cumpleaños, puede ser que cada persona elegible reciba un beneficio correcto una sola vez. En una recuperación, puede ser que el mensaje se cancele si aparece una compra antes del envío.
Esta definición obliga a identificar frontera y sujeto. El numerador cuenta resultados buenos; el denominador representa oportunidades válidas de servicio. Si el denominador incluye registros sin consentimiento, perfiles incompletos o eventos todavía no consolidados, el indicador mezcla fallas con casos que nunca debían avanzar. Si los excluye sin una regla auditable, puede ocultar problemas.
Conviene escribir primero una frase legible por negocio. Por ejemplo: “de las redenciones elegibles confirmadas, la proporción reflejada en el saldo correcto dentro de cinco minutos”. Después se traduce a consultas, eventos y umbrales. Este orden reduce la tentación de convertir una métrica técnica conveniente en sustituto de la experiencia.
Modele el journey como estados y transiciones
Un recorrido no es una serie de pantallas; es un sistema que mueve participantes entre estados a partir de eventos y reglas. Para medirlo, documente el estado inicial, las transiciones válidas, las salidas, los tiempos y los efectos. Cada transición necesita un identificador que permita correlacionar entrada, decisión y acción.
La confiabilidad se observa en cuatro planos. La cobertura indica si todas las oportunidades válidas fueron evaluadas. La latencia muestra cuánto tarda la transición. La corrección comprueba que el resultado coincide con la regla. La unicidad confirma que una oportunidad no generó efectos duplicados. En recorridos con beneficios, añada consistencia entre emisión, saldo, redención y reverso.
Este modelo permite localizar la falla. Si la entrada fue aceptada pero la decisión nunca ocurrió, hay un problema de procesamiento. Si la decisión fue correcta y el canal rechazó el envío, la degradación está en la entrega. Si el mensaje llegó y el beneficio era incorrecto, el incidente es de corrección. Un único indicador agregado borraría estas diferencias y dificultaría asignar responsables.
Construya SLIs desde eventos auditables
Cada SLI necesita fuente, unidad, fórmula, frecuencia y tratamiento de datos tardíos. El evento debe conservar identificador de participante o cuenta según corresponda, identificador de journey, versión, transición, resultado, timestamp y causa de exclusión o error. No todos esos campos tienen que exponerse en un tablero, pero sí estar disponibles para reconstruir el cálculo.
Los SLIs más útiles suelen expresarse como proporciones. Éxito correcto dividido por oportunidades válidas; transiciones dentro del tiempo divididas por transiciones completadas; efectos únicos divididos por oportunidades que generaron efecto. Para latencia, use percentiles cuando una cola larga de casos lentos afecte a una minoría importante. El promedio puede ocultar que algunos participantes esperan horas mientras la mayoría responde en segundos.
La instrumentación debe mantener semántica consistente entre servicios. OpenTelemetry distingue métricas, logs y trazas: las métricas resumen comportamiento, los logs conservan eventos y las trazas conectan operaciones a lo largo del sistema. En un journey distribuido, correlacionar estas señales ayuda a seguir una activación desde el evento de origen hasta el canal o beneficio final.
Defina SLO con ventana, objetivo y población
Un objetivo incompleto como “99% de éxito” no permite operar. Debe indicar 99% de qué, durante qué periodo, medido dónde y para quién. La ventana puede ser móvil para detectar deterioro reciente o calendario para compromisos mensuales. La elección depende del ciclo de decisión. Un recorrido diario puede necesitar señales rápidas; una cohorte mensual puede requerir espera para recibir datos tardíos.
El umbral debe partir de impacto y capacidad, no de imitar un porcentaje de infraestructura. Un 99,9% puede ser insuficiente si la falla afecta dinero y no existe reverso; un 98% puede ser útil durante un piloto si el resto entra en una cola controlada y visible. La organización debe explicar qué pasa fuera del objetivo: reintento, revisión, comunicación o compensación.
También conviene segmentar cuando la agregación oculta daño. Mercado, canal, proveedor, tipo de beneficio o versión pueden tener comportamiento distinto. Un SLO global puede pasar mientras una región entera falla. La segmentación debe limitarse a dimensiones accionables; demasiadas combinaciones crean ruido y dificultan mantener objetivos coherentes.
Use presupuestos de error para gobernar cambios
El presupuesto de error representa la porción de resultados que el objetivo permite no cumplir en una ventana. No es permiso para fallar sin consecuencias. Es una forma de equilibrar cambio y confiabilidad. Si el recorrido consume el presupuesto rápidamente, el equipo reduce exposición, pausa despliegues o dedica capacidad a corregir la causa. Si se mantiene holgura, puede experimentar dentro de límites.
En Customer Engagement, el presupuesto debe considerar severidad. Cien mensajes retrasados y cien beneficios incorrectos no tienen el mismo impacto. Puede ser necesario separar objetivos: puntualidad, corrección, unicidad y cumplimiento de exclusiones. Los efectos financieros o de consentimiento pueden tener tolerancias mucho más bajas y controles de contención específicos.
El ritmo de consumo importa más que esperar al cierre de mes. Una campaña masiva puede agotar el presupuesto en minutos. Use ventanas cortas para detectar una caída brusca y ventanas largas para observar tendencia. Las alertas deben conducir a una acción decidida de antemano, no solo abrir otra gráfica.
Diseñe alertas que indiquen qué hacer
Una alerta debe incluir journey y versión afectados, SLI, magnitud, población, inicio estimado y enlace a evidencia. El receptor necesita saber si puede pausar, reintentar, excluir un canal o escalar. Si todas las señales llegan al mismo equipo sin contexto, la fatiga de alertas reemplaza la observabilidad.
Distinga síntomas de causas. La caída de puntualidad es un síntoma que importa a negocio; la cola saturada o el proveedor lento puede ser la causa. Alertar solo por infraestructura puede perder errores de corrección. Alertar solo por el resultado final puede retrasar el diagnóstico. Las dos capas deben conectarse mediante identificadores y un runbook.
El runbook define verificación, contención, recuperación y comunicación. Para acciones repetibles, automatice con límites: por ejemplo, pausar una versión cuando el error supera un umbral. No automatice una compensación irreversible sin confirmar identidad, afectación y política.
Evite indicadores que premian el comportamiento equivocado
Contar mensajes enviados no demuestra que el journey cumplió. Tampoco aperturas o clics prueban confiabilidad; sirven para evaluar interacción. Disponibilidad del proveedor de mensajes es relevante, pero no cubre elegibilidad, contenido, beneficio ni exclusión. Cada métrica debe conservar su propósito.
Otro error es medir solo casos completados. Si las entradas perdidas no llegan al sistema de destino, el denominador desaparece y la tasa parece saludable. La reconciliación entre fuente y journey permite descubrir oportunidades ausentes. También debe vigilarse la duplicación: dos ejecuciones exitosas para la misma oportunidad no equivalen a mejor servicio.
No convierta el SLO en una promesa comercial sin revisar alcance. Un objetivo interno ayuda a operar; un SLA contractual tiene implicaciones diferentes. La documentación debe separar objetivo, compromiso y capacidad observada.
Establezca una cadencia entre negocio y tecnología
El dueño del journey define resultado, población y prioridad. Tecnología define instrumentación y mecanismos de recuperación. Operaciones valida excepciones, y datos confirma fuentes y reconciliación. La revisión semanal puede observar consumo de presupuesto, incidentes y cambios; una revisión mensual puede ajustar objetivos y eliminar indicadores que no conducen a decisiones.
Cada versión relevante del journey debe declarar los SLI que puede afectar. Antes de activar, pruebe emisión de eventos, correlación, cálculo y alerta. Después del lanzamiento, verifique volumen y distribución contra la expectativa. Esta comprobación cierra la brecha entre un tablero técnicamente correcto y una población comercial mal definida.
El aprendizaje no consiste en elevar el objetivo después de un buen mes. Primero determine si cambió el sistema, la población o la medición. Un SLO útil permanece estable el tiempo suficiente para comparar y se modifica con una razón documentada.
Valide el cálculo antes de convertirlo en gate
Una definición escrita puede fallar cuando se implementa. Compare el cálculo con una muestra manual de casos buenos, excluidos, tardíos, duplicados y erróneos. Introduzca fallas controladas en un ambiente de prueba para comprobar que el indicador cambia, la alerta se activa y el runbook conduce a una acción. Esta prueba evita tableros que permanecen verdes porque la fuente dejó de emitir eventos.
También debe probarse la reconciliación del denominador. Tome una ventana cerrada, cuente oportunidades en la fuente y siga cada una hasta su salida. Las diferencias deben tener una causa documentada, no una categoría genérica de “otros”. Cuando existen datos tardíos, publique primero un valor provisional y luego uno consolidado, identificando la versión del cálculo.
Antes de usar el SLO como gate de lanzamiento, observe una línea base suficiente para entender variación normal, estacionalidad y volumen. El objetivo inicial puede revisarse, pero cada cambio debe conservar fecha, motivo y efecto esperado. Así el sistema de medición también queda sujeto a control de cambios.
Cómo aplicarlo con Lealto
Lealto puede participar en un diagnóstico para conectar perfiles, eventos, campañas, beneficios e integraciones según el alcance del proyecto. La definición de SLI y SLO requiere confirmar qué señales existen, quién es dueño de cada fuente y qué acciones de pausa, reintento o conciliación están disponibles. No se presume que una capacidad específica esté habilitada sin verificar configuración e integración.
Un punto de partida práctico es elegir un journey importante y definir tres indicadores: cobertura de oportunidades, corrección del efecto y tiempo hasta el resultado. Después se añaden unicidad, canal o beneficio cuando la evidencia lo justifica. Este foco produce una línea base útil sin crear un catálogo de métricas imposible de operar.
Preguntas frecuentes
¿SLI y KPI son lo mismo?
No. Un SLI mide nivel de servicio observado; un KPI puede medir resultado comercial. Se relacionan, pero un journey confiable no garantiza por sí mismo conversión o retención.
¿Debe existir un SLO por cada paso?
No. Priorice transiciones que representan valor, riesgo o una dependencia crítica. Demasiados objetivos dispersan atención.
¿Un SLO sustituye pruebas?
No. Las pruebas reducen defectos antes de activar; el SLO mide comportamiento real y guía respuesta durante la operación.
Fuentes
Google SRE, Service Level Objectives: https://sre.google/sre-book/service-level-objectives/
Google SRE, Measuring Reliability: https://sre.google/resources/practices-and-processes/measuring-reliability/
OpenTelemetry, Observability Primer: https://opentelemetry.io/docs/concepts/observability-primer/
Lealto, Automatización de customer journeys: https://lealto.com/customer-engagement/automatizacion-customer-journeys/
Contáctenos
Construyamos su estrategia de lealtad