Este recurso te ayuda a
- Separar la experiencia común de las responsabilidades de cada operador.
- Definir quién origina, financia, entrega y revierte cada promesa.
- Diseñar un programa que conserve continuidad sin borrar la autonomía de la red.
Una red de franquicias puede compartir marca, propuesta comercial y experiencia visual sin funcionar como una sola empresa.
Una persona puede comprar en un local, acumular valor común y querer utilizarlo en otro. Para ella, la relación es con la marca. Para la red, alguien originó la venta, alguien asumió el costo y alguien deberá cumplir la promesa.
Ahí aparece la tensión central:
Loyalty en una red distribuida no consiste solamente en habilitar puntos en muchos locales. Consiste en gobernar identidad, permisos, funding, fulfillment, reversas y excepciones entre actores independientes.
1. Describir la red antes de diseñar el programa
No todas las redes distribuidas tienen la misma estructura.
Pueden coexistir:
- locales propios;
- franquicias;
- licenciatarios;
- distribuidores;
- ecommerce central;
- operadores regionales;
- alianzas o cooperativas;
- canales asistidos.
Antes de elegir mecánicas, completar un inventario básico:
| Tipo de unidad | Quién factura | Quién opera | Qué datos origina | Qué beneficios entrega | Quién asume el costo |
|---|---|---|---|---|---|
| Local propio | |||||
| Franquicia | |||||
| Ecommerce central | |||||
| Distribuidor |
Si la red no puede completar esta tabla, todavía no existe suficiente claridad para prometer acumulación y uso comunes.
2. Separar cinco formas de responsabilidad
La pregunta “¿de quién es el cliente?” mezcla dominios distintos.
Conviene separar:
- Dueño conceptual: define el propósito y los principios del programa.
- Dueño operativo: ejecuta una interacción concreta.
- Dueño del dato: determina el estado válido de identidad, compra, saldo o reward.
- Responsable económico: financia o reconoce el costo.
- Responsable frente al cliente: recibe, investiga y resuelve el reclamo.
Una marca puede gobernar la propuesta sin operar cada venta. Una franquicia puede entregar un reward sin ser dueña de la regla. Un sistema puede registrar un movimiento sin decidir quién absorbe el costo.
La frase “la relación pertenece a la marca” no es una definición operativa suficiente. Debe traducirse en permisos, responsabilidades, costos y procedimientos verificables.
3. Definir qué debe ser común y qué puede ser local
No todo necesita centralizarse.
| Dimensión | Común en toda la red | Variable local posible |
|---|---|---|
| Identidad | Identificador y reglas de vinculación | Método de captura según canal. |
| Earn | Principios y eventos comunes | Multiplicadores o campañas aprobadas. |
| Rewards | Catálogo o condiciones compartidas | Beneficios financiados localmente. |
| Experiencia | Promesa, lenguaje y mínimos de servicio | Activaciones o contenidos locales. |
| Datos | Estados y trazabilidad requeridos | Acceso limitado por operador. |
| Soporte | Política y escalamiento | Primera atención en el local. |
| Economía | Reglas de funding y conciliación | Presupuestos o promociones locales. |
La autonomía local puede aportar relevancia. Pero necesita límites para que el cliente no reciba promesas incompatibles entre unidades.
4. Diseñar funding y fulfillment por separado
Quien financia un beneficio no siempre es quien lo entrega.
- quién originó el evento;
- qué regla generó valor;
- quién financió ese valor;
- qué operador cumplió la promesa;
- qué evidencia confirma la entrega;
- qué ocurre ante devolución o disputa;
- qué ajuste necesita la conciliación.
Flujo de referencia
Evento en operador A ↓ Valor emitido bajo regla común ↓ Reward utilizado en operador B ↓ Entrega confirmada ↓ Costo atribuido y conciliado
La plataforma puede registrar movimientos y estados. El modelo contractual y económico debe definir cómo se compensa a los actores involucrados.
5. Diseñar identidad y acceso sin exponer toda la red
Una identidad común no implica que todos los operadores deban ver toda la información.
- qué identificadores son compartidos;
- qué datos puede consultar cada operador;
- qué información necesita para atender al cliente;
- cómo se conservan consentimiento y preferencias;
- cómo se separan datos comerciales locales y globales;
- qué ocurre cuando un operador sale de la red;
- cómo se corrigen duplicados o asociaciones erróneas.
El principio es continuidad con mínimo acceso necesario. La experiencia puede ser común sin convertir la base completa en un recurso indiscriminadamente compartido.
6. Preparar devoluciones, fraude y salida de operadores
Las situaciones difíciles revelan si el gobierno está realmente diseñado.
- devoluciones en una unidad distinta;
- reward emitido por un operador y consumido en otro;
- saldo generado por una venta luego anulada;
- beneficio local comunicado como si fuera común;
- operador que rechaza una promesa vigente;
- diferencias de precios o surtido;
- ajustes manuales;
- fraude o abuso;
- disputas de conciliación;
- suspensión o salida de una franquicia.
Una red madura no depende de acuerdos informales para resolver estas situaciones. Conserva reglas, evidencia y un proceso de escalamiento.
7. Cómo puede ayudar Qualth
Qualth puede ayudar a centralizar participantes, reglas, puntos, rewards y movimientos; conservar trazabilidad; asignar permisos; operar distintos canales; y conectarse con sistemas mediante integraciones definidas para cada implementación.
La plataforma no determina por sí sola contratos, obligaciones fiscales, funding ni settlement entre operadores. Esas decisiones deben acordarse y validarse por las partes correspondientes. Qualth puede ayudar a representar y operar el modelo aprobado dentro del alcance implementado.
Decisiones clave
- No tratar una franquicia como una sucursal propia.
- Separar gobierno, operación, datos, costo y atención.
- Definir qué es común y qué puede variar localmente.
- Diseñar funding y fulfillment como responsabilidades distintas.
- Limitar acceso a datos sin romper la continuidad.
- Preparar devoluciones, disputas y salida de operadores.
Llevar el modelo al punto de atención
El siguiente paso es convertir responsabilidades y reglas en recorridos que puedan funcionar de manera consistente en cada tienda.
Matriz
Matriz de responsabilidades y funding
Completar una fila por cada proceso relevante: