SLA de calidad de datos entre negocio y tecnología para Customer Engagement
La calidad de datos falla cuando cada área entiende algo distinto por “dato correcto”. Negocio espera que una audiencia, un saldo o un consentimiento sean utilizables; tecnología puede verificar que el archivo llegó y cumple el esquema. Ambas observaciones pueden ser ciertas mientras el journey produce una decisión equivocada. Un acuerdo de nivel de servicio de datos crea un lenguaje común sobre propósito, reglas, medición, respuesta y responsabilidad.
En este contexto, SLA describe un acuerdo operativo interno o entre equipos. No debe confundirse automáticamente con un compromiso contractual. El documento traduce necesidades de Customer Engagement a condiciones medibles y define qué ocurre cuando no se cumplen. Su valor está en acelerar decisiones y correcciones, no en producir una cifra decorativa de “calidad general”.
Vincule cada regla con una decisión de negocio
La calidad no existe en abstracto. Un teléfono ausente puede impedir una notificación; una fecha de nacimiento incompleta puede ser irrelevante para una campaña de frecuencia; un saldo duplicado puede afectar dinero y confianza. Antes de fijar objetivos, documente qué decisión usa el dato y cuál sería el impacto de una falla.
El marco de calidad de datos del Gobierno del Reino Unido recomienda que las reglas expresen propósito, parte del dato, requisito, dimensión y métrica. Esa secuencia evita crear controles porque “siempre se han medido”. Para Customer Engagement, una regla puede ser: los eventos de compra usados para acreditar puntos deben contener identificador de transacción único; la dimensión es unicidad; la métrica es la proporción de eventos válidos sin duplicado.
El propósito también determina prioridad. Identidad, consentimiento, transacciones, saldos, redenciones y eventos de activación suelen requerir atención antes que campos descriptivos poco utilizados. La organización debe explicitar el riesgo: experiencia, dinero, cumplimiento, medición u operación. Así puede asignar recursos cuando varias fuentes incumplen al mismo tiempo.
Defina el contrato mínimo del dato
El SLA necesita un catálogo acotado de productos o flujos de datos. Cada uno declara productor, consumidor, propietario de negocio, fuente de verdad, frecuencia, esquema, ventanas y reglas críticas. El nombre de una tabla no basta; debe indicarse qué representa cada registro y cuándo se considera definitivo.
Incluya identificadores, timestamps, zona horaria, versión y estados. Si una transacción puede anularse, el contrato debe describir el reverso. Si un perfil puede fusionarse, debe quedar claro cómo se conserva trazabilidad. Si los datos llegan por lotes, establezca hora de corte y tratamiento de retrasos. Estas decisiones convierten el intercambio técnico en una base operativa.
El contrato también documenta límites. Un campo puede ser opcional porque la fuente no lo conoce; una métrica puede usar un proxy; un sistema puede conservar solo determinada historia. Declarar la limitación evita que el consumidor infiera precisión inexistente. Cuando una capacidad o dato no está verificado, se registra como pendiente de confirmar en el alcance, no se inventa.
Elija dimensiones y fórmulas accionables
Exactitud, completitud, consistencia, vigencia, unicidad y trazabilidad son dimensiones comunes, pero no todas aplican igual. Seleccione las que pueden cambiar una decisión y escriba una fórmula reproducible. “Datos completos” debe convertirse en campos obligatorios presentes para una población definida. “Datos frescos” debe especificar diferencia entre tiempo del evento y disponibilidad para consumo.
Cada indicador requiere numerador, denominador, exclusiones, ventana y fuente. Excluir casos inválidos es correcto si la regla es auditable. Excluir silenciosamente errores conocidos hace que el indicador pierda credibilidad. Para dimensiones críticas, conserve muestras o identificadores que permitan investigar sin exponer más datos personales de los necesarios.
Evite un promedio único. Una tasa global de 99% puede ocultar que un país, canal o integración falla por completo. Segmente solo por variables que conduzcan a una acción: origen, mercado, tipo de evento o versión. El exceso de cortes genera tableros difíciles de operar y objetivos contradictorios.
Establezca objetivos, bandas y severidad
El objetivo debe reflejar el impacto y la capacidad de corrección. Una regla de unicidad sobre movimientos de saldo puede necesitar tolerancia muy baja y cuarentena inmediata. Un atributo secundario puede admitir una banda inferior mientras se corrige la fuente. No existe un porcentaje universal que convierta datos en “buenos”.
Defina bandas por debajo del objetivo. Una desviación pequeña puede generar tarea y seguimiento; una caída importante puede bloquear una activación; una condición crítica puede pausar acreditaciones o forzar reconciliación. La guía británica de 2026 sobre incidentes de calidad propone conectar propósito, impacto, objetivo, bandas y prioridad. Esta lógica evita que todos los defectos reciban la misma urgencia.
La severidad también considera duración y exposición. Un lote incorrecto detectado antes de uso es diferente de una falla que ya afectó beneficios. Documente quién declara el incidente, quién puede contener y quién acepta el riesgo residual. La urgencia no debe eliminar la evidencia mínima para corregir.
Aclare responsabilidades de productor y consumidor
El productor es responsable de generar el dato conforme al contrato y avisar cambios. El consumidor debe usarlo dentro del propósito acordado, validar supuestos y reportar anomalías con evidencia. El propietario de negocio decide la regla y el impacto aceptable. Tecnología implementa transporte, validación, monitoreo y recuperación. Operaciones gestiona excepciones que no pueden resolverse automáticamente.
Esta separación evita dos extremos: culpar a la fuente por una interpretación que nunca se documentó, o transferir al consumidor la limpieza permanente de defectos conocidos. La corrección sostenible ocurre en el punto que originó el problema, aunque el consumidor necesite contención temporal.
Incluya un RACI solo si clarifica decisiones. Lo importante es identificar una persona o rol responsable de cada regla crítica, una ruta de escalamiento y sustitutos. “El equipo de datos” es demasiado amplio cuando un saldo incorrecto afecta a clientes en ese momento.
Diseñe detección, cuarentena y recuperación
Los controles pueden operar en entrada, durante transformación y antes del consumo. Validar esquema detecta ausencia o formato, pero no garantiza semántica. Una fecha válida puede pertenecer al evento equivocado. Combine reglas estructurales con reconciliación contra totales, estados o fuentes independientes cuando el riesgo lo requiera.
No todo error debe bloquear el flujo. La respuesta depende de criticidad. Un registro incompleto puede ir a cuarentena mientras el resto avanza; una inconsistencia de saldo puede detener todo el lote. La cola de excepciones necesita causa, propietario, edad y estado. Sin esa operación, la cuarentena se convierte en un archivo permanente de problemas.
La recuperación debe ser idempotente. Reprocesar un lote no debe duplicar puntos, mensajes ni beneficios. Conserve identificadores de evento, versión y resultado previo. Después de corregir, verifique no solo que el proceso terminó, sino que el dato quedó utilizable en el sistema consumidor y que cualquier efecto incorrecto fue revertido.
Defina tiempos que correspondan al uso
El SLA separa frecuencia de entrega, latencia, tiempo de detección y tiempo de recuperación. Una fuente diaria puede entregar puntualmente y aun tardar demasiado en notificar un defecto. Un journey en tiempo real necesita ventanas diferentes de una analítica mensual. La misma regla puede tener objetivos por uso.
El reloj de recuperación comienza cuando existe evidencia suficiente para clasificar el incidente. También conviene medir tiempo desde que ocurrió, porque una detección tardía puede ser el riesgo principal. Use percentiles y edad de casos abiertos, no solo promedios. Los casos extremos suelen concentrar el mayor impacto operativo.
La escalación debe definir niveles y canales. Si se incumple una regla crítica, el dueño del journey necesita saber si debe pausar, usar una fuente alternativa o limitar audiencia. Tecnología necesita información reproducible: versión, periodo, origen, muestra y consulta que detectó la falla.
Conecte calidad con journeys, campañas y beneficios
Un acuerdo de datos solo crea valor cuando modifica la operación de Customer Engagement. Antes de activar un journey, verifique que sus fuentes críticas cumplen la banda requerida. Durante la ejecución, monitoree cobertura, vigencia y errores. Después, reconcilie oportunidades de entrada con decisiones y efectos.
Los beneficios requieren atención especial. La calidad no se limita al perfil; incluye reglas, catálogo, inventario, saldo, emisión, redención, expiración y reverso. Una campaña puede seleccionar bien a la audiencia y fallar por un catálogo desactualizado. Por eso el mapa de dependencias debe acompañar al SLA.
También se debe separar confiabilidad operativa de resultado comercial. Datos correctos permiten medir una campaña, pero no garantizan que cambie conducta. No atribuya una mejora de retención al cumplimiento del SLA sin un método de evaluación apropiado.
Revise el acuerdo con evidencia de incidentes
La revisión mensual o trimestral debe observar cumplimiento por regla, bandas, incidentes, tiempo de recuperación, causas recurrentes y excepciones pendientes. Un objetivo que siempre pasa puede ser irrelevante o demasiado laxo. Uno que siempre falla sin una acción financiada crea una ficción administrativa.
Use incidentes para corregir contratos y fuentes. Si los equipos limpian el mismo campo cada semana, el SLA no está resolviendo la causa. Si una regla genera falsos positivos, ajuste población o fórmula con aprobación documentada. Mantenga historial de cambios para interpretar tendencias.
La madurez aparece cuando negocio y tecnología pueden discutir impacto, costo y prioridad con los mismos datos. El acuerdo deja de ser un documento estático y se vuelve un sistema de decisiones sobre calidad, riesgo y capacidad.
Pruebe el SLA con escenarios reales
Antes de declararlo operativo, ejecute casos de datos faltantes, duplicados, retrasados, fuera de rango y contradictorios. Confirme que cada regla identifica la condición correcta, asigna la banda esperada y genera una tarea para el rol adecuado. Una prueba satisfactoria incluye la recuperación: corregir la fuente, reprocesar sin duplicar efectos y verificar el resultado en el consumidor.
Use además un escenario de fallo silencioso. Si una fuente deja de enviar registros, una tasa calculada solo con lo recibido puede permanecer perfecta. La reconciliación de volúmenes, ventanas y secuencias debe detectar la ausencia. El ejercicio revela si el acuerdo mide realmente el servicio o solo la parte visible del flujo.
Cómo aplicarlo con Lealto
Lealto puede participar en un diagnóstico para identificar perfiles, transacciones, campañas, beneficios e integraciones que intervienen en un caso de Customer Engagement. El alcance concreto debe confirmar fuentes maestras, campos, frecuencia, validaciones, responsables y manejo de excepciones. La plataforma no sustituye la propiedad del dato ni la política de calidad de cada empresa.
Un piloto puede empezar con un journey y tres reglas críticas: identidad utilizable, evento transaccional único y consentimiento vigente. Se establece línea base, objetivo, bandas, cola de excepciones y respuesta. Después se amplía a saldos, redenciones u otras entidades según evidencia y prioridad comercial. Documente también el costo de investigar, corregir y reprocesar, porque un objetivo técnicamente alcanzable puede ser operativamente insostenible si cada excepción exige trabajo manual que la organización no ha dimensionado.
Preguntas frecuentes
¿SLA de datos significa un contrato legal?
No necesariamente. Aquí se usa como acuerdo operativo. Si se convertirá en compromiso contractual, debe revisarse por las áreas correspondientes.
¿Quién debe fijar el porcentaje objetivo?
Negocio y tecnología en conjunto. El dueño del uso define impacto; el productor y el consumidor aportan capacidad, medición y recuperación.
¿Es suficiente limpiar los datos antes de una campaña?
No. La limpieza contiene el síntoma. La mejora sostenible corrige la fuente, previene recurrencia y verifica el resultado posterior.
Fuentes
Government Digital Service, Data quality issues framework: https://www.gov.uk/government/publications/implement-a-data-quality-action-plan/data-quality-issues-framework
Government Digital Service, The Government Data Quality Framework guidance: https://www.gov.uk/government/publications/the-government-data-quality-framework/the-government-data-quality-framework-guidance
Lealto, Calidad de datos para Customer Engagement: https://lealto.com/customer-engagement/calidad-datos-customer-engagement-controles/
OpenTelemetry, Observability Primer: https://opentelemetry.io/docs/concepts/observability-primer/
Contáctenos
Construyamos su estrategia de lealtad