La respuesta corta

Un programa de puntos parece un contador y no lo es. Es un libro de cuentas, con un pasivo contable detrás, reglas que cambian cada trimestre y gente intentando aprovecharse de ellas.

La decisión técnica que evita el 80 % de los problemas futuros: el saldo no se guarda, se calcula. Lo que se guarda es la secuencia de movimientos —ganó, gastó, caducó, se le ajustó— y el saldo es su suma. Guardar un número mutable y actualizarlo es lo que produce los saldos imposibles de explicar, y en un programa de fidelización explicar el saldo es la mitad del soporte.

El modelo: movimientos, no saldo

Cada movimiento lleva, como mínimo:

  • Identificador único generado en origen, para poder repetir el envío sin duplicar.
  • Tipo: acumulación, canje, caducidad, ajuste manual, reversión.
  • Origen: qué compra, qué acción o qué persona lo generó.
  • Momento en que ocurrió y momento en que se registró — no son el mismo.
  • Regla aplicada, con su versión.

Ese último campo es el que salva las auditorías. Si en marzo la regla daba dos puntos por euro y en abril da uno, tienes que poder explicar por qué un movimiento de marzo dio lo que dio. Sin versión de la regla, no puedes.

Y una consecuencia: las reglas son datos, no código. Si cambiar una promoción exige publicar una versión en la tienda, el programa está muerto antes de empezar — porque marketing cambia promociones cada semana y las tiendas no publican al mismo ritmo.

Ganar y gastar

Acumular parece lo fácil y tiene su trampa: ¿cuándo se acumulan los puntos de una compra? ¿Al pagar, al enviar, al pasar el plazo de devolución? Si es al pagar, hay que poder revertir cuando el cliente devuelve, y esa reversión puede dejar el saldo en negativo si ya gastó. Decidir qué pasa entonces es de negocio, no de ingeniería.

Canjear exige atomicidad: comprobar saldo, reservar, aplicar y confirmar, sin que dos peticiones simultáneas gasten los mismos puntos. Con conectividad móvil, la doble pulsación no es hipotética.

Caducar es la parte que casi nadie diseña y la que más quejas genera. Hay que decidir el criterio —desde la fecha de obtención, por inactividad— y avisar antes, con antelación suficiente. Un cliente que descubre que ha perdido puntos sin avisar es un cliente que desinstala.

Fraude: da por hecho que lo habrá

Cualquier mecanismo que reparta valor atrae a quien quiera explotarlo:

  • Cuentas múltiples para repetir el bono de bienvenida.
  • Compra y devolución para quedarse con los puntos, si la reversión no está bien atada.
  • Manipulación del cliente móvil: nunca calcular puntos en el dispositivo. El servidor decide, siempre.
  • Códigos y promociones compartidos donde no debían.

La regla dura: el dispositivo propone, el servidor concede. Cualquier cálculo de puntos que ocurra en la app es una sugerencia visual, y el valor bueno viene del backend.

Donde se conecta con el mundo real

Un programa serio no vive solo en la app:

  • Punto de venta físico, que es donde ocurre la mayor parte de la acumulación en retail. Identificar al cliente en caja sin fricción es el problema de producto más difícil de todo el programa.
  • Comercio electrónico, con las mismas reglas y el mismo libro de cuentas.
  • Atención al cliente, que necesita poder consultar y ajustar, con trazabilidad de quién ajustó qué.
  • La cartera del teléfono, si se usan tarjetas o pases. Ojo con un detalle que ya cubrimos en otra pieza: los pases están firmados con certificados concretos, y eso ata el programa a la cuenta que los emite — está en qué se rompe al transferir una app.

Sin cobertura

En tienda física la cobertura es mala más veces de lo que parece. Hay que decidir:

  • Si se puede identificar al cliente sin red — normalmente sí, con un código local.
  • Si se puede acumular sin red, con envío diferido.
  • Si se puede canjear sin red — y aquí la respuesta suele ser no, porque canjear sin saber el saldo real es regalar producto.

Lo que casi nadie avisa: los puntos son un pasivo

Los puntos emitidos y no canjeados son una obligación futura de la empresa, y eso tiene consecuencias contables y fiscales. Significa que finanzas necesita informes fiables: emitidos, canjeados, caducados y saldo vivo, cuadrados al céntimo.

Ese requisito, si aparece en el mes nueve, obliga a reconstruir histórico. Si aparece en el mes uno, es una consulta más sobre un libro de cuentas que ya está bien diseñado. Es la mejor razón para el modelo de movimientos.

Antes de estimar

  1. ¿Dónde se acumula: solo app, también tienda física, también web?
  2. ¿En qué momento del pedido se conceden los puntos, y qué pasa con las devoluciones?
  3. ¿Caducan? ¿Con qué criterio y con cuánto aviso?
  4. ¿Quién puede hacer ajustes manuales y con qué control?
  5. ¿Qué informes necesita finanzas, y con qué periodicidad?

La quinta la contesta el departamento equivocado si no se pregunta pronto, y es la que define la mitad del backend.

Es una de las piezas que construimos en apps de retail para empresa, normalmente junto al catálogo y al comercio electrónico en el mismo producto.