Odoo aerolíneas loyalty: programa de fidelidad open-source para LATAM

Por qué los miles aéreos son deuda, no marketing

Los programas frequent flyer no son una tarjetita de premios: son productos financieros con su propio P&L, su propia auditoría y su propia trampa contable. LATAM Pass, Smiles, LifeMiles y AeroMéxico Rewards suman más de 100 millones de cuentas y aportan hasta el 40% de la utilidad operativa de sus aerolíneas matriz. Quien los registra como gasto de marketing termina con un balance roto y una opinión calificada de la auditoría Big-4.

American Airlines inventó AAdvantage en 1981 para vender asientos vacíos. Cuarenta y cinco años después, las millas son un instrumento financiero: las venden a bancos para co-brand cards, a hoteles para reward redemption, a retailers para programas cruzados. La aerolínea ya no gana solamente moviendo aviones; gana administrando una moneda paralela con tasas de quema (breakage), tablas de equivalencia y obligaciones contractuales.

La consecuencia técnica es directa: bajo IFRS 15, vigente en todas las jurisdicciones LATAM desde enero de 2018, cada milla emitida debe contabilizarse como contract liability. No es opción metodológica; es regulación. Y los carriers que la ignoran ya saben lo que cuesta: SAT, SUNAT, DIAN y AFIP reclasifican el reconocimiento de ingresos y reabren ejercicios completos.

Hasta aquí, nada nuevo para top-tier carriers. La pregunta interesante aparece más abajo: los LCC, regionales y cargueros LATAM que no tienen un loyalty engine — ¿con qué arquitectura van a cumplir? La respuesta corta: open-source Odoo cubre 60–70% de fábrica; el resto se construye. La respuesta larga ocupa este artículo.

El mercado LATAM: cuatro grandes y la nada debajo

Encima de la línea, cuatro programas concentran el 90% de los miles emitidos en la región:

• LATAM Pass (Chile, Perú, Colombia, Brasil, Ecuador, Argentina): cerca de 40 millones de socios. Migró a esquema revenue-based en 2022 — las millas se calculan sobre el USD gastado, no sobre la distancia volada.
• Smiles (Brasil, dentro de GOL): se listó como Smiles Fidelidade S.A. en la B3 en 2013, se deslistó y se reabsorbió en GOL en 2021. Integración operativa completa tras la reestructuración del grupo.
• LifeMiles (Avianca; domicilio jurídico en Panamá): unos 12 millones de socios. Vende millas a Citibanamex, Bancolombia y BCP, entre otros bancos.
• AeroMéxico Rewards (ex-Club Premier, rebrand post-bankruptcy 2020–2022): cerca de 7 millones de socios. Partners principales: American Express México y Banamex.

Por debajo de los cuatro grandes, el panorama cambia. Viva Aerobus mueve unos 24 millones de pasajeros al año y lanzó Doters en 2022 — programa básico, sin integración CRM real. Volaris tiene V.Club, que es una suscripción de descuentos, no un FFP clásico. Sky Airline (Chile) lanzó Sky+ en 2023 con funcionalidad mínima. JetSMART opera JetSMART Smart Club como suscripción, sin acumulación basada en millas. Wingo, Plus Ultra y Star Peru no tienen FFP funcional. Aerolíneas Argentinas Plus sigue sobre Comarch sin API pública.

Sumando LCC, regionales y cargueros, hay unos 150 operadores LATAM que o no tienen loyalty o lo tienen como suscripción cruda sin acumulación, sin red de partners y sin portal del socio. Ese es el espacio donde Odoo entra: implementación de USD 25 000 a USD 80 000 contra los USD 1.5 millones a USD 8 millones de las cajas corporativas (IBS iLoyal, Sabre Loyalty, Comarch FFP, Loylogic).

#1. Cronograma regulatorio 2025–2026

Cinco cambios fiscales relevantes para loyalty aéreo se acumulan en el próximo año. Cada uno toca el ledger de millas de forma distinta.

El núcleo de IFRS 15 es brutalmente simple: cuando vendes un boleto, el transaction price se reparte entre dos obligaciones — transportar al pasajero y entregarle millas para un viaje futuro. La parte de millas recibe un estimated fair value — habitualmente entre 0.8 y 2.5 USD-cent por milla, según el programa y la categoría de redención — y se difiere en el balance como contract liability. Cuando la milla se canjea, esa porción se libera a revenue. Cuando expira sin uso, se aplica la tasa de quema actuarial y también se libera.

Qué cubre Odoo de fábrica y qué no

Odoo 18 — y la versión 19 liberada en octubre de 2025 — trae un stack que cubre la mayor parte del flujo de un loyalty aéreo. Lo que falta es lo que distingue una aerolínea de una tienda de retail: cálculo por ruta, integración con GDS, localización fiscal y revaluación actuarial del pasivo.

#1. Módulos base que ya vienen

El módulo loyalty (Community y Enterprise) maneja loyalty programs, cards, points, gift cards, ewallet, discounts, coupons y promo codes. Multi-tier se modela con loyalty.rule más condition expressions. Los reward types nativos cubren descuento porcentual o fijo, free product y free shipping. Multi-company y multi-currency están desde el core.

El stack contable (sale + account) genera el sale order con descuento por loyalty card y registra el redemption como journal entry. El deferred revenue se opera con account.deferred.revenue (Enterprise: módulo account_asset_management).

El portal del socio sale de fábrica vía website + portal: saldo, historial, redemption, estado de tier, beneficios. El socio se registra desde el website signup. El perfil del socio vive en res.partner con custom fields para tier, anniversary, aeropuerto preferido. La jerarquía partner → corporate account → travel agency es la misma que el core ya usa para B2B.

#2. Funcionalidad que sale gratis

• Acumulación de millas sobre ticket sale, vía sale.order.line con regla de loyalty
• Redemption sobre compra de boleto, como discount line
• Progresión de tier por qualifying miles, ejecutada con cron y campo custom
• Expiración por cron — si no hay actividad en X meses, se queman las millas
• Portal self-service: balance, historial, beneficios por tier
• Multi-currency con FX-conversion a USD para el ledger global
• Multi-company para alianzas donde varias entidades legales comparten el programa
• Beneficios por tier vía product.product con pricing condicional

#3. Funcionalidad que hay que construir

Lo siguiente no está y siempre — siempre — termina siendo el grueso del proyecto:

1. Cálculo por route × RBD × tier multiplier. Hace falta un módulo flight_loyalty_calculation, lookup-table para distancia de ruta (vía OAG, IATA o manual), multiplicador por booking class (RBD), multiplicadores por tier y promo. Cuatro a seis semanas de desarrollo según la matriz tarifaria del carrier.
2. Integración con GDS y PSS. Amadeus Soaring (REST), Sabre Web Services (SOAP/XML), Travelport Universal API, Hitit Crane PSS (popular en LCC LATAM), Navitaire New Skies (Accelya). El middleware estándar es Kafka más worker dedicado para real-time accrual.
3. PCI-compliant co-brand credit cards. Tokenización (Visa Token Service, Mastercard MDES), segmentación de scope PCI DSS — el PAN nunca toca Odoo —, settlement diario por issuer (Visa Direct, Mastercard Send).
4. Localización fiscal para millas. l10n_pe para CPE bajo Resolución 000040-2025 de SUNAT con código especial de mileage payment; l10n_mx para CFDI 4.0 con descuento como línea separada; l10n_co para DIAN con redemption como item separado; l10n_ar para AFIP/ARCA con comprobante de fidelidad.
5. Revaluación actuarial del pasivo diferido. Recalcular trimestralmente la breakage rate, ajustar el fair value cuando cambia el award chart, dejar todo auditable para Big-4. Sin esto, la opinión calificada está esperando.
6. Liquidación con partners B2B. Bancos que compran millas en lote para co-brand, hoteles que las compran para rewards de huéspedes, settlement mensual, invoice, FX-conversion. Es el primer módulo que las aerolíneas regionales subestiman.
7. RFM-segmentación y modelos de propensity-to-churn. Recency-Frequency-Monetary, modelos ML (XGBoost, LightGBM), integración con marketing automation (Mautic, ActiveCampaign, Mailgun). Esto se suele dejar para fase 2, lo cual está bien.

Cuándo Odoo funciona (y cuándo está fuera de juego)

La regla simple: Odoo está pensado para carriers que llegan hasta unos 5 millones de socios y unas 200 transacciones por segundo. Más arriba, hay que pensar en arquitecturas mixtas o directamente en cajas corporativas.

#1. Sí — LCC y regionales hasta 5M socios

La arquitectura típica: Odoo Community o Enterprise + cuatro módulos custom (flight_loyalty_calculation, pnr_integration, deferred_miles, partner_settlement) + middleware PSS (Kafka + worker) + localización l10n_{cc}. Costo: USD 35 000 a USD 80 000 inicial + USD 1 500 a USD 3 000/mes de soporte.

Carriers donde tiene sentido evaluar este camino: Wingo Rewards (Colombia, ~5M pasajeros/año), JetSMART Loyalty (Chile, Argentina, Perú, ~9M) si migra de suscripción a mileage, Plus Ultra Perú para construir un FFP desde cero, y los cargo loyalty de Aerolíneas Cargueras Argentinas o LATAM Cargo. Throughput soportado: hasta 200 TPS, hasta 5M socios y 100M millas/año acumuladas — con PostgreSQL configurado correctamente (partitioning por member_id range, materialized views para agregados diarios).

#2. Mixto — Odoo como back-office en mid-tier

Para carriers entre 5 y 20 millones de socios (Avianca, Copa, AeroMéxico, Volaris cuando madure), la arquitectura sana es híbrida. Odoo se queda con HR, finance, partner relations y IFRS 15 deferred revenue accounting. El loyalty engine front-office se contrata externo: Comarch FFP (la elección legacy LATAM), PROS Loyalty (SaaS más nuevo), Loylogic (premium) o Sabre Loyalty si el carrier ya está sobre Sabre PSS. Integración por REST API. Costo: Odoo USD 60 000 a USD 120 000 + licencia loyalty engine USD 200 000 a USD 800 000/año.

El driver del corte es throughput y uptime: 500 a 2 000 TPS, 99.99% disponibilidad del portal del socio 24/7, y SLA contractuales con partners que ya no admiten downtime mantenible.

#3. No — top-tier 30M+

LATAM Group post-restructuring y AeroMéxico post-Delta JV están fuera del alcance de Odoo como loyalty engine: 30 millones de socios o más, throughput sostenido por encima de 2 000 TPS, esquemas de partner-accrual cruzados entre alianzas (SkyTeam, oneworld) con compensación inter-carrier, SLA estrictos frente a la alianza y failover multi-región 24/7. Aquí mandan IBS iLoyal, Sabre Loyalty, Lufthansa Systems FMS o Amadeus Altéa Customer Management Suite. Odoo puede quedarse en finance — donde la regulación IFRS 15 vive — pero no como loyalty core.

Seis errores que destruyen una implementación de loyalty en Odoo

Los errores siguientes aparecen en orden de frecuencia. Los primeros tres son contables y rompen el balance; los últimos tres son operativos y rompen la confianza del socio o del partner.

#1. Registrar millas como gasto de marketing

Qué se rompe. El balance subestima obligaciones y el P&L sobreestima ingresos. La auditoría Big-4 emite opinión calificada. SAT, SUNAT, DIAN o AFIP, cuando revisan, reclasifican el ingreso oculto y aplican el ajuste retroactivo.

Qué corresponde. Al emitir milla: Dr Sales / Cr Contract liability al fair value (0.8–1.5 USD-cent típico). Al canjear: Dr Contract liability / Cr Revenue. Revaluación trimestral de la contract liability contra la breakage rate calculada actuarialmente.

#2. No segregar millas por estado

Qué se rompe. El reporting a partners miente. Citibanamex, Bancolombia y BCP pagan por earned-not-redeemed. Si el ledger no distingue earned, redeemed, expired y bonus, el cálculo está mal y se subreporta entre 8% y 15% del ingreso mensual del partner channel.

Qué corresponde. Agregar un campo status a la línea de loyalty.card + audit log vía mail.thread. Todas las operaciones sobre millas atraviesan una capa de servicio — nunca loyalty.card.write() directo.

#3. Tier downgrade manual o inexistente

Qué se rompe. El socio que calificó para Premium hace un año y este año vuela dos veces debería bajar a Silver. Sin cron, sigue viendo "Premium" en el portal mientras los beneficios fallan en el contador del aeropuerto — o al revés. El NPS cae 15 a 25 puntos sobre esa cohorte.

Qué corresponde. Cron mensual: recalcular qualifying-miles sobre rolling 12 meses, comparar contra threshold, ejecutar upgrade o downgrade y disparar notificación. Mensaje al socio: "Querido [name], este año volaste X millas; tu nivel para el próximo año es [tier]". Sin sorpresas en el contador.

#4. Liquidación con partners en Excel

Qué se rompe. Bancos y hoteles esperan invoice mensual por compra de millas. El cálculo manual toma 5 a 7 días y deja 8% a 12% de error por errores de conversión cambiaria y mismatches de cierre. La cobranza se retrasa y, peor, el partner desconfía.

Qué corresponde. Módulo partner_mile_settlement: cron de fin de mes que agrupa todas las compras de millas por partner, genera invoice vía account.move y envía PDF por mail.message. Tiempo: 1.5 días en lugar de 5–7.

#5. PCI compliance roto en co-brand cards

Qué se rompe. Si Odoo procesa PAN directamente, la aerolínea entra al scope de PCI DSS. Las multas de Visa y Mastercard van de USD 5 000 a USD 100 000 mensuales, y en caso grave el merchant agreement se revoca. La emisión de tarjetas co-brand se suspende y la lealtad se desploma con ella.

Qué corresponde. Token-based storage. El card data nunca toca Odoo: un vault externo (Stripe, Adyen, Cybersource, Kushki, Mercado Pago) emite token; Odoo guarda token + last 4 + brand. El settlement diario llega como batch import de journal entries.

#6. Política de expiración no definida

Qué se rompe. Los carriers legacy a veces "olvidan" quemar millas inactivas. Eso infla la deferred revenue liability — y cuando Big-4 audita la breakage rate real, reclasifica revenue al ejercicio actual y descuadra el cierre.

Qué corresponde. Política explícita: la milla expira a los 36 meses de inactividad y se reactiva al comprar boleto. Cron job + notificación a 60, 30 y 7 días del vencimiento. Sin sorpresas para el socio, sin sorpresas para la auditoría.

Caso de una aerolínea CIS: +22% de retención, –68% en settlement

Cliente anónimo: aerolínea bandera de mercado CIS, cerca de 10 millones de socios registrados, programa legacy sobre Comarch FFP hasta 2017. Churn trimestral en Q4: 15%. Liquidación con partners: manual, 5 a 7 días. IFRS 15 desalineado con GAAP local. Una opinión calificada de la auditoría flotando en el aire.

El proyecto corrió de 2017 a 2019 con cinco frentes en paralelo.

El core member ledger migró a Odoo con un módulo custom loyalty_miles. PostgreSQL partitioning por rango de member_id; materialized view para agregados diarios; índice cubriente sobre (member_id, accrual_date) que dejó las queries del portal en menos de 80ms p95.

El deferred revenue IFRS 15 se modeló sobre account.deferred.revenue con regla custom. Al emitir: Dr Sales a un fair value cercano a USD 0.012/milla, Cr Contract liability. Revaluación trimestral de breakage contra modelo actuarial alimentado por años de historia.

La segmentación RFM salió de tres materialized views — Recency (días desde el último vuelo), Frequency (vuelos en 12 meses), Monetary (USD gastados) — con sieve de Champion a Lost en siete cubetas. Esos segmentos alimentaban una capa de triggers conductuales: e-mail + push tras 30 días sin actividad (win-back), 90 días (award personalizado), tier downgrade detectado a 60 días vista (retention bonus). El modelo de propensity-to-churn corría sobre XGBoost en Airflow, refit semanal.

Finalmente, la liquidación con partners se automatizó: cron mensual, REST API hacia bancos y hoteles, invoice generado el día 1.

Resultados, doce meses después del go-live:

• +22% en retención Q1–Q4 contra el ejercicio anterior
• –68% en tiempo de settlement (5–7 días → 1.5 días)
• IFRS 15 compliant, opinión calificada removida en el siguiente cierre
• Mile redemption rate del 12% al 18% — la milla pasó de balasto contable a moneda viva

La pelea no era construir el ledger. La pelea era convencer al área de planning de que la milla era un pasivo, no una palanca de marketing.

La arquitectura se traslada a mid-tier LATAM con tres adaptaciones: multi-currency real (USD primario + COP, MXN, PEN, CLP, ARS, BRL en paralelo), localización fiscal completa (CFDI 4.0, CPE SUNAT, DIAN factura electrónica, AFIP comprobante) y scope PCI para co-brand cards. Para LCC y regionales (Viva, JetSMART, Wingo, Plus Ultra, Star Peru) la arquitectura se simplifica: menos partners, menos tiers, RFM más liviana — pero el stack de base (Odoo + deferred revenue + RFM + retention triggers) es exactamente el mismo. Comparable, en concepto, al caso del data warehouse de QIC: una capa analítica sobre un core transaccional bien partido.

Cierre y dónde profundizar

La conclusión es incómoda para los carriers legacy y obvia para los regionales: el loyalty aéreo es un producto financiero con P&L propio, y la mayor parte del mercado LCC LATAM lo está tratando como un folleto. Los grandes ya gastaron millones en IBS, Sabre y Comarch. En la franja de Viva, Wingo, JetSMART, Plus Ultra, Star Peru y los cargueros — y son la mayoría de los operadores LATAM — hay un hueco que open-source Odoo cierra al 5% al 10% del costo de la caja.

El caso CIS demuestra que la arquitectura Odoo + PostgreSQL + RFM + IFRS 15 levanta retención +22% cuando está bien ajustada. Esos principios se trasladan a LATAM con la corrección por multi-currency y localización fiscal.

Para profundizar:

• Implementación de Odoo — metodología y pricing
• Auditoría de Odoo — diagnóstico de un deployment existente
• Odoo + Analytics — RFM, churn prediction, loyalty metrics
• Odoo Perú — SUNAT CPE para aviación
• Odoo México — SAT CFDI 4.0 para airlines
• Odoo Colombia — DIAN factura electrónica para airlines
• Odoo Argentina — AFIP/ARCA loyalty deferred revenue
• Caso QIC Data Warehouse — arquitectura analítica relacionada

Si eres CFO, Head of Loyalty o CIO de una aerolínea regional LATAM y quieres una lectura específica de tu deployment, pide una auditoría de Odoo de 30 minutos o lee primero el perfil del autor.

Preguntas frecuentes