---
type: RFI
asset_id: RFI-EL-PlataformaComunidades-AfiliacionTarjetaPuntos-v01
version: v01
status: Draft
owner: Victor Heredia
sherpa_owner: Jay
fecha_creacion: 2026-06-03
fecha_ultima_actualizacion: 2026-06-03
intellbank: IB-EL-EmpowerLabs
subbank: PB-EL-Plataforma
tipo_largo: Request for Implementation (solicitud interna de implementación) — Plataforma de Comunidades Colaborativas · Capa de Afiliación + Tarjeta de Marca Privada + Sistema de Puntos + Transacciones
destinatario: Equipo de desarrollo interno EmpowerLabs (con posibilidad de sumar programador adicional si fuera necesario)
naturaleza_documento: Solicitud de implementación interna · NO es licitación a terceros · NO es documento comercial
proposito: Documento formal de Request for Implementation que especifica los requerimientos funcionales para que el equipo interno de desarrollo de EmpowerLabs incorpore a la Plataforma de Comunidades Colaborativas las capabilities de (a) modelo de afiliación organizacional + membresías individuales, (b) tarjeta de marca privada con co-branding, (c) sistema de puntos / monedero electrónico, (d) tracking de transacciones presenciales en comercios afiliados, (e) multi-tenancy para soportar simultáneamente Rebelocity Club + TribusRRHH + Marketplace Sindical Mexicano (Michel Vázquez/Agustín Avilés · escala 800K usuarios potenciales). Pide al equipo responder con capacidades actuales, propuesta técnica, esfuerzo y plazos.
fuentes_input:
  - Junta de programación 2026-06-03 (minuta subida al chat) — clarificaciones de Victor sobre tipos de usuarios, tarjeta y puntos
  - PLAN-EL-DesarrolloPlataformaComunidades-v01 (sprint dev base con items 1.21 y 1.22)
  - DC-IS-AnalisisCompetitivo-TDU-MarketplaceColaborativo-v02 (modelo TDU/Capital People de referencia)
  - DC-REB-RebelocityClub-PlanEstrategico-v01 Anexo B (ReClub Card como caso piloto)
  - SPEC-REB-RClub-ArquitecturaDatos-RegistroPerfil-v01 (registro + perfil ya specificados por Anahí Martínez)
  - SPEC-REB-RClub-DirectorioMiembros-v02 (directorio de miembros Fase 1 ya specificado)
  - PLAN-TriRH-Rally2-Gamificacion-v02 (sistema de puntos en producción Rally 2)
  - XD-EL-Loop-HiOrg-MarketplaceColaborativo-v01 (oportunidad sindical 800K-100K usuarios)
plazo_respuesta_sugerido: 10 días hábiles desde envío
---

# RFI · Plataforma de Comunidades Colaborativas

## Capa de Afiliación + Tarjeta de Marca Privada + Sistema de Puntos + Transacciones

> **Nota sobre la nomenclatura.** En el ecosistema EmpowerLabs, **RFI significa Request for Implementation** (Solicitud de Implementación interna). No es una Request for Information (sentido genérico del mercado). Es un documento interno dirigido al equipo de desarrollo de EmpowerLabs para que formalice la propuesta técnica, esfuerzo y plazos para construir las capabilities descritas. **No es una licitación a terceros ni un documento comercial.**

---

## 0. Sumario ejecutivo del RFI

EmpowerLabs solicita al equipo de desarrollo interno que responda formalmente a este RFI (Request for Implementation) describiendo:

1. **Capacidades técnicas actuales** de la plataforma de comunidades colaborativas frente a cada requerimiento listado en §3.
2. **Propuesta técnica** para construir lo que falta — arquitectura, modelo de datos, integraciones, riesgos.
3. **Estimación de esfuerzo y plazos** por capability — en personas-sprint o personas-mes, y semanas calendario.
4. **Tecnologías y dependencias** que la propuesta requiere (frameworks, pasarelas, almacenamiento, infra).
5. **Preguntas que el equipo de desarrollo necesita resolver con Victor o producto** antes de iniciar.

El alcance del RFI es **diseñar y construir la capa que falta** para que la plataforma soporte el lanzamiento formal de **tres comunidades en paralelo**:

| Comunidad | Estado | Escala objetivo |
|---|---|---|
| **TribusRRHH** | En producción · Rally 2 activo | Miles de profesionales RRHH (LATAM) |
| **Rebelocity Club** | Soft launch agosto 2026 | 8K-15K atletas Año 1 → 25K Año 2 |
| **Marketplace Sindical Mexicano (Michel/Agustín)** | Definiendo requerimientos · primer contacto | **800.000 empleados potenciales · meta 100K Año 1 · 200 empresas proveedoras** |

**Las capabilities solicitadas deben ser:** multi-tenant nativas · configurables sin código por administrador de cada comunidad · documentadas · escalables a 1M+ usuarios concurrentes en el horizonte 24-36 meses.

---

## 1. Contexto general

### 1.1 La plataforma existe y opera

La Plataforma de Comunidades Colaborativas de EmpowerLabs integra **13 módulos canónicos** ya construidos:

| # | Módulo | Status |
|---|---|---|
| 1 | News Engine | Operativo |
| 2 | Librería + MasterPlaybooks (MPI) | Operativo |
| 3 | Foros | Operativo |
| 4 | Directorio + Perfiles profesionales/empresariales | Operativo (en TriRH) · ya specificado para Rebelocity (`SPEC-REB-RClub-DirectorioMiembros-v02`) |
| 5 | Marketplace B2B/B2C | Operativo parcial — requiere 3 niveles de tienda (ver `PLAN-EL-DesarrolloPlataformaComunidades-v01` item 1.22) |
| 6 | Cursos + Campus virtual | Operativo |
| 7 | Gamificación + Rallies | Operativo (Rally 2 TribusRRHH · 100 puntos · 8-9 misiones · badges · leaderboard) — **se extiende en este RFI** |
| 8 | Clasificados | Operativo |
| 9 | Empleos | Operativo |
| 10 | Comunicación cruzada (chat, mensajería) | Operativo |
| 11 | Eventos + Calendario | Operativo parcial — venta de boletos requiere ajustes (item 1.22) |
| 12 | Membresías multinivel | Operativo (Free / Pro / Premium / Enterprise) — **se extiende en este RFI con capa de Afiliación** |
| 13 | IA transversal (Sherpa + KatIA) | Operativo |

### 1.2 Lo que se decidió en la Junta de Programación 2026-06-03

La junta del 3 de junio entre Victor + Jesús + Alex aclaró el modelo conceptual que este RFI formaliza. Decisiones clave declaradas por Victor:

1. **Dos capas independientes que coexisten:**
   - **Afiliación** = la "marca paraguas" — una empresa, club, sindicato, asociación, iglesia, etc. que afilia miembros y paga por ellos.
   - **Membresía** = el nivel individual del miembro — Básica, Oro, Platinum (nombres tentativos), con paquetes de beneficios distintos.
   - **Un miembro puede tener AMBAS:** estar afiliado a una empresa (que cubre cuota) Y tener un nivel personal (que define beneficios y puntos).

2. **La tarjeta es digital primero (QR), física opcional.** Co-branding con la empresa afiliada (ejemplo: "Tarjeta Rebelocity Club CON marca de empresa X"). Identificador único que codifica tipo + nivel + empresa + ID secuencial.

3. **Sistema de puntos opera como monedero electrónico** (modelo airline rewards):
   - Se ganan puntos por inscripción · compras en plataforma · compras en comercios afiliados · logros (retos) · referidos · recomendaciones.
   - Se gastan puntos **solo dentro del ecosistema** (libros · MPIs · tickets · etc.).
   - Los comercios externos **dan puntos** al cliente; no reciben puntos a cambio. Reciben **cliente + comisión por referido**.

4. **Comercios escanean QR del miembro vía app del comercio** para registrar la transacción → asignar puntos → enriquecer perfil del cliente con su comportamiento de compra.

5. **Escala objetivo es alta:** el sindicato mexicano de Michel Vázquez tiene 800.000 empleados; meta 100.000 afiliados en Año 1 + 200 empresas proveedoras. Esto NO es un proyecto de "pequeños" — la arquitectura debe escalar.

### 1.3 Lo que ya está specificado y NO debe reinventarse

| Spec existente | Qué cubre |
|---|---|
| `SPEC-REB-RClub-ArquitecturaDatos-RegistroPerfil-v01` | Registro mínimo (Nombre · Correo · País · Disciplina) + perfil completo en Rally Etapa 2 |
| `SPEC-REB-RClub-DirectorioMiembros-v02` | Directorio Fase 1 con filtros · tarjetas · modal · API endpoints |
| `PLAN-EL-DesarrolloPlataformaComunidades-v01` | Plan de desarrollo macro · items 1.21-1.27 + 3 niveles de tienda |
| `PLAN-TriRH-Rally2-Gamificacion-v02` | Sistema de puntos en producción (Rally 2) |
| `DC-IS-AnalisisCompetitivo-TDU-MarketplaceColaborativo-v02` | Modelo TDU/Capital People como **referencia comparativa** + las 6 deficiencias estructurales que esta plataforma corrige |
| `DC-REB-RebelocityClub-PlanEstrategico-v01` Anexo B | ReClub Card como **caso piloto** (Free/Pro/Elite/Corporate · 3 capas Digital/Física/Protección) |

**El equipo de desarrollo debe leer estos documentos antes de responder al RFI.**

---

## 2. Estado actual de la plataforma — vista para el equipo dev

### 2.1 Lo que opera

- Multi-tenant base (TribusRRHH opera como un tenant aislado).
- Sistema de membresías básico (Free / Pro / Premium / Enterprise — sin granularidad ni configurabilidad por comunidad documentada).
- Sistema de puntos básico (Rally 2: 100 puntos · 8-9 misiones · badges · leaderboard · Punchify-based).
- Marketplace B2B/B2C con catálogo de proveedores · tiendas operativas en algunos clientes.
- Calendario y eventos con publicación · gestión básica · sin venta de boletos integrada.
- Sherpa + KatIA (asistentes IA) integrados en playbooks y home.

### 2.2 Lo que NO existe todavía (objeto de este RFI)

- **Capa de afiliación** organizacional (empresas paraguas) con miembros agrupados y co-branding de tarjeta.
- **Tarjeta de marca privada digital** (QR único · numeración con tipo+nivel+empresa+secuencial · física opcional).
- **Monedero electrónico** transversal con múltiples fuentes de adquisición de puntos (más allá del Rally) y redención dentro del ecosistema.
- **App del comercio** para tracking de transacciones presenciales con escaneo de QR.
- **Sistema de referidos** integrado al monedero (puntos por referir).
- **Comisión por referido** al comercio (la plataforma cobra al comercio cuando manda cliente).
- **Capa de configuración admin por comunidad** para definir reglas de puntos, niveles de membresía, descuentos, co-branding.
- **Multi-tenant verificado** para escala 800K-1M usuarios.

### 2.3 Lo que está en proceso paralelo (no objeto de este RFI pero relacionado)

- 3 niveles de tienda (Directorio · Eventos · Eventos+Tienda Full) — item 1.22 `PLAN-EL-DesarrolloPlataformaComunidades-v01`.
- Venta de boletos integrada con pasarela de pago (Bancard · Mercado Pago · Stripe LATAM) — item 1.22.
- Sistema de banners para sponsors — item 1.22.
- Actualización de vista marketplace/tiendas (UI/UX) — item 1.26.
- Integración con Master Suite 2.0 / Sherpa / OneRocket (tema separado de la junta).

---

## 3. Especificación funcional de requerimientos

### 3.1 Tipos de usuarios

La plataforma debe distinguir y soportar **tres grandes categorías de usuarios** con sub-roles:

#### 3.1.1 Empresas Afiliadas (organización paraguas)

Entidad organizacional que **agrupa y paga por sus miembros**. Una empresa afiliada puede ser:

| Tipo | Ejemplos | Caso de uso |
|---|---|---|
| **Empresa** | Banamex · Estafeta · empresa privada · empresa pública | Beneficios deportivos/wellness para empleados |
| **Club** | Asunción Runners · Os Trota · club ciclista · club triatlón | Beneficios para socios del club |
| **Sindicato** | Sindicato mexicano de Michel · sindicato de salud | Beneficios para sindicalizados (escala 100K-800K) |
| **Asociación profesional** | Colegio de Contadores · Colegio Médico · barra de abogados | Beneficios para agremiados |
| **Iglesia / Comunidad religiosa** | Diócesis · parroquia · congregación | Beneficios para correligionarios |
| **Federación deportiva** | Federación Paraguaya de Atletismo · Asociación Triatlón | Beneficios para federados |
| **Embajada / Institución pública** | Embajada de Brasil · SENATUR | Programas wellness / cultural |

**Capabilities mínimas para Empresa Afiliada:**
- Perfil organizacional (nombre legal, marca pública, logo, datos de contacto, datos fiscales)
- Plan de afiliación contratado (cantidad de miembros, pricing por miembro o por contrato)
- Branding propio (logo + colores + nombre comercial para co-branding de tarjeta)
- Panel admin para alta/baja de miembros, asignación de nivel, monitoreo de uso
- Dashboard de engagement (cuántos miembros usan, qué consumen, ROI estimado)
- Facturación y reporte de pagos
- Multi-administrador (cuenta corporativa con múltiples usuarios admin con roles)

#### 3.1.2 Miembros (usuarios personales / compradores finales)

Persona física que se inscribe en la plataforma. Puede llegar por **dos rutas**:

| Ruta de ingreso | Quién paga la membresía |
|---|---|
| **Afiliado por una empresa** | La empresa afiliada cubre la cuota (B2B2C) |
| **Independiente / individual** | El miembro paga directamente (B2C) |

Un miembro **puede estar simultáneamente afiliado a más de una empresa** y/o tener membresía individual.

**Sub-roles dentro del miembro** (heredado de `SPEC-REB-RClub-ArquitecturaDatos-RegistroPerfil-v01`):
- Atleta amateur · Atleta competitivo · Coach · Club (representante) · Organizador · Marca (representante)
- En TribusRRHH: profesional de RRHH (heredado del Rally 2)
- En marketplace sindical mexicano: empleado sindicalizado · familiar dependiente · jubilado

**Capabilities mínimas para Miembro:**
- Perfil personal (datos básicos + perfil contextual por comunidad — ej: deportivo en Rebelocity, profesional en TriRH)
- Vinculación con 1+ empresa afiliada (opcional · puede ser nula si es independiente)
- Nivel de membresía individual (Básica · Oro · Platinum o equivalente — ver §3.2.2)
- Tarjeta de marca privada vinculada (QR único · numeración)
- Monedero electrónico de puntos con histórico
- Histórico de transacciones (compras · usos · puntos ganados/gastados)
- Configuración de privacidad y notificaciones

#### 3.1.3 Comercios / Proveedores (vendedores)

Entidad que ofrece productos o servicios a los miembros, dentro o fuera de la plataforma. Subdividido en tres tipos (alineado con `PLAN-EL-DesarrolloPlataformaComunidades-v01` item 1.22):

| Tipo de comercio | Qué vende | Tier de tienda |
|---|---|---|
| **Solo directorio** (Tier 1) | Presencia básica · sin transacción · link a tienda externa | Tier 1 — Directorio |
| **Eventos** (Tier 2) | Eventos propios con venta de boletos en la plataforma | Tier 2 — Eventos |
| **Eventos + Tienda Full** (Tier 3) | Eventos + catálogo transaccional + CRM + analytics | Tier 3 — Full transaccional |

**Capabilities mínimas para Comercio:**
- Perfil de comercio (datos básicos · categoría · zona · datos fiscales)
- Panel admin para alta/baja de eventos · productos · servicios
- **App del comercio** para escanear QR de miembro y registrar transacción presencial (ver §3.6)
- Dashboard CRM (compradores · recurrencia · ticket promedio · perfil agregado · tendencias)
- Reportes financieros (revenue · comisiones · liquidaciones)
- Configuración de % de puntos a otorgar por transacción + % de cashback

#### 3.1.4 Administradores y staff (transversal)

Usuarios internos del operador de la plataforma:

| Rol | Permisos |
|---|---|
| **Super-admin EmpowerLabs** | Acceso transversal a todos los tenants · configuración global · monitoreo |
| **Admin de comunidad** (ej: Victor para Rebelocity · admin TriRH · admin del marketplace sindical) | Configuración completa de la comunidad · sin acceso a otras comunidades |
| **Staff de comunidad** | Operativo (atención · soporte · moderación) sin acceso a configuración financiera |
| **Admin de Empresa Afiliada** | Solo sobre su empresa y sus miembros |
| **Admin de Comercio** | Solo sobre su comercio |

#### 3.1.5 Diagrama de relaciones

```
                    PLATAFORMA (multi-tenant)
                            │
        ┌───────────────────┼───────────────────┐
        ▼                   ▼                   ▼
   COMUNIDAD            COMUNIDAD          COMUNIDAD
   Rebelocity Club      TribusRRHH         Marketplace Sindical
        │                                       │
   ┌────┼────────────┐                      ┌──┼─────────────┐
   ▼    ▼            ▼                      ▼  ▼             ▼
 EMPRESAS         MIEMBROS              EMPRESAS  MIEMBROS  COMERCIOS
 AFILIADAS    (individuales o          AFILIADAS  (sindicaliz)
 (clubes,      afiliados a una        (sindicatos
 empresas,     empresa)                 + empresas
 sindicatos)        ▲                  agremiadas)
        │           │
        └───>───[afilia]
                    │
                COMERCIOS
            (Tier 1/2/3)
```

---

### 3.2 Modelo de Afiliación + Membresía individual

#### 3.2.1 Capa Afiliación (empresa paraguas)

Cuando una **Empresa Afiliada** firma contrato con la comunidad, recibe:

| Componente | Descripción |
|---|---|
| **Plan de afiliación** | Define cantidad de miembros incluidos, niveles permitidos, condiciones contractuales (la definición comercial se gestiona fuera de este documento) |
| **Tarjeta de marca compartida** | Co-branding (logo de Rebelocity Club + logo de la Empresa Afiliada) — la tarjeta del miembro afiliado lleva ambas marcas |
| **Codificación de identificador** | Cada tarjeta emitida bajo una Empresa Afiliada lleva un código que identifica a esa empresa (ver §3.3.3) |
| **Panel admin de empresa** | Alta/baja de miembros · asignación de nivel · monitoreo |
| **Reportes de uso** | Engagement · cuántos miembros usan · qué consumen |

**Casos de uso documentados:**
- **Rebelocity Club:** Asunción Runners (25K seguidores) firma como Empresa Afiliada · sus socios reciben tarjeta co-brandeada con beneficios endurance del ecosistema Rebelocity.
- **Marketplace Sindical Mexicano:** Sindicato de Michel firma como Empresa Afiliada · sus 100K sindicalizados Año 1 reciben tarjeta co-brandeada con beneficios del marketplace + descuentos en 200 proveedores afiliados.
- **TribusRRHH:** una empresa cliente afilia a su equipo de RRHH como beneficio · acceso a contenido + comunidad + Rally.

#### 3.2.2 Capa Membresía individual (niveles del miembro)

Independientemente de la afiliación organizacional, cada miembro tiene **un nivel personal** con beneficios graduales. Naming tentativo (a confirmar por comunidad):

| Nivel | Naming sugerido | Beneficios graduales (funcionalidad que el sistema debe soportar) |
|---|---|---|
| **Nivel 1** | Básica | Acceso comunidad · perfil · onramp puntos · directorio |
| **Nivel 2** | Oro | + MPIs ilimitados · sherpa premium · descuentos marketplace configurables · cashback configurable · acceso preferencial eventos |
| **Nivel 3** | Platinum | + concierge · descuentos elevados configurables · cashback elevado · bundles turismo · capa de protección (seguros · telemedicina vía partner) |
| **Corporate / Custom** | Por contrato | White-label · branding propio · multi-administrador · API |

> *Los porcentajes específicos de descuento, cashback, conversión puntos→USD, y pricing se configuran por administrador de comunidad. El sistema debe soportar la mecánica; los valores económicos son decisión de cada comunidad.*

**Decisiones clave que el equipo dev debe poder soportar:**
- Cada comunidad **renombra los niveles** sin tocar código (ReClub Pro/Elite · TriRH Profesional · Sindicato Sindicalizado/Plus, etc.)
- Cada comunidad **define el pricing y los beneficios** por nivel
- Cada comunidad **define las reglas de puntos** por nivel (multiplicadores, % de cashback, fuentes habilitadas)
- Cada miembro **puede ser upgradeado o downgradeado** sin perder histórico (de puntos, transacciones, etc.)
- Cada nivel debe poder ser **subsidiado por la Empresa Afiliada** (la empresa paga el upgrade de Básica → Oro a sus afiliados como beneficio extra)

#### 3.2.3 Casos compuestos típicos

Un miembro puede vivir simultáneamente todos los siguientes:

| Caso | Composición (mecánica que debe soportar el sistema) |
|---|---|
| **Independiente Básica** | Sin afiliación · nivel Básica · sin cuota de membresía |
| **Independiente Oro** | Sin afiliación · nivel Oro · cuota individual (paga el miembro directamente) |
| **Afiliado por empresa, Básica** | Empresa afiliada lo registra como Básica · empresa cubre la cuota · miembro no paga |
| **Afiliado por empresa, Oro (subsidio empresa)** | Empresa afiliada lo registra como Oro como beneficio premium · empresa cubre el upgrade · miembro no paga |
| **Afiliado por empresa, Oro (mejora individual)** | Empresa registra como Básica · miembro paga la diferencia para upgradearse a Oro |
| **Doblemente afiliado** | Miembro afiliado a Asunción Runners (su club) Y a su empresa (su trabajo) · ambas tarjetas en su wallet · puede usar la que prefiera para cada transacción |

El equipo dev debe poder soportar TODOS estos casos por configuración.

---

### 3.3 Tarjeta de afiliación (ReClub Card y equivalentes por comunidad)

#### 3.3.1 Naturaleza de la tarjeta

- **Digital obligatoria** (en app móvil + web) con QR único persistente por miembro.
- **Física opcional** (impresión por tercero) — el miembro puede solicitar tarjeta de plástico que reproduce el QR.
- **Co-branding configurable** por Empresa Afiliada:
  - Tarjeta de miembro independiente: logo Rebelocity Club (o de la comunidad correspondiente)
  - Tarjeta de miembro afiliado por empresa: logo Rebelocity Club + logo Empresa Afiliada
- **Naming por comunidad**: ReClub Card (Rebelocity) · pendiente naming para TriRH y marketplace sindical.

#### 3.3.2 Identificador único (numeración)

Cada tarjeta lleva un **número de identificación** que codifica metadata. Propuesta de estructura (a validar):

```
Estructura: TIPO – NIVEL – EMPRESA – SECUENCIAL

Ejemplos:
- Tarjeta independiente Oro Rebelocity: REB-2-000-001245
- Tarjeta afiliada por Asunción Runners, nivel Básica: REB-1-AR01-005678
- Tarjeta afiliada por Sindicato Mexicano X, Oro: SIN-2-SX01-099431
- Tarjeta TriRH afiliada por empresa Y, nivel Premium: TRH-3-EY03-002145
```

| Segmento | Significado |
|---|---|
| `TIPO` | 3 letras de la comunidad (REB/TRH/SIN/...) |
| `NIVEL` | 1 dígito con el nivel de membresía (1=Básica, 2=Oro, 3=Platinum, 0=Independiente sin nivel pagado) |
| `EMPRESA` | 4 caracteres alfanuméricos para la Empresa Afiliada (000 si independiente) |
| `SECUENCIAL` | 6+ dígitos correlativos por comunidad |

**Decisión técnica que el equipo dev debe proponer:**
- ¿Numeración secuencial centralizada o distribuida?
- ¿Sistema de verificación (checksum / Luhn / similar) para evitar falsificación?
- ¿Cómo se garantiza unicidad en escala 1M+ tarjetas activas?

#### 3.3.3 Wallet del usuario

Cada miembro tiene un **wallet digital** (sección en app + web) que muestra:
- Tarjeta(s) activa(s) — si tiene más de una, las muestra todas
- QR escaneable para presentar en comercios
- Saldo de puntos actual
- Histórico de movimientos
- Próximos beneficios disponibles
- Estado de pagos y renovaciones

#### 3.3.4 Diferenciación vs modelo TDU/Capital People

Según `DC-IS-AnalisisCompetitivo-TDU-MarketplaceColaborativo-v02`, la tarjeta TDU es un **plástico pasivo** sin posibilidad de rastrear quién compró. Nuestra tarjeta DEBE:
- Identificar al miembro en cada transacción (QR único)
- Permitir trazabilidad de comportamiento (qué consume, dónde, cuándo, cuánto)
- Habilitar yield management dinámico (descuentos por hora/día/anticipación)
- Generar data de intención agregada para sponsors y comercios (CRM)
- Soportar cashback cruzado al monedero (las 6 deficiencias TDU corregidas — ver §B.5 Anexo B Plan Rebelocity)

---

### 3.4 Sistema de puntos / Monedero electrónico

#### 3.4.1 Naturaleza del sistema

Modelo **airline rewards** (AAdvantage · Aeroméxico Rewards · Avianca LifeMiles):
- Los puntos son **una moneda interna** del ecosistema.
- **Se ganan** por una variedad de acciones configurables.
- **Se gastan** solo dentro del ecosistema (no retirables a cuenta bancaria).
- **Estado de cuenta** visible al miembro en todo momento.

#### 3.4.2 Fuentes de adquisición (ganar puntos) — configurables por comunidad

| Fuente | Trigger | Configurable por admin |
|---|---|---|
| **Inscripción inicial / bono de bienvenida** | Registro confirmado | Sí — monto fijo |
| **Compra de boleto de evento dentro de la plataforma** | Pago confirmado | Sí — % por categoría de evento |
| **Compra en marketplace (B2B o B2C)** | Pago confirmado | Sí — % por categoría de proveedor |
| **Suscripción premium (upgrade de nivel)** | Pago de membresía | Sí — multiplicador anual/mensual |
| **Compra registrada por comercio físico** | App del comercio escanea/registra (ver §3.6) | Sí — % por comercio, por categoría, por hora/día (yield) |
| **Referido de nuevo miembro** | Nuevo usuario se registra con código + completa primer hito calificador | Sí — puntos por registro + extra por hito completado |
| **Participación en eventos (check-in)** | Asistencia confirmada en evento | Sí — puntos por evento |
| **Completar misiones / rallies** | Misión completada (Rally 2 ya en producción) | Sí — extender modelo Rally 2 a otras comunidades |
| **Generar contenido (post · review · comentario)** | Acción registrada con anti-spam | Sí — caps diarios |
| **Reto cumplido (entrenamiento · curso · etc.)** | Validación por sistema o moderador | Sí — según producto |
| **Logro especial** (badge desbloqueado · aniversario · campaña sponsor) | Trigger especial | Sí |

**Anti-fraude requerido:**
- Caps diarios/semanales por usuario.
- Validación de referidos (no auto-referido · misma IP/dispositivo · método de pago duplicado).
- Detección de patrones anómalos (cuentas múltiples · uso atípico).
- Bloqueo o reversa de puntos sospechosos.

#### 3.4.3 Formas de redención (gastar puntos)

| Redención | Configurable por admin |
|---|---|
| Descuento en compra de boletos de eventos | Sí — tasa de conversión puntos→USD |
| Descuento o saldo en compras del marketplace | Sí — tasa de conversión |
| Upgrade de nivel de tarjeta (Básica → Oro · Oro → Platinum) | Sí — costo en puntos |
| Compra de MPIs premium · contenido · libros · audiolibros | Sí |
| Cupones para comercios afiliados (canje en app del comercio) | Sí — el comercio acepta puntos en lugar de dinero parcial |
| Bundles de turismo deportivo (boleto + hotel + transporte) | Sí |
| Donaciones a causas sociales del ecosistema | Sí — con tracking |
| Sorteos / experiencias exclusivas | Sí — campañas spot |

**Regla central declarada por Victor:** los puntos **no son retirables a banco**. Solo se redimen dentro del ecosistema. Esto crea el loop de retención.

#### 3.4.4 Visualización para el miembro

App + web deben mostrar al miembro:
- **Saldo actual** de puntos (grande y visible)
- **Histórico completo de movimientos** (filtrable por: ganados/gastados/caducados · fuente · fecha)
- **Próximas redenciones disponibles** según su saldo (sugerencias contextuales)
- **Tasa de conversión** vigente (puntos → equivalente monetario configurable)
- **Caducidad** de puntos si aplica (puntos expiran a Y meses)
- **QR de su tarjeta** para presentar en comercios
- **Beneficios activos** de su nivel + de sus afiliaciones

#### 3.4.5 Visualización para administradores

- Admin de comunidad: dashboard con puntos emitidos/redimidos · fuentes activas · top usuarios · top comercios · costo total del programa.
- Admin de empresa afiliada: puntos consumidos por sus afiliados · top usuarios · uso por categoría.
- Admin de comercio: puntos otorgados por su comercio · clientes recurrentes · ticket promedio.

#### 3.4.6 Sistema contable de puntos

El equipo dev debe proponer cómo:
- **Cuadrar el balance** de puntos emitidos vs redimidos (ledger interno completo y auditable).
- **Mantener trazabilidad** de cada movimiento de puntos (fuente · destino · timestamp · admin que lo aprobó si aplica).
- **Exportar reportes** del programa de puntos en formato consumible por contabilidad/ERP (CSV · API · webhook).
- **Soportar reconciliación** cuando hay discrepancias.

---

### 3.5 Transacciones permitidas

Tipología de transacciones que la plataforma debe procesar:

#### 3.5.1 Transacciones monetarias (cobro real con pasarela)

> *El término **Plataforma** en esta tabla se refiere a la Comunidad operadora (TribusRRHH, Rebelocity Club, Marketplace Sindical, etc.) que recibe el cobro. El equipo dev debe soportar la mecánica de cada tipo de transacción · el % de comisión es configurable por administrador de comunidad y se gestiona fuera de este documento.*

| Transacción | Quién paga | A quién |
|---|---|---|
| Compra de boleto de evento | Miembro | Organizador del evento |
| Compra de membresía individual (Oro · Platinum) | Miembro | Plataforma |
| Cobro de afiliación de empresa | Empresa afiliada | Plataforma |
| Compra en marketplace (Tier 3 transaccional) | Miembro | Proveedor |
| Suscripción de proveedor (Tier 1/2/3) | Proveedor | Plataforma |
| Sponsorship (4 niveles Sponsor Stack) | Sponsor | Plataforma |
| Cobro de comisión por referido | Comercio | Plataforma |
| Bundle turismo deportivo | Miembro | Múltiples destinatarios (hotel · transporte · tour) |
| Producción de MPI patrocinado | Sponsor | Plataforma |
| Renovación automática de membresía | Miembro o Empresa | Plataforma |

#### 3.5.2 Transacciones de puntos (sin dinero · ledger interno)

| Transacción | Origen | Destino | Notas |
|---|---|---|---|
| Asignación de puntos por bono inicial | Plataforma | Miembro | Trigger: registro |
| Asignación de puntos por compra en plataforma | Plataforma | Miembro | Trigger: pago confirmado |
| Asignación de puntos por compra en comercio | Comercio (vía app) | Miembro | Trigger: escaneo QR |
| Asignación de puntos por referido | Plataforma | Miembro referidor | Trigger: registro + hito calificador del referido |
| Asignación de puntos por misión / reto | Plataforma | Miembro | Trigger: validación |
| Redención de puntos en plataforma | Miembro | Plataforma | Conversión puntos → descuento monetario equivalente |
| Redención de puntos en comercio | Miembro | Comercio | Comercio recibe puntos · plataforma le acredita el equivalente monetario menos comisión |
| Caducidad de puntos | Plataforma | (sistema) | Expiración programada |
| Reversa de puntos por fraude detectado | Plataforma | (sistema) | Trigger: investigación |

#### 3.5.3 Transacciones mixtas (puntos + dinero · ej: "pago parte en puntos")

El equipo dev debe poder soportar pagos donde:
- 30% del monto se paga con puntos del miembro
- 70% se paga con tarjeta vía pasarela
- El comercio recibe el 100% en dinero (la plataforma cubre el % de puntos)

Esto es **clave del modelo airline** y diferenciador vs TDU.

#### 3.5.4 Flujo de liquidación al comercio / organizador / proveedor

El equipo dev debe especificar:
- Plazo de liquidación (¿inmediata? ¿quincenal? ¿mensual?)
- Mecanismo de liquidación (transferencia · pago directo · acreditación a cuenta interna)
- Manejo de reversiones (devoluciones · disputas)
- Reportes de conciliación
- Compliance fiscal (facturación · retenciones · reportes a SAT/Hacienda en cada país)

---

### 3.6 App del comercio (capability nueva — modelo "gasolinería")

Capability **diferenciadora vs TDU**. Permite que un comercio físico registre transacciones de tarjetahabientes.

#### 3.6.1 Flujo lado comercio

1. Comercio abre app o web "Comercio EmpowerLabs" en su dispositivo (tablet · smartphone · POS).
2. Login con credenciales del comercio (multi-usuario · admin + cajeros).
3. Pantalla principal: "Registrar transacción".
4. Miembro muestra QR de su tarjeta → comercio escanea (cámara) o ingresa código manual.
5. Sistema reconoce al miembro · muestra: nombre · nivel de tarjeta · empresa afiliada (si aplica) · saldo de puntos · descuento o cashback aplicable.
6. Comercio ingresa: monto de compra + categoría (configurable por comercio · ej: "Bicicleta", "Servicio mecánico", "Nutrición").
7. Sistema calcula y muestra:
   - Puntos a otorgar al miembro
   - Cashback al monedero del miembro
   - Descuento a aplicar al ticket (si aplica)
   - Comisión a cobrar al comercio (por referido / por uso de plataforma)
8. Comercio confirma transacción.
9. Miembro recibe push + email de confirmación.
10. Record queda en dashboard del comercio + dashboard del miembro.

#### 3.6.2 Flujo lado miembro

1. Miembro entra al comercio.
2. Antes de pagar, abre app → tab "Mi Tarjeta" → muestra QR.
3. Comercio escanea.
4. Miembro paga normalmente en caja (efectivo · tarjeta · transferencia — **lo que sea**).
5. Miembro ve confirmación de puntos ganados + saldo actualizado.

**Nota crítica del equipo dev:** la app del comercio **NO procesa el pago monetario** (eso lo hace el POS del comercio o efectivo). La app solo **registra la transacción para efectos de puntos + cashback + CRM + comisión**. Esto reduce fricción y compliance (no somos pasarela de pago presencial).

#### 3.6.3 Dashboard del comercio

El comercio debe ver en su panel:
- Compras del día / semana / mes registradas con tarjeta
- Top miembros (frecuencia · ticket promedio · gasto total)
- Perfil agregado de tarjetahabientes que lo visitan (nivel · empresa afiliada · disciplina · etc.)
- Tendencias de gasto por categoría
- Comparativo vs benchmarks del ecosistema
- Campañas activas (ej: "Cashback 2x los martes")
- Descarga de base de contactos con consentimiento
- Liquidaciones pendientes y pagadas

#### 3.6.4 Modelo de cobro al comercio por esta capability

A definir con producto. Opciones que el sistema debe soportar:
- Fee fijo mensual (incluido en Tier Pro/Premium de tienda)
- Fee variable sobre transacciones registradas
- Fee por lead generado (si el comercio activa campaña)
- Comisión por referido (el comercio paga a la plataforma % del ticket cuando el miembro fue "enviado" por la plataforma)

---

### 3.7 Multi-tenancy

#### 3.7.1 Requerimientos arquitectónicos

La plataforma debe operar **N comunidades en paralelo**, completamente aisladas:

- **Datos aislados por comunidad** (catálogos, miembros, transacciones, puntos).
- **Branding propio** (logo, colores, dominio o subdominio).
- **Configuración independiente** (reglas de puntos, niveles, pricing, sponsors, banners, etc.).
- **Pasarela de pago configurable por comunidad** (Bancard PY para Rebelocity · Bancos MX para sindical · etc.).
- **Compliance configurable por país** (PY: Ley 4868 + 7120 · MX: NOM-151 · etc.).
- **Usuarios pueden pertenecer a más de una comunidad** con perfil compartido pero wallets y tarjetas separados.

#### 3.7.2 Escala objetivo

| Comunidad | Año 1 | Año 2 | Horizonte 36 meses |
|---|---|---|---|
| Tribus RRHH | Mantener | Escalar a 5K-10K | 25K |
| Rebelocity Club | 8K-15K miembros | 25K | 50K+ regional LATAM |
| Marketplace Sindical Mexicano (Michel) | **100K** | 250K | **800K (universo total sindicato)** |
| Replicación a otras ligas/federaciones LATAM | 0 | 1-2 nuevas | 5+ |
| **TOTAL plataforma agregado** | **~120K** | **~280K** | **~900K-1M** |

**El equipo dev debe responder explícitamente:** ¿puede la arquitectura actual soportar 1M usuarios concurrentes? Si no, ¿qué cambia? ¿cuál es el costo de infra a esa escala?

---

## 4. Capabilities ya documentadas que el equipo dev debe reutilizar

| Documento | Qué cubre | No reinventar |
|---|---|---|
| `SPEC-REB-RClub-ArquitecturaDatos-RegistroPerfil-v01` | Registro mínimo (5 campos) + perfil completo en Rally · esquema users table | Reutilizar para todas las comunidades · agregar capa de afiliación + tarjeta |
| `SPEC-REB-RClub-DirectorioMiembros-v02` | Directorio Fase 1 con filtros · tarjetas · modal · API endpoints | Reutilizar para todas las comunidades · adaptar filtros por comunidad |
| `PLAN-EL-DesarrolloPlataformaComunidades-v01` | 3 niveles de tienda · creación de eventos · venta de boletos · banners · UI/UX | Coordinarse — items 1.21-1.27 son contexto de este RFI |
| `PLAN-TriRH-Rally2-Gamificacion-v02` | Sistema de puntos en producción (100 puntos · 8-9 misiones · badges · leaderboard · Punchify) | Extender modelo · NO reescribir Rally 2 desde cero |
| `DC-REB-RebelocityClub-PlanEstrategico-v01` Anexo B | ReClub Card (4 niveles · 3 capas · cashback cruzado · co-branding) | Caso piloto · usar como referencia funcional |

---

## 5. Preguntas explícitas al equipo de desarrollo (qué pedimos que respondan)

El equipo dev debe responder formalmente a las siguientes preguntas en su respuesta al RFI:

### 5.1 Capacidades actuales

- **P1.** ¿Cuál es el modelo de datos actual de membresías? ¿Soporta el modelo Afiliación + Membresía individual descrito en §3.2 o requiere refactor?
- **P2.** ¿Cuál es el modelo de datos actual de puntos (Rally 2)? ¿Es por comunidad o global? ¿Soporta múltiples fuentes y formas de redención configurables sin código?
- **P3.** ¿La arquitectura es genuinamente multi-tenant (datos aislados por tenant) o single-tenant con casos de uso? Si lo segundo, ¿qué requiere refactor a multi-tenant?
- **P4.** ¿Qué pasarelas de pago están integradas hoy? ¿Cuáles falta integrar para Bancard PY, Mercado Pago LATAM, pasarelas mexicanas (Conekta · MIT · OpenPay) para el caso sindical?
- **P5.** ¿Qué capacidad de carga (usuarios concurrentes) soporta la infraestructura actual? ¿A qué costo de infra escala a 100K · 500K · 1M usuarios?

### 5.2 Propuesta para construir lo que falta

- **P6.** Para la **capa de Afiliación + Tarjeta de Marca Privada con co-branding** (§3.2 + §3.3): ¿cuál es la propuesta técnica? ¿Cuánto esfuerzo (personas-sprint)? ¿Qué plazo?
- **P7.** Para el **sistema de puntos extendido** (§3.4): ¿cómo se extiende Rally 2 o se reescribe? ¿Cómo se garantiza el contable de "deuda" de puntos emitidos?
- **P8.** Para la **app del comercio** (§3.6): ¿PWA o nativa? ¿Qué SDK de cámara/escaneo? ¿Cuánto esfuerzo? ¿Costo de mantenimiento?
- **P9.** Para **transacciones mixtas (puntos + dinero)** (§3.5.3): ¿cómo se modela el split de pago? ¿La pasarela soporta nativamente o se construye lógica de orquestación?
- **P10.** Para **multi-tenancy a escala 1M usuarios** (§3.7): ¿cuál es la arquitectura propuesta? ¿Bases de datos separadas por tenant? ¿Schema-based? ¿Row-level security? Tradeoffs.

### 5.3 Estimación y plazos

- **P11.** Estimación de esfuerzo total del sprint (en personas-sprint o personas-mes) discriminado por capability.
- **P12.** Plazo calendario sugerido (sprint plan tentativo · hitos verificables).
- **P13.** Equipo propuesto (composición · perfiles · seniority · si se necesita sumar programador adicional al equipo interno actual, justificarlo).
- **P14.** Necesidades de infraestructura y servicios externos (hosting · APIs · SDKs · licencias técnicas).

### 5.4 Riesgos y dependencias

- **P15.** ¿Qué riesgos técnicos identifica el equipo dev?
- **P16.** ¿Qué dependencias externas requiere (proveedores · APIs · acuerdos · compliance)?
- **P17.** ¿Qué información o decisiones necesita de Victor / producto antes de iniciar?

### 5.5 Stack y tecnología

- **P18.** Stack tecnológico propuesto (frontend · backend · DB · cache · queue · search · storage · CDN · IA).
- **P19.** Estándares de seguridad propuestos (encriptación · auth · 2FA · GDPR-equivalent · auditoría).
- **P20.** Plan de testing (unit · integration · load · security · UAT).
- **P21.** Plan de monitoring y observabilidad (logs · métricas · alertas · APM).

---

## 6. Criterios de evaluación de la respuesta al RFI

Victor + Jay revisarán la respuesta del equipo interno con los siguientes criterios (en orden de prioridad):

| # | Criterio | Peso sugerido |
|---|---|---|
| 1 | **Comprensión del modelo Afiliación + Membresía + Tarjeta + Puntos multi-tenant** | 30% |
| 2 | **Propuesta de arquitectura escalable** a 1M usuarios | 20% |
| 3 | **Realismo de plazos y esfuerzo** estimado | 20% |
| 4 | **Compatibilidad con el stack actual** (TribusRRHH Rally 2 en producción · no romper lo que opera) | 10% |
| 5 | **Capacidad de mantener y operar** post-lanzamiento con el equipo actual (o justificación de programador adicional) | 10% |
| 6 | **Documentación y procesos** (calidad · transparencia · gobernanza) | 10% |

---

## 7. Plazo y formato de respuesta

### 7.1 Plazo
**3 días hábiles** desde la fecha de envío de este RFI.

### 7.2 Formato esperado
Documento estructurado (PDF o Markdown preferentemente) que responda **explícitamente** a las preguntas P1-P21 de §5.



### 7.4 Documentos adjuntos sugeridos.
- Diagrama de arquitectura propuesto.
- Plan de sprints tentativo.

---

## 8. Cross-references (documentos técnicos y funcionales)

> *Esta sección lista solo documentación relevante para el equipo de desarrollo. Documentación comercial, financiera y estratégica está fuera del alcance de este RFI.*

- **Junta de origen:** Junta Prog 3jun26 (minuta subida 2026-06-03)
- **Plan de desarrollo base:** [[PLAN-EL-DesarrolloPlataformaComunidades-v01]]
- **Análisis competitivo TDU (modelo referencia técnico-funcional):** [[DC-IS-AnalisisCompetitivo-TDU-MarketplaceColaborativo-v02]]
- **Spec registro/perfil Rebelocity:** [[SPEC-REB-RClub-ArquitecturaDatos-RegistroPerfil-v01]]
- **Spec directorio miembros Rebelocity:** [[SPEC-REB-RClub-DirectorioMiembros-v02]]
- **Sistema de puntos en producción TriRH:** [[PLAN-TriRH-Rally2-Gamificacion-v02]]
- **Anexo B Plan Rebelocity (ReClub Card como caso piloto funcional):** [[DC-REB-RebelocityClub-PlanEstrategico-v01]]
- **TP del room marketplace deportivo (contexto funcional):** [[TP-REB-RebClub-MarketplaceDeportivo-IdeacionGTM-v01]]
- **XDoc Loop sindical mexicano (contexto de escala):** [[XD-EL-Loop-HiOrg-MarketplaceColaborativo-v01]]

---

## 9. Glosario

| Término | Definición |
|---|---|
| **Plataforma** | La Plataforma de Comunidades Colaborativas de EmpowerLabs (13 módulos) |
| **Comunidad** | Tenant de la plataforma (Rebelocity Club, TribusRRHH, Marketplace Sindical, etc.) |
| **Empresa Afiliada** | Organización paraguas (empresa, club, sindicato, asociación, iglesia, federación, embajada) que afilia miembros |
| **Miembro** | Usuario personal (puede ser afiliado por una Empresa o independiente) |
| **Comercio / Proveedor** | Entidad que ofrece productos/servicios — vendedor en el marketplace |
| **Afiliación** | Contrato organizacional entre Empresa Afiliada y la Comunidad |
| **Membresía** | Nivel individual del Miembro (Básica · Oro · Platinum o equivalente) |
| **Tarjeta de Marca Privada** | Tarjeta digital + opcional física del miembro · puede tener co-branding |
| **Co-branding** | Tarjeta con doble logo: el de la Comunidad + el de la Empresa Afiliada |
| **Wallet del miembro** | Vista que agrupa tarjeta(s) + saldo de puntos + histórico |
| **Monedero electrónico** | Sistema de puntos del miembro · no retirable a banco · solo redimible en ecosistema |
| **App del comercio** | Aplicación para que el comercio escanee QR del miembro y registre transacción presencial |
| **Yield management** | Descuentos dinámicos por hora/día/anticipación (corrige deficiencia TDU) |
| **Cashback cruzado** | Modelo donde el miembro recibe % de su gasto como puntos redimibles solo dentro del ecosistema |
| **Multi-tenancy** | Capacidad de la plataforma de operar múltiples Comunidades aisladas en paralelo |
| **MPI** | Master Playbook Inteligente (capability ya existente) |
| **Sherpa / KatIA** | Asistentes IA integrados (ya operativos) |

---

## 10. Anexo — Decisiones que NO obstruyen la respuesta al RFI

Las siguientes decisiones son responsabilidad de Victor + producto/comercial y se resolverán en paralelo a la implementación. **No deben bloquear** la propuesta técnica del equipo dev — el sistema debe soportar la mecánica · los valores se configuran por administrador de comunidad cuando estén definidos.

- [ ] Naming definitivo de la tarjeta por comunidad (ReClub Card · TriRH Card · pendiente sindical mexicano)
- [ ] Valores configurables por comunidad (todos a definir fuera de este RFI):
  - Pricing de niveles (Básica · Oro · Platinum)
  - Tasa de conversión puntos → equivalente monetario
  - Porcentajes de cashback por nivel y categoría
  - Caducidad de puntos
  - Porcentajes de comisión por tipo de transacción
- [ ] Partner para tarjeta física (proveedor de impresión)
- [ ] Partner insurtech para Capa Protección del ReClub Elite
- [ ] Estructura legal y fiscal del programa de puntos (cada país)
- [ ] Naming convención definitiva para identificadores de tarjeta (REB-2-AR01-005678 es propuesta)
- [ ] Reglas anti-fraude específicas (caps · validaciones · etc.)

---

## 11. Changelog

- **2026-06-03 · v01** — Primer release del RFI (Request for Implementation interno). Integra: (a) decisiones de la Junta de Programación 2026-06-03 (capa Afiliación + capa Membresía individual · QR digital · co-branding · puntos modelo airline), (b) inventario completo del vault sobre la Plataforma de Comunidades Colaborativas (13 módulos canónicos + 6 specs ya producidas + Rally 2 en producción TribusRRHH), (c) caso piloto ReClub Card del Anexo B Plan Rebelocity, (d) análisis competitivo TDU como referencia comparativa funcional, (e) escala objetivo agregada de 1M usuarios para horizonte 36 meses (driver: marketplace sindical mexicano 800K empleados potenciales). Documento transversal a Rebelocity Club + TribusRRHH + Marketplace Sindical Mexicano. **Ajustes 2026-06-03 (mismo día):** (i) naming "RebelClub" → "ReClub" global, (ii) RFI redefinido como Request for Implementation (solicitud interna · NO licitación a terceros), (iii) destinatario explícito = equipo interno EmpowerLabs (con posibilidad de sumar programador adicional si fuera necesario), (iv) eliminada toda referencia a información financiera del proyecto (pricing membresías, comisiones, ROI · queda solo la mecánica técnica configurable), (v) plazo respuesta ajustado a 3 días hábiles. **Pendiente:** envío al equipo de desarrollo · evaluación de respuesta.

---

*Request for Implementation · Plataforma de Comunidades Colaborativas · EmpowerLabs · 2026-06-03*  
*Owner: Victor Heredia · Sherpa técnico: Jay · IntelliBank: IB-EL-EmpowerLabs / PB-EL-Plataforma*  
*Audiencia: Equipo de desarrollo interno EmpowerLabs (con posibilidad de sumar programador adicional)*