Dónde mostrar el club adentro de tu tienda para que la gente lo use
Producto
Producto
Cómo conectar tu sistema a un motor de fidelización: qué eventos mandar y qué escuchar
9 min de lectura
Resumir con IA
9 min de lectura
Cuando una empresa arma su programa sobre un motor por API, la parte difícil no es la pantalla de puntos: es decidir qué le cuenta su sistema al motor, cuándo se lo cuenta y qué hace cuando el motor le avisa algo de vuelta. Esta es la lista de eventos que sostiene el noventa por ciento de los programas, con los casos que rompen la cuenta si nadie los pensó antes.
Una empresa que decide poner su propia marca adelante y usar un motor de fidelización por debajo suele llegar con el diseño del programa bastante claro: cuántos puntos por compra, qué niveles, qué se canjea. Lo que casi nunca está definido es lo otro, que es donde se va el tiempo de la integración: qué eventos manda cada sistema, en qué momento y qué pasa cuando algo se cae en el medio.
El motor no adivina nada. No sabe que una compra se pagó, que un pedido se devolvió, que un empleado cumplió el objetivo del trimestre o que un distribuidor llegó al volumen del mes: eso lo sabe el sistema de la empresa, y el programa existe en la medida en que se lo cuente.
Lo que sigue es la lista corta de eventos que sostiene casi cualquier programa, qué conviene escuchar del otro lado, y los cuatro casos que rompen las cuentas si no se resuelven antes del go live.
Los eventos que tu sistema manda
Son menos de los que parece. Un programa completo se sostiene con cinco o seis, y el resto son variantes.
- El alta del miembro, con el identificador que tu sistema ya usa para esa persona.
- La transacción que suma, que en un ecommerce es la compra pagada y en otros programas puede ser un objetivo cumplido, un volumen alcanzado o una acción completada.
- La reversa, que es la devolución, la anulación o el pedido cancelado.
- El canje, cuando el catálogo o el checkout son tuyos y el motor sólo valida el saldo.
- El cambio de datos del miembro, que es lo que mantiene el perfil sincronizado con tu fuente de verdad.
El identificador es la decisión más importante de toda la integración y es la más difícil de cambiar después. Tiene que ser el mismo que usa tu sistema, estable en el tiempo y único: el documento, el número de socio, el legajo o el código de cliente, pero no el correo, que la gente cambia, ni el teléfono, que se reasigna.
Y cada evento necesita una clave propia, para que mandarlo dos veces no acredite dos veces. Es lo que salva la integración el día que un reintento automático repite media hora de eventos, que es un día que siempre llega.
Lo que conviene escuchar del otro lado
Acá está la diferencia entre un programa que corre solo y uno que hay que ir a preguntarle todo el tiempo cómo va.
El saldo cambió. Es lo que le permite a tu aplicación mostrar el saldo correcto sin consultarlo en cada pantalla, y lo que evita el peor detalle de un programa propio: que la app diga un número y el resumen diga otro.
El miembro subió de nivel. Es el momento con más efecto de todo el programa y el que más se desaprovecha: si tu sistema se entera, puede mandar el mensaje, habilitar el beneficio y mostrarlo en la pantalla siguiente.
El canje se completó o se cayó. Sobre todo cuando hay premios físicos de por medio, porque ahí el estado lo mueve la logística y no vos.
El miembro entró o salió de un segmento, que es lo que dispara las campañas desde tu propio sistema de mensajería, si es que preferís mandarlas vos.
La regla general es simple: lo que tu producto tiene que mostrar en el momento, se escucha; lo que se consulta de vez en cuando, se pregunta. Un sistema que consulta el saldo en cada carga de pantalla funciona igual hasta que crece, y ahí empieza a pagar latencia por un dato que podría haber tenido guardado.
Los cuatro casos que hay que resolver antes del go live
La devolución de algo que ya se canjeó
Alguien acumula con una compra, canjea, y después devuelve esa compra. El saldo a retirar ya no está.
La salida sana es dejar la cuenta en negativo y compensarla con la próxima acumulación, que es bastante mejor que reclamarle a alguien un canje ya usado. Lo importante no es cuál de las dos políticas se elige: es que esté elegida antes del primer caso, porque si no se resuelve a mano y cada uno con un criterio distinto.
El mismo humano con dos cuentas
Pasa siempre que hay más de un canal: la persona compró online con un correo y en el mostrador dio su documento, y quedaron dos miembros con dos saldos.
Conviene definir desde el principio cuál es el dato que unifica y tener resuelta la fusión de cuentas. Cuanto más histórico acumulan las dos, más confuso es el resultado para el miembro y más caro es arreglarlo.
El evento que llega tarde
Un sistema se cae, se acumulan eventos y entran todos juntos dos horas después. Si la acreditación depende de la hora de llegada y no de la hora en que ocurrió, esas transacciones caen en el mes equivocado o pierden una promoción que estaba vigente.
Por eso cada evento viaja con la fecha del hecho y no con la de envío, y el motor calcula sobre esa. Es una línea de diseño que no se nota nunca, salvo el día que se cae algo.
La regla que cambia
El día que la empresa decide que ahora se acumula distinto, hay que saber qué pasa con lo acumulado antes.
Lo que funciona es que la regla tenga fecha de vigencia y que lo viejo se calcule con la regla vieja. Recalcular el histórico con la regla nueva cambia saldos que los miembros ya vieron, y un saldo que baja sin explicación es el reclamo más difícil de contestar que tiene un programa.
Qué queda de cada lado
Conviene decirlo explícito, porque es la confusión más común cuando la marca pone el frente.
Del lado del motor quedan los miembros, el saldo, los niveles y su progreso, las reglas de acumulación con sus multiplicadores, los segmentos, el catálogo de premios con su canje y la logística de los premios físicos. Es la parte que no se ve y la que nadie quiere mantener a mano.
Del lado de la empresa quedan las pantallas, la identidad, el contenido, la mensajería si se maneja desde el sistema propio, y las decisiones de negocio: cuánto se devuelve, qué se canjea y a quién se le habla.
Y hay algo que conviene que quede del lado del motor aunque tengas equipo para hacerlo: el cálculo del saldo. Es la clase de lógica que parece simple hasta que aparecen las devoluciones parciales, los vencimientos, los ajustes manuales y la auditoría de por qué esta persona tiene estos puntos. Un programa que crece necesita poder responder esa última pregunta con precisión, y esa respuesta es un historial, no un número.
En qué orden se hace
La integración que sale bien casi siempre sigue el mismo orden, y no es el que parece.
Primero los miembros y las transacciones que suman, contra un ambiente de prueba y con datos reales copiados. Con eso solo ya se puede ver si las reglas hacen lo que el negocio esperaba, que es la parte que más veces hay que corregir.
Después las reversas, que es donde aparecen los casos raros de la operación de cada empresa.
Recién ahí las pantallas, cuando el saldo que van a mostrar ya es confiable. Empezar por la interfaz es la forma más común de terminar rehaciéndola.
Y por último los canjes, que son lo último que un miembro hace y lo primero que se rompe si el catálogo y el stock no están resueltos.
Todo eso se hace con el equipo que después va a operar el programa, no sólo con el equipo técnico: la mitad de las decisiones de la integración son de negocio disfrazadas de detalles de implementación.
Preguntas frecuentes
¿Cuánto tarda una integración así?
Depende mucho más del diseño del programa que del código. Mandar eventos y escuchar webhooks es trabajo conocido para cualquier equipo; definir qué suma, cuánto, con qué tope y qué pasa con las devoluciones es lo que lleva las reuniones.
Lo que acorta los plazos de verdad es llegar con dos cosas decididas: cuál es el identificador del miembro y qué eventos ya existen en el sistema. Casi siempre existen y están en otro lado, dentro del ERP o del punto de venta.
¿Hace falta que el programa sea para clientes?
No, y esa es una de las razones para usar un motor por API en vez de una solución cerrada. El mismo motor sostiene programas para empleados y equipo de ventas, para la red de distribuidores, para colaboradores externos o para socios, cada uno con su mecánica.
Lo que cambia entre esas audiencias no es la infraestructura, es el evento que suma: en un programa de clientes es la compra, en uno de equipo de ventas es el objetivo cumplido, y en uno de distribuidores, el volumen del período.
¿Y si ya tenemos puntos hechos a mano en nuestra base?
Se migran los saldos antes de abrir el programa nuevo, y esa es la parte que no se puede improvisar: un miembro que entra y ve menos puntos de los que tenía es una pérdida de confianza difícil de revertir.
El orden que funciona es exportar los saldos, convertirlos si la unidad cambia, cargarlos como un ajuste inicial con su motivo y recién ahí abrir el programa. Con los saldos cargados de antemano, el cambio es invisible para el miembro.
¿Qué pasa si el motor no responde en algún momento?
Tu producto no puede quedar esperando: la acumulación se encola y se reintenta, y la pantalla muestra lo último que sabía con una marca de que hay movimientos pendientes. Es el mismo criterio que cualquier integración de pagos.
Por eso los eventos viajan con su clave propia y con la fecha del hecho: cuando la cola se destraba, todo entra en orden, nada se acredita dos veces y las cuentas cierran igual que si no hubiera pasado nada.
En esta nota
- Producto
- eventos de compra
- webhooks
- integración con el ERP
- saldo en tiempo real
