Reglas de acumulación, cupones y promociones: cómo resolver beneficios que compiten
Cuando una compra cumple simultáneamente una regla de acumulación, un cupón y una promoción, el problema no es técnico únicamente: el orden de cálculo cambia el precio, los puntos, el margen y la expectativa del cliente. Retail, restaurantes y ecommerce necesitan definir elegibilidad, prioridad, exclusividad, mejor beneficio, topes y reversos antes de publicar ofertas. Esta guía se concentra en la convivencia de beneficios concurrentes y en cómo explicarla de forma reproducible. KA-018 aborda cupones personalizados y KA-091 el versionado de reglas; aquí se diseña la política que decide qué aplica, en qué secuencia y qué ocurre cuando una devolución o corrección obliga a deshacer el resultado.
El problema aparece cuando más de una regla es verdadera
Una compra puede calificar al mismo tiempo para puntos base, bono por categoría, cupón de bienvenida, descuento del comercio y beneficio de nivel. Si el sistema no define cómo conviven, cada canal puede calcular un resultado distinto o aplicar más valor del previsto. La complejidad no proviene de tener muchas promociones, sino de carecer de un modelo explícito de prioridad, exclusividad y base de cálculo.
Antes de configurar campañas, el negocio debe decidir qué familias existen y cuál es su propósito. Acumulación reconoce comportamiento futuro; descuento reduce el precio actual; cupón representa una autorización; cashback crea valor posterior; beneficio de nivel modifica condiciones. Tratar todo como un porcentaje borra diferencias contables y de experiencia. El motor necesita tipos, etapas y resultados observables.
Definir familias y etapas de cálculo
Una estructura útil separa precio base, descuentos comerciales, promociones, cupones, uso de saldo y acumulación. Dentro de cada etapa se establecen reglas de competencia; entre etapas, un orden. Por ejemplo, un cupón podría aplicarse después de un descuento de producto, y la acumulación calcularse sobre el monto neto elegible. Esa es una política posible, no una verdad universal. Lo importante es que sea explícita y consistente con POS, ecommerce y reportes.
Cambiar el orden cambia el resultado. Aplicar diez por ciento y luego un descuento fijo no equivale a invertirlos. Calcular puntos sobre monto bruto puede otorgar valor sobre impuestos, propinas o artículos excluidos. Cada campo debe tener definición y ejemplo. Un diagrama de cálculo ayuda, pero debe traducirse a casos de prueba con entradas y salidas exactas.
Exclusivo, mejor beneficio o acumulable
Los motores comerciales suelen ofrecer patrones como exclusivo, mejor precio, compuesto o siempre aplicar. Exclusivo impide combinar; mejor beneficio selecciona una regla entre candidatas; compuesto suma o encadena resultados; siempre aplicar reserva una regla que no compite. Estos conceptos permiten gobernar la concurrencia, pero requieren prioridades para resolver empates y evitar ciclos.
La elección depende de economía y promesa. Una promoción financiada por proveedor puede coexistir con puntos de la marca, mientras dos cupones de adquisición pueden competir. Un beneficio regulatorio o contractual quizá deba aplicarse siempre. El tradeoff está entre generosidad, claridad y costo. Combinar todo puede sorprender al negocio; bloquear todo puede frustrar al cliente. La política debe ser comunicable en caja y en términos, no solo entendible por quien configuró el motor.
Elegibilidad antes de prioridad
Primero se determina qué reglas califican: canal, fecha, producto, tienda, miembro, nivel, cantidad, método de pago o código. Solo después se resuelve competencia. Mezclar ambas fases complica explicaciones y debugging. También debe distinguirse una regla no elegible de una elegible que perdió frente a otra. Esa diferencia permite explicar al usuario por qué un cupón no se aplicó sin inventar una respuesta.
La elegibilidad debe usar datos disponibles en el momento correcto. Si el POS no envía SKU o categoría, una promoción dependiente de esos campos no puede evaluarse con confiabilidad. Los valores faltantes necesitan política: rechazar, aplicar una regla conservadora o enviar a revisión. Completarlos con supuestos silenciosos produce pérdidas y disputas.
Canjes, devoluciones y reversos
El orden de cálculo también gobierna devoluciones. Si una transacción combinó descuento y puntos, el reverso necesita reproducir qué valor se otorgó y qué se consumió. Recalcular con reglas actuales puede dar un resultado distinto si la campaña cambió. Por eso la transacción debe conservar versiones, componentes y bases. El motor no debería depender de reconstruir la historia desde configuraciones vigentes.
Una devolución parcial plantea qué artículos devuelven puntos, cómo se prorratea un cupón fijo y si un bono por umbral deja de ser válido. Estas decisiones conectan con KA-070, pero nacen en el diseño de concurrencia. Los casos deben definirse antes de lanzamiento y compartirse con finanzas y servicio. Si soporte ajusta saldos, debe hacerlo con trazabilidad y límites.
Experiencia en caja y mensajes al usuario
El resultado correcto técnicamente puede sentirse arbitrario si no se explica. El recibo o interfaz debería mostrar descuentos y beneficios con nombres comprensibles, sin exponer fórmulas internas. Cuando una combinación no está permitida, el usuario necesita saber qué opción se aplicó y, si corresponde, poder elegir. En ecommerce, probar escenarios antes de pagar reduce abandono; en tienda, la respuesta debe ser rápida para no detener la fila.
La operación también necesita mensajes para cajeros y soporte. Un código de error genérico obliga a adivinar. Conviene distinguir expirado, no elegible, ya usado, conflicto con otro beneficio y limitación de canal. Esa taxonomía mejora resolución y revela configuraciones defectuosas. No se trata de mostrar toda la lógica, sino de convertirla en decisiones accionables.
Gobierno, simulación y publicación
Toda regla necesita propietario, vigencia, versión y aprobación. Antes de activarla, una simulación con canastas representativas estima costo y detecta conflictos. El conjunto debe incluir casos normales, límites, múltiples cupones, redención, devolución, zonas horarias y datos faltantes. Después del lanzamiento, se monitorean combinaciones inesperadas y diferencias entre canales.
La configuración debe poder revertirse sin borrar evidencia. Un cambio urgente que sobrescribe la regla anterior impide reconciliar transacciones. Separar diseño, aprobación, despliegue y observación conecta con KA-091 y KA-105. La concurrencia es una política de negocio implementada en tecnología; por eso no puede quedar bajo una sola persona sin revisión.
Cómo evaluar la solución
Una demostración útil presenta la misma canasta con reglas concurrentes y explica paso a paso el resultado. Debe mostrar prioridad, exclusividad, mejor beneficio, composición, base de cálculo, límites y trazabilidad. También prueba POS y ecommerce, porque la paridad importa más que una interfaz elegante. Las APIs deben devolver componentes suficientes para que cada canal muestre la decisión.
Lealto publica capacidades de programas, cupones y campañas, pero el comportamiento exacto de una combinación depende de la configuración e integración aprobadas. La evaluación debe confirmar qué reglas están disponibles, dónde se calculan y cómo se registran. No debe asumirse una capacidad por analogía con otro motor.
Preguntas frecuentes
¿Siempre debe aplicarse el mejor descuento? No. La política puede priorizar exclusividad, financiamiento o una promesa específica. Debe definirse y comunicarse.
¿Los puntos se calculan sobre monto bruto o neto? Depende del diseño; impuestos, artículos excluidos y descuentos requieren definición explícita.
¿Por qué guardar la versión de la regla? Para explicar y revertir transacciones según lo que estaba vigente cuando ocurrieron.
Comunicar la regla sin exponer el motor
Los términos y pantallas deben describir restricciones relevantes con lenguaje entendible: vigencia, exclusividad, productos participantes y base de acumulación. No es necesario publicar el algoritmo interno completo, pero sí evitar promesas que el motor contradiga. Si la comunicación dice que un cupón se combina y la configuración lo bloquea, la falla es de gobierno. Marketing, comercio y tecnología deben aprobar la misma interpretación.
En caja, el recibo o mensaje debe nombrar el beneficio aplicado y, cuando sea útil, el motivo de no aplicar otro. Para soporte, se conserva una explicación más detallada con reglas y prioridades. Esta doble capa protege claridad y diagnósticos. También permite evaluar impacto de cambios: una nueva promoción se simula contra campañas vigentes y se revisa si altera mensajes, términos o capacitación. La coherencia entre cálculo y promesa es una condición de confianza, no un detalle de UX.
Casos de prueba que negocio debe poder leer
Un conjunto mínimo cubre compra sin promoción, una regla elegible, dos reglas exclusivas, empate de prioridad, cupón más puntos, artículos excluidos, monto parcialmente pagado con saldo, devolución total y devolución parcial. Cada caso incluye datos de entrada, reglas vigentes, pasos de cálculo, resultado y mensaje al usuario. Negocio valida la intención; tecnología automatiza regresión.
Los casos se mantienen junto a las reglas, no en una hoja olvidada. Cuando cambia una prioridad, el sistema muestra qué resultados anteriores se modificarían. Esta comparación evita lanzar una mejora local que rompe otra campaña. En operaciones multipaís se añaden monedas, impuestos y zonas horarias según alcance. El PASS exige que POS, ecommerce y backend produzcan el mismo resultado o una diferencia explícitamente diseñada.
Convertir la política comercial en reglas comprobables
Antes de activar una campaña, negocio debe poder leer ejemplos de carrito y anticipar el resultado: beneficio aplicado, orden de cálculo, puntos generados, mensaje mostrado y efecto de una devolución. Tecnología necesita la misma política expresada como condiciones, prioridades y versiones auditables. Un conjunto de pruebas con combinaciones válidas, incompatibles y limítrofes reduce sorpresas en caja y soporte. Lealto debe evaluarse sobre la capacidad verificable de representar y operar las reglas aprobadas para el alcance del cliente. Si una excepción depende de intervención manual, debe quedar visible como costo operativo, no esconderse detrás de una configuración aparentemente flexible.
Fuentes
- Microsoft Learn — concurrencia en componentes de precio
- Shopify Help — combinaciones de descuentos
- Lealto — capacidades de puntos, cupones y campañas
- Atlas — KA-018, KA-026 y KA-091 como fronteras canónicas
Contáctenos
Construyamos su estrategia de lealtad