Construir tu propio sistema de puntos o integrar un motor: la cuenta real

Lo que aparece después de la primera versión

La primera versión funciona: alguien compra, suma puntos, canjea. Lo que llega después es la lista real del sistema.

• ·Las devoluciones y las anulaciones. Si la compra se deshace, los puntos también, y si esos puntos ya se canjearon hay que decidir qué pasa. Eso es saldo negativo, compensación con compras futuras o descuento del reembolso, y cada camino toca la contabilidad del programa.
• ·Los estados intermedios de un canje. El canje pedido, el canje confirmado, el premio despachado, el premio entregado, el canje caído a mitad de camino porque el inventario no estaba. Sin esos estados, el primer canje fallido deja una cuenta en un estado imposible de arreglar sin tocar la base a mano.
• ·El vencimiento del saldo, que no es una fecha en una columna: es un proceso que corre todos los días, sabe qué puntos vencen primero, avisa antes por dos canales y deja registro de lo que avisó.
• ·Los niveles con su ventana de cálculo, la subida, el mantenimiento, la bajada y el plazo de gracia. Es la parte que más reclamos genera y la que más lógica tiene adentro.
• ·La idempotencia, que es la que nadie estima. El sistema de la empresa reintenta un aviso de compra y el motor no puede acreditar dos veces. Sin eso, el primer día de tráfico real duplica saldos.
• ·La auditoría. Cuando alguien reclama que le faltan puntos, hace falta poder decir de dónde salió cada movimiento y quién lo generó. Un saldo sin historial es una discusión que la marca pierde siempre.

Ninguna de esas piezas es intelectualmente difícil. Todas juntas son un producto, y un producto que hay que mantener mientras el equipo tendría que estar construyendo lo que diferencia a la empresa.

La parte que casi nunca entra en la estimación: el premio

Un programa de puntos sin premios que la gente quiera es una tabla de saldos. Y aquí es donde el desarrollo propio se topa con algo que no se resuelve escribiendo código.

Si los premios son productos propios, la empresa ya tiene inventario y logística, así que el problema es acotado. Pero en la mayoría de los programas los premios que mueven la aguja son de otro tipo: electrodomésticos, cosas para la casa, tecnología, experiencias. Ofrecer eso significa comprar, almacenar, despachar, atender el reclamo del envío y reponer lo que se agotó.

Eso no es un módulo, es una operación, y es la razón por la que muchos programas internos y muchos clubes propios terminan con un catálogo de tres premios que a nadie le interesan. Cuando el catálogo y la logística vienen resueltos por un tercero, la empresa define qué se puede canjear y no toca inventario ni envíos.

Lo mismo pasa con los canales. Un programa serio manda avisos por correo y por WhatsApp, con plantillas, con estados de entrega y con manejo de bajas. Eso también es un sistema, y es otro que hay que mantener.

Cuándo sí conviene desarrollarlo

Hay casos donde el desarrollo propio es la respuesta correcta, y conviene decirlos.

Cuando la mecánica de puntos es el producto y no un complemento: una app cuya propuesta central es la acumulación, donde cada detalle de esa lógica es diferencial competitivo. Ahí tercerizar el corazón del producto no tiene sentido.

Cuando hay una restricción regulatoria o de infraestructura que obliga a que los datos y la lógica vivan adentro, sin excepciones.

Y cuando el programa es deliberadamente mínimo y va a seguir siéndolo: un sello digital sin niveles, sin premios físicos, sin vencimiento y sin campañas. Eso sí se escribe en dos semanas y se mantiene con poco.

Fuera de esos tres casos, lo que se está decidiendo no es construir o comprar: es en qué va a trabajar el equipo los próximos seis meses, y si el mantenimiento de un motor de puntos es lo que mejor paga ese tiempo.

Qué significa integrar un motor, en concreto

Integrar no es adoptar el frente de otra marca. La empresa se queda con la interfaz, la identidad y la experiencia; el motor resuelve la lógica por detrás.

El contrato es simple: el sistema de la empresa avisa que algo pasó (una compra, una devolución, un objetivo cumplido, un alta) y el motor contesta con el resultado ya aplicado, con las reglas que la empresa configuró. Los puntos, los niveles, el vencimiento, los canjes, las campañas y los premios quedan del otro lado.

Eso permite dos cosas que un desarrollo propio consigue mucho más tarde. La primera es cambiar reglas sin tocar código: la tasa de acumulación de una categoría, el umbral de un nivel o un vencimiento son configuración, no un despliegue. La segunda es tener varias audiencias sobre la misma base, cada una con sus reglas, que es lo que necesita una empresa que quiere reconocer a clientes, a su equipo interno y a su red de canales sin montar tres sistemas.

Para una tienda armada en Tiendanube, VTEX o WooCommerce esto ni se programa: la integración ya existe y el programa queda andando conectado al catálogo y a los pedidos. La conversación de construir o integrar aparece cuando hay una app propia, un producto de software o un sistema interno, y ahí la vía es la API.

Cómo hacer la cuenta antes de decidir

La comparación honesta no es la licencia mensual contra las horas de la primera versión. Son cuatro cosas contra la licencia.

El desarrollo completo, no el de la primera versión: la lista de la primera sección, con los estados, el vencimiento, la auditoría y el panel para que marketing cambie reglas sin pedirle nada a nadie.

El mantenimiento anual, que en un sistema que maneja saldos no baja nunca del todo, porque cada cambio de reglas del negocio lo toca.

La operación de los premios, si el catálogo va a tener algo más que descuentos propios.

El costo de oportunidad, que suele ser el más grande y el que menos se escribe: qué no va a hacer el equipo mientras hace esto.

Puesta así, la decisión casi siempre se aclara sola. Y el criterio que ordena es bastante simple: si la lógica de puntos es lo que la empresa vende, se construye; si es lo que la empresa usa para vender otra cosa, se integra.

Preguntas frecuentes