Home / SOP

00 — PLAYBOOK: Lanzar un Cliente Nuevo

Índice de la página
  1. 01SOP TooAudience multi-tenant
  2. 021. Filosofía del SOP
  3. 032. ¿Qué replica este SOP?
  4. 043. Roles en un launch
  5. 054. Línea de tiempo macro (cliente #2 en adelante)
  6. 065. Las 4 fases de un launch
  7. Fase A — Discovery & Acuerdo (Día -7 a Día -1)
  8. Fase B — Provisioning & Scraping (Día 0 a Día 1)
  9. Fase C — Construcción & Producción (Día 2 a Día 5)
  10. Fase D — Launch & Loop (Día 6 en adelante)
  11. 076. Cuándo este SOP NO aplica
  12. 087. Cómo evoluciona el SOP
  13. 098. Métricas del SOP (cómo sabemos que funciona)
  14. 109. Próximas acciones para cerrar v1.0
  15. 11CHANGELOG

SOP TooAudience multi-tenant

Cómo pasar de "firmamos a un cliente nuevo" a "primer webinar live en producción" en ≤ 5 días, partiendo del sistema piloto construido para Martín Rieznik.

Versión: 0.1 (pre-piloto)
Última actualización: 2026-05-05
Owner: Jesús (TooAudience)

1. Filosofía del SOP

  1. Multi-tenant desde día 1. No "vamos viendo si después se replica". El sistema YA está parametrizado. Replicar es ejecutar este playbook, no rediseñar.
  2. El cliente decide menos cosas de las que cree. Las únicas decisiones del cliente están en 03_DECISIONES_CLAVE.md. Todo lo demás está pre-definido por el sistema TooAudience.
  3. Lo que no se automatiza, se checklist-ea. Si requiere intervención humana, está en 01_RUNBOOK_NEW_CLIENT.md con responsable + tiempo estimado.
  4. El primer cliente es el más caro. Los siguientes pagan el sistema. Acumulamos templates con cada launch — esos templates bajan el costo del próximo.
  5. Si el SOP no aplica al cliente nuevo, no es el SOP el que falla — es el cliente equivocado. No hacer "excepciones" sin documentar; cada excepción es deuda técnica de SOP.

2. ¿Qué replica este SOP?

El sistema completo construido para Martín Rieznik:

Componente Replicable como Tiempo estimado
Quick Funnel (quiz + form + bifurcación) Nueva ruta /<slug>/ en tooaudience-paraguas (Vercel) 5 min
Sales pages (taller + membresía + replay + transferencia + checkout selector) Misma ruta, render parametrizado por client_config.json 5 min
Tracking (Meta Pixel + CAPI server-side + Supabase events + UTMs) Mismo schema multi-tenant client_id 0 min (ya está)
Bot WhatsApp 1:1 Mismo bot multi-tenant, nuevo número + nuevo system prompt 1 día (calentar número)
Bots de grupos (3 tipos) Mismo motor, nuevo client_id 5 min
50+ ads en Meta NUEVO: requiere material crudo del cliente 1 semana (sesión grabación)
Sales script + scorecards Misma metodología (agents/copywriter/ + agents/promise-engineer/) Output regenerado en horas
Pasarelas (4 plataformas × 6 SKUs) NUEVO: requiere cuentas del cliente 3-5 días (depende de aprobación)
Operación recurrente semanal (loop lun-sab) Mismo loop, ejecutado por mismo equipo recurrente

Conclusión: el camino crítico para lanzar al cliente #2 es (a) sesión de grabación + (b) cuentas de pasarelas. Todo lo demás se monta en horas.

3. Roles en un launch

Mismos roles que en Martín. No cambian.

Rol Persona Responsabilidad en un cliente nuevo
Estratega + Operación Jesús Cierra acuerdo, configura _CONFIG.md, orquesta lanzamiento, valida con cliente
Tech / DevOps / Bot Eric Ejecuta clone-script, provisiona Supabase + Railway + WA number, valida E2E
Cliente Firma decisiones de 03_DECISIONES_CLAVE.md, da accesos, graba sesiones, dicta webinars
Cortex (asistente) — Scraping marca, copies, ads, slides, monitoreo
Closer (se reasigna o se contrata) Handoff de leads calientes

4. Línea de tiempo macro (cliente #2 en adelante)

Día -7 (firma)        → Cuestionario 03_DECISIONES_CLAVE enviado al cliente
Día -3                → Cliente devuelve cuestionario completo + accesos pedidos
Día 0  (kick-off)     → _CONFIG.md llenado + clone-script ejecutado
Día 1                 → Scraping marca completa + análisis avatar/mecanismo/objeciones
Día 2                 → Sesión 1 de grabación (12 hooks) + Sesión 2 (10 objeciones) + Sesión 3 (oferta) + Sesión 4 (pitch membresía)
                      → (+ si modelo evergreen: GRABACIÓN ÚNICA de las 4 clases, opcional anticipar a este día o hacerlo el Día 6 con audiencia paga)
Día 3                 → Edición ads + sales pages + slides webinar + edición de la grabación única
Día 4                 → Bot WA configurado + grupos creados + pasarelas configuradas + tests E2E
Día 5                 → Soft launch (ads piloto $100/día) + ensayo
Día 6 (lunes)         → PRIMER LANZAMIENTO (live único de la grabación si Opción A, primer relanzamiento si Opción B)
Día 7+                → Loop semanal evergreen recurrente (replay automático sin cliente, salvo Q&A opcional)

Punto crítico: la sesión de grabación única (4-6 hrs) es el único compromiso semanal pesado del cliente. En modelo evergreen NO se repite cada semana. Si cliente no puede dedicar ~6hs en una semana → calendario se estira o el modelo no aplica.

5. Las 4 fases de un launch

Fase A — Discovery & Acuerdo (Día -7 a Día -1)

  • Llamada de discovery con cliente (1h)
  • Análisis preliminar de su marca (Cortex revisa YouTube + IG + ads históricos en 30 min)
  • Acuerdo comercial firmado (mismo modelo Martín 50/50, ajustable)
  • Cuestionario 03_DECISIONES_CLAVE.md → cliente lo devuelve completo
  • Cliente da accesos: Meta Business Manager + YouTube Studio + Hotmart productor + dLocal productor + datos transferencia

Fase B — Provisioning & Scraping (Día 0 a Día 1)

  • Llenar _CONFIG.md del cliente con respuestas del cuestionario
  • Ejecutar clone-script (provisiona Supabase + Railway + ruta Vercel + carpeta Drive)
  • Cortex arranca scraping completo (YouTube + IG + entrevistas + ads históricos)
  • Análisis: avatar profundo + mecanismo único + hooks candidatos + objeciones top
  • Eric configura número WA + arranca calentamiento (lleva 7-14 días en paralelo)

Fase C — Construcción & Producción (Día 2 a Día 5)

  • 4 sesiones con cliente en bloque (1 día completo si se puede)
  • Ads producidos: 25 reciclados winners + 10 orgánicos viralizados + 16 retargeting clips = 50+
  • Sales pages renderizadas (todas leen del config, cero código nuevo)
  • Bot WA con system prompt parametrizado de la voz del cliente
  • 3 bots de grupo activados
  • Pasarelas configuradas con 24 SKUs + transferencia
  • Slides webinar deck + pitch membresía
  • Test E2E desde dispositivo limpio

Fase D — Launch & Loop (Día 6 en adelante)

  • Primer webinar live
  • Operación semanal según clientes-tooaudience/<slug>/checklists/18_OPERACION_SEMANAL.md
  • Reporte mensual con KPIs + transferencia 50% del profit
  • Iteración: ajuste de ads, tests A/B, refresh creativo

6. Cuándo este SOP NO aplica

Algunos clientes no encajan. Detectar temprano evita mal-launch:

Señal Diagnóstico Acción
Cliente no tiene contenido de YouTube ni IG con tracción Sin material crudo para ads ni mecanismo único Rechazar o cobrar fase 0 de "construcción de marca" antes
Cliente no quiere ni siquiera 1 sesión de grabación única (~6 hrs en una semana) Sin grabación, no hay producto evergreen ni live Rechazar
Cliente vende productos < $20 USD ticket Margen no cubre comisiones + ads Rechazar
Cliente quiere control 100% de la operación Imposible — TooAudience opera, cliente valida Rechazar
Cliente tiene cuenta Meta baneada históricamente Riesgo de baneo de TooAudience por asociación Rechazar
Nicho prohibido por Meta sin posicionamiento posible (armas, crypto agresivo, multinivel) No se puede pautar Rechazar

7. Cómo evoluciona el SOP

Versión Cuándo Qué se actualiza
v0.1 Pre-launch Martín (hoy) Templates iniciales basados en plan de Martín
v1.0 Post-mortem Martín (sáb 13/6) Aprendizajes del primer launch real → ediciones a templates + checklists
v1.1 Post primer cliente #2 Ediciones del segundo caso
v2.0 5 clientes en producción Refactor mayor + clone-script v2 (más automatización)

8. Métricas del SOP (cómo sabemos que funciona)

Métrica Target v1.0 Target v2.0
Tiempo "firma → primer webinar live" ≤ 14 días ≤ 5 días
% de pasos manuales vs automatizados 60/40 20/80
Reúso de copy del cliente anterior 0% (cada cliente único) 0% (igual)
Reúso de infra/schema/bot 100% 100%
Costo de provisioning por cliente nuevo (Vercel + Supabase + Railway + DNS + WA setup) < $50 USD < $30 USD
Cliente puede arrancar sin Eric pasando >2hs No (v1) Sí (v2)

9. Próximas acciones para cerrar v1.0

Estas tareas se ejecutan después del primer launch de Martín, durante el post-mortem y los días siguientes.

  • Eric: construir clone_client.py con steps automatizables (provisioning Supabase + Railway + ruta Vercel + carpeta clientes-tooaudience).
  • Jesús: capturar aprendizajes del Día 2 de Martín (sesión grabación) → mejorar oferta.template.md y webinar_guion.template.md.
  • Cortex: extraer copy patterns que funcionaron de los 50 ads de Martín → mejorar ad_brief.template.md.
  • Jesús: documentar negociación 50/50 que funcionó con Martín → carpeta sop/comercial/contratos/.
  • Eric: documentar lecciones del setup de WA Cloud API → mejorar checklist 11_WHATSAPP_API_NUMEROS.md.
  • Todos: revisar 19 checklists de Martín y marcar qué tareas son 100% replicables vs cliente-específicas.

CHANGELOG

  • 2026-05-05 — JT — v0.1 inicial. Estructura del playbook + 4 fases + métricas. Pre-launch Martín.
  • 2026-05-05 — JT — Modelo default cambia a EVERGREEN. Día 6 ya no es "primer webinar live cada semana", es "primer lanzamiento" (live único o relanzamiento). Loop semanal post-launch: replay automático, cliente NO dicta cada semana. Tabla "Cuándo no aplica" actualizada (live recurrente cada semana ya no es razón de rechazo; ahora la razón es no querer ni siquiera la sesión única de grabación).
← Anterior · 00
README