--- type: PLAN asset_id: PLAN-EL-DesarrolloPlataformaComunidades-v01 version: v01 status: Draft owner: Victor Heredia sherpa_owner: Jay fecha_creacion: 2026-06-01 fecha_ultima_actualizacion: 2026-06-01 intellbank: IB-EL-EmpowerLabs subbank: PB-EL-Plataforma tipo_largo: Plan de Desarrollo — Plataforma de Comunidades Colaborativas (Sprint de lanzamiento) audiencia: Equipo de desarrollo (interno EmpowerLabs + partner técnico tipo OneRocket) proposito: Instrucciones de desarrollo para que el equipo retome y revise capabilities críticas de la plataforma de comunidades colaborativas — sistema de puntos, tarjeta de marca privada, tracking comercial, sistema de tiendas en 3 niveles, eventos + venta de boletos, sistema de banners. La plataforma ya está construida y operando (TribusRRHH); este sprint la prepara para lanzamiento formal de comunidades (Rebelocity Club piloto · IntegraSalud · marketplace sindical Michel/Agustín). referencias_canonicas: - Plataforma Comunidades Colaborativas (documento conceptual) — 13 módulos canónicos - DC-IS-AnalisisCompetitivo-TDU-MarketplaceColaborativo-v02 (modelo de monedero electrónico + cashback) - DC-REB-RebelocityClub-PlanEstrategico-v01 + Anexo B (RebelClub Card como caso piloto de tarjeta de marca privada) - VR-REB-MercadoDeportivoPY-v01 (catálogo de proveedores PY) - TP-REB-RebClub-MarketplaceDeportivo-IdeacionGTM-v01 (§3.5 enumera los 13 módulos) - PLAN-TriRH-Rally2-Gamificacion-v02 (sistema de puntos en producción TribusRRHH) - XD-EL-Loop-HiOrg-MarketplaceColaborativo-v01 (caso sindical mexicano paralelo) --- # PLAN · Desarrollo de la Plataforma de Comunidades Colaborativas ## Sprint de lanzamiento formal — instrucciones para el equipo de desarrollo --- ## 0. Contexto ### 0.1 De dónde venimos La **Plataforma de Comunidades Colaborativas** de EmpowerLabs está construida y operando. Tiene los **13 módulos canónicos** documentados (News Engine · Librería+MasterPlaybooks · Foros · Directorio+Perfiles · Marketplace B2B/B2C · Campus · Gamificación+Rallies · Clasificados · Empleos · Comunicación cruzada · Eventos+Calendario · Membresías multinivel · IA transversal). Hoy soporta TribusRRHH (Rally 2 con 8 misiones · 100 puntos · badges · leaderboard · Sherpa + KatIA) y es la base sobre la que arranca Rebelocity Club + IntegraSalud + el marketplace sindical Michel/Agustín. ### 0.2 A dónde vamos **Lanzamiento formal de las comunidades** con un producto ancla por comunidad: tarjeta de membresía con beneficios tangibles (estilo TDU/Capital People upgrade), sistema de puntos transaccional, tracking comercial real, eventos con venta de boletos, marketplace en tres niveles de proveedor y sistema de banners para sponsors. ### 0.3 A quién va dirigido este plan Equipo de desarrollo (interno EmpowerLabs + partner técnico tipo OneRocket). Es un **plan ejecutivo**, no un PRD línea por línea. Cubre: capabilities a revisar, criterios de éxito, dependencias, prioridades. Cada item numerado puede expandirse a su propio PRD/spec si el equipo dev lo requiere. ### 0.4 Principio rector La plataforma EmpowerLabs gana **por arquitectura, no por escala**. Cada capability debe corregir las 6 deficiencias estructurales del modelo TDU documentadas en el `DC-IS-AnalisisCompetitivo-TDU-MarketplaceColaborativo-v02`: ausencia de transaccionalidad, cero CRM, descuentos estáticos, sin comunidad, sin data de intención, sin fidelización vía cashback. Cada decisión del equipo dev debe verificarse contra este principio. --- ## 1. Estado actual de la plataforma — síntesis para el equipo dev ### 1.1 Módulos en producción confirmados | # | Módulo | Status | Caso de producción | |---|---|---|---| | 1 | News Engine | Operativo | TribusRRHH news + bienvenidas | | 2 | Librería + MasterPlaybooks | Operativo | Playbooks + MPIs · MasterSherpa integrado | | 3 | Foros | Operativo | TribusRRHH foros gremiales | | 4 | Directorio + Perfiles | Operativo | Perfiles profesionales con muro propio | | 5 | Marketplace B2B/B2C | **A REVISAR** | Existe pero requiere ajustes (item 1.22) | | 6 | Cursos + Campus virtual | Operativo | Microlearning + certificaciones | | 7 | Gamificación + Rallies | Operativo parcial | TribusRRHH Rally 2 · 100 puntos · badges · leaderboard. **Sistema de puntos requiere extensión** (item 1.21) | | 8 | Clasificados | Operativo | Tipo Craigslist por categorías | | 9 | Empleos | Operativo | LinkedIn interno con matching IA | | 10 | Comunicación cruzada | Operativo | Chat interno + mensajes empresa↔cliente | | 11 | Eventos + Calendario | **A REVISAR** | Existe pero venta de boletos requiere ajuste (item 1.22) | | 12 | Membresías multinivel | Operativo | Free / Pro / Premium / Enterprise | | 13 | IA transversal | Operativo | Sherpa + KatIA + automation | ### 1.2 Lo que NO existe todavía y este sprint produce - **Tarjeta de marca privada por comunidad** (1.21 + 1.23) — capability nueva, inspirada en TDU Capital People pero con upgrade tecnológico. - **Tracking de compras presenciales en comercio físico** (1.21 + 1.24) — vía app del comercio (modelo gasolinería con escaneo). - **Sistema de banners** (1.22 + 1.27) — para sponsors y categorías. - **Tres niveles de tienda** (1.22) — Directorio · Eventos · Eventos+Tienda full. - **Sistema de referidos con puntos** (1.26) — incorporado al sistema de puntos como event source. - **Visualización transparente de movimientos del monedero/puntos** para el usuario y para el comercio (1.21 + 1.24). --- ## 2. Objetivos del sprint de desarrollo Al cierre de este sprint, **una comunidad cualquiera** (Rebelocity Club como caso piloto, o IntegraSalud/marketplace sindical en paralelo) debe poder: 1. **Lanzarse formalmente al público** con un producto comercial coherente: tarjeta de membresía con beneficios tangibles + marketplace funcional + eventos con boletos. 2. **Emitir su propia tarjeta de marca privada** (digital + física opcional) ligada a un sistema de puntos y monedero electrónico. 3. **Acreditar compras presenciales en comercios** vía app del comercio (no solo compras online). 4. **Vender boletos de eventos propios** desde la propia plataforma sin depender de Eventrid/Cronocheck externos. 5. **Generar puntos** por cada transacción interna (boletos, marketplace, suscripciones premium, contenido) **y** por compras externas registradas por el comercio **y** por referidos. 6. **Mostrar al comercio un panel** con compras realizadas con tarjeta, perfil de comprador, recurrencia. 7. **Ofrecer 3 niveles de tienda a proveedores** con feature set distinto. 8. **Vender banners y patrocinios** dentro de la plataforma como activo publicitario. --- ## 3. Inventario de capabilities a revisar y desarrollar (items numerados) ### **1.21 — Sistema de puntos + Tarjeta de marca privada de la comunidad** ★ > *Texto original del brief: Revisar status de sistema de puntos. Abrir la posibilidad de ligar a una tarjeta de marca privada de la comunidad. Debe incluir un app por parte del comercio donde se haga la compra. Incluir un sistema que permita visualizar las compras o uso de la tarjeta.* #### 1.21.1 Auditoría del sistema de puntos actual El equipo dev debe producir un **reporte de status (1-3 pp)** que responda: - ¿Cuál es el modelo de datos actual de "puntos" en TribusRRHH (Rally 2)? ¿Tabla única, tabla por usuario, tabla de eventos? - ¿Es un sistema **por comunidad** (multi-tenant) o **global** (un solo wallet por usuario en toda la plataforma EmpowerLabs)? - ¿Existe API de "ganar puntos" / "gastar puntos" / "consultar balance"? - ¿Se pueden definir reglas de adquisición de puntos por administrador de comunidad (sin tocar código)? - ¿Hay reportes/dashboards de puntos por comunidad, por usuario, por fuente de adquisición? **Decisión técnica que el equipo dev debe proponer y validar con Victor:** modelo *single wallet global por usuario* (puntos transferibles entre comunidades del ecosistema) vs *wallet por comunidad* (puntos solo redimibles en la comunidad que los emitió). Recomendación inicial: **wallet por comunidad** (más simple, evita arbitraje entre productos, alineado al cashback cruzado del análisis competitivo TDU). #### 1.21.2 Extensión del sistema de puntos — fuentes de adquisición El sistema debe permitir configurar (sin tocar código, vía panel admin de la comunidad) **al menos las siguientes fuentes de adquisición de puntos**: | Fuente | Trigger | Configurable por admin | |---|---|---| | 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 (Pro/Elite/Corporate) | Pago de membresía | Sí — multiplicador anual o mensual | | **Compra registrada por comercio físico** | App del comercio escanea/registra (ver 1.24) | Sí — % por comercio, por categoría, por hora/día | | **Referido de nuevo miembro** | Nuevo usuario se registra con código de referido + completa primer hito (compra, evento, etc.) | Sí — puntos por referido + puntos por hito completado | | Participación en eventos | Asistencia confirmada (check-in en evento) | Sí — puntos por evento | | Completar misiones / rallies (gamificación existente Rally 2) | Misión completada | Sí — ya existe en TribusRRHH | | Generar contenido (post en foro, review de proveedor, etc.) | Acción registrada | Sí — anti-spam con cap diario | | Reto cumplido (entrenamiento, curso, etc.) | Validación por sistema o moderador | Sí — depende del producto | **Anti-abuso requerido:** caps diarios/semanales · validación de referidos (no auto-referido · misma IP/dispositivo · fraude detection básico). #### 1.21.3 Redención de puntos Sistema debe permitir configurar **al menos las siguientes formas de redención**: - Descuento en compra de boletos de eventos. - Descuento o saldo en compras de marketplace. - Upgrade de nivel de tarjeta (Free → Pro · Pro → Elite) con conversión configurable (ej: 50.000 puntos = 1 año de upgrade). - Conversión a cupones físicos en comercios participantes (ver 1.24). - Redención por MPIs premium / contenido / experiencias. - Donaciones a causas sociales del ecosistema (con tracking). **Regla central:** los puntos **no son retirables a banco**. Solo se redimen dentro del ecosistema. Esto es la lógica del monedero electrónico TDU-upgrade del análisis competitivo. #### 1.21.4 Tarjeta de marca privada — emisión y vinculación Capability nueva. Permite que **una comunidad** (Rebelocity Club, IntegraSalud, marketplace sindical) **emita su propia tarjeta** con: - **Branding personalizable** (logo + colores + nombre — ej: "RebelClub Card" para Rebelocity). - **Niveles configurables por comunidad** (Free · Pro · Elite · Corporate · admite renombrado). - **Versión digital obligatoria** (en app móvil + web · QR único persistente por usuario). - **Versión física opcional** (impresión por tercero · branding + número + QR · activación por usuario). - **Vinculación 1:1 con el wallet de puntos** del usuario en esa comunidad. - **Vinculación 1:1 con la membresía** del usuario (la tarjeta refleja el nivel actual). - **Caducidad y renovación** configurable por nivel. **Caso piloto del sprint:** **RebelClub Card** (Rebelocity Club) según especificación en `Anexo B del DC-REB-RebelocityClub-PlanEstrategico-v01`. El equipo dev debe poder reusar la misma capability para emitir tarjetas de IntegraSalud y del marketplace sindical Michel/Agustín cambiando solo configuración. #### 1.21.5 Visualización para el usuario App + Web deben mostrar al usuario: - Saldo actual de puntos. - Histórico de movimientos (ganados / gastados / caducados) con fuente declarada y fecha. - Próximas redenciones disponibles según su saldo (ofertas, descuentos, upgrades). - QR único de su tarjeta para presentar en comercio. - Beneficios activos de su nivel de tarjeta. --- ### **1.22 — Sistema de tiendas con 3 niveles + Eventos + Boletos + Banners** ★ > *Texto original del brief: Checar que funcionan bien las tiendas. Ideal tener 3 niveles: Solo directorio · Eventos · Eventos y tienda (full). Checar que se pueden crear eventos. Checar si se puede vender boletos. Revisar el sistema de banners.* #### 1.22.1 Niveles de tienda — definición funcional | Nivel | Nombre canónico | Features incluidos | Audiencia / pricing tentativo | |---|---|---|---| | **Nivel 1** | **Directorio** | Perfil de proveedor · datos básicos (logo, descripción, contacto, ubicación, redes) · presencia en buscador de la comunidad · 1 categoría primaria · sin transacción | Free o pricing mínimo (USD 0-30/mes). Onramp para captar inventario. | | **Nivel 2** | **Eventos** | Todo Nivel 1 · capability de **crear y publicar eventos** propios · venta de boletos a través de la plataforma · check-in en evento · descuentos a tarjetahabientes · banners en zona del proveedor | Pro (USD 30-80/mes). Para organizadores de eventos (clubes deportivos, gimnasios, productores) | | **Nivel 3** | **Eventos + Tienda (Full)** | Todo Nivel 2 · **tienda transaccional completa** (catálogo productos/servicios · carrito · pago · gestión de inventario) · **dashboard CRM** (compradores, recurrencia, ticket promedio) · **yield management** (descuentos dinámicos) · **MPIs propios** (patrocinio de Master Playbooks Inteligentes) · banners premium · lead generation con perfil de intención | Premium (USD 200-500/mes). Marcas, distribuidores, sponsors. | **Cross-cutting:** los 3 niveles deben poder convivir en una misma comunidad simultáneamente. El admin de la comunidad puede subir/bajar un proveedor de nivel desde panel. #### 1.22.2 Capability "Creación de eventos" (todos los niveles 2 y 3) El proveedor debe poder crear un evento con: - Nombre · descripción · imagen de portada · galería. - Fecha(s) · hora · ubicación geográfica (con mapa). - **Modalidades / categorías de boleto** (ej: 5K · 10K · 21K · 42K · Early bird · General · Elite · Corporativo). Mínimo 5 tipos configurables, ideal ilimitado. - **Cupos por modalidad** + cupos totales del evento. - **Pricing por modalidad** + **descuentos para tarjetahabientes** + **early bird con fechas de corte**. - **Información del kit / qué incluye / qué entregamos al inscrito**. - **Política de cancelación / reembolso**. - **Formulario de inscripción personalizable** (campos: edad, sexo, talla de remera, contacto emergencia, club, condiciones médicas, etc.). - **Régimen de puntos** del evento (cuántos puntos genera la compra de boleto · cuántos por check-in · cuántos por completar el evento). - **Promotores afiliados** (capability de referidos del evento — cada promotor recibe link único + comisión por venta). - **Estado del evento** (borrador / publicado / agotado / cerrado / cancelado). #### 1.22.3 Capability "Venta de boletos" (todos los niveles 2 y 3) El sistema debe procesar la compra del boleto **dentro de la plataforma**: - **Pasarela de pago** integrada — Bancard (PY) + alternativas regionales (Mercado Pago, Stripe LATAM). El sistema debe soportar **múltiples pasarelas configurables por comunidad** (cada comunidad puede usar la que prefiera o la disponible en su país). - **Comisión configurable de plataforma** por evento o por comunidad (tentativa: 6-10% sobre valor del ticket — compite con Eventrid ~10%). - **Confirmación de compra** vía email + push notification + entrada en el wallet de tarjeta del usuario. - **Boleto digital** con QR único por boleto (no transferible salvo configuración). - **Asignación automática de puntos** al monedero del comprador según regla configurada. - **Reembolsos** procesables por admin de la comunidad o admin del evento. - **Reportes para el organizador**: inscritos · revenue · breakdown por modalidad · proyecciones · contactos descargables. - **Reporte para el comprador**: histórico de boletos comprados · próximos eventos. #### 1.22.4 Capability "Check-in en evento" - **App del organizador / staff** con escaneo de QR para check-in masivo. - **Reporte en vivo** de asistencia (% del cupo presente · faltantes). - **Trigger automático** de puntos por asistencia (configurable por evento). - Capability complementaria a la app del comercio (ver 1.24) — puede ser la misma app con permisos distintos. #### 1.22.5 Sistema de banners Capability publicitaria dentro de la comunidad: **Tipos de banner:** - **Banner principal de home** (rotativo · top 3 sponsors visibles · alta visibilidad). - **Banner lateral** (categorización por contexto · ej: banner de Specialized cuando el usuario está navegando MPI de "Mi primer L'Étape"). - **Banner contextual** dentro de tiendas / eventos (sponsor de la tienda · sponsor del evento). - **Banner en news/contenido** (sponsor de la sección editorial). - **Banner en email/newsletter** (alcance push + persistente). **Capabilities requeridas:** - **Calendario de campañas** con start/end date. - **Segmentación de audiencia** por nivel de tarjeta · por geografía · por intereses (disciplinas / categorías). - **Reportes de impresiones, clics, CTR** para el sponsor. - **Marketplace de banners** (auto-servicio para sponsors de Nivel 3 que pueden comprar banner directamente). - **Aprobación admin** antes de publicación. - **Pricing por slot** configurable. --- ### **1.23 — Capability transversal: Multi-tenant por comunidad** Esto no aparece como item explícito en el brief pero es **dependencia técnica de todo lo anterior**. La misma plataforma debe operar **múltiples comunidades aisladas** simultáneamente: - Rebelocity Club (deportes endurance Paraguay/LATAM) - Tribus RRHH (RRHH Paraguay) - IntegraSalud / marketplace sindical (México · Michel + Agustín) - N comunidades futuras Cada comunidad debe tener: - Branding propio (logo, colores, dominio o subdominio). - Catálogo de proveedores propio. - Tarjeta de marca privada propia. - Reglas de puntos propias. - Sistema de banners propio. - Usuarios pueden pertenecer a varias comunidades con perfil compartido pero wallet/tarjeta por comunidad. **Action item dev:** confirmar arquitectura multi-tenant actual. Si está construido como single-tenant con casos de uso, escalar a multi-tenant antes del lanzamiento formal. --- ### **1.24 — App del comercio para tracking de compras presenciales** ★ (deriva del brief 1.21) > *Texto original: "Debe incluir un app por parte del comercio donde se haga la compra. Incluir un sistema que permita visualizar las compras o uso de la tarjeta."* Es la capability **más diferenciada del sistema** vs TDU. #### 1.24.1 Concepto Cuando un tarjetahabiente entra a un comercio afiliado (ej: una tienda de bicicletas, un gimnasio, una farmacia deportiva, un fisio), el comercio puede **registrar la compra del cliente** vía app o tablet del comercio. El registro: - Acredita puntos al monedero del cliente. - Genera record para el dashboard CRM del comercio. - Genera dato de intención para el ecosistema (categoría de gasto · ticket · recurrencia). - Aplica descuento o cashback automáticamente. Es el modelo "gasolinería con tarjeta de puntos" pero con upgrade tecnológico: el comercio recibe valor (CRM + data) en lugar de absorber descuento. #### 1.24.2 Flujo de usuario (lado comercio) 1. Comerciante abre app/web "Comercio EmpowerLabs" en su dispositivo (tablet o smartphone). 2. Login con credenciales del comercio (multi-usuario · admin del comercio + cajeros). 3. Pantalla principal: "Registrar compra". 4. Cliente muestra QR de su tarjeta · comerciante escanea (cámara) o ingresa código manual. 5. Sistema reconoce al cliente · muestra: nombre · nivel de tarjeta · saldo de puntos actual · descuento o cashback aplicable. 6. Comerciante ingresa monto de compra + categoría (configurable por comercio · ej: "Bicicleta", "Accesorios", "Servicio mecánico"). 7. Sistema calcula: - Puntos ganados (% configurado). - Cashback al monedero (si aplica). - Descuento aplicado al ticket (si la tarjeta lo prevé). 8. Cliente recibe push notification + email de confirmación. 9. Record queda en dashboard del comercio. #### 1.24.3 Flujo de usuario (lado cliente) 1. Cliente entra al comercio · ya tiene la tarjeta digital activa. 2. Antes de pagar, abre app de la comunidad → tab "Mi Tarjeta" → muestra QR. 3. Comerciante escanea (paso 4 del flujo comercio). 4. Cliente paga normalmente en caja (efectivo · tarjeta de crédito · transferencia · lo que sea — **el flujo de puntos es independiente del flujo de pago**). 5. Cliente ve confirmación de puntos ganados en su app + saldo actualizado. **Nota clave:** la app del comercio **NO procesa el pago monetario** (eso lo sigue haciendo el POS del comercio o efectivo). La app solo **registra la compra para efectos de puntos + cashback + CRM**. Esto reduce fricción y compliance (no somos pasarela de pago presencial — somos sistema de lealtad y CRM). #### 1.24.4 Dashboard del comercio El comercio debe ver en su panel: - **Compras del día / semana / mes** registradas con tarjeta. - **Top clientes** (por frecuencia · por ticket promedio · por gasto total). - **Perfil agregado** de la base de tarjetahabientes que lo visitan (disciplina · nivel · geografía · edad). - **Tendencias** de gasto por categoría. - **Comparativo** vs benchmarks del ecosistema (¿mi ticket promedio está arriba o abajo del promedio de tiendas similares?). - **Campañas activas** del comercio (ej: cashback 2x los martes). - **Descarga** de base de contactos en formato CSV (con consentimiento del usuario para ser contactado). #### 1.24.5 Modelo de cobro al comercio por esta capability A definir con producto. Opciones que el equipo dev debe poder 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). --- ### **1.25 — Sistema de referidos con puntos** (deriva del brief) > *Texto original: "Y que la gente pueda ganar puntos por ejemplo por recomendar miembros."* Es subcapability del sistema de puntos (1.21) pero merece spec propio. #### 1.25.1 Funcionalidad Cada usuario tiene un **código de referido único** + link compartible. Cuando un nuevo usuario se registra usando ese código: - El referidor recibe X puntos al instante (configurable · ej: 100 puntos). - El nuevo usuario recibe X puntos de bienvenida (configurable). - Cuando el nuevo usuario completa su **primer hito calificador** (compra de boleto · suscripción Premium · primera compra en marketplace), el referidor recibe puntos adicionales (configurable · ej: 500 puntos extra). #### 1.25.2 Anti-fraude - Caps por referidor (máximo N referidos premium por mes). - Validación de IP / dispositivo / método de pago (no permitir auto-referidos). - Histórico de referidos en perfil del usuario (transparencia + accountability). - Bloqueo de cuentas con patrones sospechosos. #### 1.25.3 Mecánica viral adicional (recomendada) - **Programa de embajadores** — tarjetahabientes con N referidos pueden upgrade a "Embajador" con beneficios (badge · % cashback elevado · acceso preferencial a eventos). - **Tableros de referidos** públicos · gamificación opcional. --- ### **1.26 — Actualizar vista de marketplace / tiendas** (deriva del brief) > *Texto original: "Actualizar la vista..."* Item de UI/UX. El equipo de producto + diseño debe: - **Auditar UX actual** del marketplace (en TribusRRHH y donde más esté en uso). - **Diseñar vista de comunidad** con secciones claras: Calendario · Marketplace (proveedores + niveles) · Eventos · Mi Tarjeta · Mi Comunidad (foros · perfiles). - **Mostrar diferenciadores por nivel** de proveedor (Nivel 3 con destaque visual · banners premium · etiqueta "Premium" o "Sponsor"). - **Filtros y búsqueda** por disciplina · categoría · geografía · descuento disponible · cashback elevado. - **Vista del proveedor (storefront propio)** con look-and-feel personalizable. - **Integración visual con sistema de banners** sin saturar UX. Entregable mínimo: **mockups de 4-6 pantallas clave** (home comunidad · marketplace listado · perfil de proveedor · evento individual · mi tarjeta · checkout boleto) validados con producto antes de pasar a desarrollo. --- ### **1.27 — Lanzar comunidades — Go-to-market técnico** (general del brief) > *Texto original: "Vamos ahora si a lanzar las comunidades"* Esto no es un feature, es un **estado de readiness** del producto. El equipo dev debe entregar: - **Checklist de readiness** de cada comunidad (Rebelocity Club piloto + IntegraSalud + Tribus RRHH refresh): - Branding personalizado completo - Catálogo inicial de proveedores cargado (mínimo 20-50 por comunidad) - Tarjeta de marca privada activa - Sistema de puntos calibrado con reglas configuradas - Eventos del calendario cargados (mínimo 10-20 eventos por comunidad) - Sistema de banners con primer slot vendido - Pasarela de pago activa y testeada - Compliance básico (Términos, Privacidad, datos personales) - Performance testeado (carga concurrente · tiempos de respuesta) - Monitoreo en producción (alertas · logs · métricas de uso) - **Plan de migración de TribusRRHH** al nuevo set de capabilities (sin perder el Rally 2 que ya está en producción). - **Plan de onboarding técnico** para nuevos clientes (qué configurar primero · qué cargar · cómo lanzar). --- ## 4. Decisiones técnicas y dependencias ### 4.1 Decisiones que el equipo dev debe presentar a Victor | # | Decisión | Recomendación inicial | Quién decide | |---|---|---|---| | D1 | Wallet de puntos: global vs por comunidad | Por comunidad (más simple · evita arbitraje) | Victor | | D2 | Arquitectura multi-tenant: confirmar status actual | Validar y reforzar antes del lanzamiento | Equipo dev + Victor | | D3 | Pasarela de pago — soportar múltiples por país | Bancard PY (Rebelocity) + Mercado Pago (regional) + Stripe (internacional) | Victor + producto | | D4 | App del comercio — nativa (iOS/Android) vs PWA | PWA primero · nativa fase 2 si volumen lo amerita | Equipo dev | | D5 | Tarjeta física — quién imprime y distribuye | Proveedor tercero por contrato (no construir capability propia) | Victor + ops | | D6 | Stack tecnológico actual — auditoría y go/no-go | Equipo dev produce reporte | Equipo dev | | D7 | Integración con Eventrid / Cronocheck (ticketing externo) — coexistir o reemplazar | Coexistir fase 1 (importar eventos vendidos en Eventrid · marcar como "external") · reemplazar fase 2 | Producto | | D8 | Anti-fraude para referidos — nivel de validación | Validación de IP + dispositivo + método de pago + caps mensuales | Equipo dev | | D9 | Notificaciones push — proveedor (Firebase / OneSignal / nativo) | A definir según costo y existing stack | Equipo dev | | D10 | Compliance datos personales — auditoría legal | Asesoría legal externa antes de lanzamiento formal | Victor + legal | ### 4.2 Dependencias críticas - **Compliance e-commerce PY** (Ley 4868 + Ley 7120 Mercosur) — pieza obligatoria para Rebelocity Club. - **Partnership pasarela de pago** (Bancard + Mercado Pago) — debe estar firmado antes del lanzamiento. - **Inventory de catálogo inicial** — Victor + Rodrigo cargan los primeros 20-50 proveedores Rebelocity (referencias en VR-REB-MercadoDeportivoPY-v01). - **Branding RebelClub Card** — naming, logo, identidad visual cerrada antes de imprimir tarjetas físicas. - **Insurtech partnership** (Capa Protección de RebelClub Elite) — sin esto, el Elite v0 sale sin la capa de seguros (degraded mode). --- ## 5. Roadmap sugerido — 4 sprints / 12 semanas > *Cronograma tentativo · el equipo dev debe validarlo contra capacidad real y proponer ajustes.* ### Sprint 1 (semanas 1-3) — Auditoría + extensión sistema de puntos - D6 — Auditoría stack tecnológico actual + reporte status. - 1.21.1 — Auditoría sistema de puntos TribusRRHH + reporte. - D1, D2 — Decisiones de arquitectura confirmadas. - 1.21.2 — Extender sistema de puntos con nuevas fuentes de adquisición. - 1.25 — Sistema de referidos básico (puntos por nuevo miembro registrado). - 1.23 — Confirmar / reforzar arquitectura multi-tenant. **Hito Sprint 1:** sistema de puntos opera para 3+ fuentes (compra boleto + compra marketplace + referido) en TribusRRHH como ambiente de prueba. ### Sprint 2 (semanas 4-6) — Tarjeta de marca privada + Capability tienda - 1.21.4 — Emisión de tarjeta de marca privada digital (QR único · vinculación con wallet + membresía). - 1.21.5 — Visualización para usuario (saldo · histórico · QR). - 1.22.1 — 3 niveles de tienda implementados (Directorio · Eventos · Eventos+Tienda full). - 1.26 — Vista actualizada del marketplace (UI/UX nuevos mockups → implementación). **Hito Sprint 2:** Rebelocity Club operable con RebelClub Card digital + marketplace en 3 niveles + nuevo UX. ### Sprint 3 (semanas 7-9) — Eventos + Boletos + App del comercio - 1.22.2 — Capability "Creación de eventos" completa. - 1.22.3 — Venta de boletos integrada con pasarela de pago. - 1.22.4 — Check-in en evento. - 1.24 — App del comercio (PWA) para tracking de compras presenciales. **Hito Sprint 3:** primer evento real de Rebelocity vendido en plataforma + primera tienda piloto registra compra de tarjetahabiente. ### Sprint 4 (semanas 10-12) — Banners + Hardening + Lanzamiento - 1.22.5 — Sistema de banners completo (5 tipos + segmentación + reportes). - 1.21.4 — Versión física de la tarjeta (impresión por tercero). - D7 — Integración con Eventrid (importar histórico). - 1.27 — Checklist de readiness para lanzamiento. - Hardening: performance · monitoring · alertas · compliance · datos personales. **Hito Sprint 4:** **Lanzamiento formal** de Rebelocity Club + tarjeta física disponible + sistema de banners activo + primer Sponsor de Categoría con campaña pagada en plataforma. ### Pos-lanzamiento (semanas 13+) — Refresh TriRH + IntegraSalud onboarding - Migrar TriRH al nuevo set de capabilities (cuidando no romper Rally 2 en producción). - Onboarding técnico de IntegraSalud + marketplace sindical (Michel/Agustín) en paralelo. - Capa Protección de RebelClub Elite (partnership insurtech) si está listo. - White-label Corporate (Fase 2 RebelClub Card) para clubes ancla. --- ## 6. Criterios de éxito del sprint Al cierre del sprint completo (12 semanas), debe ser cierto que: - [ ] **Cualquier comunidad** del ecosistema EmpowerLabs puede emitir su propia tarjeta de marca privada en menos de 1 día de configuración (no de desarrollo). - [ ] El **sistema de puntos** opera con al menos 7 fuentes de adquisición distintas configurables sin código. - [ ] **Referidos** generan puntos validados y anti-fraude opera. - [ ] **3 niveles de tienda** están claramente diferenciados y un proveedor puede subir/bajar de nivel con un click admin. - [ ] **Un organizador** puede crear un evento, configurar 5+ modalidades de boleto, y vender boletos en la plataforma con pasarela activa. - [ ] **Una tienda física** puede usar la app del comercio para registrar una compra presencial de un tarjetahabiente en menos de 30 segundos. - [ ] **Un sponsor** puede comprar un banner en la plataforma desde un panel de auto-servicio y ver impresiones/CTR en su dashboard. - [ ] **Rebelocity Club está formalmente lanzado** con catálogo inicial cargado, tarjeta activa, mínimo 10 eventos vendiendo boletos y mínimo 1 Sponsor de Categoría pagando. - [ ] **Tribus RRHH** sigue operando sin regresiones (Rally 2 vivo). - [ ] **Performance verificado** bajo carga (mínimo 1.000 usuarios concurrentes sin degradación visible). - [ ] **Compliance básico cerrado** (Términos, Privacidad, datos personales · Ley 4868 + Mercosur). --- ## 7. NEXTs declarados - [NEXT][Equipo dev] Producir auditoría de status (1-3 pp) del sistema de puntos actual (1.21.1) en semana 1. - [NEXT][Equipo dev] Producir auditoría de stack tecnológico + propuesta arquitectura multi-tenant (D6 + D2) en semana 1. - [NEXT][Producto + Diseño] Producir mockups de las 4-6 pantallas clave (1.26) en semana 1-2 para validación con Victor antes de Sprint 2. - [NEXT][Victor + Rodrigo] Cargar catálogo inicial de 20-50 proveedores Rebelocity Club desde lista del VR-REB-MercadoDeportivoPY-v01. - [NEXT][Victor] Confirmar pasarelas de pago a soportar fase 1 (recomendación: Bancard PY + Mercado Pago LATAM + Stripe internacional). - [NEXT][Victor] Identificar 2-3 candidatos insurtech para Capa Protección RebelClub Elite (puede correr en paralelo al sprint dev). - [NEXT][Victor + Producto] Definir naming definitivo de la tarjeta (RebelClub Card es temporal). - [NEXT][Equipo dev] Proponer cronograma firme con capacidades del equipo (4 sprints · 12 semanas es tentativo). - [NEXT][Jay] Si el equipo dev lo solicita, producir PRD detallado por capability (item por item — uno a la vez según prioridad). - [NEXT][Legal] Asesoría externa para compliance datos personales + términos plataforma + pasarela. --- ## 8. Cross-references - **Documento conceptual de la plataforma:** Plataforma Comunidades Colaborativas (13 módulos canónicos · subido al chat 2026-06-01) - **Análisis competitivo origen del modelo de tarjeta + monedero:** [[DC-IS-AnalisisCompetitivo-TDU-MarketplaceColaborativo-v02]] - **Plan estratégico Rebelocity (Anexo B con RebelClub Card):** [[DC-REB-RebelocityClub-PlanEstrategico-v01]] - **VR mercado deportivo PY (catálogo de proveedores):** [[VR-REB-MercadoDeportivoPY-v01]] - **TP del room marketplace deportivo (13 módulos enumerados):** [[TP-REB-RebClub-MarketplaceDeportivo-IdeacionGTM-v01]] - **Sistema de puntos en producción TribusRRHH:** [[PLAN-TriRH-Rally2-Gamificacion-v02]] - **XDoc Loop marketplace sindical (caso México paralelo):** [[XD-EL-Loop-HiOrg-MarketplaceColaborativo-v01]] --- ## 9. Changelog - **2026-06-01 · v01** — Primer release del Plan de Desarrollo de la Plataforma de Comunidades Colaborativas. Producido sobre la base del documento conceptual de los 13 módulos + análisis competitivo TDU + Anexo B del Plan Estratégico Rebelocity + auditoría de inventario actual (TribusRRHH Rally 2 en producción). Numeración 1.X mantenida según convención del brief original de Victor (items 1.21 y 1.22 desarrollados; items 1.23-1.27 derivados del brief expandido). Cronograma tentativo 4 sprints · 12 semanas pendiente validación del equipo dev. --- *Plan de Desarrollo · Plataforma de Comunidades Colaborativas · EmpowerLabs · 2026-06-01* *Owner: Victor Heredia · Sherpa: Jay · IntelliBank: IB-EL-EmpowerLabs / PB-EL-Plataforma* *Audiencia: equipo de desarrollo (interno + partner técnico)*