--- type: PAP asset_id: PAP-HIORGS-ModeloProducto-Interno-v01 version: v01 status: Draft owner: Victor Heredia sherpa_owner: Jay fecha_creacion: 2026-05-20 fecha_ultima_actualizacion: 2026-05-20 fecha_migracion_bmf: 2026-05-20 intellbank: IB-EL-EmpowerLabs subbank: PB-EL-Project-Bank proposito: PAP · ModeloProducto Interno · IB-EL-EmpowerLabs nota_migracion: Frontmatter BMF agregado en batch masivo 2026-05-20 · Workbench FASE 5C · proposito pendiente revisión manual --- # PAP-HIORGS-ModeloProducto-Interno-v01 **Paper Interno — El Modelo Completo del Producto WORX OS** **Documento narrativo de uso interno EmpowerLabs y consultores certificados. No es activo cliente-facing. Es el documento que un facilitador abre antes de su primer Lab y sale entendiendo el sistema completo, no solo sus piezas.** --- | Campo | Valor | |---|---| | **Asset ID** | PAP-HIORGS-ModeloProducto-Interno-v01 | | **Tipo** | PAP — Paper (interno) | | **Audiencia** | Equipo EmpowerLabs + Sherpa Guides certificados externos + consultores en proceso de certificación | | **NO es** | Activo cliente-facing. No se entrega a prospectos ni a clientes. Para el cliente vive `PAP-HIORGS-GranReto-v01` (registro distinto). | | **Room** | PB-HiOrg — Hyperintelligent Org | | **IntelliBank** | IB-EL-EmpowerLabs | | **SubBank** | PB-EL-Project-Bank / PB-HiOrg-Hyperintelligent Org | | **Owner** | Victor Heredia | | **Sponsor** | Victor Heredia | | **Versión** | v01 | | **Fecha de creación** | 2026-04-25 | | **Última actualización** | 2026-04-25 | | **Estado** | Activo — v01 firme tras tripleta canónica | | **Continúa desde** | CP-HIORGS-Producto-Estrategia-v01 + CP-HIORGS-Producto-Catalogo-v01 + MPB-HIORGS-Replicacion-Playbook-v01 + CP-HIORGS-Solucion-Arquitectura-v01 + PAP-HIORGS-GranReto-v01 | | **Tags** | [paper, interno, modelo-de-producto, WORX OS, formacion-facilitadores, espiritu-del-producto] | --- ## Preámbulo — ¿Para quién es este paper? Este paper no se le da a un cliente. Se le da a alguien que va a *operar* el WORX OS. A un facilitador interno de EmpowerLabs antes de su primer Lab. A un Sherpa Guide externo que está cerrando su programa de certificación. A un consultor que va a integrarse al equipo y necesita el sistema entero, no la versión técnica fragmentada en tres canonical pieces y un masterplaybook. Quien va a operar el producto necesita más que el manual del producto. Necesita su *espíritu*. La razón por la que cada decisión está donde está. Lo que no se dice en los documentos canónicos pero es el aire que respira el sistema. Eso es lo que hace este paper. Si vienes de leer los documentos canónicos (CP-Estrategia, CP-Catálogo, MPB-Replicación), aquí no vas a encontrar mecánica nueva. Vas a encontrar cómo se conectan las piezas y por qué están donde están. Si todavía no los has leído, **léelos primero** — este paper asume que conoces el qué; trabaja sobre el *por qué*. --- ## I. Por qué existe el WORX OS ### 1.1 La pregunta que lo origina El WORX OS no nació como producto. Nació como respuesta a una pregunta que una directora general le hizo a Victor en una primera reunión: **"¿y qué me van a entregar?"** Esa pregunta condensa la frustración de cualquier cliente serio frente al mercado de "transformación con IA" hoy. Las consultoras tradicionales venden análisis. Los proveedores de plataformas venden módulos. Los gurús venden procesos. **Nadie entrega un sistema operativo organizacional que opere desde el día siguiente del primer pago.** El WORX OS existe porque esa entrega es posible — pero no como suma de piezas. Solo como sistema instalado. Y solo si quien lo instala entiende que está instalando un sistema operativo, no implementando un proyecto. ### 1.2 El problema canónico vive en otra parte Las **5 capas del problema organizacional en la era de la IA** — Parálisis IA, Sangrado invisible, Caos operacional, Carga sobre TI, Dimensión humana — están documentadas en el `PAP-HIORGS-GranReto-v01.md`. Ese paper es para el cliente. **Ahí no vamos a repetir lo que ya está dicho.** Lo que sí vale la pena marcar aquí: cada una de esas 5 capas existe en el cliente *antes* de que llegue EL. Lo que el WORX OS entrega no es "una solución". Es la **disolución simultánea de las 5 capas**. Por eso vendemos el bundle, no las piezas. Cada pilar resuelve unas capas y sostiene a los otros pilares en las suyas. Quitar un pilar deja capas sin atender. Esto se ve en la matriz 3×5 de la lámina 7 del deck. **Si un facilitador la entiende, entiende el sistema.** Si no la entiende, va a empujar a un cliente a comprar una capa suelta — y va a romper la promesa. ### 1.3 La era de la IA no es la era de la IA Vale la pena decirlo así, sin eufemismo. El WORX OS no es un producto sobre adopción de IA. **Es un producto sobre cómo operar una organización en un mundo donde la IA ya está presente en todas partes.** Esa diferencia es estructural. El cliente que compra "ayuda con IA" termina con pilotos. El cliente que compra "un nuevo modo de operar que tiene IA integrada" termina con un sistema. Lo segundo es lo que vendemos. Cuando un facilitador le dice a un cliente *"vamos a instalar tu nuevo sistema operativo organizacional, y la IA es un sustrato que lo hace posible, no la novedad"*, el cliente entiende. Cuando un facilitador empieza con *"vamos a ayudarte a adoptar IA"*, el cliente lo confunde con cualquier otro proveedor del mercado. La diferencia entre las dos frases es la diferencia entre vender el WORX OS y vender un servicio comoditizado. --- ## II. La filosofía operativa del producto ### 2.1 Equipo + proyecto vivo · la unidad irreductible La D-013 lo cerró: **la unidad mínima de transformación organizacional es un equipo concreto trabajando un proyecto concreto.** Ni el individuo, ni la empresa abstracta, ni el área funcional sin proyecto. Esto tiene una razón empírica de 10+ años de EmpowerLabs original: las transformaciones que se intentan a nivel "empresa" sin descender a equipos vivos fracasan. No porque el método sea malo. Porque no hay sustrato vivo donde aterrizar. Lo opuesto también es cierto: cuando un facilitador respeta la unidad equipo+proyecto, el método funciona casi automáticamente. Cuando la rompe — porque el cliente quiere "transformar el área entera" sin un proyecto específico, o quiere "que toda la empresa adopte" sin equipos asignados — el Lab se diluye y los entregables se vuelven blandos. **Para un facilitador, la regla operativa es:** *Si no encuentras el equipo y el proyecto, no arranques el Lab. Conversación correctiva primero.* Mejor un Lab pospuesto que un Lab sin sustrato. ### 2.2 Anti-pause · no se detiene la operación, se acelera Esta es la herencia personal de Victor de la primera era de EmpowerLabs y vive en cada conversación comercial: **el cliente no abandona ni pausa sus proyectos actuales para entrar al Lab.** El Lab los toma como sustrato. La frase que un facilitador debe poder decir con honestidad es: > *"Tus proyectos vivos son donde se instala el ecosistema. No te pedimos que pares para transformar — te pedimos que sigas, y nosotros instalamos sobre lo que ya está corriendo."* Esto es diferenciador estructural vs. consultoras tradicionales (Big 4) que sí piden pausa, redirección o "transformación" como evento separado de la operación. Un facilitador que olvide este principio cae en el modo consultoría tradicional sin notarlo. La señal: cuando un facilitador empieza a sugerir *"podríamos primero hacer un workshop de alineación"* sin ataque al proyecto vivo del equipo, está rompiendo el espíritu del WORX OS. ### 2.3 Instalación, no implementación Las palabras importan. El WORX OS **se instala**. No se implementa. Una implementación es lo que hace un proveedor de plataforma cuando configura su software para un cliente. Una instalación es lo que hace un técnico cuando deja un sistema corriendo en una máquina nueva — el sistema sigue corriendo cuando el técnico se va. El facilitador del WORX OS es un instalador. Su éxito se mide porque el sistema sigue corriendo cuando él se va. No porque entregó un reporte. No porque facilitó talleres. Porque el ecosistema quedó vivo en la organización del cliente. Si al cierre del Lab el cliente piensa *"qué bueno que vinieron, esperemos seguir avanzando"*, falló el Lab. Si piensa *"esto ya es nuestro modo de operar"*, funcionó. ### 2.4 El Lab no es secuencial Esto es una corrección de Victor al modelo inicial y se canonizó como D-006: **el Lab de 40 días incluye desde día 1 el arranque de proyectos. Detonación, implementación y capacitación operan en paralelo, no en cascada.** Para un facilitador esto significa: **no hay una "fase de preparación" antes de empezar a trabajar sobre el proyecto vivo del equipo.** El proyecto vivo arranca el día 1 con el ecosistema parcialmente activado. La activación se completa mientras el proyecto avanza. La capacitación ocurre sobre el proyecto, no en sesiones separadas. Esto es contraintuitivo si vienes de cualquier escuela de consultoría tradicional. Pero es la única forma de respetar el principio anti-pause y de instalar (no implementar). Si se hace secuencial, el Lab se vuelve programa de capacitación — y los programas de capacitación no instalan sistemas operativos. ### 2.5 Los 3 entregables simultáneos Al cierre del Lab, el cliente recibe **tres cosas a la vez**, no en orden de prioridad: - **Proyectos del cliente avanzados o resueltos** — el sustrato vivo, ahora con el ecosistema operando sobre él. - **Equipo capacitado** — entrenado en el flujo nuevo, no en uso de herramientas. La capacitación es subproducto de operar el ecosistema sobre proyectos reales. - **Ecosistema instalado** — WORX OS + WORX + SherpaX corriendo en patrón estable, no en modo demo. Esto se ve simple. Es la promesa más difícil de sostener del producto. La mayoría de los servicios competidores entregan uno de estos tres, casi siempre el más blando (capacitación). El WORX OS **entrega los tres simultáneamente, o no entrega nada**. Si en el día 41 falta uno, falló el Lab. --- ## III. La arquitectura del producto ### 3.1 Los 3 pilares y por qué se sostienen entre sí **WORX** es el método: cómo opera la organización en su día a día con IA integrada. Ritmos, cadencias, formatos, flujos. La forma del trabajo. **WORX OS** es la arquitectura cognitiva: el sustrato que captura, indexa y sirve el conocimiento corporativo. La memoria viva del cliente. **SherpaX** es la interfaz humana: el agente personal que acompaña a cada colaborador en su flujo. La capa que hace que el sistema le hable a las personas en su contexto, no como pop-up de productividad. Los tres se sostienen entre sí. WORX sin WORX OS es un método sin memoria — se desvanece a las semanas. WORX OS sin WORX es una base de datos sin ritmo — se vuelve archivo muerto. SherpaX sin los otros dos es un asistente de IA genérico — se comoditiza al primer año. Los tres juntos son un **sistema operativo organizacional**. Por eso vendemos el bundle. La regla del bundle es estructural, no comercial. **Es estructural porque la matriz 3×5 lo demuestra: ningún pilar resuelve solo las 5 capas del problema.** Es comercial como consecuencia. Si un facilitador empuja a un cliente a comprar solo SherpaX porque "es lo más fácil de adoptar", está rompiendo la arquitectura y empujando un fracaso futuro. A los 6 meses ese cliente va a abandonar SherpaX porque sin WORX OS y sin WORX, SherpaX queda como demo bonita sin tracción operativa. ### 3.2 Las 3 fases y por qué se superponen **Detonación → Lab → Acompañamiento.** No es secuencia de fases — es secuencia de modos de presencia de EL en el cliente. - En **Detonación** EL está en modo diagnóstico-decisión. Tiempo: 0-2 semanas. - En **Lab** EL está en modo instalador. Tiempo: 40 días, superpuesto con el final de Detonación. - En **Acompañamiento** EL está en modo guía. Tiempo: 12 meses, arranca al final del Lab. Las fases se superponen porque las modalidades de presencia se traslapan. Al día 35 del Lab, el facilitador ya está pensando en el Acompañamiento M1. Al M3 del Acompañamiento, ya hay conversación abierta sobre equipo #2 (otra Detonación que arranca). **Para un facilitador esto significa que el momento del cliente determina su modo, no el cronograma.** Saber leer el momento del cliente es parte del oficio. ### 3.3 Las 3 fases NO son producto Esto es importante para no confundir con consultoras: las 3 fases son el **proceso de entrega del producto**. El producto es el ecosistema instalado. La gente compra el ecosistema, no las fases. Las fases son cómo se entrega. Un cliente que pregunta *"¿qué duración tiene tu programa de transformación?"* está aplicando el modelo equivocado. La respuesta canónica es: > *"No es un programa con duración. Es un sistema operativo que se instala. La instalación toma 40 días y el sistema lo operas tú con nuestro acompañamiento por 12 meses iniciales, renovables."* Cambiar el sustantivo cambia el sentido del producto. --- ## IV. La identidad de mercado ### 4.1 Síntesis F · dos productos La D-012 cerró que el ecosistema HIORG sostiene dos productos, no uno: - **WORX OS** — B2B-equipo. Lo que este paper describe. Para organizaciones que quieren transformar su modo de operar sobre equipos vivos con proyectos vivos. - **SherpaX Personal** — B2O standalone. Para profesionales individuales que quieren un agente personal sin esperar a que su organización se transforme. Ambos comparten arquitectura técnica y filosofía. Pero tienen economías, canales y ciclos de venta distintos. Mantenerlos como un solo producto los confundía. Separarlos limpió el catálogo. **Para un facilitador del WORX OS, la regla es simple:** SherpaX Personal no es tu producto. Vive en otro Room, con otro equipo, con otra economía. Cuando un prospecto entra al embudo HIORG, la pregunta es si califica para WORX OS. Si no, **no lo empujes a SherpaX Personal como consuelo — derívalo limpio al canal correcto** (cuando exista) o sé honesto y di que no hay match. Empujar SherpaX Personal a un cliente B2B-equipo "para empezar" es una trampa. El cliente compra SherpaX Personal y siente que ya empezó. Pero no instaló nada. Y el WORX OS queda parado. ### 4.2 La frontera no negociable El WORX OS **no se vende por capas separadas**. Esta es la regla más violada en conversación comercial cuando un facilitador siente presión de cierre. Hay que defenderla. Cuando un cliente dice *"solo queremos SherpaX para mi equipo"*, la respuesta canónica es: > *"SherpaX vive en el ecosistema. Si quieres SherpaX para un piloto acotado, lo hacemos como **Piloto Accidental** dentro de tu organización — no es venta de SherpaX, es siembra del ecosistema. El piloto es entrada baja al WORX OS, no producto independiente."* El Piloto Accidental existe precisamente para esos casos. Tiene crédito 100% contra el Lab si el cliente avanza. Pero **el piloto no es Lab descontado, ni es SherpaX independiente**. Es siembra. La distinción importa porque preserva la integridad del catálogo. ### 4.3 Las 3 condiciones T-5 · la reja de calificación Un prospecto califica para WORX OS cuando cumple las **tres condiciones acumulativas**, no las tres por separado: 1. **Equipo identificable con proyecto vivo de horizonte 3-12 meses.** 2. **Workflows operativos repetibles susceptibles de volverse factorías-IA.** 3. **Comprador con autoridad sobre el equipo (CIO, CEO, dueño).** Si cumple las tres → embudo HIORG. Si falta una → conversación correctiva. Si faltan dos o más → no es prospecto WORX OS hoy. **Mejor decir que no que vender un Lab a un cliente que no califica.** Un Lab fallido daña reputación y catálogo. Una venta no hecha solo cuesta tiempo. --- ## V. La economía del producto ### 5.1 Por qué el pricing está en 3 capas El WORX OS cobra en tres capas porque entrega valor en tres planos simultáneos: - **Capa 1 — Implementation Fee:** el valor del ecosistema instalado. Lab inicial + Labs subsiguientes Modelo A + tier Train-the-Trainers Modelo B. - **Capa 2 — Subscription recurrente:** el valor del ecosistema operando. Acompañamiento M1-M12 + renovaciones. - **Capa 3 — Expansión interna:** el valor del ecosistema replicándose dentro del cliente. Más equipos, más asientos, más capas activas. El cliente paga las tres porque recibe las tres. No paga por hora, no paga por seat genérico, no paga por módulo. **Paga por instalación, por operación y por expansión** — los tres planos del producto. Esto le da defensa al pricing frente a competidores que cobran en una sola dimensión. *"Tu plataforma cobra por seat. Pero un seat sin sistema no genera valor. Yo te cobro la instalación porque sin instalación no hay sistema, te cobro la operación porque sin operación no hay sistema vivo, y te cobro la expansión porque sin expansión el sistema se queda chico para tu organización."* ### 5.2 Por qué los descuentos de Modelo A están donde están D-014 cerró: equipo #2 = 50–60% del Lab inicial · equipos #3+ = 30–40% del Lab inicial. Ambos ajustables por complejidad. Esto no es descuento por volumen. Es **calibración por curva de aprendizaje**. El segundo Lab usa el WORX OS instalado, los patrones WORX adaptados y el Sherpa Guide ya conoce al cliente. El tercer Lab profundiza esa curva. Por eso el descuento crece. Pero el descuento tiene piso. Por debajo del 30% el Lab subsidiaria se vuelve carga operativa para EL — saturación de capacidad sin retorno proporcional. Por eso a partir del equipo #4 la conversación canónica es Modelo B: el cliente que necesita más equipos paga la certificación de facilitadores internos, no Labs descontados infinitamente. ### 5.3 Por qué Modelo B no es "más barato" que Modelo A Esta es la regla que un facilitador debe poder defender en conversación comercial: **Modelo B no es la opción barata.** Es la opción *diferente*. Modelo B convierte el método en capacidad interna del cliente. Eso tiene valor estructural distinto. Si el cliente proyecta 4-6 Labs en 24 meses, Modelo B es más eficiente que pagar 4-6 veces el descuento Modelo A. Si proyecta menos, Modelo A es más eficiente. Calibrar Modelo B "barato" para empujarlo a clientes que no lo necesitan es trampa. Esos clientes compran la certificación, no la usan, y luego acusan al producto de no entregar valor. Modelo B se ofrece solo a clientes que lo van a usar — clientes con pipeline interno de equipos que justifique la inversión. ### 5.4 EmpowerScan no es producto HIORG EmpowerScan vive en track Empowernomics. Es entrada baja al embudo HIORG, no SKU del WORX OS. Esto importa para el facilitador porque: - EmpowerScan no la corre el Sherpa Guide del WORX OS. La corre el equipo Empowernomics. - Si un prospecto entra por EmpowerScan y califica para WORX OS, hay un *handoff* — el Sherpa Guide entra al embudo después del scan. - Si un prospecto pregunta *"¿qué incluye el WORX OS?"*, EmpowerScan no se menciona como incluido. Es referido como puerta de entrada opcional, separada. --- ## VI. La replicación y la Red de EmpowerTeamsX ### 6.1 Cuándo deja de ser implementación y empieza a ser Red Un cliente está en "implementación" mientras corre su primer Lab. Está en "Red en formación" cuando se cumplen las **3 condiciones de Red activa** (ver MPB-Replicación §1.2): 1. ≥ 1 Lab cerrado con rúbrica firmada. 2. Ecosistema en M3+ del Acompañamiento con telemetría estable. 3. ≥ 1 conversación de expansión iniciada. Antes de eso → cliente como instalación. Después → cliente como nodo de la Red. **Para un facilitador esto cambia el modo de presencia.** En implementación el facilitador es instalador (alta intensidad operativa). En Red el facilitador es guía de la Red (cadencia regular, intervención selectiva). Confundir los modos es confundir el producto: un facilitador en modo instalador atendiendo a un cliente en Red satura la relación. Un facilitador en modo guía conduciendo un Lab no instala nada. ### 6.2 Modelo A · cuándo y por qué Modelo A aplica cuando: - Cliente con WORX OS instalado y estable. - Cliente que NO quiere o NO puede sostener facilitadores internos. - Cliente con horizonte de 1-3 equipos adicionales en 12-24 meses. La economía de Modelo A es: **el cliente paga el método cada vez que lo necesita.** Eso le da flexibilidad operativa sin compromiso estructural. A cambio paga descuento decreciente, no precio plano. Para el facilitador, Modelo A es el modo natural del WORX OS durante los primeros 24 meses de cualquier cliente. La mayoría de los clientes empieza así. Algunos terminan migrando a Modelo B. Otros se quedan en Modelo A indefinidamente — y eso es válido si el ritmo del cliente lo soporta. ### 6.3 Modelo B · cuándo, por qué y cómo no diluirlo Modelo B convierte el método en capacidad interna del cliente. Aplica cuando: - Cliente con ≥ 2 Labs cerrados Modelo A. - Pipeline interno de equipos #4+ que justifique inversión en certificación. - Cuerpo operativo capaz de sostener facilitadores internos. La economía de Modelo B es distinta: fee de certificación inicial + auditoría EL del **ecosistema instalado** (gente + método + arquitectura) + acompañamiento del primer Lab tutorado + re-certificación anual + acceso a actualizaciones del método. **El gate no es certificación de personas — es certificación del ecosistema completo.** Esto importa porque sin esa frontera, Modelo B se diluye al primer cliente que diga *"ya tenemos a Pedro y a Ana certificados, dennos el sello"*. El sello no se da por personas. Se da porque el ecosistema completo del cliente está puesto a punto: WORX OS sano, WORX en patrón, SherpaX adoptado, gente entrenada, arquitectura coherente. Para un facilitador que conduce auditorías de Modelo B la regla es: **PASS solo si el ecosistema lo justifica. PASS-CON-REMEDIACIÓN si está cerca pero falta algo. FAIL si no.** No PASS de cortesía. No PASS para no perder al cliente. La integridad del producto vive en la auditoría. ### 6.4 La frontera operativa post-Modelo B Una vez Modelo B activo, los facilitadores certificados del cliente corren los Labs internos. **El Sherpa Guide EL no interviene operativamente en esos Labs.** Si interviene, anula la promesa de Modelo B (el cliente paga certificación pero sigue dependiendo de EL). La intervención EL post-Modelo B se limita a: - Cadencias de método y comunidad (canal cerrado de Sherpa Guides certificados). - Auditoría anual de re-certificación. - Apoyo en escalamientos críticos (dilución detectada · cliente solicita ayuda explícita). Para el facilitador EL esta es una transición incómoda. Después de meses de instalación intensa, el cliente entra en modo autónomo. El facilitador siente que "le quitan al cliente". Hay que entender: **no se lo quitan — el cliente se gradúa**. Si el facilitador interviene operativamente igual, está rompiendo el producto. --- ## VII. Lo que un facilitador debe saber antes del Lab Esta sección es operativa. Es lo que un Sherpa Guide debe poder responder con honestidad antes de su primer Lab. Si alguna respuesta no está clara, **no es momento de su primer Lab**. ### 7.1 ¿Por qué el cliente compró? El cliente que firmó tiene una historia. La conoces. La firmó porque cumple las 3 condiciones T-5 y porque la conversación comercial le mostró que el WORX OS resuelve algo concreto en su operación. Antes del kick-off del Lab, el facilitador debe poder articular: - ¿Cuál es el equipo? ¿Quién lo lidera? ¿Quién forma parte? - ¿Cuál es el proyecto vivo? ¿Cuál es su horizonte? ¿Cuál es su entregable principal? - ¿Qué dolor del cliente esperan que el ecosistema resuelva? - ¿Quién es el comprador y qué éxito espera ver al día 41? Si no puede articular alguna, hay que regresar a la documentación del cliente o pedir reunión de contexto. **No se entra a kick-off sin esto claro.** ### 7.2 ¿Qué se entrega al día 41? Los 3 entregables simultáneos: - Proyectos del cliente avanzados o resueltos con el ecosistema operando sobre ellos. - Equipo capacitado en el flujo nuevo. - Ecosistema instalado (WORX OS + WORX + SherpaX) corriendo en patrón estable. Verificable con la rúbrica de calidad del MPB-Lab40-Playbook (a producir). Si la rúbrica no se firma, no se cierra el Lab — y se activa plan de remediación. ### 7.3 ¿Qué pasa si el equipo se resiste? Pasa. Más seguido de lo que parece desde fuera. La resistencia tiene firmas reconocibles: ausencia recurrente en cadencias, escepticismo activo sobre IA, demanda de "métricas tradicionales" que invaliden el ecosistema, presión política interna del cliente sobre el equipo. Ante resistencia el facilitador tiene tres movimientos canónicos: 1. **Diagnóstico operativo.** ¿La resistencia es del equipo o de su entorno? ¿Es activa o pasiva? ¿Es una persona o el patrón colectivo? 2. **Conversación con el sponsor.** El sponsor del equipo en el cliente debe saber. Si no actúa, el Lab se atasca. 3. **Plan de detonación correctivo.** A veces hay que pausar 2-3 días, reconfigurar el equipo (a veces remover una persona), y reanudar. Lo que el facilitador NO debe hacer ante resistencia: **forzar adopción**. Forzar adopción daña al cliente y daña al producto. Mejor pausar y reconfigurar. ### 7.4 ¿Cuándo escalar a Victor? Escalar a Victor cuando: - Decisiones estructurales fuera del catálogo (descuento fuera de rango, scope ajustado, caso especial no previsto). - Señales de dilución del método en el equipo del facilitador. - Oportunidades de evolución del producto detectadas en el Lab. - Conflicto serio con sponsor del cliente. - Riesgo de Lab fallido. NO escalar para decisiones operativas estándar del Lab. El facilitador certificado tiene autoridad operativa completa sobre su Lab. Escalación es para decisiones de producto, no de operación. --- ## VIII. Lo que un facilitador NUNCA debe hacer Lista corta. Cada ítem es regla absoluta. ### 8.1 Vender una capa por separado del bundle Romper la frontera del bundle es romper el producto. Si un cliente quiere solo SherpaX, la respuesta es Piloto Accidental, no SherpaX standalone. ### 8.2 Dar un Lab descontado para "cerrar" El descuento del Lab inicial debilita la referencia de todos los Labs siguientes (Modelo A está calibrado contra el Lab inicial). Si hay que negociar, se negocia Piloto Accidental con crédito, no Lab descontado. La integridad del precio del Lab inicial es estructural. ### 8.3 PASS de cortesía en auditoría Modelo B La auditoría es la integridad del producto. PASS solo si el ecosistema lo justifica. FAIL es válido y necesario. PASS-de-cortesía dilute la certificación y mata Modelo B en horizonte largo. ### 8.4 Intervenir operativamente en Labs post-Modelo B Una vez certificado un cliente Modelo B, sus facilitadores corren los Labs. EL solo entra a auditoría anual y a escalamientos críticos. Intervenir operativamente anula la promesa de Modelo B. ### 8.5 Empujar SherpaX Personal a un cliente B2B-equipo Son productos distintos con economías distintas. Un prospecto B2B-equipo que termina comprando SherpaX Personal es un prospecto perdido para el WORX OS. **No se hace.** ### 8.6 Forzar adopción ante resistencia del equipo Daña al cliente y al producto. Mejor pausar, diagnosticar, reconfigurar. ### 8.7 Vender el WORX OS como "ayuda con IA" Esa frase comoditiza al producto. La frase canónica es *"un nuevo modo de operar que tiene IA integrada"*. La diferencia entre las dos frases es la diferencia entre vender un sistema operativo y vender un servicio comoditizado. ### 8.8 Pausar la operación del cliente para el Lab El principio anti-pause es estructural. El Lab opera *sobre* la operación viva, no *en lugar de* ella. Pausar la operación del cliente rompe el principio y empuja al cliente al modo consultoría tradicional. ### 8.9 Operar sin la unidad equipo + proyecto vivo Sin equipo y proyecto identificados, el Lab no tiene sustrato. Mejor pausar el Lab y conversar correctivo que arrancar sin sustrato. ### 8.10 Asumir que el playbook es opcional El MPB-Lab40-Playbook (cuando exista) define cómo se corre el Lab. Sus rúbricas son verificables. Sus criterios son canónicos. Un facilitador que opera "a su manera" rompe la replicabilidad del producto y diluye la posibilidad de Modelo B futuro. --- ## IX. La gobernanza interna del producto ### 9.1 Quién decide qué - **Cambios de identidad del producto** (qué es / qué no es / frontera con SherpaX Personal) → Victor sin excepción. - **Cambios de catálogo o pricing referencia** → propuesta de runner del room → ratificación de Victor → registro en CP-Catálogo + CHANGELOG del XPack. - **Cambios del playbook del Lab** → propuesta del Sherpa Guide ejecutor → revisión runner → ratificación Victor → registro en MPB-Lab40-Playbook. - **Excepciones comerciales caso por caso** → Victor. - **Canonización de patrones repetidos** → si una excepción se da ≥ 3 veces, runner propone canonización. ### 9.2 La cadencia operativa del room El room HIORG vive como sesiones de diseño asíncronas Victor ↔ runner (Jay) en Cowork mode, con persistencia entre sesiones vía vault. Cada sesión cierra con minuta + actualización de XPack vivo. Para un facilitador esto significa que **las decisiones del producto viven en el vault**, no en mensajes sueltos ni en memoria de Victor. La fuente de verdad son los activos canónicos del room: paper, deck, CP-Solucion, CP-Estrategia, CP-Catalogo, MPB-Replicación, este paper interno, MPB-Lab40 (cuando exista), PLAN-Sprint (cuando exista). Si el facilitador encuentra contradicción entre lo que dice un activo canónico y lo que recuerda haberle oído a Victor, **gana el activo canónico** — y se levanta tensión en el room para canonizar la contradicción. ### 9.3 El changelog inmutable Cada decisión vinculante del producto se registra en el CHANGELOG del XPack del room. Eso es la memoria del producto. Quien quiera entender por qué algo está donde está, abre el changelog y lo encuentra fechado, firmado y con evidencia. Esta es disciplina que no parece importar hasta el día que alguien pregunta *"¿quién decidió que el descuento del equipo #2 fuera 50–60%?"* y la respuesta tiene que existir en el vault, no en una conversación que ya nadie recuerda. --- ## X. Lo que viene · v02 del producto El WORX OS v01 está cerrado. Eso no significa que esté terminado. Significa que tiene identidad, arquitectura, catálogo y modelo de replicación firmes — y operable. **Tres tensiones abiertas para v02** que un facilitador debe conocer porque van a evolucionar el producto en los próximos meses: ### 10.1 Índice de Inteligencia del Equipo + tiers tipo ISO (T-6) La auditoría EL del ecosistema instalado evolucionará de PASS/FAIL a un score numérico con tiers escalonados (sugerencia inicial: Foundation / Operating / Mastery / Excellence). El cliente podrá certificarse en aspectos diferenciados del producto (modelo · arquitectura · uso de la interfase). El cliente *aspira* a niveles superiores → genera demanda interna de Modelo A o Modelo B sin que EL la empuje. Para el facilitador esto significa que la auditoría dejará de ser binaria. Habrá conversaciones tipo *"tu equipo está en nivel Operating, para llegar a Mastery hace falta X y Y"* — eso da textura comercial al acompañamiento. ### 10.2 Diagnóstico de Madurez WORX OS · Hook masivo (T-7) Una puerta de entrada baja distinta del EmpowerScan, evaluada contra las 5 capas del Paper Gran Reto. Resuelve el hueco "no tenemos punto de entrada masivo al embudo HIORG". Conecta narrativamente Paper ↔ Catálogo. Posible canal de reactivación de TP-DemandGen. Para el facilitador esto significa que va a haber un nuevo SKU 0.3 en el catálogo, distinto del Piloto Accidental — un diagnóstico evaluativo, no un piloto técnico. Sirve como conversación inicial cuando un prospecto entra sin estar listo para el Lab. ### 10.3 Evolución de los playbooks ejecutables El MPB-Lab40-Playbook se está produciendo. Cuando exista, será la fuente de verdad sobre cómo corre el Lab paso a paso. Hasta entonces, el facilitador que conduce un Lab opera con Victor en sombra y con este paper como guía narrativa. Cuando MPB-Lab40 esté vivo, este paper interno se actualizará a v02 para integrar referencias al playbook ejecutable. --- ## XI. El compromiso EL Un facilitador que termina de leer este paper debe poder firmar (al menos consigo mismo) un compromiso operativo con el producto. Aquí va — formulado en primera persona, no como obligación legal sino como ética operativa: > *Voy a vender el WORX OS como sistema operativo organizacional, no como ayuda con IA.* > > *Voy a respetar la unidad equipo + proyecto vivo. Si el cliente no la tiene, no arranco el Lab.* > > *Voy a defender el principio anti-pause. El cliente no abandona ni pausa sus proyectos para entrar al Lab.* > > *Voy a instalar, no implementar. Mi éxito se mide porque el sistema sigue corriendo cuando me voy.* > > *Voy a operar las tres fases en superposición, no en cascada. El proyecto vivo arranca el día 1.* > > *Voy a entregar los tres entregables simultáneos al día 41. Si falta uno, falló el Lab.* > > *Voy a defender la regla del bundle. Las 3 capas no se venden por separado. Si presionan, ofrezco Piloto Accidental, no capa standalone.* > > *Voy a respetar las 3 condiciones T-5 de calificación. Mejor un prospecto declinado que un Lab fallido.* > > *Voy a calibrar Modelo A y Modelo B con honestidad. Modelo B no es la opción barata — es la opción diferente.* > > *Voy a sostener la integridad de la auditoría EL. PASS solo si el ecosistema lo justifica. FAIL es válido.* > > *Voy a respetar la frontera operativa post-Modelo B. Si el cliente se graduó, no lo retomo operativamente.* > > *Voy a escalar a Victor cuando toque. Voy a operar con autoridad cuando toque.* > > *Voy a registrar las decisiones que tome en el vault, no en mi memoria.* Si el facilitador no puede firmar alguna de estas líneas con honestidad, no debe conducir un Lab todavía. Más estudio, más sombra, más conversación con Victor. El producto vale más que cualquier urgencia comercial individual. --- ## XII. Cierre Este paper interno se actualiza cuando: - Se cierra una decisión vinculante nueva del producto (D-015, D-016, …). - Se ratifica una v02 de los activos canónicos. - Se aprende algo operativo que merezca canonizarse en el espíritu del producto. - Se incorpora un facilitador nuevo al programa de certificación y aporta perspectiva externa. Próxima revisión esperada: cuando se ratifiquen T-6 (Índice + tiers ISO) y T-7 (Diagnóstico-Hook) — porque ambas modifican mecánicamente la auditoría y el embudo, y este paper debe absorberlo en v02. --- ## Documentos hermanos referenciados **Activos canónicos del producto WORX OS (fuentes técnicas):** - `PAP-HIORGS-GranReto-v01.md` — paper cliente-facing sobre el problema canónico (5 capas). - `CP-HIORGS-Solucion-Arquitectura-v01.md` — arquitectura técnica (3 pilares · 3 fases · matriz 3×5 · anti-pause). - `CP-HIORGS-Producto-Estrategia-v01.md` — estrategia de producto (Síntesis F · frontera · ciclo · pricing 3 capas · gobernanza). - `CP-HIORGS-Producto-Catalogo-v01.md` — catálogo de SKUs (12 SKUs en 4 capas · reglas de combinación · casos límite). - `MPB-HIORGS-Replicacion-Playbook-v01.md` — replicación post-Lab (Modelo A · Modelo B · auditoría EL · cadencia). - `OUT-HIORGS-Modelo-Deck-v02.pptx` — deck pitch (16 láminas · matriz 3×5 · Red de EmpowerTeamsX). **Documentos canónicos del room:** - `XP-EL-HIORGS-Portfolio-v01.md` — XPack vivo del room (estado · NEXT · DISCUSSION · CHANGELOG). - `MIN-HIORGS-RoomProductizacion-v01.md` — minuta del room (sesiones 2026-04-24 y 2026-04-25 · D-001 a D-014 · T-1 a T-8). **Activos pendientes que cuando existan se referencian aquí en v02:** - `MPB-HIORGS-Lab40-Playbook-v01.md` — playbook ejecutable del Lab. - `PLAN-HIORGS-Productizacion-Sprint-v01.md` — plan del sprint de productización. - `CAS-EL-LabPraxis-ArquitecturaProducto-v01.md` — caso LabPraxis con D-012/013/014. --- *PAP-HIORGS-ModeloProducto-Interno-v01 · IB-EL-EmpowerLabs/PB-EL-Project-Bank/PB-HiOrg-Hyperintelligent Org/ · 2026-04-25* *Paper Interno del Modelo Completo de Producto WORX OS. Audiencia: equipo EL + Sherpa Guides certificados externos. NO es activo cliente-facing. Cierra T-8 abierta el mismo día. Sigue MePB-XX-Paper-Schema-v01.*