Home / Checklists

11 — WhatsApp Business API + Números + Calentamiento

Índice de la página
  1. 01Cliente: Martín Rieznik / LevantArte
  2. Área: Stack de WhatsApp (provider + número + templates + calentamiento)
  3. 020. Definición de "done" para esta checklist
  4. 031. Pre-requisitos
  5. 042. Tareas
  6. 2.1 Comparativa de providers (BLOQUEANTE)
  7. 2.2 Cuenta WhatsApp Business API + verificación Meta
  8. 2.3 Compra del número
  9. 2.4 Números — mínimo 2 (principal + backup)
  10. 2.4b CRM de atención al cliente humana (separado del bot)
  11. 2.5 Plantillas de mensajes (templates aprobados por Meta)
  12. 2.6 Calentamiento gradual del número
  13. 2.7 Webhook entrante a Railway worker
  14. 2.8 Política de opt-out + cumplimiento
  15. 2.9 Costos por mensaje + monitoreo
  16. 2.10 Identidad visual del perfil WA Business
  17. 2.11 Documentación
  18. 053. Variables y posibilidades a anticipar
  19. 064. Multi-tenant: cómo se replica al cliente #2
  20. 075. Recursos y archivos relacionados
  21. 086. Notas y aprendizajes (post-mortem)
  22. 09CHANGELOG

Cliente: Martín Rieznik / LevantArte

Área: Stack de WhatsApp (provider + número + templates + calentamiento)

CHECKLIST FUNDACIONAL — bloquea estrictamente 10 (bot 1:1) y 12 (grupos WA). Decidir provider de WhatsApp Business API, contratar mínimo 2 números (1 principal + 1 backup), aprobar plantillas de mensajes con Meta, calentar el número primario gradualmente para evitar ban, dejar webhook conectado a Railway, e instalar CRM de atención al cliente humana sobre el mismo número (clarificado 2026-05-05: prioridad WA = números primero → bot 1:1 + CRM atención humana después). Sin esto, ni el bot ni los grupos ni el CRM funcionan.

Última actualización: 2026-05-05
Responsable principal (R): Eric
Aprobador (A): Jesús
Deadline: 24 may 2026 (calentamiento del 24 may al 7 jun = 14 días, suficiente para arrancar el 8 jun con número confiable)
Depende de: 01_INFRA_TECNICA.md (Railway worker para webhook)
Bloquea a: 10_BOT_WHATSAPP_1A1.md, 12_GRUPOS_WHATSAPP.md, 07_WEBINAR.md, 19_GO_LIVE_8_JUNIO.md

0. Definición de "done" para esta checklist

  • Provider de WhatsApp Business API decidido y contratado, comparativa documentada.
  • Cuenta WhatsApp Business API verificada con Meta Business + display name aprobado.
  • Mínimo 2 números activos: 1 principal calentado + 1 backup parqueado. Plan de añadir 3er secundario si volumen lo justifica (> 5000 conversaciones/semana).
  • CRM de atención al cliente humana decidido + integrado al mismo número WA (3 candidatos: Wati, Respond.io, Front).
  • Mínimo 5 plantillas de mensajes aprobadas por Meta (recordatorio pre-webinar, post-compra, etc.).
  • Calentamiento gradual ejecutado durante 14 días (días 1-7 conversaciones bajas, semana 2 escalado), métricas registradas.
  • Webhook entrante apuntando a Railway worker, recibe mensajes correctamente.
  • Política de opt-out documentada y operativa.
  • Documento de costos por mensaje (template vs sesión) en _CONFIG.md > whatsapp.

1. Pre-requisitos

# Pre-requisito Provisto por Estado
1 Meta Business Manager de TooAudience activo Jesús ✅ asumido
2 Tarjeta de crédito para pagar provider Jesús ✅
3 Railway worker para webhook entrante Eric (checklist 01) ⚠️
4 Decisión de país del número (AR vs US vs paraguas) Jesús ⚠️
5 Brand name "LevantArte" disponible en Meta para display Jesús ⚠️ verificar
6 Logo + descripción + URL de LevantArte para perfil de WA Business Martín ⚠️

2. Tareas

2.1 Comparativa de providers (BLOQUEANTE)

  • Tabla comparativa de 5 providers con pros/contras/costos. R: Eric + Cortex. Done cuando: tabla en _CONFIG.md > whatsapp_provider_comparison.
Provider Pros Contras Costo aprox
WhatsApp Cloud API (oficial Meta) Sin intermediarios, costo más bajo (paga solo a Meta), rate limits altos, soporte directo Meta. Mejor para escala multi-tenant. Setup más técnico (Eric tiene que armar webhook + media handling). Sin features de UI. $0.005-$0.075 por conversación (varía por país, AR ~$0.04). Sin fee del provider. Más barato a escala.
Twilio WhatsApp API Stack maduro, SDK Node/Python, docs excelentes, dashboard, fácil multi-tenant via subaccounts. Markup de Twilio sobre Meta (suele ser 2x). Algunos features tarde vs Cloud API. $0.005 markup + costo Meta. ~$0.08-0.10/msg AR.
360dialog BSP focado en LATAM, soporte español, calentamiento incluido en onboarding, buena UX para gestión de plantillas. Markup notable. Dependencia de un BSP intermedio. Setup demora días por verificación. ~€49/mes base + €0.05-0.10/msg.
Wati Inbox UI lista para closers humanos (handoff fácil), bots no-code (no nos sirve, ya tenemos bot propio). Caro a escala, UI lock-in. Multi-tenant no nativo. ~$49-99/mes/número + costos por msg.
MessageBird Plataforma enterprise omnichannel (WA + SMS + email), buena para multi-tenant. Overkill para nuestro caso, costoso, contratos enterprise. Custom pricing, generalmente caro.
  • DECISIÓN ASUMIDA RECOMENDADA: WhatsApp Cloud API (oficial Meta). Razones: (a) escala multi-tenant futura sin markups, (b) Eric tiene capacidad de armar el webhook, (c) costo 30-50% menor a Twilio a volumen, (d) sin lock-in con BSP. Backup mental: si Eric encuentra blocker técnico, switch a Twilio se hace en < 1 día (mismo modelo de templates, solo cambia el SDK). R: Jesús + Eric. Done cuando: decisión firmada en _CONFIG.md > whatsapp_provider.
  • Validar que el provider elegido soporta: webhooks entrantes, media (audio/imagen), templates, opt-out, billing detallado por conversación. R: Eric. Done cuando: checklist de features OK.

2.2 Cuenta WhatsApp Business API + verificación Meta

  • Crear/verificar Meta Business Manager de TooAudience. R: Jesús. Done cuando: BM verificado con domain + tax info.
  • Crear WhatsApp Business Account (WABA) dentro del BM. R: Eric + Jesús. Done cuando: WABA creada + visible en BM.
  • Verificación del business con documentos legales (CUIT TooAudience + recibo de servicios + URL del sitio). R: Jesús. Done cuando: status "Verified" en Meta Business.
  • Display name "LevantArte" solicitado a Meta. NOTE: Meta tarda 1-3 días en aprobar y a veces rechaza si el nombre no coincide con marca pública verificable. R: Eric. Done cuando: display name aprobado o alternativa elegida ("LevantArte by Martín" / "Martín Rieznik").
  • Foto de perfil + descripción + email + URL del perfil WA Business. R: Cortex (assets) + Eric (carga). Done cuando: perfil completo visible en WA.

2.3 Compra del número

  • Decisión de país del número: R: Jesús + Eric. Done cuando: decidido + documentado.
  • Opción A — AR (+54 9 11 …): pros: cercanía con audiencia, mayoría argentina; contras: costo por mensaje más alto en AR (~$0.04 conversación), DNI argentino necesario para portar/comprar.
  • Opción B — US (+1 …): pros: costos más bajos, fácil aprovisionar via Twilio/Cloud API; contras: leads pueden ver "número de USA" raro, posible desconfianza.
  • Opción C — Paraguas internacional / virtual (+44 / +52): pros: anonimato del país, fácil aprovisionar; contras: la audiencia argentina puede sospechar.
  • Recomendación asumida: AR (+54) por trust del avatar argentino. Si no hay DNI disponible, fallback a US.
  • Provisionar número vía Cloud API (link a un número físico/SIM) o vía Twilio (compra digital). R: Eric. Done cuando: número activo en WABA + recibe SMS de verificación.
  • Asociar número con WABA: pasar OTP, asignar PIN, configurar 2FA. R: Eric. Done cuando: número asociado.
  • Test de envío inicial: mandar mensaje desde el número a un personal de prueba. R: Eric. Done cuando: mensaje recibido OK.

2.4 Números — mínimo 2 (principal + backup)

  • Provisionar número PRINCIPAL + arrancar calentamiento (ver § 2.6). R: Eric. Done cuando: número activo + tier sube a GREEN en 14 días.
  • Provisionar número de RESPALDO del mismo país. NO calentar agresivo. Mantener "lazy warmup" con 2-5 mensajes/semana a contactos de prueba. R: Eric. Done cuando: número activo en WABA + parqueado + tier mantenido.
  • Documentar protocolo de failover: si número primario es baneado/limitado, en X minutos se cambia config + bot empieza a operar con número 2. R: Eric. Done cuando: runbook failover_wa_number.md listo.
  • Política de 3er número: agregar secundario activo si volumen sostenido > 5000 conversaciones/semana, o si el principal entra repetidamente en YELLOW. R: Eric. Done cuando: política decidida + documentada.

2.4b CRM de atención al cliente humana (separado del bot)

Clarificación 2026-05-05: hay 3 vías de atención que comparten el mismo número WA:
- Bot 1:1 (responde automático con LLM) — checklist 10
- CRM atención al cliente humana (humano del equipo TooAudience responde personalmente desde inbox bonito, NO es handoff de cierre) — esta sección
- Closer humano (handoff de venta) — checklist 15

El CRM es para soporte/atención (ej: "no llegó mi acceso", "tengo un problema con el pago", "puedo cambiar la fecha"). Es ortogonal al closer.

  • Decidir CRM de atención al cliente entre 3 opciones. R: Eric + Jesús. Done cuando: decisión firmada en _CONFIG.md > crm_atencion.
  • Opción 1 — Wati: pros: inbox UI lista, multi-agent, snippets, tagging, reportes; integra Meta Cloud API + Twilio. Contras: pricing por número de agente; lock-in suave; nicho LATAM medio.
  • Opción 2 — Respond.io: pros: omnichannel (WA + IG + email + SMS), workflow builder, AI assist; multi-tenant amigable. Contras: caro a escala, curva más empinada.
  • Opción 3 — Front: pros: experiencia "email pero para WA", colaboración tipo Slack, asignación clara, reportes maduros. Contras: caro, más enterprise; integración WA via partner.
  • Recomendación inicial: probar Respond.io o Wati en piloto (free trial) → decidir mes 2.
  • Integrar CRM al mismo número WA (no número paralelo). El CRM lee/escribe sobre el mismo phone_number_id que el bot 1:1. Política de turnos: si el bot entrega al CRM atención, el bot SE SILENCIA en esa conversación; cuando humano cierra ticket, bot puede retomar. R: Eric. Done cuando: integración probada con un caso real.
  • Workflow de atención humana paralelo al bot: definir intents que disparan handoff al CRM (no al closer): "no llegó mi acceso", "problema técnico", "quiero refund/devolución", "preguntas sobre cuenta/factura", "actualización de datos", "queja". R: Cortex. Done cuando: lista en recursos/handoff_crm_atencion.md.
  • Routing de tres vías desde el bot 1:1: cada turno el bot evalúa: ¿responde el bot? ¿manda al CRM atención? ¿manda al closer? Documentar en recursos/routing_3_vias.md. R: Cortex + Eric. Done cuando: lógica clarificada en sistema.
  • Asignar humanos al CRM atención: definir quién atiende soporte (rol distinto del closer — puede ser TooAudience interno, Cortex como first-line, escalation a Jesús). R: Jesús. Done cuando: 1 persona principal asignada + horarios + SLA documentados.
  • SLA de atención al cliente: respuesta humana ≤ 2 hrs en horario activo, ≤ 8 hrs fuera. Bot mantiene la conversación con respuestas pre-aprobadas mientras tanto. R: Jesús + Eric. Done cuando: SLA documentado + alertas activas.
  • Reportes del CRM: tickets abiertos/cerrados, CSAT post-atención, tiempo medio de resolución, top issues. Semanal a grupo interno. R: Cortex. Done cuando: report semanal sábado AM.

2.5 Plantillas de mensajes (templates aprobados por Meta)

Meta requiere que mensajes "outbound iniciados por business" usen templates pre-aprobados. Mensajes dentro de "ventana de servicio" (24hs después de que el lead escribió) son libres.

  • Catálogo de templates a crear (mínimo 5): R: Cortex. Done cuando: lista en R/WhatsApp/templates_catalogo.md.
    | Template ID | Categoría Meta | Propósito | Variables | Estado aprob. |
    |-------------|----------------|-----------|-----------|---------------|
    | recordatorio_webinar_lunes | UTILITY | Mandar lunes 14:00 a registrados | {{1}}=nombre, {{2}}=hora, {{3}}=link | ⚠️ pending |
    | link_webinar_pre_show | UTILITY | Mandar lunes 19:30 con link al webinar | {{1}}=nombre, {{2}}=link | ⚠️ |
    | pitch_taller_post_webinar | MARKETING | Mandar lunes 21:30 con link al /martin/taller | {{1}}=nombre, {{2}}=precio_actual, {{3}}=link, {{4}}=hora_corte | ⚠️ |
    | confirmacion_compra_taller | UTILITY | Post-pago | {{1}}=nombre, {{2}}=sku, {{3}}=link_grupo | ⚠️ |
    | recordatorio_clase_taller | UTILITY | Mié/jue/vie 19:30 a compradores | {{1}}=nombre, {{2}}=clase_n, {{3}}=link | ⚠️ |
    | replay_disponible | MARKETING | Martes a registrados que no asistieron | {{1}}=nombre, {{2}}=link_replay | ⚠️ |
    | apertura_membresia_jueves | MARKETING | Jueves 21:00 a compradores taller | {{1}}=nombre, {{2}}=precio, {{3}}=link | ⚠️ |
    | ultima_chance_viernes | MARKETING | Viernes 22:00 cierre ventana | {{1}}=nombre, {{2}}=link, {{3}}=hora_cierre | ⚠️ |

  • Crear templates en Meta WA Manager con texto + variables + categoría correcta. R: Eric. Done cuando: 8 templates submitted.

  • Esperar aprobación Meta (24-72h típicas). R: Meta. Done cuando: ≥ 5 templates con status "Approved" (mínimo viable para launch).
  • Re-trabajar templates rechazados: causas comunes: (a) categoría errónea (UTILITY vs MARKETING), (b) urls de tracking no permitidas en MARKETING fuera de ventana 24h, (c) lenguaje promocional excesivo en UTILITY. R: Cortex (rewrite) + Eric (resubmit). Done cuando: 8/8 aprobados.
  • Versionar templates en Git (templates/wa/*.json). R: Eric. Done cuando: archivos en repo.
  • Tabla de costos por template (Meta cobra distinto por categoría + país): R: Eric. Done cuando: tabla en _CONFIG.md > whatsapp_costs.
  • UTILITY conversation AR: ~$0.0224
  • MARKETING conversation AR: ~$0.0379
  • SERVICE conversation AR: $0 (lead inicia)
  • AUTHENTICATION AR: ~$0.0150

2.6 Calentamiento gradual del número

Meta penaliza números nuevos que envían mucho de golpe. Curva recomendada para evitar rate limit / ban.

  • Día 0 (24 may, prov del número): cero envíos masivos. Solo 5-10 mensajes manuales con cuentas conocidas (Eric, Jesús, Cortex test, Martín). R: Eric. Done cuando: respuestas recibidas (tier de calidad sube).
  • Días 1-3 (25-27 may): 20-50 conversaciones reales/día. Mensajes 1:1 con leads de prueba (cuentas amigas). Buscar respuestas (engagement positivo). R: Eric + Cortex. Done cuando: rate sostenido sin warnings de Meta.
  • Días 4-7 (28-31 may): 100-250 conversaciones/día. Empezar a integrar bot 1:1 con leads orgánicos del scraping de IG (con consentimiento). R: Eric. Done cuando: tier de calidad "GREEN".
  • Días 8-14 (1-7 jun): 500-1000 conversaciones/día. Empezar a usar templates aprobados con leads que ya optaron in. R: Eric. Done cuando: tier "GREEN" sostenido + 0 spam reports significativos.
  • Día 15 (8 jun) — LAUNCH: volumen pleno con ~1500-3000 conversaciones del primer webinar. R: Todos. Done cuando: webinar live + WA respondiendo sin throttling.
  • Métricas a registrar diariamente durante calentamiento: R: Eric. Done cuando: dashboard wa_warmup_dashboard con tabla.
  • Mensajes enviados / recibidos
  • Tier de calidad Meta (GREEN / YELLOW / RED)
  • Spam reports
  • Tasa de respuesta (% de outbound que reciben reply)
  • Latencia de envío (ms)
  • Política anti-ban: NUNCA enviar a números no opted-in. NUNCA enviar idéntico copy a > 100 personas (variar templates/variables). RESPETAR opt-outs inmediatamente. R: Eric + Cortex. Done cuando: política en _CONFIG.md > wa_compliance.

2.7 Webhook entrante a Railway worker

  • Endpoint en Railway worker /wa/webhook que recibe POST de Meta/Twilio. R: Eric. Done cuando: endpoint deployado + verificable con curl.
  • Verificación del webhook con Meta: token de challenge GET. R: Eric. Done cuando: Meta marca webhook como "Verified".
  • Subscribir a eventos necesarios: messages, message_status (delivered/read/failed), account_update. R: Eric. Done cuando: subscriptions activas.
  • Validación de signature (HMAC) en cada webhook recibido (anti-spoofing). R: Eric. Done cuando: requests sin signature válida son rechazados con 403.
  • Procesamiento idempotente (si Meta reenvía un msg, no duplicar). Usar wa_message_id. R: Eric. Done cuando: test de duplicado pasa.
  • Persistencia inmediata en mensajes_wa (incluso antes de procesar lógica del bot). R: Eric. Done cuando: mensaje queda guardado < 100ms.
  • Throughput target ≥ 50 msg/seg sostenido. R: Eric. Done cuando: load test pasa.
  • Alertas si webhook devuelve > 1% errores en 5 min. R: Eric. Done cuando: alerta configurada.

2.8 Política de opt-out + cumplimiento

  • Palabras opt-out: "STOP", "BAJA", "BORRAME", "NO MAS", "UNSUBSCRIBE". R: Cortex. Done cuando: lista en config.
  • Acción al detectar opt-out: bot responde "Listo, no te escribo más. Si querés volver, mandame START." + marca lead opted_out=true + remueve de grupos. R: Eric + Cortex. Done cuando: flow probado.
  • NO mandar templates marketing a leads opted_out (filtro pre-envío). R: Eric. Done cuando: regla aplicada en sender.
  • Re-opt-in con "START": lead manda "START" → bot responde + marca opted_out=false. R: Eric. Done cuando: flow probado.
  • Footer de opt-out en templates marketing: "Para no recibir más, escribí STOP". R: Cortex. Done cuando: incluido en templates.
  • Compliance RGPD-ish: política de privacidad publicada en sales pages + endpoint admin para borrar lead a pedido. R: Cortex (texto) + Eric (impl). Done cuando: ambos listos.
  • Logging de opt-outs auditable. R: Eric. Done cuando: tabla opt_out_log con timestamp + razón.

2.9 Costos por mensaje + monitoreo

  • Tabla de costos AR por categoría (UTILITY/MARKETING/AUTH/SERVICE) cargada en _CONFIG.md > whatsapp_costs. R: Eric. Done cuando: tabla actualizada.
  • Estimación de gasto mensual del piloto: 4 webinars × 1500 leads × 8 mensajes promedio = 48k mensajes/mes × $0.03 promedio = ~$1440/mes. R: Eric. Done cuando: estimación documentada + reportada a Jesús (entra en gastos compartidos 50/50).
  • Alerta de gasto si supera $X/día (umbral configurable, default $100/día). R: Eric. Done cuando: alerta a Slack/WA del equipo.
  • Reporte mensual de costos WA parte del balance 50/50 con Martín. R: Eric + Jesús. Done cuando: tabla en reporte.

2.10 Identidad visual del perfil WA Business

  • Foto de perfil: logo LevantArte 640x640 PNG. R: Cortex. Done cuando: foto cargada.
  • Nombre de display: "LevantArte" (o aprobado). R: Eric. Done cuando: visible.
  • Descripción (139 chars max): "La Ciencia de la Seducción. Webinars en vivo lunes 20hs ARG. Hablá con nosotros para reservar tu lugar." R: Cortex. Done cuando: cargada.
  • Email + URL: contacto@levantarte.com (o equivalente) + https://deacademia.com/martin/. R: Cortex + Eric. Done cuando: cargados.
  • Categoría de business: "Education" o "Coach". R: Eric. Done cuando: seleccionada.
  • Horarios de atención: Lun-Vie 9-21 ARG. R: Cortex. Done cuando: cargado.

2.11 Documentación

  • Runbook wa_operations.md con: cómo agregar template, cómo bumpear tier, cómo manejar warning de Meta, cómo failover a número 2. R: Eric. Done cuando: runbook en repo.
  • Diagrama de arquitectura WA → Cloud API → Webhook → Railway → Bot → Supabase. R: Eric. Done cuando: diagrama en docs/wa_architecture.md.
  • Cheat sheet para Cortex sobre cómo se redactan templates aprobables (lenguaje neutro, variables permitidas, no spammy). R: Cortex. Done cuando: doc.

3. Variables y posibilidades a anticipar

Escenario Plan B
Meta rechaza display name "LevantArte" Probar variantes: "LevantArte by Martín Rieznik", "Martín Rieznik". Si todas rechazadas, usar "TooAudience" + comunicar al lead "te escribimos desde TooAudience, partner de LevantArte".
Meta tarda > 5 días en verificar el business Backup BSP via 360dialog (más rápido en LATAM por verificación local). Asumir 2 semanas en peor caso.
Provider Cloud API tiene blocker técnico inesperado Switch a Twilio en < 1 día. Mismo modelo de templates. Markup vale por escapar del blocker.
Meta rechaza > 50% de templates Re-escribir con lenguaje más neutral (tono UTILITY incluso para algunos MARKETING). Categorizar todo como UTILITY donde se pueda. Usar SERVICE conversations (lead inicia) cuando posible.
Calentamiento muestra tier YELLOW/RED día 7 Pausar envíos masivos 48h. Solo conversaciones manuales con engagement alto. Re-escalar más lento (multiplicar por 1.5x en vez de 2x).
Número primario baneado en plena semana de webinar Failover en < 30 min: cambiar config WABA al número 2, reenviar último template aprobado a leads activos comunicando "nuevo número, agendá", el bot 1:1 sigue desde número 2. Pérdida estimada: 2-4 horas + algunos leads que no actualizan contacto.
Spam reports > 5% en primera semana Auditar copies (Cortex). Reducir frecuencia de envío. Agregar más variabilidad. Re-leer compliance. Si persiste, parar y rehacer estrategia.
Costos WA superan $100/día estimado Reducir frecuencia de templates marketing (priorizar UTILITY que es 40% más barato). Usar más SERVICE conversations (free). Negociar volumen con Meta (no realista en piloto).
WhatsApp Cloud API down (rare pero pasa) Status page de Meta + comunicar a leads via IG/Email mientras dura. SLA de Meta: 99.9%.
Webhook de Railway recibe burst (1000/seg) en pico de webinar Auto-scaling Railway + queue (BullMQ/Redis). Backpressure controlado.
Templates expiran sin renovar (Meta limpia inactivos) Cron mensual: re-validar templates en uso. Re-submit si caen.
Lead reporta nuestro número como spam a Meta Detectar via webhook account_update evento "quality drop". Pausar envíos a ese segmento + auditar.
Número de respaldo no se calienta Calentar de modo "lazy": aunque parqueado, mandar 2-5 mensajes/semana a contactos de prueba para mantener tier.
Leads escriben fuera de ventana 24h y bot quiere responder con marketing Bot detecta ventana cerrada → manda template UTILITY pre-aprobado ("hola {{1}}, vi tu mensaje, contame en qué te ayudo") → reabre ventana de servicio.
Cliente nuevo (multi-tenant) requiere número AR pero no tiene DNI Provisionar via Twilio AR (no requiere DNI físico, business verification suficiente).
Costos por país varían (cliente expande a México/España) Tabla de costos por país en _CONFIG.md. Estimación pre-launch por cliente nuevo.

4. Multi-tenant: cómo se replica al cliente #2

Qué hay que parametrizar para que esto sea reusable. Esta sección alimenta el SOP sop/lanzar-cliente/.

  • Variables a externalizar (en clients.config_json > whatsapp):
  • whatsapp.provider (cloud_api|twilio|360dialog)
  • whatsapp.waba_id (WhatsApp Business Account ID)
  • whatsapp.phone_number_id (ID de Meta del número)
  • whatsapp.phone_number_display (E.164 ej +5491178954321)
  • whatsapp.backup_phone_number_id
  • whatsapp.display_name, whatsapp.profile_url, whatsapp.profile_pic_url, whatsapp.profile_email, whatsapp.profile_description
  • whatsapp.templates[] (array de { template_id, name, category, language, variables[] })
  • whatsapp.opt_out_keywords[], whatsapp.opt_in_keywords[]
  • whatsapp.cost_per_msg.{country, utility, marketing, service, auth}
  • whatsapp.warmup_status (cold|warming|warm|hot)
  • whatsapp.daily_volume_target
  • whatsapp.alert_thresholds.{spend_per_day, spam_rate_pct, latency_ms}
  • Tabla wa_numbers en Supabase ya documentada en checklist 10 (1 número → 1 cliente).
  • Templates a guardar en sop/lanzar-cliente/templates/whatsapp/:
  • provider_decision_matrix.md (la comparativa de § 2.1)
  • templates_catalogo.md.template (los 8 templates universales con placeholders)
  • meta_business_verification_checklist.md
  • warmup_curve_14_dias.md (curva escalonada de calentamiento)
  • opt_out_compliance.md (política base)
  • failover_runbook.md (cómo cambiar a número de respaldo)
  • wa_architecture_diagram.md
  • Sustituciones automáticas (clone_client.py):
  • Provisionar nuevo WABA + número en Cloud API (semi-automatizado, requiere confirmación humana por verificación Meta)
  • Submit los 8 templates universales con nombre/marca del cliente nuevo (vía Cloud API REST)
  • Inicializar whatsapp.warmup_status='cold' + cron de calentamiento
  • Generar failover_runbook.md con números del cliente
  • Asociar wa_numbers row con client_id del cliente nuevo
  • Lo que NO se replica (cliente-específico): número físico (cada cliente tiene el suyo), display_name (marca propia), profile assets (logo/foto), curva de calentamiento real (cada cliente arranca de cold).
  • Riesgo crítico multi-tenant: si un cliente del paraguas TooAudience tiene tier RED por mal uso, NO afecta directo a otros clientes (cada WABA es independiente), pero Meta puede revisar el BM completo. Política: si un cliente entra en RED, suspender sus envíos hasta resolver. Documentar como kill-switch.

5. Recursos y archivos relacionados

  • 10_BOT_WHATSAPP_1A1.md — Bot consume el número WA + templates.
  • 12_GRUPOS_WHATSAPP.md — Grupos viven en el mismo número WA.
  • 01_INFRA_TECNICA.md — Railway worker + Supabase tablas.
  • 07_WEBINAR.md — Templates de recordatorio + post-CTA.
  • 13_PIXEL_TRACKING.md — Eventos de WA disparan CAPI.
  • ../02_PLAN_INTERNO_EQUIPO.md — Plan macro § 1.5 + § 12 riesgo "Bot WhatsApp rate-limited" mitigación.
  • WhatsApp Cloud API docs: https://developers.facebook.com/docs/whatsapp/cloud-api
  • Twilio WhatsApp docs: https://www.twilio.com/docs/whatsapp
  • 360dialog docs: https://docs.360dialog.com/
  • Best practices Meta: https://developers.facebook.com/docs/whatsapp/messaging-limits

6. Notas y aprendizajes (post-mortem)

Llenar después del primer ciclo. Estos aprendizajes son los que se llevan al SOP.

  • Vacío hasta primera ejecución (calentamiento del 24 may al 7 jun + go-live 8 jun).

CHANGELOG

  • 2026-05-05 — JT/Cortex — Creación inicial. Comparativa 5 providers, decisión Cloud API, calentamiento 14 días, 8 templates iniciales, opt-out, costos AR.
  • 2026-05-05 — JT — Refuerzo de prioridad: NÚMEROS PRIMERO, después bot + CRM. Sumada § 2.4b — CRM de atención al cliente humana (Wati/Respond.io/Front) integrado al mismo número WA, distinto del bot y del closer. Routing de 3 vías documentado.
← Anterior · 10
Bot WhatsApp 1:1