Una plataforma de lealtad que convierte transacciones empresariales en engagement

Una plataforma de lealtad parece simple si el requisito es solo un saldo de puntos. La lealtad empresarial es un problema de integración y transacciones. Cada organización llega con sistemas de clientes distintos, fuentes de transacción distintas, autenticación, protocolos, formatos de solicitud, reglas de acumulación y canje, modelos de recompensa, campañas, necesidades de reportería y canales de notificación propios.

Algunos sistemas exponen APIs modernas; otros dependen de contratos antiguos e integraciones estilo SOAP/XML. Algunas transacciones son sincrónicas y de cara al cliente; otras dependen de plataformas externas que pueden ser lentas o estar temporalmente fuera de servicio. El estado de lealtad igual tiene que seguir siendo explicable y correcto.

La plataforma debía atender a organizaciones cuyos negocios y programas de lealtad eran lo bastante distintos como para que construir un producto a la medida de cada una fuera la respuesta fácil de corto plazo. La arquitectura tenía que volver configurables esas diferencias sin aplanar todo al mínimo común denominador.

Un solo evento de negocio puede tocar varias preocupaciones. Una transacción puede cambiar un saldo, afectar una categoría, otorgar o consumir una recompensa, avanzar un reto, calificar a un cliente para una campaña y disparar una notificación push. Esas acciones tienen dependencias y modos de falla distintos, pero deben comportarse como una sola experiencia coherente.

El modelo de dominio compartido separa la configuración propia de cada organización del motor central de lealtad. Las diferencias de programa, como comportamiento de acumulación, categorías, recompensas, campañas, plantillas y comportamiento de integración, se representan como configuración y datos siempre que es práctico, lo que permite que una sola plataforma central soporte programas muy distintos.

Una capa de integración adapta los sistemas empresariales externos a ese modelo común. Los distintos protocolos y formas de payload se normalizan en la frontera, con manejo configurable de solicitud y respuesta donde corresponde. Los intentos de integración son observables y recuperables, para que una falla externa no se convierta en una deriva inexplicable del estado de lealtad.

Una capa de disparadores conecta los cambios de estado de lealtad con el engagement del cliente. Las transacciones y los eventos de ciclo de vida pueden otorgar o canjear puntos, emitir recompensas, actualizar retos, seleccionar campañas e impulsar notificaciones push mediante las mismas reglas de la plataforma, en vez de a través de sistemas inconexos.

Las experiencias de lectura intensiva, como saldos y catálogos, se pueden cachear con agresividad, mientras que los caminos que modifican transacciones conservan estado persistente y autoritativo. El modelo de rendimiento refleja así la diferencia entre servir rápido las experiencias de cliente y preservar la corrección financiera y de lealtad.

Lideré la arquitectura y la dirección técnica del modelo de lealtad compartido, la configuración por organización, el marco de integración empresarial, los flujos de transacciones y puntos, las recompensas, los disparadores de campañas y notificaciones, el rendimiento y la evolución de nube y plataforma detrás del sistema. También lideré el trabajo de adaptar ese mismo núcleo a organizaciones cuyos requisitos eran lo bastante distintos como para que productos separados hubieran sido la respuesta más fácil.

1. Un núcleo configurable en lugar de una bifurcación por organización

   Por qué

   Bifurcar resuelve rápido la primera personalización y encarece cada corrección de seguridad, función, integración y cambio de plataforma que venga después. Un núcleo común mantiene compartidas esas inversiones.

   Concesión

   El modelo de configuración tiene que absorber variación significativa, y los modelos de negocio genuinamente nuevos obligan a la arquitectura compartida a evolucionar.

2. Poner la variación empresarial en la frontera de integración

   Por qué

   El motor de lealtad debería razonar sobre un modelo interno consistente incluso cuando los sistemas upstream hablan protocolos, esquemas, modelos de autenticación y formatos de transacción distintos.

   Concesión

   La capa de adaptadores y mapeo se vuelve una superficie de producto por derecho propio y exige buenos diagnósticos cuando un contrato externo cambia.

3. Conectar el estado de lealtad a un motor de disparadores explícito

   Por qué

   Un evento de negocio a menudo necesita hacer más que actualizar un saldo de puntos. Conectar reglas de lealtad, recompensas, retos, campañas y notificaciones vuelve al engagement parte del mismo dominio y no una colección de sistemas laterales desconectados.

   Concesión

   Los flujos dirigidos por disparadores exigen un manejo cuidadoso de reintentos, orden, ejecución duplicada y fallas parciales.

4. Tratar la falla de sistemas externos como una condición operativa esperada

   Por qué

   Los grandes sistemas empresariales no comparten la misma ventana de disponibilidad ni el mismo comportamiento ante fallas. Las llamadas de integración necesitan suficiente registro, recuperación, reintento y visibilidad operativa como para que las fallas temporales se diagnostiquen y reconcilien en lugar de convertirse en inconsistencias silenciosas.

   Concesión

   La recuperabilidad introduce colas, estado, reconciliación y complejidad operativa que una integración sincrónica simple evitaría.

La plataforma puede sostener múltiples programas de lealtad con marcas distintas y ecosistemas empresariales muy diferentes sin convertir a cada organización nueva en una base de código nueva. Las mejoras del núcleo se publican una vez, mientras las integraciones y el comportamiento del programa se adaptan alrededor.

Más importante aún, las transacciones, el estado de lealtad y el engagement del cliente viven en una sola arquitectura. La misma actividad de negocio puede actualizar el valor del cliente, cambiar su elegibilidad, emitir un beneficio, avanzar un reto y disparar la siguiente interacción sin coser un producto distinto para cada paso.

Los nombres de clientes y marcas, la economía de los programas, los volúmenes de transacción, los sistemas de socios, los contratos de integración, la lógica de notificaciones y los detalles de infraestructura se omiten intencionalmente.

• Node.js
• PostgreSQL
• Redis
• AWS
• React
• REST
• SOAP