> ## Documentation Index > Fetch the complete documentation index at: https://internal.softcrum.com/llms.txt > Use this file to discover all available pages before exploring further. # Fidelización — preguntas respondidas > Las 29 preguntas del módulo de fidelización, abiertas y respondidas el mismo día. Es el único módulo con sus decisiones cerradas, y por eso el único con specs en revisión. **Estado:** 27 respondidas · 2 diferidas · **0 abiertas**. Abiertas y cerradas el **2026-08-17**. Las decisiones ya están aplicadas: los 14 feature specs y el PRD subieron a `0.2.0` y pasaron a `review`. Lo único que falta para que lleguen a `approved` y `1.0.0` es tu visto bueno. ## Dos respuestas cambiaron el diseño No lo ratificaron, lo cambiaron. Vale la pena tenerlas presentes porque explican por qué dos tablas son como son. **OQ-LOY-02.** La recomendación era que los puntos de estatus no expiraran por lote. La respuesta fue que **la expiración es política de la moneda, no de su tipo**: cada empresa configura si su moneda de estatus expira o no. Eso abrió una consecuencia que se cerró en el mismo movimiento — cuando una moneda de estatus expira, el período de gracia y el evento `tier.grace_started` **dejan de ser opcionales**, porque si no un member pierde nivel sin haber dejado de comprar. Vive en [`point_currency`](/schemas/loyalty/point-currency). **OQ-LOY-07.** La recomendación era un nombre interno fijo hasta que llegara multi-programa. La respuesta fue **multi-programa desde el día 1**, lo que revierte DEC-H2 — así que primero se escribió [ADR-021](/adr/adr-021-multi-program-from-day-one) y desde ahí se aplicó a los specs. Vive en [`program`](/schemas/loyalty/program). Y **OQ-LOY-14** dejó un principio transversal que hoy está en `standards/api.md`: **todo parámetro de política es configurable por tenant, con un default publicado.** ## Las 29 | ID | Pregunta | Afecta | Decisión | | ------------- | ------------------------------------------------------------------------------------------------------------------------------ | ----------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **OQ-LOY-01** | ¿La ventana de devolución (el tiempo que un `earn` queda `pending`) vive en el programa o por regla de acumulación? | FS-LOY-0002 | **Distinta de la recomendación** — Por programa. Ratificado además que un programa pertenece a una sola empresa. | | **OQ-LOY-02** | ¿Los puntos de estatus expiran, o solo los canjeables? | FS-LOY-0002, FS-LOY-0010, PRD | **Distinta de la recomendación** — **Configurable por moneda.** Ambos tipos pueden expirar o no; la plataforma debe permitir toda combinación. | | **OQ-LOY-03** | ¿`revoke` es distinto de un `adjust` negativo, o la distinción es solo de reportería? | FS-LOY-0002 | **Distinto, y la diferencia es intención.** `revoke` es "esto nunca debió acreditarse" (fraude, reversa); `adjust` es "corregimos un monto". Reportería, disputas y antifraude necesitan separarlos, y el costo es una fila en un catálogo. | | **OQ-LOY-04** | ¿`points_lifetime_earned` vive en `contact_balance` o en una proyección de reportería aparte? | FS-LOY-0003 | **En `contact_balance`.** Crece monótonamente y se actualiza en la misma transacción que ya está abierta; una proyección aparte agrega un job por un entero. | | **OQ-LOY-05** | Cuando varias reglas calzan con un evento, ¿aplican todas o una prioridad se detiene en la primera? | FS-LOY-0004 | **Aplican todas, con `stop_on_match` opcional por regla.** El caso común es acumulativo (una regla base más una campaña). Detenerse por defecto sorprende; permitir detenerse explícitamente cubre el caso exclusivo. | | **OQ-LOY-06** | ¿El presupuesto por contacto se evalúa sobre la vida de la campaña o sobre una ventana móvil? | FS-LOY-0004 | **Vida de la campaña.** Una campaña ya tiene ventana de vigencia; una ventana móvil dentro de otra ventana es difícil de explicar y de auditar. Quien quiera recurrencia crea campañas sucesivas. | | **OQ-LOY-07** | ¿El programa por defecto recibe un nombre visible para el tenant, o uno interno fijo hasta que llegue multi-programa? | FS-LOY-0001 | **Distinta de la recomendación** — **Multi-programa desde el inicio** — ver ADR-021. | | **OQ-LOY-08** | ¿`per_contact_limit` de una recompensa se cuenta sobre la vida del member o sobre un período móvil? | FS-LOY-0005 | **Configurable, con default vida.** "Una vez por cliente" es el caso dominante; "una vez al mes" es real pero minoritario. Un campo `limit_window_days` nullable cubre ambos sin bifurcar la lógica. | | **OQ-LOY-09** | Al revertir un canje, ¿los puntos restaurados mantienen su vencimiento original o se reinicia? | FS-LOY-0006 | **Mantienen el original.** Reiniciar convierte el rollback en una forma de extender vencimientos, y alguien lo va a descubrir. Si el lote original ya expiró, el spec ya define un lote nuevo que hereda el vencimiento más próximo. | | **OQ-LOY-10** | ¿Hay un límite de tiempo tras el cual un canje ya no se puede revertir? | FS-LOY-0006 | **Sí, configurable por programa, default 90 días.** Sin límite, un canje de hace dos años se puede revertir contra un saldo y un catálogo que ya no existen. | | **OQ-LOY-11** | Largo y alfabeto del código de cupón: ¿cuánta entropía frente a que sea legible en voz alta? | FS-LOY-0007 | **Distinta de la recomendación** — Aceptada, subida a **12 caracteres** para soportar cientos de millones de códigos sin que la generación pelee consigo misma. | | **OQ-LOY-12** | ¿Un código genérico se puede restringir a un segmento en vez de a un contacto? | FS-LOY-0007 | **Sí.** Es la forma natural de una campaña ("20% para clientes VIP") y el segmento ya existe en `core`. La validación agrega una verificación de pertenencia, nada más. | | **OQ-LOY-13** | Cuando se viola un conjunto no combinable, ¿el motor conserva el beneficio de mayor precedencia o rechaza el request completo? | FS-LOY-0008 | **Conserva el de mayor precedencia y reporta la exclusión.** Rechazar todo en un mostrador deja al cajero sin salida; conservar el mejor beneficio es lo que el cliente espera y la razón tipada explica por qué el otro no aplicó. | | **OQ-LOY-14** | Ventana de atribución de referidos por defecto: ¿30, 60 o 90 días? | FS-LOY-0009 | **Distinta de la recomendación** — Aceptada **como default**, con el principio general de que toda empresa pueda configurarlo. | | **OQ-LOY-15** | ¿Las conversiones marcadas por fraude expiran si nadie las revisa, y después de cuánto? | FS-LOY-0009 | **No expiran; escalan.** A los 14 días sin revisar, alerta al tenant. Expirarlas automáticamente significa perder referidos legítimos por inacción administrativa, que es exactamente lo que la política de "marcar, no rechazar" quiso evitar. | | **OQ-LOY-16** | Ventana de calificación de niveles por defecto: ¿12 meses móviles o año calendario? | FS-LOY-0010 | **12 meses móviles.** Es continua y justa, y evita el precipicio de enero. El año calendario existe como modo para quien lo pida, pero no como default. | | **OQ-LOY-17** | ¿Entrar en período de gracia emite un evento, para poder hacer una campaña "estás a punto de perder Gold"? | FS-LOY-0010 | **Sí, `loyalty.tier.grace_started`.** Es una de las campañas de retención de mayor rendimiento del formato, y omitir el evento la haría imposible sin sondear la base. | | **OQ-LOY-18** | ¿Un member puede saltarse un nivel cuando un solo evento cruza dos umbrales? | FS-LOY-0010 | **Sí, salta al nivel más alto alcanzado, y emite un solo evento.** Retenerlo un escalón es arbitrario y el member ya cumplió el umbral. | | **OQ-LOY-19** | Horizontes de aviso de vencimiento por defecto: ¿30 y 7 días, o un único aviso a 14? | FS-LOY-0011 | **30 y 7.** El de 30 da tiempo real de reaccionar; el de 7 es el que convierte. Uno solo a 14 es un compromiso que no hace bien ninguna de las dos cosas. | | **OQ-LOY-20** | ¿`cohort_key` es la fecha de vencimiento o el mes? | FS-LOY-0011 | **La fecha.** El mes agrupa lotes con vencimientos distintos en un solo aviso, y el member recibe "vencen 1 200 puntos" cuando en realidad vencen 400 el día 3 y 800 el día 28. | | **OQ-LOY-21** | ¿Un desafío puede ser repetible (mensual, con reinicio), o cada instancia es un desafío distinto? | FS-LOY-0012 | **Instancias distintas, generadas por una plantilla.** Un desafío repetible con reinicio destruye la historia de participación; instancias separadas la conservan y el reporte funciona solo. | | **OQ-LOY-22** | ¿Las insignias otorgan puntos de estatus, convirtiéndolas en entrada de nivel? | FS-LOY-0012 | **No por sí mismas; sí como efecto de regla opcional.** Acoplar insignias a niveles hace que cada insignia nueva mueva la distribución de niveles sin que nadie lo pretenda. | | **OQ-LOY-23** | TTL de reserva de presupuesto en `apply_discount`: ¿15, 30 o 60 minutos? | FS-LOY-0013 | **30 minutos.** Cubre un checkout con fricción real (pago rechazado, cambio de tarjeta) sin inmovilizar presupuesto de campaña por carros abandonados. | | **OQ-LOY-24** | ¿Soportamos descuentos por línea en la primera versión de `apply_discount`, o solo a nivel de carro? | FS-LOY-0013 | **Solo carro en la primera versión.** Por línea exige un modelo de producto y de categorías que hoy no tenemos, y el 80% de las promociones son a nivel de carro. | | **OQ-LOY-25** | ¿El snapshot del carro queda sujeto al tier de retención estándar, o a uno más corto por no ser una orden? | FS-LOY-0013 | **Más corto: 90 días fijos.** Sirve para reconciliación y disputa; conservar carros por 25 meses acumula datos de comportamiento de compra que no necesitamos y que sí tendríamos que defender. | | **OQ-LOY-26** | Ventana de agrupación de push de wallet passes: ¿5, 15 o 60 minutos? | FS-LOY-0014 | **15 minutos.** A 5 el member siente cada compra; a 60 el saldo del pass se ve desactualizado justo cuando lo abre en la caja. | | **OQ-LOY-27** | ¿El wallet pass se ofrece automáticamente a cada member, o solo a solicitud? | FS-LOY-0014 | **A solicitud, con un enlace prominente.** Empujarlo automáticamente exige un push que el member no pidió y en Apple es fricción de revisión; el enlace en el correo de bienvenida convierte igual de bien. | | **OQ-LOY-28** | Librerías de firma de wallet passes (Apple y Google) | FS-LOY-0014 | Necesita **un ADR nuevo** (DEC-H5). No es una pregunta, es trabajo de investigación. El FS no sale de `draft` hasta que exista. | | **OQ-LOY-29** | ¿La política de expiración por defecto cambia según la plantilla vertical? | PRD-LOY, FS-LOY-0002 | Depende de que existan las plantillas verticales (DEC-H7), que aún no están especificadas. Diferida hasta descomponer `core`, que es quien las posee. | Veinticinco quedaron exactamente como la recomendación. Las cinco con matiz están marcadas. **OQ-LOY-28** y **OQ-LOY-29** se cerraron sin decidir: la primera necesita un ADR sobre librerías de firma de wallet passes, la segunda depende de que existan las plantillas verticales. Están en [diferidas](/decisions/deferred). ## Historial | Fecha | Evento | | ---------- | ------------------------------------------------------------------------------ | | 2026-08-17 | Se abren las 29 preguntas al descomponer el módulo de fidelización | | 2026-08-17 | El owner responde el lote completo: 27 decididas, 2 diferidas | | 2026-08-17 | Se aplican a los 14 feature specs y al PRD, que suben a `0.2.0` / `review` | | 2026-08-17 | OQ-LOY-07 revierte DEC-H2, así que se escribe ADR-021 antes de tocar los specs | | 2026-08-18 | Se migran a esta sección con su historial |