---
type: CP
asset_id: CP-HIORGS-Producto-Catalogo-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: CP · Producto Catalogo · IB-EL-EmpowerLabs
nota_migracion: Frontmatter BMF agregado en batch masivo 2026-05-20 · Workbench FASE 5C · proposito pendiente revisión manual
---

# CP-HIORGS-Producto-Catalogo-v01

**Canonical Piece — Catálogo de SKUs Vendibles del SO-HiORG**

**Fuente única de verdad sobre qué se vende, en qué unidades, con qué pricing de referencia, con qué dependencias y con qué entregables por SKU.**

---

| Campo | Valor |
|---|---|
| **Asset ID** | CP-HIORGS-Producto-Catalogo-v01 |
| **Tipo** | Canonical Piece (Catálogo) |
| **Room** | PB-HiOrg — Hyperintelligent Org |
| **IntelliBank** | IB-EL-EmpowerLabs |
| **SubBank** | PB-EL-Project-Bank / PB-HiOrg-Hyperintelligent Org |
| **Owner** | Victor Heredia |
| **Sponsor** | Victor Heredia |
| **Runners** | Jay (mantenimiento) |
| **Versión** | v01 |
| **Fecha de creación** | 2026-04-25 |
| **Última actualización** | 2026-04-25 |
| **Estado** | Activo — v01 firme con pricing estructural ratificado; valores absolutos por equipo de trabajo a refinar con datos de mercado en v02 |
| **Documentos padre** | CP-HIORGS-Producto-Estrategia-v01 |
| **Documentos hermanos** | CP-HIORGS-Solucion-Arquitectura-v01, MPB-HIORGS-Replicacion-Playbook-v01, MPB-HIORGS-Lab40-Playbook-v01 |
| **Tags** | [canonical-piece, catalogo, SKUs, pricing, SO-HiORG, Modelo-A, Modelo-B, Train-the-Trainers, EmpowerScan, Piloto-Accidental] |

---

## 0. Propósito de este documento

Este Canonical Piece existe para resolver una pregunta operativa concreta:

> *Cuando se prepara una propuesta comercial nueva, ¿qué líneas exactas se cotizan, en qué unidad, a qué precio de referencia, con qué dependencias y qué entregables por línea?*

Es el documento que cualquier miembro de EmpowerLabs debe abrir antes de:

- Construir el cuerpo económico de una propuesta (BioPappel, Posta, próximos prospectos).
- Negociar pricing en una conversación comercial.
- Definir scope de un Lab nuevo.
- Calcular el costo de expansión a equipos #2/#3 dentro de un cliente existente.
- Cotizar la activación del tier Train-the-Trainers (Modelo B).

Las reglas de identidad y frontera viven en CP-HIORGS-Producto-Estrategia-v01. Las reglas de cómo se ejecuta cada SKU viven en MPB-HIORGS-Lab40-Playbook y MPB-HIORGS-Replicacion-Playbook. Este documento solo responde *qué se vende, a qué, y por cuánto de referencia*.

---

## 1. Reglas de uso de este catálogo

### 1.1 La unidad de venta base

**El SKU base es "equipo + proyecto vivo"**, no horas, no asientos, no módulos. Esto deriva directamente de D-013 (unidad mínima de transformación).

Asientos de SherpaX y XDocs del Corp-Brain-OS se cuentan como métrica de salud del ecosistema instalado, **no se cotizan como SKU independiente** dentro del SO-HiORG. Si un prospecto pide *"solo asientos SherpaX"*, el camino canónico es Piloto Accidental (SKU 1.1) o derivación al Room SherpaX Personal.

### 1.2 La regla del bundle

Las 3 capas del SO-HiORG (WORX + Corp-Brain-OS + SherpaX) **no aparecen como SKUs separados en este catálogo**. Aparecen como contenido del bundle dentro del SKU del Lab. La frontera es absoluta — no hay excepción comercial. Solo el Piloto Accidental opera como entrada baja, pero se vende como "siembra del ecosistema completo", no como capa individual.

### 1.3 Estructura de pricing en 3 capas

El catálogo está organizado por las **3 capas de pricing** que se cobran al cliente del SO-HiORG (sección §5 del CP-Estrategia):

- **Capa 1 — Implementation Fee** (Lab inicial + Labs subsiguientes Modelo A + tier Train-the-Trainers Modelo B)
- **Capa 2 — Subscription recurrente** (Acompañamiento M1-M12 + renovaciones)
- **Capa 3 — Expansión interna** (más equipos, más asientos, más capas activas en otras divisiones)

Más una **capa 0** de entradas bajas al embudo (EmpowerScan, Piloto Accidental).

### 1.4 Notación de pricing

Este catálogo fija **estructura, ratios y unidades**. Los valores absolutos en USD/MXN se manejan en propuestas concretas y se ratifican caso por caso con Victor hasta que se consoliden 2-3 ejecuciones reales del Lab que permitan refinar con datos de mercado en v02.

Donde aparece `[Lab inicial]` se refiere al fee del Lab del equipo #1 del cliente — la referencia base para todos los descuentos de Modelo A.

Donde aparece `[orientación @Victor]` se trata de un valor que Victor define caso por caso en la propuesta — el catálogo no lo congela en v01.

---

## 2. Capa 0 — Entradas bajas al embudo

### 2.1 SKU 0.1 — EmpowerScan *(referencia, no es producto HIORG)*

| Campo | Valor |
|---|---|
| **SKU** | 0.1 |
| **Nombre** | EmpowerScan |
| **Track de origen** | Empowernomics (no HIORG) |
| **Función en HIORG** | Puerta de entrada baja al embudo SO-HiORG |
| **Unidad** | 1 sesión de diagnóstico |
| **Duración** | 90 min |
| **Entregable** | Reporte de diagnóstico EmpowerScan + decisión Go/No-Go para conversación HIORG |
| **Pricing** | Definido en track Empowernomics — fuera del scope de este catálogo |
| **Quién lo ejecuta** | Equipo Empowernomics |
| **Cuándo se usa** | Antes de calificar prospecto SO-HiORG, cuando el prospecto entra por canal Empowernomics |

**Nota:** EmpowerScan es la única "entrada baja" recomendada para prospectos que aún no califican las 3 condiciones T-5. Si las cumplen tras el EmpowerScan → conversación SO-HiORG directa.

### 2.2 SKU 0.2 — Piloto Accidental

| Campo | Valor |
|---|---|
| **SKU** | 0.2 |
| **Nombre** | Piloto Accidental |
| **Función** | Entrada baja al embudo SO-HiORG cuando el cliente quiere "probar" el ecosistema antes de comprometerse al Lab completo |
| **Unidad** | 1 piloto + 1 equipo + 1 proyecto vivo acotado |
| **Duración** | 2-4 semanas |
| **Entregable** | (a) ecosistema básico activado sobre 1 proyecto vivo · (b) telemetría inicial · (c) decisión Go/No-Go para Lab completo |
| **Pricing** | Fee fijo bajo, configurado como **"crédito 100%"** contra el Lab inicial si el cliente avanza al SKU 1.1 dentro de los siguientes 60 días |
| **Quién lo ejecuta** | Sherpa Guide + Detonador (mismo equipo que el Lab) |
| **Lógica del crédito** | El piloto NO compite con el Lab. Es siembra del ecosistema. Si el cliente avanza, lo que pagó por piloto se descuenta de la Capa 1 |
| **Caso de uso típico** | Cliente que ya invertirá pero quiere ver el ecosistema en sus manos primero. NO sirve como reemplazo del Lab — sirve como detonante |

**Riesgo:** que el Piloto Accidental se venda como producto sustituto del Lab (cliente "se queda" con el piloto y no avanza). Mitigación: criterio de detención al cierre del piloto (rúbrica del Sherpa Guide → Go/No-Go honesto). Si rúbrica dice No-Go → no se empuja venta del Lab.

---

## 3. Capa 1 — Implementation Fee

Esta capa cubre los Labs (inicial + subsiguientes Modelo A) y el tier Train-the-Trainers (Modelo B). Es la única capa donde aparece pricing fijo por SKU.

### 3.1 SKU 1.1 — Lab inicial SO-HiORG (equipo #1)

| Campo | Valor |
|---|---|
| **SKU** | 1.1 |
| **Nombre** | Lab inicial SO-HiORG — equipo #1 |
| **Unidad** | 1 equipo + 1 proyecto vivo (ver criterios T-5 en CP-Estrategia §2.1) |
| **Duración** | 40 días (Fase 1 del ciclo de vida) |
| **Pricing referencia** | `[Lab inicial]` — fee fijo del Lab del primer equipo del cliente. Valor absoluto en propuesta concreta, orientación @Victor caso por caso hasta v02 |
| **Lógica de pricing** | Por valor del ecosistema instalado, no por hora/esfuerzo. Calibrado para reflejar (a) avance del proyecto vivo del cliente · (b) equipo capacitado · (c) ecosistema corriendo |
| **Entregables** | (1) Proyectos del cliente avanzados o resueltos con ecosistema operando · (2) equipo capacitado en flujo nuevo · (3) Corp-Brain-OS instalado e indexando · (4) WORX en patrón base · (5) SherpaX seats activos para todos los miembros del equipo · (6) rúbrica de calidad firmada por Sherpa Guide certificado |
| **Dependencias técnicas** | Acceso a sistemas del cliente (autorización IT) · disponibilidad del equipo durante 40 días (no 100%, sí presencia regular) · proyecto vivo identificado y autorizado como sustrato |
| **Dependencias comerciales** | Cumplir las 3 condiciones T-5 (CP-Estrategia §2.1) · contrato firmado · pago Capa 1 según términos |
| **Términos de pago referencia** | 50% al cierre del contrato · 50% al cierre del Lab tras rúbrica de calidad firmada (orientación @Victor — ajustable) |
| **Quién lo ejecuta** | Sherpa Guide certificado (Victor en cliente cero · Jesús/Gustavo certificados a partir de v02 del producto) |

**Reglas de excepción:** ninguna. Si el prospecto pide *"un Lab más corto"* o *"medio Lab"* → no se vende. La duración 40 días es estructural — derivada de D-005/D-006 + lecciones de 10+ años de EmpowerLabs original. Si no caben 40 días en la realidad del cliente, se conversa Piloto Accidental (SKU 0.2) o no se vende.

### 3.2 SKU 1.2 — Lab equipo #2 (Modelo A)

| Campo | Valor |
|---|---|
| **SKU** | 1.2 |
| **Nombre** | Lab equipo #2 — Modelo A (EL facilita) |
| **Unidad** | 1 equipo nuevo dentro del mismo cliente + 1 proyecto vivo nuevo |
| **Duración** | 40 días |
| **Pricing referencia** | **50–60% de `[Lab inicial]`** — ajustable por complejidad de los proyectos del nuevo equipo. Ratificado D-014. |
| **Lógica del descuento** | Reutilización del Corp-Brain-OS instalado · reutilización de WORX patrones · curva de aprendizaje del Sherpa Guide en este cliente · economía de seats SherpaX en bloque |
| **Quién decide rango (50% vs 60%)** | Sherpa Guide propone tras scoping del proyecto del equipo #2 → ratifica Victor |
| **Entregables** | Iguales a SKU 1.1 sobre el equipo #2, más integración con el ecosistema instalado del equipo #1 |
| **Dependencias** | Lab equipo #1 cerrado y rúbrica firmada · ecosistema del equipo #1 operando establemente (M3+ recomendado) · cumple las 3 condiciones T-5 sobre el equipo #2 |
| **Caso de uso típico** | Cliente con SO-HiORG instalado en un equipo y un CIO/CEO que quiere replicar a otra área operativa concreta |

### 3.3 SKU 1.3 — Lab equipos #3+ (Modelo A)

| Campo | Valor |
|---|---|
| **SKU** | 1.3 |
| **Nombre** | Lab equipos #3, #4, #N — Modelo A (EL facilita) |
| **Unidad** | 1 equipo nuevo (a partir del 3°) + 1 proyecto vivo nuevo |
| **Duración** | 40 días (estándar) o 30 días (curva de aprendizaje del Sherpa Guide en el cliente) — decisión @Sherpa Guide + @Victor |
| **Pricing referencia** | **30–40% de `[Lab inicial]`** — ajustable por complejidad de los proyectos del nuevo equipo. Ratificado @Victor 2026-04-25. |
| **Lógica del descuento** | Curva de aprendizaje madura · ecosistema bien instalado · Sherpa Guide ya conoce el cliente · onboarding del equipo nuevo más rápido |
| **Entregables** | Iguales a SKU 1.2 |
| **Dependencias** | Equipos #1 y #2 con ecosistemas instalados estables · cliente con cadencia de gobierno propia del ecosistema (M6+) |
| **Riesgo de canibalización con Modelo B** | Si el cliente se está acercando a "muchos equipos en cola" → conversación de Modelo B (SKU 1.4) explícita. La regla canónica: **a partir del equipo #4, evaluar Modelo B con el cliente**. |

### 3.4 SKU 1.4 — Tier Train-the-Trainers (Modelo B)

| Campo | Valor |
|---|---|
| **SKU** | 1.4 |
| **Nombre** | Tier Train-the-Trainers — Modelo B |
| **Unidad** | 1 cohorte de facilitadores internos del cliente (3-6 personas) |
| **Duración** | Programa de certificación 6-12 semanas + auditoría EL del ecosistema |
| **Componentes** | (1) Currículum de certificación de facilitadores internos · (2) Auditoría EL del ecosistema instalado del cliente (gate obligatorio) · (3) Acompañamiento del primer Lab corrido por facilitadores certificados (tutela) · (4) Re-certificación anual obligatoria |
| **Pricing referencia** | Fee de certificación inicial `[orientación @Victor]` + royalty por equipo certificado posterior `[orientación @Victor]` + fee anual de re-certificación `[orientación @Victor]`. Calibrado para que el cliente no encuentre arbitraje contra Modelo A barato → Modelo B no debe ser "más barato que Modelo A" en horizonte 24 meses |
| **Gate de certificación** | **Certificación EL del ECOSISTEMA INSTALADO** (método + arquitectura + gente puestos a punto), NO solo certificación de personas. Sin esa certificación EL del ecosistema, el cliente no puede ostentar "ejecución certificada SO-HiORG" y EL no responde por resultados. |
| **Entregables** | (a) facilitadores internos certificados · (b) ecosistema certificado anualmente · (c) playbook de replicación del cliente · (d) acceso a actualizaciones del método |
| **Dependencias** | Cliente con ≥ 2 Labs cerrados bajo Modelo A · cliente con cuerpo operativo capaz de sostener facilitadores internos · pipeline de equipos del cliente que justifique inversión |
| **Riesgo principal** | Dilución de método si la certificación es laxa. Mitigación: gate de auditoría EL no negociable + re-certificación anual + telemetría obligatoria del ecosistema instalado del cliente compartida con EL |
| **Quién lo ejecuta** | Programa de certificación corrido por EL central. Auditoría ejecutada por Sherpa Guide senior + Victor o delegado. Re-certificación = mismo equipo |

### 3.5 SKU 1.5 — Auditoría EL del ecosistema instalado (gate Modelo B + control de calidad)

| Campo | Valor |
|---|---|
| **SKU** | 1.5 |
| **Nombre** | Auditoría EL del ecosistema instalado |
| **Unidad** | 1 auditoría completa de un ecosistema de cliente |
| **Duración** | 1-2 semanas |
| **Función dual** | (a) gate inicial de Modelo B · (b) re-certificación anual del cliente Modelo B · (c) opcional para clientes Modelo A que quieran sello de salud |
| **Entregable** | Reporte canónico de salud del ecosistema (3 capas + integración + adopción + telemetría) + plan de remediación si aplica + sello de certificación si pasa |
| **Pricing referencia** | `[orientación @Victor]` · fee fijo · ajustable por tamaño del ecosistema |
| **Dependencias** | Telemetría del ecosistema instalado disponible · acceso a equipo del cliente para entrevistas · acceso a Corp-Brain-OS y SherpaX del cliente para inspección |

---

## 4. Capa 2 — Subscription recurrente

### 4.1 SKU 2.1 — Acompañamiento M1-M12 (post-Lab)

| Campo | Valor |
|---|---|
| **SKU** | 2.1 |
| **Nombre** | Acompañamiento SO-HiORG M1-M12 |
| **Unidad** | 12 meses de operación viva del ecosistema instalado por el Lab |
| **Pricing referencia** | Subscription mensual o anual — `[orientación @Victor]` por equipo + asientos SherpaX adicionales · valor calibrado contra el `[Lab inicial]` para reflejar "operación viva del ecosistema" |
| **Componentes incluidos** | (1) Mantenimiento operativo del Corp-Brain-OS (hosting, updates, troubleshooting) · (2) Evolución del WORX según ritmo del equipo · (3) Soporte SherpaX (seats incluidos, training, evolución del agente) · (4) Cadencias de revisión de salud del ecosistema (mensual M1-M3, trimestral M4-M12) · (5) Account Lead asignado |
| **Lo que NO incluye** | Labs nuevos para equipos #2/#3+ (eso es SKU 1.2/1.3 · Capa 3) · auditoría completa del ecosistema (eso es SKU 1.5) · cambios estructurales de arquitectura del Corp-Brain-OS (cotización aparte) · activación de capas en otras divisiones (eso es expansión interna) |
| **Dependencias** | Lab inicial cerrado y rúbrica firmada · contrato de subscription firmado |
| **Términos** | Renovación M13+ requiere acuerdo explícito · cancelación con notice contractual (orientación @Victor) |
| **Quién lo ejecuta** | Account Lead (Victor + Jay hoy · rol a definir en v02 del producto) + Sherpa Guide en cadencias |

### 4.2 SKU 2.2 — Renovación M13+ (post-Año 1)

| Campo | Valor |
|---|---|
| **SKU** | 2.2 |
| **Nombre** | Renovación SO-HiORG (Año 2+) |
| **Unidad** | 12 meses adicionales · renovable |
| **Pricing referencia** | Subscription anual · `[orientación @Victor]` con escalamiento sobre 2.1 calibrado por crecimiento del ecosistema (XDocs · seats activos · capas en uso) |
| **Componentes** | Iguales a SKU 2.1 · más opcionalmente: revisión de evolución de método (versiones nuevas de WORX) · revisión de roadmap de SherpaX |
| **Dependencias** | Auditoría EL del ecosistema (SKU 1.5) recomendada al inicio del Año 2 · NPS / salud operativa demostrable |
| **Caso de uso típico** | Cliente con M12 cumplido, ROI claro, decisión de seguir |

---

## 5. Capa 3 — Expansión interna (más equipos / seats / capas)

Esta capa contiene los SKUs ya descritos arriba (1.2, 1.3, 1.4) más los add-ons de expansión que no requieren Lab nuevo:

### 5.1 SKU 3.1 — Expansión SherpaX seats (sin Lab nuevo)

| Campo | Valor |
|---|---|
| **SKU** | 3.1 |
| **Nombre** | Expansión de asientos SherpaX |
| **Unidad** | Bloque de seats adicionales para personas del cliente que NO estuvieron en el Lab original pero pertenecen al equipo o a equipos vecinos integrados al ecosistema |
| **Pricing referencia** | Fee por seat-mes o por bloque · `[orientación @Victor]` |
| **Lo que incluye** | Activación del seat · onboarding ligero del usuario · acceso al Corp-Brain-OS del cliente · soporte estándar |
| **Lo que NO incluye** | Capacitación profunda (eso requiere Lab) · cambios de WORX para el área de la persona |
| **Restricción** | Solo aplicable a personas integradas al equipo donde el ecosistema corre. **Personas fuera del scope del ecosistema → SherpaX Personal (otro producto, otro Room)** |

### 5.2 SKU 3.2 — Activación de capa en otra división (Lab acotado)

| Campo | Valor |
|---|---|
| **SKU** | 3.2 |
| **Nombre** | Activación de capa SO-HiORG en otra división del cliente |
| **Unidad** | 1 división nueva del cliente con su propio equipo + proyecto |
| **Función** | Cuando el cliente ya tiene SO-HiORG en una división y quiere activarlo en otra, sin que sea un Lab equipo #2 estricto |
| **Pricing referencia** | Estructura híbrida — fee fijo por integración con el Corp-Brain-OS existente + Lab acotado por el equipo nuevo (descuento Modelo A vigente) |
| **Caso de uso típico** | Cliente grande con múltiples divisiones · primera división tiene ecosistema · segunda división quiere activarse y aprovechar el Corp-Brain-OS compartido |

### 5.3 SKU 3.3 — Add-on Auditoría EL anual

(remite al SKU 1.5 · este es el contexto de uso recurrente para clientes Modelo A que quieren sello de salud)

---

## 6. Excepciones y casos comerciales especiales

### 6.1 Descuentos no estándar

Cualquier descuento fuera de los rangos canónicos (50–60% / 30–40% para Modelo A) requiere aprobación explícita de Victor caso por caso. Si un patrón de excepción se repite ≥ 3 veces → propuesta de canonización en CP-Catálogo v02.

### 6.2 Ajuste por complejidad

Los rangos 50–60% (#2) y 30–40% (#3+) se ajustan por complejidad de los proyectos del equipo nuevo. La complejidad la propone el Sherpa Guide tras scoping → ratifica Victor. Criterios de ajuste a la alta:

- Proyectos del equipo nuevo en dominio muy distinto al del equipo #1.
- Stack técnico del equipo nuevo no compatible con el Corp-Brain-OS instalado (requiere puentes nuevos).
- Equipo nuevo con resistencia operativa identificada en scoping.

Criterios de ajuste a la baja (dentro del rango):

- Equipo nuevo con proyectos altamente alineados al equipo #1 (mismo dominio, mismo método, mismo stack).
- Personas del equipo nuevo ya familiarizadas con SherpaX (seats vía SKU 3.1 antes del Lab).

### 6.3 Cliente que pide "solo SherpaX" o "solo Corp-Brain-OS"

Respuesta canónica (CP-Estrategia §2.4): **no se vende por separado**. Camino canónico: Piloto Accidental (SKU 0.2) o derivación a SherpaX Personal (Room aparte) si la persona es individuo y no organización contratante.

### 6.4 Cliente Modelo B que no pasa la auditoría

Si la auditoría EL (SKU 1.5) no certifica el ecosistema instalado, el cliente no puede ostentar "ejecución certificada SO-HiORG" y EL no responde por resultados de los Labs corridos por sus facilitadores internos. Camino: plan de remediación + re-auditoría tras 60-90 días. Si no se remedia → revocación de certificación + cliente vuelve a Modelo A.

### 6.5 Cliente que quiere comprar un Lab "para ver"

Camino: Piloto Accidental (SKU 0.2) con crédito 100% contra el Lab. NO Lab descontado. La integridad del SKU 1.1 es estructural — descontar el Lab inicial debilita el catálogo de todos los siguientes Labs (referencia rota).

---

## 7. Tabla resumen del catálogo

| SKU | Nombre | Capa | Unidad | Pricing referencia |
|---|---|---|---|---|
| 0.1 | EmpowerScan *(track Empowernomics)* | 0 | 1 sesión 90 min | Fuera de scope — track Empowernomics |
| 0.2 | Piloto Accidental | 0 | 1 piloto · 1 equipo · 1 proyecto · 2-4 sem | Fee bajo · crédito 100% contra SKU 1.1 |
| **1.1** | **Lab inicial SO-HiORG (equipo #1)** | **1** | **1 equipo · 40 días** | **`[Lab inicial]` — orientación @Victor caso por caso** |
| 1.2 | Lab equipo #2 (Modelo A) | 1 | 1 equipo · 40 días | **50–60% de `[Lab inicial]`** · ajustable por complejidad |
| 1.3 | Lab equipos #3+ (Modelo A) | 1 | 1 equipo · 40 días | **30–40% de `[Lab inicial]`** · ajustable por complejidad |
| 1.4 | Tier Train-the-Trainers (Modelo B) | 1 | 1 cohorte 3-6 facilitadores · 6-12 sem | Fee certificación + royalty + re-certificación anual · `[orientación @Victor]` |
| 1.5 | Auditoría EL del ecosistema | 1 | 1 auditoría · 1-2 sem | Fee fijo · `[orientación @Victor]` |
| 2.1 | Acompañamiento M1-M12 | 2 | 12 meses · subscription | Subscription mensual/anual · `[orientación @Victor]` |
| 2.2 | Renovación M13+ | 2 | 12 meses · renovable | Subscription anual · escalamiento sobre 2.1 |
| 3.1 | Expansión SherpaX seats | 3 | Bloque de seats · seat-mes | Fee por seat o por bloque · `[orientación @Victor]` |
| 3.2 | Activación de capa en otra división | 3 | 1 división nueva · Lab acotado | Híbrido: integración + Lab acotado · descuento Modelo A vigente |
| 3.3 | Auditoría EL anual recurrente | 3 | 1 auditoría/año | Mismo SKU 1.5 |

---

## 8. Reglas de combinación (qué SKU activa qué SKU)

- **SKU 0.2 (Piloto)** → activa SKU 1.1 (Lab inicial) con crédito 100% si avanza en 60 días.
- **SKU 1.1 (Lab inicial)** → activa obligatoriamente SKU 2.1 (Acompañamiento M1-M12) en el contrato.
- **SKU 1.1** + tiempo M3+ estabilizado → desbloquea SKU 1.2 (Lab equipo #2) y SKU 3.1 (asientos extra).
- **SKU 1.2 cerrado** → desbloquea SKU 1.3 (Labs equipos #3+).
- **A partir del equipo #4** → conversación obligatoria sobre SKU 1.4 (Modelo B) explícita con el cliente.
- **SKU 1.4 (Modelo B)** requiere previamente SKU 1.5 (auditoría · gate inicial) y la activa anualmente como recurrencia.
- **SKU 2.2 (Renovación M13+)** → recomienda SKU 1.5 (auditoría) al inicio del Año 2.

---

## 9. Lo que NO está en este catálogo

- **SherpaX Personal (B2O standalone).** Pertenece a un Room dedicado fuera de HIORG. Su catálogo será CP-SherpaXPersonal-Catalogo-vXX al abrir ese Room.
- **EmpowerScan como producto vendible.** Vive en track Empowernomics — aquí solo aparece como entrada al embudo HIORG.
- **WORX como MetaPlaybook universal.** Track separado (`project_worx_mpb`).
- **Servicios ad-hoc** (consultoría, talleres, conferencias, etc.) — no son producto SO-HiORG, son actividades comerciales separadas.

---

## 10. Cierre

Este catálogo es la única fuente de verdad para construir propuestas comerciales nuevas del SO-HiORG. Cualquier propuesta que no corresponda a un SKU listado o a una excepción autorizada caso por caso por Victor es señal de que algo del catálogo está faltando — abrir tensión en el room, no improvisar la propuesta.

**Próxima revisión esperada:** v02 tras 2-3 ejecuciones reales del Lab que permitan refinar valores absolutos de pricing con datos de mercado y completar los `[orientación @Victor]` con rangos canónicos.

---

*CP-HIORGS-Producto-Catalogo-v01 · IB-EL-EmpowerLabs/PB-EL-Project-Bank/PB-HiOrg-Hyperintelligent Org/ · 2026-04-25*
*Pieza canónica de Catálogo de SKUs del SO-HiORG. Derivada de CP-HIORGS-Producto-Estrategia-v01. Pricing estructural ratificado por D-014 + cierre tensión menor #3+ (2026-04-25). Sigue MePB-XX-CanonicalPiece-Schema-v01.*