Booking architecture

Booking unificado no significa obligar al club a abandonar todos sus canales.

La arquitectura correcta separa adquisición, inventario, customer relationship y atribución.

Un inventario, varios canales

Un club puede recibir demanda desde su propia web, una app white-label, marketplaces y una red cross-club. El core necesita una representación coherente de pista, slot, precio y estado.

Los conectores deben respetar las capacidades reales

Si un proveedor permite API read/write, se puede diseñar sync y prevención de conflictos. Si solo permite export o lectura, el sistema debe trabajar dentro de ese límite y no fingir integración bidireccional.

Adquisición externa y retención directa pueden coexistir

Un marketplace puede ser útil para descubrir nuevos jugadores. La oportunidad económica aparece cuando el club entiende origen, coste de distribución y qué parte de la demanda recurrente puede servir directamente.

La identidad portable no es el CRM privado

Un jugador puede tener identidad, nivel y preferencias portables, mientras historial de gasto, churn, segmentación y notas siguen siendo privadas de cada club.

La prioridad es integridad de reserva

Locks, idempotencia, control de concurrencia y reglas claras de sync son más importantes que una interfaz bonita cuando varios canales pueden tocar el mismo inventario.

Revisar mi arquitectura de booking