Cómo agregar un programa de lealtad al proyecto de un cliente de tu software factory sin construir el motor

Por qué el programa de puntos se cotiza mal

Sumar y restar es la parte fácil. Lo que se come las horas aparece después: la compra que se devuelve cuando los puntos ya se usaron, el multiplicador que vale sólo para un segmento, el nivel que se mantiene comprando y se pierde si no, los puntos que vencen y hay que avisar antes, el canje que no puede dejar el saldo en negativo aunque lleguen dos pedidos al mismo tiempo.

Y encima de eso está la operación. El cliente no quiere pedirte un deploy cada vez que cambia una regla, quiere ver cuántos miembros tiene en cada nivel y quiere saber quién dejó de comprar. Cada uno de esos pedidos es un tablero o una pantalla de administración más que nadie presupuestó.

El problema no es que tu equipo no pueda construirlo, es que no le conviene. Cada hora que se va en la lógica de puntos es una hora que no se va en lo que el cliente realmente diferencia: su app, su tienda o su sistema.

Qué hace tu equipo y qué hace el motor

Tu equipo pone el frente. Las pantallas del programa con el diseño y la marca del cliente, los eventos que el producto ya dispara (un registro, una compra, una devolución) y un endpoint donde recibir los avisos del motor. Es trabajo de producto, que es lo que tu software factory sabe hacer.

El motor pone la lógica. Miembros y perfiles, puntos y movimientos, niveles y reglas, segmentos y campañas, premios y canjes. Con un motor de lealtad por API como el de Loybox, eso ya está construido y en producción, y queda invisible en el stack: el miembro ve la app de la marca y nunca se entera de qué corre por debajo.

La separación también ordena las conversaciones. Las reglas, los niveles y el catálogo los define el equipo del cliente que después va a operar el programa, y se cambian sin tocar tu código. Tu equipo deja de ser el lugar donde se piden los cambios de la promoción del mes.

Lo que hay que cuidar al integrar

Cada compra viaja con su referencia. La orden del sistema del cliente es la que identifica la transacción en el motor, y es la que permite que una devolución revierta los puntos de esa compra puntual y no de cualquier otra. Conviene enviarla siempre, desde el primer evento.

Los webhooks se procesan como si pudieran llegar dos veces. El motor envía cada movimiento a tu endpoint en el momento en que ocurre, con reintentos con espera creciente si tu servidor no responde. Eso es lo que hace confiable al sistema, y también es la razón por la que tu lado tiene que tolerar un aviso repetido sin acreditar dos veces lo mismo.

La firma se verifica siempre. Cada envío llega firmado con HMAC, así que tu endpoint puede comprobar que el aviso viene del motor antes de tocar nada. Es una validación de pocas líneas y es la que evita que alguien te dispare un canje desde afuera.

El orden importa por miembro, no en general. Los eventos de un mismo miembro llegan en el orden en que ocurrieron, que es lo que necesitas para que el saldo y el nivel que muestra tu app no salten hacia atrás.

Todo esto se escribe contra un ambiente de prueba, con credenciales propias y los webhooks funcionando, antes de tocar producción. Y no se arranca solo con la documentación: el levantamiento del stack, el diseño del programa y la salida se hacen junto con el equipo de Loybox, que después sigue como soporte técnico directo.

Qué acordar con el cliente antes de cotizar

Quién define y quién opera el programa. Si la respuesta es tu software factory, vas a terminar haciendo de área de marketing. Lo sano es que el cliente tenga a alguien que diseñe las reglas y revise el panel, y que tu equipo se ocupe de que la integración funcione.

Para quién es el programa. No siempre son clientes finales. Muchos proyectos piden reconocer al equipo de ventas, a la red de distribuidores o a colaboradores externos, y el mismo motor sostiene esas audiencias con la mecánica que a cada una le corresponde. Saberlo antes cambia las pantallas que hay que hacer.

Qué se premia y con qué. Si los premios son productos del propio cliente, el canje se resuelve dentro de su sistema. Si quiere premios físicos que no fabrica, el motor tiene premios con logística integrada, y el cliente no tiene que manejar inventario ni envíos. Las dos cosas se presupuestan distinto.

Qué entra en tu cotización y qué no. Tu parte son las pantallas, la integración de eventos, el endpoint de webhooks y las pruebas. El motor, el panel de operación y la analítica vienen del otro lado, y su alcance depende de las audiencias, de los sistemas contra los que se integra y del volumen del programa. Separarlo en la propuesta evita que el cliente lea todo como desarrollo tuyo.

Preguntas frecuentes