## Asset Header

- **Asset ID:** SOP-MPX-CHTSM-ImplementationGuide-v01
- **Version:** v01
- **Status:** Draft
- **Owner:** Victor Heredia
- **IntellBank:** IB-MPX-MasterPlaybooks
- **Tipo:** SOP — Standard Operating Procedure
- **Propósito:** GUÍA DE IMPLEMENTACIÓN
- **Última actualización:** 2026-04-11

---

# GUÍA DE IMPLEMENTACIÓN
## MTB-CHTSM v1.1 — Canonical High-Ticket Sales MetaPlaybook
### Para el Líder del Proyecto

---

**Documento:** MTB-IMPL-GUIDE-001
**Versión:** 1.0
**Fecha:** Marzo 2026
**Asset ID:** MP-DAC-CHTSM-001 / MP-DAC-CEM-001
**Clasificación de Riesgo:** R3 — Revenue-Critical Infrastructure
**Propietario:** Victor Heredia — Master Playbooks

---

## ÍNDICE

- PARTE I — Contexto y Arquitectura
  - Sección 1: Posicionamiento dentro del BigMetaFactory
  - Sección 2: Componentes del Sistema
  - Sección 3: Mapa de Integración de Capas L0–L6
- PARTE II — Proceso de Implementación
  - Sección 4: Pre-requisitos y Configuración Inicial
  - Sección 5: Proceso del Experto para Generar su MasterPlaybook
  - Sección 6: Integración con CRM
  - Sección 7: Configuración Operativa del AI Sherpa
  - Sección 8: Integración CEM ↔ CHTSM
- PARTE III — Modelo Piloto
  - Sección 9: Esquema de Piloto — Fases de Validación
  - Sección 10: KPIs y Métricas de Control
- PARTE IV — Roadmap
  - Sección 11: Roadmap Detallado Paso a Paso

---

# PARTE I — CONTEXTO Y ARQUITECTURA

---

## Sección 1: Posicionamiento dentro del BigMetaFactory

### 1.1 ¿Qué es el BigMetaFactory (BMF)?

El BigMetaFactory (BMF) es la arquitectura de gobernanza L0–L6 que convierte el conocimiento experto de Victor en un sistema operativo de negocios replicable, AI-nativo y auditado. No es una colección de documentos: es una cadena de producción de inteligencia operacional.

```
L0 → Fundación Estratégica (Visión, ICP, Oferta Canónica)
L1 → Taxonomía y Clasificación (Tipos de MetaPlaybook, Convenciones)
L2 → Domain MetaFactory (CHTSM — Protocolo de Ventas High-Ticket)
L3 → Factory Orchestration (CEM — Mapa de Eventos de Conversión)
L4 → Separación Humano/AI (Skill-Level Decomposition)
L5 → Control Loop Medible (Métricas, Scoring, Dashboards)
L6 → Mutation Governance (Versionado, Patch Protocol, Certificación)
```

### 1.2 Posición del CHTSM v1.1 en el BMF

El MTB-CHTSM opera en **Capa L2 — Domain MetaFactory**. Es la autoridad canónica de ventas: define el lenguaje, el protocolo de calificación, la arquitectura de objeciones y la cadencia de seguimiento para el proceso de venta de la oferta principal ($25K–$75K, Milestone-based).

| Componente | Capa | Función |
|---|---|---|
| MTB-CHTSM v1.1 | L2 | Autoridad canónica del proceso de ventas |
| MTB-CEM v1.0 | L3 | Orquestación de eventos y routing AI→Humano |
| AI Sherpa | L4 (AI) | Ejecución determinística de pre-calificación |
| Victor (Humano) | L4 (Human) | Strategy Validation + Final Close |
| CRM (HubSpot/etc.) | L5 | Panel de control y observabilidad |
| Versionado | L6 | Control de mutaciones, auditoría |

### 1.3 Flujo de Valor del Sistema Completo

```
PROSPECTO ENTRA
      ↓
[AI SHERPA] — Ejecuta CEM (L3)
  • Lee eventos del prospecto
  • Score RS + IFS + US + AAS
  • Si TS ≥ 40 y IFS ≥ 14 y RS ≥ 12 → ESCALATE
      ↓
[VICTOR] — Ejecuta CHTSM (L2)
  • Strategy Validation Call
  • Manejo de objeciones canónico
  • Final Close
      ↓
[CRM] — Registra disposición (L5)
  • Tags CEM/CHTSM aplicados
  • Pipeline actualizado
  • Métricas capturadas
      ↓
[CONTROL LOOP] — Observa y ajusta (L5/L6)
  • Review semanal de scoring
  • Patch protocol si hay deriva
```

---

## Sección 2: Componentes del Sistema

### 2.1 MTB-CHTSM v1.1 — Canonical High-Ticket Sales MetaPlaybook

**Asset ID:** MP-DAC-CHTSM-001
**Tipo:** Type D — Structural Authority Engine
**Propósito:** Protocolo canónico de ventas para la oferta Demand & Conversion MetaFactory Deployment

**Secciones Clave:**
- Section 0: BMF Governance Layer (Registro canónico, Interfaz cross-factory, Clasificación de riesgo)
- Section I: Domain Definition & Strategic Foundation (ICP, Oferta, Transformación)
- Section II: Transformation Architecture (Resultado prometido, Milestones)
- Section III: Qualification System (Scoring de 3 etapas)
- Section IV: Objection Architecture (Árboles de objeción canonizados)
- Section V: Sales Call Protocol (Discovery, Validation, Close)
- Section VI: Follow-Up & Escalation Protocol (Cadencia post-call)
- Section VII: Metrics & Control (KPIs, Dashboard, Umbrales de deriva)
- Deployment Certification Block (Firma de compliance)

### 2.2 MTB-CEM v1.0 — Conversion Event Map

**Asset ID:** MP-DAC-CEM-001
**Tipo:** L3 Factory Orchestration
**Propósito:** Observar eventos del prospecto → Calcular score → Decidir routing AI/Humano

**Categorías de Eventos (48 eventos en total):**
- Educational Events (EE) — 12 eventos
- Intent Events (IE) — 14 eventos
- Maturity Events (ME) — 12 eventos
- Objection Events (OE) — 10 eventos

**Framework de Scoring:**
- RS (Readiness Score): 0–20
- IFS (Intent & Fit Score): 0–20
- US (Urgency Score): 0–10
- AAS (Authority & Access Score): 0–10
- **Total Score (TS): 0–60**
- **Umbral de Escalación: TS ≥ 40, IFS ≥ 14, RS ≥ 12**

### 2.3 AI Sherpa

**Rol:** Agente AI determinístico que ejecuta el CEM
**Skills AI (IDs):**
- SK-AI-QUAL-001 — Qualification Scoring
- SK-AI-EVENT-002 — Event Detection & Classification
- SK-AI-ROUTE-003 — Routing Decision Engine
- SK-AI-BRIEF-004 — Pre-Call Brief Generation
- SK-AI-FOLLOW-005 — Follow-Up Sequencing
- SK-AI-TAG-006 — CRM Tag Applicator
- SK-AI-NURTURE-007 — Nurture Path Selector
- SK-AI-REPORT-008 — Metrics Reporting
- SK-AI-VERSION-009 — Version Compliance Check

### 2.4 CRM — Sistema de Registro

**Función:** Panel de control operativo de L5
**Tags CRM Requeridos (CEM-driven):**
- `[DISPOSITION_ADVANCE]` — Prospecto avanza al siguiente estado
- `[MATURITY_LEVEL_1/2/3]` — Nivel de madurez AI
- `[BUDGET_SIGNAL_GREEN/YELLOW/RED]` — Señal de presupuesto
- `[DECISION_MAKER_CONFIRMED]` — Tomador de decisión confirmado
- `[PRE_CALL_BRIEF_COMPLETE]` — Brief pre-llamada generado
- `[OBJECTION_CATEGORY_X]` — Categoría de objeción detectada
- `[ESCALATE_TO_VICTOR]` — Trigger de escalación confirmado

---

## Sección 3: Mapa de Integración de Capas L0–L6

```
┌─────────────────────────────────────────────────────────────┐
│  L0 — FUNDACIÓN ESTRATÉGICA                                 │
│  • Oferta: Demand & Conversion MetaFactory Deployment       │
│  • Precio: $25K–$75K / Milestone-based                     │
│  • ICP: Founder-Led Service Business $1M–$5M ARR           │
│  • Transformación: Claridad operacional + AI Sales Engine   │
└──────────────────────────┬──────────────────────────────────┘
                           │
┌──────────────────────────▼──────────────────────────────────┐
│  L1 — TAXONOMÍA                                             │
│  • Tipo de Asset: Type D (Structural Authority Engine)      │
│  • Convenciones de ID: MP-DAC-[ASSET]-[NUM]                 │
│  • Protocolo de Versionado: vMAJOR.MINOR                    │
└──────────────────────────┬──────────────────────────────────┘
                           │
┌──────────────────────────▼──────────────────────────────────┐
│  L2 — DOMAIN METAFACTORY (CHTSM v1.1)                      │
│  • Protocolo de calificación 3-stage                        │
│  • Árbol de objeciones canonizado                           │
│  • Script de llamada: Discovery→Validation→Close            │
│  • Métricas y umbrales de control                           │
└──────────────────────────┬──────────────────────────────────┘
                           │
┌──────────────────────────▼──────────────────────────────────┐
│  L3 — FACTORY ORCHESTRATION (CEM v1.0)                     │
│  • Detección de 48 eventos de conversión                    │
│  • Scoring framework RS+IFS+US+AAS (max 60)                 │
│  • Decision tree: AI Route vs. Victor Route                 │
│  • Generación de Pre-Call Brief                             │
└──────────────────────────┬──────────────────────────────────┘
                           │
┌──────────────────────────▼──────────────────────────────────┐
│  L4 — SEPARACIÓN HUMANO/AI                                  │
│  • AI Skills: SK-AI-QUAL-001 ... SK-AI-VERSION-009          │
│  • Human Skills: SK-HU-DISC-001 ... SK-HU-AUDIT-007         │
│  • Victor: Strategy Validation + Final Close únicamente     │
└──────────────────────────┬──────────────────────────────────┘
                           │
┌──────────────────────────▼──────────────────────────────────┐
│  L5 — CONTROL LOOP MEDIBLE (CRM)                            │
│  • Tags CRM como señales observables                        │
│  • KPIs: Call-to-close rate, scoring accuracy, time-to-cal │
│  • Review semanal de métricas y deriva                      │
└──────────────────────────┬──────────────────────────────────┘
                           │
┌──────────────────────────▼──────────────────────────────────┐
│  L6 — MUTATION GOVERNANCE                                   │
│  • Patch Protocol: BMF Hardening Patches                    │
│  • Certification Block en cada asset                        │
│  • Control de versiones: CHTSM v1.1, CEM v1.0              │
│  • Auditoría trimestral obligatoria                         │
└─────────────────────────────────────────────────────────────┘
```

---

# PARTE II — PROCESO DE IMPLEMENTACIÓN

---

## Sección 4: Pre-requisitos y Configuración Inicial

### 4.1 Checklist de Variables Congeladas (Frozen Variables)

Antes de activar cualquier componente del sistema, confirmar que las siguientes variables están 100% definidas y no serán modificadas durante el piloto:

| Variable | Valor Frozen | Estado |
|---|---|---|
| Oferta Principal | Demand & Conversion MetaFactory Deployment | ✓ Frozen |
| Rango de Precio | $25,000 – $75,000 | ✓ Frozen |
| ICP | Founder-Led Service Business, $1M–$5M ARR | ✓ Frozen |
| Modelo de Duración | Milestone-Based | ✓ Frozen |
| Transformación | Claridad operacional + AI-deployable sales engine | ✓ Frozen |
| Touchpoints de Victor | Strategy Validation + Final Close | ✓ Frozen |
| MasterPlaybook Piloto | MasterPlaybook Híbrido (contenido + AI Sherpa) | ✓ Frozen |

> **REGLA CRÍTICA:** Ninguna variable frozen puede modificarse durante el Piloto Fase 1 (semanas 1–6). Cualquier cambio propuesto debe pasar por el Patch Protocol (L6) y documentarse como mutación formal.

### 4.2 Stack Tecnológico Requerido

**CRM (obligatorio):**
- HubSpot (recomendado) o CRM equivalente con capacidad de custom properties y tagging
- Debe soportar pipelines personalizados y campos de texto libre para scoring
- Acceso API para integración con AI Sherpa

**AI Sherpa (obligatorio):**
- Plataforma: Claude API (Anthropic) con acceso a herramientas/tools
- Capacidad de leer inputs de CRM y escribir tags de vuelta
- Acceso a los documentos CEM v1.0 y CHTSM v1.1 como knowledge base

**Comunicación (obligatorio):**
- Canal de email rastreable (para detección de eventos IE/EE)
- Integración con LinkedIn o equivalente (señales ME)
- Calendly o equivalente para scheduling de calls

**Documentación (recomendado):**
- Google Drive, Notion, o similar para almacenar:
  - MTB-CHTSM High Ticket Sales.docx (v1.1)
  - MTB-CEM Technical Design.docx (v1.0)
  - Pre-Call Briefs generados por AI Sherpa

### 4.3 Roles y Responsabilidades

| Rol | Persona | Responsabilidades |
|---|---|---|
| Líder de Proyecto | Victor Heredia | Aprobación de implementación, validation calls, final close |
| Operador AI | Designado | Monitoreo del AI Sherpa, review de scoring, aplicación de tags |
| Configurador CRM | Técnico/Operador | Setup de propiedades, pipelines, automatizaciones |
| Auditor BMF | Victor Heredia | Review semanal de métricas, aprobación de patches |

---

## Sección 5: Proceso del Experto para Generar su MasterPlaybook

Esta sección describe el proceso completo que un experto (Victor u otro experto en la fábrica) debe seguir para generar y activar su MasterPlaybook dentro del BMF.

### 5.1 Etapa 1 — Definición y Congelamiento de Variables (Semana 1)

El experto debe completar el cuestionario de Frozen Variables antes de construir ningún asset:

**Preguntas Obligatorias:**
1. ¿Cuál es exactamente la oferta high-ticket? (nombre, descripción en 1 párrafo)
2. ¿Cuál es el rango de precio y el modelo de engagement? (precio, duración, estructura)
3. ¿Quién es el ICP exacto? (industria, tamaño, síntomas, cargo del decisor)
4. ¿Cuál es la transformación prometida? (estado actual → estado futuro en 30–90 días)
5. ¿Cuándo y cómo interviene el experto en el proceso? (touchpoints humanos)
6. ¿Cuál es el modelo de delivery? (milestone-based, retainer, proyecto)

Una vez respondidas, estas variables se "congelan" y se registran en el Certification Block del CHTSM.

### 5.2 Etapa 2 — Construcción del CHTSM (Semana 1–2)

Con las variables congeladas, el experto (o su equipo) construye el MTB-CHTSM siguiendo la estructura canónica:

**Paso 2.1 — Section 0: BMF Governance Layer**
- Completar Registry Header (Asset ID, Versión, Fecha)
- Escribir L0 Alignment Statement (cómo este asset sirve la estrategia L0)
- Mapear Cross-MetaFactory Interface Map (qué otros assets consume/produce)
- Completar Deployment Certification Block con firma de compliance

**Paso 2.2 — Sections I–VII: Contenido Operativo**
- Section I: Definir dominio, ICP, oferta, transformación — verbatim de frozen variables
- Section II: Construir Transformation Architecture con milestones específicos
- Section III: Diseñar Qualification System (Stage 1 pre-cal, Stage 2 scoring, Stage 3 discovery)
- Section IV: Documentar Objection Architecture (mínimo 5 objeciones canónicas con respuesta)
- Section V: Escribir Sales Call Protocol (guión de Discovery, Validation, Close)
- Section VI: Definir Follow-Up & Escalation Protocol (cadencia y triggers)
- Section VII: Establecer Metrics & Control (KPIs, umbrales, dashboard)

**Entregables de Etapa 2:**
- MTB-CHTSM [NombreExperto].docx (versionado)
- MTB-CHTSM [NombreExperto].md (versión markdown para AI consumption)

### 5.3 Etapa 3 — Construcción del CEM (Semana 2–3)

Con el CHTSM definido, el experto construye el CEM como su capa de orquestación L3:

**Paso 3.1 — Event Taxonomy**
- Adaptar los 48 eventos estándar al contexto específico del experto
- Confirmar/ajustar los pesos de scoring para el ICP específico
- Documentar señales observables para cada evento en los canales disponibles

**Paso 3.2 — Decision Tree**
- Definir umbrales de escalación apropiados para el volumen esperado
- Confirmar touchpoints humanos vs. AI para el experto específico
- Documentar el Pre-Call Brief template que el AI Sherpa producirá

**Paso 3.3 — Nurture Paths**
- Definir 3 nurture paths (Maturity Level 1, 2, 3)
- Asignar contenido del MasterPlaybook Híbrido a cada path
- Establecer triggers de reactivación y descarte

**Entregables de Etapa 3:**
- MTB-CEM [NombreExperto] Technical Design.docx
- MTB-CEM [NombreExperto] Technical Design.md

### 5.4 Etapa 4 — Review y Certificación (Semana 3)

Antes de activar el sistema, el Líder del Proyecto realiza:

**Checklist de Certificación:**
- [ ] Todas las frozen variables están documentadas y firmadas en el Certification Block
- [ ] CHTSM contiene mínimo 5 objeciones canonizadas
- [ ] CEM tiene scoring configurado para todos los 48 eventos
- [ ] Decision tree tiene umbrales definidos y documentados
- [ ] CRM tiene todas las custom properties y pipelines configurados
- [ ] AI Sherpa tiene acceso a los assets y ha pasado test de smoke
- [ ] Pre-Call Brief template produce output legible y accionable
- [ ] Métricas de control están definidas en Section VII del CHTSM

---

## Sección 6: Integración con CRM

### 6.1 Configuración de Propiedades Personalizadas

El CRM debe tener las siguientes propiedades configuradas antes de activar el sistema:

**Propiedades de Scoring (CEM):**

| Propiedad | Tipo | Descripción |
|---|---|---|
| `cem_rs_score` | Número (0–20) | Readiness Score actual |
| `cem_ifs_score` | Número (0–20) | Intent & Fit Score actual |
| `cem_us_score` | Número (0–10) | Urgency Score actual |
| `cem_aas_score` | Número (0–10) | Authority & Access Score actual |
| `cem_total_score` | Número (0–60) | Total Score calculado |
| `cem_maturity_level` | Opción (1/2/3) | Nivel de madurez AI detectado |
| `cem_escalation_ready` | Booleano | Si cumple todos los umbrales |
| `cem_last_scored_date` | Fecha | Última fecha de scoring |

**Propiedades de Disposición (CHTSM):**

| Propiedad | Tipo | Descripción |
|---|---|---|
| `chtsm_stage` | Opción | pre-qual / qualified / discovery / validation / close / won / lost / nurture |
| `chtsm_objection_category` | Texto | Categoría de objeción principal |
| `chtsm_call_outcome` | Texto | Resultado de la última llamada |
| `chtsm_follow_up_sequence` | Opción | A/B/C/D según protocolo Section VI |
| `chtsm_close_date_estimated` | Fecha | Fecha estimada de cierre |

### 6.2 Configuración del Pipeline de Ventas

El pipeline CRM debe reflejar exactamente el flujo del CHTSM:

```
ETAPA 1: Pre-Qualification (AI)
   → Entrada: Lead nuevo
   → Exit Criteria: TS ≥ 40, IFS ≥ 14, RS ≥ 12

ETAPA 2: Qualified — AI Pre-Cal Completa
   → Entrada: Umbral CEM alcanzado
   → Exit Criteria: Pre-Call Brief generado y entregado a Victor

ETAPA 3: Discovery Call Scheduled
   → Entrada: Victor confirma llamada
   → Exit Criteria: Discovery Call completada

ETAPA 4: Strategy Validation
   → Entrada: Post-Discovery, fit confirmado
   → Exit Criteria: Propuesta entregada o Validation Call completada

ETAPA 5: Final Close
   → Entrada: Prospecto ha revisado propuesta
   → Exit Criteria: Decisión (Won/Lost/Nurture)

ETAPA 6A: WON — Client
ETAPA 6B: LOST — Archive
ETAPA 6C: NURTURE — Return to AI track
```

### 6.3 Automatizaciones CRM Requeridas

**Automatización 1 — Score Update Trigger:**
- Trigger: Campo `cem_total_score` actualizado
- Acción: Si TS ≥ 40 AND IFS ≥ 14 AND RS ≥ 12 → Mover a Etapa 2 + Notificar a Victor

**Automatización 2 — Pre-Call Brief Delivery:**
- Trigger: Contacto entra a Etapa 2 (Qualified)
- Acción: AI Sherpa genera Pre-Call Brief → Se entrega por email a Victor + Se adjunta al registro del contacto

**Automatización 3 — Follow-Up Sequence:**
- Trigger: Etapa 3 (Discovery Call Scheduled) + Resultado registrado
- Acción: Iniciar secuencia de follow-up A/B/C/D según outcome de Section VI del CHTSM

**Automatización 4 — Nurture Re-activation:**
- Trigger: Contacto en NURTURE + Nuevo evento IE o ME detectado
- Acción: Re-score CEM → Si nuevo TS ≥ 40 → Mover de vuelta a Etapa 1

### 6.4 Tags CRM y su Significado Operativo

| Tag | Trigger | Acción del Sistema |
|---|---|---|
| `[DISPOSITION_ADVANCE]` | Score alcanza umbral | Mover etapa + Notificar Victor |
| `[MATURITY_LEVEL_1]` | RS < 12 o IFS < 10 | Iniciar Nurture Path 1 (educación básica) |
| `[MATURITY_LEVEL_2]` | RS 12–15, IFS 10–13 | Iniciar Nurture Path 2 (casos de uso) |
| `[MATURITY_LEVEL_3]` | RS ≥ 16, IFS ≥ 14, TS < 40 | Iniciar Nurture Path 3 (urgencia y autoridad) |
| `[BUDGET_SIGNAL_GREEN]` | AAS ≥ 8 con señal presupuesto | Priorizar en queue de Victor |
| `[BUDGET_SIGNAL_YELLOW]` | AAS 5–7 | AI continúa nurturing financiero |
| `[BUDGET_SIGNAL_RED]` | AAS < 5 | Mover a Nurture Path 1 |
| `[DECISION_MAKER_CONFIRMED]` | Título = founder/CEO/owner | Aumentar prioridad |
| `[PRE_CALL_BRIEF_COMPLETE]` | Brief generado exitosamente | Desbloquear agenda de Victor |
| `[ESCALATE_TO_VICTOR]` | Todos los umbrales cumplidos | Notificación inmediata a Victor |

---

## Sección 7: Configuración Operativa del AI Sherpa

### 7.1 Estructura del Prompt del AI Sherpa

El AI Sherpa debe ser configurado con el siguiente contexto mínimo:

**Knowledge Base Requerida:**
1. MTB-CEM Technical Design.md (verbatim)
2. MTB-CHTSM High Ticket Sales.md (Section III y Section 0 como mínimo)
3. Definición del ICP congelado
4. Template de Pre-Call Brief

**Instrucciones del Sistema (System Prompt del AI Sherpa):**

```
Eres el AI Sherpa para el sistema de ventas de Master Playbooks.
Tu función es ejecutar el Conversion Event Map (CEM v1.0) de manera determinística.

CONTEXTO:
- Oferta: Demand & Conversion MetaFactory Deployment ($25K–$75K)
- ICP: Founder-Led Service Business ($1M–$5M ARR)
- Tu rol: Pre-calificación y routing. NO cierras ventas.

PROCESO:
1. Lee los eventos disponibles del prospecto (emails, LinkedIn, contenido consumido, calls previas)
2. Clasifica cada evento según la taxonomía CEM (EE/IE/ME/OE)
3. Calcula RS, IFS, US, AAS según pesos documentados
4. Evalúa: TS ≥ 40, IFS ≥ 14, RS ≥ 12?
   - SI → Genera Pre-Call Brief + Aplica tag [ESCALATE_TO_VICTOR]
   - NO → Determina Maturity Level + Asigna Nurture Path
5. Aplica tags CRM correspondientes
6. Documenta razonamiento en campo de notas del CRM

RESTRICCIONES:
- No improvises. Sigue el CEM exactamente.
- No des precios ni cierres. Eso es territorio de Victor.
- Si hay ambigüedad sobre un evento, clasifícalo conservadoramente (peso menor).
- Actualiza scores solo cuando hay evidencia observable, no inferida.
```

### 7.2 Proceso de Handoff AI → Victor

Cuando el AI Sherpa confirma escalación, el handoff debe seguir este protocolo:

**Pre-Call Brief Template (generado por AI Sherpa):**

```
PRE-CALL BRIEF — [Nombre Prospecto]
Generado por: AI Sherpa | Fecha: [Fecha]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

SCORES ACTUALES:
  RS (Readiness):        [X]/20
  IFS (Intent & Fit):    [X]/20
  US (Urgency):          [X]/10
  AAS (Authority):       [X]/10
  TOTAL:                 [X]/60  ← Umbral: 40

CONTEXTO DEL PROSPECTO:
  Empresa: [Nombre]
  ARR Estimado: [Rango]
  Cargo: [Título]
  Pain Point Principal: [Descripción]

EVENTOS OBSERVADOS:
  • [Evento 1 — Categoría — Peso]
  • [Evento 2 — Categoría — Peso]
  • [Evento N — Categoría — Peso]

OBJECIÓN ANTICIPADA:
  Categoría: [X]
  Respuesta CHTSM Section IV recomendada: [Referencia]

PREGUNTAS SUGERIDAS PARA DISCOVERY:
  1. [Pregunta basada en pain point detectado]
  2. [Pregunta de urgencia basada en US signals]
  3. [Pregunta de autoridad/presupuesto basada en AAS]

SEÑALES DE ALERTA:
  [Si aplica: señales negativas detectadas]

RECOMENDACIÓN: AVANZAR A DISCOVERY CALL
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
```

### 7.3 Skills Humanas de Victor (CHTSM Section IV Reference)

**Skills Humanas Requeridas (SK-HU):**

| Skill ID | Nombre | Cuándo Se Activa |
|---|---|---|
| SK-HU-DISC-001 | Discovery Mastery | Discovery Call — primeros 20 min |
| SK-HU-FRAME-002 | Value Framing | Post-Discovery, pre-propuesta |
| SK-HU-OBJ-003 | Objection Resolution | Cuando prospecto plantea resistencia |
| SK-HU-AUTH-004 | Authority Establishment | Opening de cualquier llamada |
| SK-HU-CLOSE-005 | Closing Architecture | Últimos 10 min de Validation Call |
| SK-HU-FOLLOW-006 | Relationship Continuity | Follow-up post-call |
| SK-HU-AUDIT-007 | Deal Audit | Post-mortem de deals cerrados/perdidos |

---

## Sección 8: Integración CEM ↔ CHTSM

### 8.1 Puntos de Conexión entre CEM y CHTSM

El CEM (L3) consume y amplifica el CHTSM (L2). Los puntos de conexión son:

| CEM Output | CHTSM Input | Mecanismo |
|---|---|---|
| Escalation Score (TS ≥ 40) | Stage 3 Discovery Qualification | Tag [ESCALATE_TO_VICTOR] |
| Objeción detectada (OE) | Section IV — Objection Architecture | Tag [OBJECTION_CATEGORY_X] |
| Maturity Level 1/2/3 | Section VI — Follow-Up Protocol | Tag [MATURITY_LEVEL_X] |
| Pre-Call Brief | Section V — Sales Call Protocol | Entrega a Victor pre-call |
| Budget Signal | Section III — Stage 2 Scoring | Tag [BUDGET_SIGNAL_X] |
| Decision Maker Confirmed | Section III — Stage 1 Pre-Qual | Tag [DECISION_MAKER_CONFIRMED] |

### 8.2 Protocolo de Sincronización de Estados

Cuando Victor completa una llamada, debe registrar en el CRM:

**Post-Call Registration (obligatorio en < 30 min):**
1. Resultado de la llamada (avanzar / nurture / descarte)
2. Objeción principal planteada (categoría según CHTSM Section IV)
3. Próximo paso acordado con el prospecto
4. Ajuste de score si aplica (re-score manual justificado)
5. Flag de anomalía si el prospecto no coincide con el ICP congelado

Este registro permite que el AI Sherpa actualice su modelo y la siguiente interacción sea más precisa.

---

# PARTE III — MODELO PILOTO

---

## Sección 9: Esquema de Piloto — Fases de Validación

El piloto está diseñado para validar el sistema de manera controlada antes de escalar. Consta de 3 fases con criterios de salida claros.

### 9.1 FASE 1 — Configuración y Smoke Test (Semanas 1–2)

**Objetivo:** Tener el sistema en pie con configuración completa. Sin prospectos reales.

**Actividades:**
- Configurar CRM con todas las propiedades y pipelines
- Configurar AI Sherpa con knowledge base completa
- Crear 3 prospectos ficticios (Maturity Level 1, 2 y 3) y correr el CEM manualmente
- Verificar que los tags se aplican correctamente
- Verificar que el Pre-Call Brief se genera correctamente para el ML3
- Victor revisa 1 Pre-Call Brief y valida calidad

**Criterios de Salida Fase 1:**
- [ ] CRM configurado al 100% (propiedades, pipeline, automatizaciones)
- [ ] AI Sherpa produce Pre-Call Brief legible en test con prospecto ficticio ML3
- [ ] Tags se aplican correctamente en los 3 casos de prueba
- [ ] Victor aprueba la calidad del Pre-Call Brief
- [ ] No hay errores en las automatizaciones CRM

### 9.2 FASE 2 — Piloto Controlado (Semanas 3–6)

**Objetivo:** Procesar 5–10 prospectos reales a través del sistema completo.

**Reglas del Piloto:**
- Seleccionar prospectos que ya están en pipeline (no nuevos en frío)
- El Operador AI supervisa CADA scoring del AI Sherpa antes de que se apliquen tags
- Victor recibe Pre-Call Brief y valida antes de cada llamada
- Cada deal tiene un post-mortem de 30 min al finalizar

**Métricas a Capturar (semanal):**
- Número de prospectos procesados por AI Sherpa
- Número de escalaciones generadas
- Precisión del scoring (¿el score predijo correctamente el outcome?)
- Tiempo de Victor por prospecto (vs. sin el sistema)
- Calidad del Pre-Call Brief (rating 1–5 por Victor)
- Tasa de conversión Discovery → Propuesta
- Tasa de conversión Propuesta → Close

**Criterios de Salida Fase 2:**
- [ ] Mínimo 5 prospectos procesados completamente
- [ ] Scoring accuracy ≥ 70% (score predijo outcome correctamente)
- [ ] Pre-Call Brief rating promedio ≥ 4/5
- [ ] Al menos 1 deal cerrado o en etapa Final Close
- [ ] Tiempo de Victor reducido vs. proceso manual anterior
- [ ] Cero errores críticos en el sistema (datos perdidos, tags incorrectos)

### 9.3 FASE 3 — Optimización y Escalamiento (Semanas 7–10)

**Objetivo:** Ajustar el sistema basado en aprendizajes del piloto y preparar para escalar.

**Actividades:**
- Revisar todos los post-mortems de Fase 2
- Identificar patrones de scoring que no funcionaron
- Aplicar primer Patch Protocol (L6) si se requieren ajustes al CEM o CHTSM
- Documentar ajustes como mutaciones formales (versión 1.1 → 1.2 si aplica)
- Entrenar al Operador AI para operar con menor supervisión
- Crear SOP (Standard Operating Procedure) para el Operador AI

**Criterios de Salida Fase 3:**
- [ ] Scoring accuracy ≥ 80%
- [ ] Pre-Call Brief rating promedio ≥ 4.5/5
- [ ] SOP del Operador AI documentado y aprobado
- [ ] Primer Patch aplicado si fue necesario, documentado en L6
- [ ] Sistema listo para operar con Operador AI semi-autónomo

### 9.4 Registro de Aprendizajes del Piloto

Para cada prospecto procesado en el piloto, registrar:

| Campo | Descripción |
|---|---|
| ID Prospecto | ID anónimo del deal |
| Score CEM final | TS, RS, IFS, US, AAS |
| Maturity Level asignado | 1, 2 o 3 |
| Objeción principal | Categoría detectada |
| Outcome real | Won / Lost / Nurture |
| Predicción fue correcta | Sí / No / Parcial |
| Calidad del Pre-Call Brief | Rating 1–5 + notas |
| Tiempo de Victor | Minutos reales invertidos |
| Observaciones | Qué funcionó / qué no |

---

## Sección 10: KPIs y Métricas de Control

### 10.1 Dashboard Semanal del Líder del Proyecto

**Métricas Primarias (cada lunes):**

| KPI | Fórmula | Umbral Verde | Umbral Rojo |
|---|---|---|---|
| Scoring Accuracy | Predicciones correctas / Total | ≥ 75% | < 60% |
| Escalation Rate | Escalaciones / Prospectos totales | 10–30% | > 40% o < 5% |
| Pre-Call Brief Quality | Avg rating Victor (1–5) | ≥ 4.0 | < 3.0 |
| Discovery → Propuesta | Deals con propuesta / Calls | ≥ 50% | < 30% |
| Propuesta → Close | Deals cerrados / Propuestas | ≥ 25% | < 15% |
| Tiempo de Victor/deal | Minutos promedio por deal | ≤ 120 min | > 240 min |
| Deriva de Score | Variación promedio de TS | ≤ 5 pts | > 10 pts |

### 10.2 Señales de Alarma (Triggers de Revisión Inmediata)

Si se detecta cualquiera de lo siguiente, el Líder del Proyecto debe convocar una revisión dentro de las 48 horas:

- Scoring accuracy cae por debajo de 60% en 2 semanas consecutivas
- Victor rechaza más de 2 Pre-Call Briefs en una semana por calidad deficiente
- Se detectan prospectos escalados que no cumplen el ICP congelado
- Tasa de conversión Discovery → Propuesta cae por debajo de 30%
- El AI Sherpa aplica tags incorrectos en más de 3 prospectos en una semana

### 10.3 Protocolo de Review Semanal

**Cada lunes (30 min — Victor + Operador AI):**
1. Revisar dashboard de KPIs de la semana anterior
2. Revisar post-mortems de deals cerrados/perdidos
3. Identificar anomalías en scoring (¿algún score que no predijo bien?)
4. Decidir si se requiere un Patch Protocol (L6)
5. Actualizar prioridades de nurture paths según pipeline actual

---

# PARTE IV — ROADMAP

---

## Sección 11: Roadmap Detallado Paso a Paso

### SEMANA 1 — Fundación del Sistema

**Lunes:**
- [ ] Confirmar y documentar las 7 Frozen Variables en el Certification Block del CHTSM
- [ ] Designar al Operador AI (persona responsable de supervisar el AI Sherpa)
- [ ] Asignar acceso al Operador AI a los documentos CHTSM y CEM

**Martes–Miércoles:**
- [ ] Configurar CRM: crear todas las propiedades personalizadas (Sección 6.1)
- [ ] Crear el pipeline de ventas con las 6 etapas (Sección 6.2)
- [ ] Configurar automatizaciones CRM (Sección 6.3)

**Jueves:**
- [ ] Configurar el AI Sherpa: cargar knowledge base (CHTSM.md + CEM.md)
- [ ] Configurar system prompt del AI Sherpa (Sección 7.1)
- [ ] Crear template de Pre-Call Brief en el sistema

**Viernes:**
- [ ] Review del setup completo — Victor + Operador AI
- [ ] Documentar cualquier gap o ajuste necesario
- [ ] Aprobar para avanzar a Smoke Test

**Entregable de Semana 1:** CRM configurado + AI Sherpa configurado + Aprobación de Victor

---

### SEMANA 2 — Smoke Test

**Lunes–Martes:**
- [ ] Crear Prospecto Ficticio A (Maturity Level 1 — RS: 8, TS: 25)
- [ ] Correr CEM manual con el AI Sherpa
- [ ] Verificar que se asigna Nurture Path 1 y tags correctos

**Miércoles:**
- [ ] Crear Prospecto Ficticio B (Maturity Level 2 — RS: 14, TS: 35)
- [ ] Correr CEM manual
- [ ] Verificar Nurture Path 2 y tags

**Jueves:**
- [ ] Crear Prospecto Ficticio C (Maturity Level 3 — RS: 17, TS: 45 — escalación)
- [ ] Correr CEM manual → debe generar Pre-Call Brief
- [ ] Victor revisa Pre-Call Brief y da feedback

**Viernes:**
- [ ] Corregir cualquier problema detectado en smoke test
- [ ] Documentar ajustes realizados
- [ ] Confirmar criterios de salida Fase 1 cumplidos
- [ ] GO/NO-GO para Fase 2 (decisión de Victor)

**Entregable de Semana 2:** Smoke test aprobado + Pre-Call Brief validado por Victor

---

### SEMANA 3 — Inicio del Piloto Real (Fase 2)

**Lunes:**
- [ ] Seleccionar 3–5 prospectos reales del pipeline actual para el piloto
- [ ] Criterio de selección: prospectos en conversación activa que no hayan sido cerrados
- [ ] Briefing con Operador AI: proceso de supervisión semanal

**Martes–Viernes:**
- [ ] Para cada prospecto seleccionado:
  - [ ] Operador AI alimenta datos al AI Sherpa (historial de interacciones)
  - [ ] AI Sherpa genera score inicial
  - [ ] Operador AI revisa y aprueba (o ajusta) score
  - [ ] Tags aplicados al CRM
  - [ ] Para prospectos TS ≥ 40: generar Pre-Call Brief

**Entregable de Semana 3:** 3–5 prospectos en el sistema con scoring inicial

---

### SEMANA 4 — Primera Ronda de Llamadas con Pre-Call Brief

**Lunes:**
- [ ] Victor recibe Pre-Call Brief de prospectos escalados
- [ ] Victor valida cada brief (rating 1–5 + notas)
- [ ] Identificar gaps en el brief para feedback al Operador AI

**Martes–Jueves:**
- [ ] Victor realiza Discovery Calls usando protocolo CHTSM Section V
- [ ] Post-cada llamada: registrar en CRM (< 30 min post-call)
  - [ ] Outcome
  - [ ] Objeción principal
  - [ ] Próximo paso
  - [ ] Re-score si aplica

**Viernes:**
- [ ] Review semanal: Victor + Operador AI (30 min)
- [ ] Actualizar métricas del dashboard
- [ ] Primer ajuste de scoring si hay patrones evidentes

**Entregable de Semana 4:** Primera ronda de Discovery Calls completada con datos en CRM

---

### SEMANA 5 — Optimización de Scoring y Nurture

**Lunes–Martes:**
- [ ] Operador AI revisa todos los scores de prospectos en Nurture
- [ ] Verificar que las secuencias de nurture se están ejecutando (contenido del MasterPlaybook)
- [ ] Identificar prospectos en Nurture que hayan generado nuevos eventos IE/ME

**Miércoles–Jueves:**
- [ ] Re-score de prospectos con nuevos eventos
- [ ] Actualizar tags y etapas en CRM
- [ ] Para cualquier prospecto que cruce umbral: generar nuevo Pre-Call Brief

**Viernes:**
- [ ] Primer análisis de precisión de scoring
  - ¿Los prospectos escalados eran realmente buen fit?
  - ¿Algún prospecto en nurture debería haberse escalado antes?
- [ ] Documentar hallazgos para posible Patch Protocol

**Entregable de Semana 5:** Primera evaluación de precisión del scoring + Lista de posibles ajustes

---

### SEMANA 6 — Cierre del Piloto Fase 2

**Lunes–Miércoles:**
- [ ] Victor realiza Validation Calls / Final Close con prospectos en etapa avanzada
- [ ] Completar todos los post-mortems de deals del piloto
- [ ] Compilar todos los datos de métricas de Semanas 3–6

**Jueves:**
- [ ] Reunión de Review de Fase 2 (Victor + Operador AI — 60–90 min)
  - [ ] ¿Se cumplieron los criterios de salida de Fase 2?
  - [ ] ¿Qué funcionó bien?
  - [ ] ¿Qué necesita ajuste?
  - [ ] ¿Se requiere Patch Protocol?

**Viernes:**
- [ ] GO/NO-GO para Fase 3 (decisión de Victor)
- [ ] Si se requiere Patch Protocol: iniciar proceso L6

**Entregable de Semana 6:** Report de Fase 2 + Decisión de Fase 3

---

### SEMANA 7 — Optimización y Primer Patch Protocol (si aplica)

**Lunes–Martes:**
- [ ] Si se detectaron problemas en scoring: ajustar pesos del CEM
- [ ] Si el Pre-Call Brief tiene gaps: actualizar template
- [ ] Si el protocolo de objeciones no funcionó: enriquecer Section IV del CHTSM
- [ ] Documentar todos los cambios como mutaciones formales (L6)

**Miércoles:**
- [ ] Aplicar Patch Protocol formal:
  - [ ] Crear documento de Patch con descripción de cambios
  - [ ] Actualizar número de versión si aplica (v1.1 → v1.2)
  - [ ] Actualizar Deployment Certification Block
  - [ ] Re-generar versiones .docx y .md actualizadas

**Jueves–Viernes:**
- [ ] Re-correr smoke test con scoring actualizado
- [ ] Entrenar a Operador AI en los cambios
- [ ] Actualizar knowledge base del AI Sherpa con assets actualizados

**Entregable de Semana 7:** Assets actualizados (si Patch) + Operador AI re-entrenado

---

### SEMANA 8 — Documentación del SOP Operativo

**Lunes–Miércoles:**
- [ ] Operador AI redacta el SOP de operación diaria/semanal del sistema
- [ ] SOP debe incluir:
  - [ ] Proceso de scoring de prospectos nuevos (paso a paso)
  - [ ] Proceso de revisión y aprobación de scores
  - [ ] Proceso de generación y entrega de Pre-Call Briefs
  - [ ] Proceso de actualización de nurture sequences
  - [ ] Proceso de reporte semanal a Victor

**Jueves:**
- [ ] Victor revisa y aprueba el SOP
- [ ] Ajustes finales al SOP

**Viernes:**
- [ ] SOP publicado en base de conocimiento del equipo

**Entregable de Semana 8:** SOP Operativo aprobado por Victor

---

### SEMANA 9–10 — Escalamiento

**Semana 9:**
- [ ] Incorporar nuevos prospectos (más volumen)
- [ ] Operador AI opera con menor supervisión directa
- [ ] Victor solo recibe Pre-Call Briefs y notificaciones de escalación
- [ ] Monitoreo de métricas: ¿se mantienen dentro de umbrales?

**Semana 10:**
- [ ] Review final del piloto completo (10 semanas)
- [ ] Declarar sistema en producción o extender piloto
- [ ] Planificar primer ciclo de auditoría trimestral (Q2)
- [ ] Documentar aprendizajes en el registro L6

**Entregable Semana 10:** Sistema declarado en producción + Plan de auditoría Q2

---

## Resumen Visual del Roadmap

```
SEMANA 1    Fundación y Configuración del Sistema
SEMANA 2    Smoke Test (3 prospectos ficticios)
            ↓
            ✓ GO/NO-GO — Fase 2
            ↓
SEMANA 3    Incorporar 3–5 prospectos reales al sistema
SEMANA 4    Primera ronda Discovery Calls con Pre-Call Briefs
SEMANA 5    Optimización de scoring y nurture sequences
SEMANA 6    Cierre Fase 2 — Review y GO/NO-GO Fase 3
            ↓
            ✓ GO/NO-GO — Fase 3
            ↓
SEMANA 7    Patch Protocol (si aplica) — Ajustes al CEM/CHTSM
SEMANA 8    Documentación del SOP Operativo
SEMANA 9    Escalamiento — Mayor volumen, menor supervisión
SEMANA 10   Review Final — Declaración de Producción
            ↓
            ✓ SISTEMA EN PRODUCCIÓN
            ↓
Q2          Primera Auditoría Trimestral (L6)
```

---

## Criterios Finales de Éxito del Piloto

El piloto se considera exitoso cuando se cumplen TODOS los siguientes criterios al finalizar la Semana 10:

| Criterio | Umbral de Éxito |
|---|---|
| Scoring Accuracy | ≥ 80% |
| Pre-Call Brief Quality | Rating promedio ≥ 4.5/5 |
| Tiempo de Victor / deal | Reducción ≥ 40% vs. proceso manual |
| Discovery → Propuesta | ≥ 50% |
| Propuesta → Close (en piloto) | ≥ 1 deal cerrado |
| SOP documentado | Aprobado por Victor |
| Operador AI semi-autónomo | Sin supervisión diaria de Victor |
| Sistemas L6 activos | Versión, certificación, patch activos |

---

## Contacto de Soporte y Gobernanza

**Asset Owners:**
- MTB-CHTSM v1.1: Victor Heredia — victor@masterplaybooks.com
- MTB-CEM v1.0: Victor Heredia — victor@masterplaybooks.com

**Revisión Next Scheduled:**
- Control Plane Sync: Primer lunes de cada mes
- Auditoría Trimestral L6: Primer mes de cada trimestre
- Mutation Review: Cada vez que scoring accuracy < 70% o según necesidad

---

*Documento generado por el BigMetaFactory Control System | MTB-IMPL-GUIDE-001 v1.0*
*Clasificación: R3 — Revenue-Critical Infrastructure | Uso Interno*