Este recurso te ayuda a
- Definir qué identidad, estado e historial deben continuar entre canales.
- Asignar fuentes de verdad y responsabilidades por dominio.
- Diseñar integraciones progresivas sin prometer una sincronización universal desde el primer día.
Una empresa puede vender en tiendas, ecommerce, app, WhatsApp o call center y seguir ofreciendo experiencias fragmentadas.
Tener muchos canales es multicanalidad. La omnicanalidad aparece cuando una persona puede continuar la misma relación sin empezar de cero y sin encontrar versiones contradictorias de su identidad, saldo, rewards o beneficios.
La pregunta no es cuántos canales tiene la empresa. Es si esos canales pueden responder de manera coherente:
- quién es esta persona;
- qué actividad ya registró;
- qué saldo o progreso tiene;
- qué beneficio puede utilizar;
- qué reward ya fue consumido;
- qué ocurrió ante una devolución;
- qué sistema tomó cada decisión.
1. Diseñar continuidad antes que conectividad
Una integración puede mover datos y aun así no sostener una relación coherente.
Antes de elegir endpoints, webhooks o conectores, conviene definir qué continuidad necesita la experiencia.
Por ejemplo, una persona puede:
- registrarse en ecommerce;
- comprar en una tienda;
- consultar sus puntos en un portal;
- seleccionar un reward desde el móvil;
- usarlo en otra sucursal;
- devolver parte de la compra inicial;
- consultar soporte por una diferencia de saldo.
Ese recorrido exige conservar, como mínimo:
- una identidad consistente;
- referencias entre eventos;
- un saldo explicable;
- estados únicos para rewards y códigos;
- una política de devoluciones;
- evidencia para soporte;
- trazabilidad entre canales y sistemas.
Integrar loyalty no es mover puntos. Es preservar el significado de cada evento dentro de una relación continua.
2. Separar identidad, eventos, reglas y experiencia
No todos los sistemas tienen que hacer todo.
Una arquitectura más clara separa cuatro responsabilidades:
| Dominio | Pregunta central | Ejemplos de responsabilidad |
|---|---|---|
| Identidad | ¿Quién es la persona o cuenta? | Alta, login, identificadores externos, matching, consentimiento. |
| Eventos | ¿Qué ocurrió? | Compra, devolución, visita, canje, uso de beneficio. |
| Reglas y estado | ¿Qué consecuencia produce? | Puntos, elegibilidad, tier, reward, vencimiento, reversa. |
| Experiencia | ¿Qué ve y puede hacer la persona? | Saldo, progreso, selección, validación, mensajes y soporte. |
Un canal puede originar un evento sin ser dueño del saldo. Un portal puede mostrar rewards sin decidir elegibilidad. Un POS puede validar un código sin administrar todo el programa.
La claridad de responsabilidades reduce duplicados y evita que cada canal construya su propia versión de la relación.
3. Definir una fuente de verdad por dominio
No siempre existe un único sistema maestro para todo. Sí debería existir una autoridad definida para cada estado relevante.
| Estado | Fuente de verdad esperada | Sistemas que pueden consumirlo |
|---|---|---|
| Identidad y consentimiento | Sistema o servicio autorizado para ese dominio | Ecommerce, POS, portal, CRM, soporte. |
| Compra y devolución | Sistema que confirma la transacción | Loyalty, ERP, reporting, atención. |
| Ledger y saldo | Motor que registra movimientos y reversas | Portal, POS, ecommerce, soporte. |
| Tier y elegibilidad | Motor de reglas o servicio acordado | Canales, campañas, atención. |
| Reward y código | Sistema que controla emisión, vigencia y consumo | Portal, POS, ecommerce. |
| Evidencia operativa | Logs y auditoría correspondientes | Operaciones, soporte, finanzas. |
La fuente de verdad no es necesariamente el sistema que muestra el dato. Es el sistema autorizado para determinar su estado.
4. Diseñar contratos de eventos y estados
Para que varios canales continúen una relación, necesitan compartir un lenguaje operativo.
Cada evento relevante debería incluir, según corresponda:
- identificador único;
- identidad o cuenta vinculada;
- tipo de evento;
- fecha y origen;
- referencia externa;
- atributos necesarios para evaluar reglas;
- estado;
- vínculo con eventos anteriores;
- versión o evidencia suficiente para conciliación.
También deben definirse estados y transiciones.
Compra recibida ↓ Validación de elegibilidad ↓ Movimiento pendiente ↓ Movimiento disponible ↓ Posible devolución o reversa
Reward elegible ↓ Seleccionado ↓ Emitido ↓ Validado ↓ Consumido
Sin estados explícitos, cada canal interpreta “activo”, “usado” o “confirmado” de manera distinta.
5. Elegir el nivel de integración por recorrido
Una operación omnicanal puede evolucionar de forma progresiva.
| Recorrido | Opción inicial | Evolución posible |
|---|---|---|
| Identificación | Búsqueda o vinculación asistida | Consulta y alta desde el canal. |
| Compras | Archivo periódico o registro manual | Evento automático con idempotencia. |
| Saldo | Consulta desde una herramienta central | Lectura en tiempo cercano al evento. |
| Rewards | Emisión central y validación asistida | Selección y consumo desde canales conectados. |
| Devoluciones | Conciliación periódica | Reversa vinculada al evento original. |
| Soporte | Investigación manual con historial | Workflow con evidencia y estados compartidos. |
No todo necesita ser inmediato. Pero la experiencia debe declarar qué es inmediato, qué puede demorar y cómo se resolverán las diferencias.
La integración progresiva funciona cuando el cliente percibe una promesa coherente y la empresa puede explicar cada estado.
6. Diseñar fallas y conciliación
Las integraciones reales tienen demoras, reintentos, duplicados y datos incompletos.
Antes del lanzamiento conviene definir:
- qué ocurre si un evento llega dos veces;
- cómo se identifica un reintento;
- qué pasa si un canal está temporalmente desconectado;
- cuándo un movimiento queda pendiente;
- cómo se corrige un saldo divergente;
- quién inicia una reversa;
- cómo se concilian operaciones por lote;
- qué evidencia necesita soporte;
- qué sistema comunica el resultado al cliente.
La idempotencia, la trazabilidad y la conciliación no son detalles técnicos aislados. Son controles que protegen la promesa de continuidad.
Señal de madurez
Una operación no es omnicanal porque todos los procesos sean instantáneos. Es omnicanal cuando la organización sabe qué estado es válido, puede explicar una diferencia y tiene un camino consistente para resolverla.
7. Cómo puede ayudar Qualth
Qualth puede ayudar a centralizar programas, participantes, reglas, movimientos, puntos, tiers, rewards y beneficios; exponer estados a portales o canales; registrar eventos; y conectarse con sistemas mediante APIs e integraciones definidas para cada implementación.
Cuando alguno de los sistemas todavía no está integrado, el programa puede comenzar con flujos progresivos o asistidos y evolucionar sin esperar una automatización completa.
La plataforma no reemplaza la definición de fuentes de verdad, contratos, responsabilidades ni políticas de excepción. Ayuda a operar esas decisiones dentro del alcance acordado.
Una fila incompleta señala una decisión pendiente de producto, operación o integración.
Decisiones clave
- Diseñar continuidad de relación antes de seleccionar tecnología.
- Asignar una fuente de verdad por dominio.
- Separar quién origina, quién decide, quién muestra y quién corrige.
- Definir estados, referencias e idempotencia antes de automatizar.
- Elegir el nivel de integración por recorrido y no como una promesa global.
- Preparar conciliación y soporte como parte de la experiencia.
Medir si la continuidad funciona
El siguiente paso es observar identidad, comportamiento, utilización, incidencias y economía durante la primera etapa de operación.
Matriz
Mapa de continuidad omnicanal
Completar una fila por cada momento crítico: