Home / Checklists

10 — Bot WhatsApp 1:1 (Multi-tenant)

Índice de la página

Cliente: Martín Rieznik / LevantArte

Área: Bot conversacional 1:1 con voz de Martín

Extender el repo del bot 1:1 de TooAudience a multi-tenant: 1 bot procesa N clientes simultáneos, lee client_id por número de WhatsApp, system prompt parametrizable desde clients.config_json, voz de Martín extraída de YouTube, conoce oferta vigente y precios dinámicos, vende taller con urgencia honesta, hace handoff a closer humano cuando corresponde.

Última actualización: 2026-05-05
Responsable principal (R): Eric (infra) + Cortex (system prompt + copy + intents)
Aprobador (A): Jesús
Deadline: 31 may 2026 (testeo end-to-end con bot real entre 1-7 jun)
Depende de: 01_INFRA_TECNICA.md (Supabase + Railway), 11_WHATSAPP_API_NUMEROS.md (BLOQUEANTE ESTRICTO — números deben estar activos + calentados ANTES de arrancar este checklist), 08_OFERTA_Y_STACK.md (oferta firmada), 06_VIDEOS_YOUTUBE.md (transcripciones para voz)
Bloquea a: 12_GRUPOS_WHATSAPP.md, 07_WEBINAR.md (mensaje 19:30 link al webinar), 19_GO_LIVE_8_JUNIO.md
Bloqueante crítico: B1 del INDEX — Jesús pasar repo bot 1:1 a Eric.

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

Repo del bot 1:1 extendido a multi-tenant: lee client_id por número WA + carga system prompt de clients.config_json.
System prompt de Martín redactado, validado contra muestras de voz de YouTube + aprobado por Martín.
Bot detecta los 7 intents mínimos con confianza ≥ 0.75 en dataset de validación.
Bot ejecuta las 5 tareas operativas: registrar lead, invitar al grupo pre-webinar, recordar lunes, vender taller con urgencia honesta del precio escalonado, handoff a humano cuando intent = QUIERO_COMPRAR_PERO.
Cada mensaje (in/out) guardado en mensajes_wa con intent_detectado + lead_id + client_id.
Test E2E: usuario completa quiz → mensaje pre-llenado → bot responde < 60s → suena a Martín → invita a grupo → recuerda lunes → vende taller.
Dashboard de monitoreo: conversaciones activas, intents distribuidos, fallback rate, tiempo de respuesta promedio.
Fallback a humano cuando confidence < umbral (0.6) o intent fuera del catálogo.

1. Pre-requisitos

#	Pre-requisito	Provisto por	Estado
1	Repo del bot 1:1 entregado a Eric (B1 INDEX)	Jesús → Eric	⚠️ CRÍTICO
2	Supabase project `tooaudience-martin` con schema deployado	Eric (checklist 01)	⚠️
3	Railway service para workers del bot	Eric (checklist 01)	⚠️
4	Checklist 11 COMPLETO — número WA Business API activo + calentado (tier GREEN) + webhook + CRM atención humana decidido + 2 números mínimo (principal + backup)	Eric (checklist 11)	⚠️ BLOQUEANTE ESTRICTO
5	Oferta firmada en `_CONFIG.md > oferta`	Martín (checklist 08)	⚠️
6	Transcripciones de YouTube de Martín indexadas	Cortex (checklist 06)	⚠️
7	Top 10 objeciones rotas extraídas	Cortex (checklist 06)	⚠️
8	Mecanismo único nombrado	Martín (checklist 08)	⚠️
9	Closer humano on-call definido (quién atiende handoffs)	Jesús (checklist 15)	⚠️
10	API key de modelo LLM (OpenAI/Anthropic) en Railway env	Eric	⚠️

2. Tareas

2.1 Recibir y auditar repo del bot 1:1

Jesús pasa el path/repo del bot a Eric (BLOQUEANTE B1). R: Jesús. Done cuando: Eric tiene acceso de admin al repo.
Eric clona y audita estado actual: stack (Node/Python/etc), dependencias, qué hace hoy, qué le falta. R: Eric. Done cuando: doc audit_bot_actual.md con findings.
Identificar gaps multi-tenant vs estado actual (probable single-tenant). R: Eric + Cortex. Done cuando: lista de gaps en doc.
Plan de extensión: refactor incremental vs rewrite. R: Eric. Done cuando: decisión + estimación de horas.

2.2 Multi-tenant: 1 bot, N clientes

Tabla de routing wa_numbers en Supabase: (numero_wa_business, client_id, activo). Permite que 1 bot procese N clientes según el número que le mandan. R: Eric. Done cuando: tabla creada + seed con número de Martín → client_id=martin.
Webhook entrante desde provider WA → resuelve client_id por numero_destino antes de procesar. R: Eric. Done cuando: webhook devuelve client_id correcto en logs.
Cargar clients.config_json en memoria al startup + invalidar cache cada 5 min (para hot-reload de system prompts). R: Eric. Done cuando: cambio en config se refleja en bot < 5 min sin redeploy.
Aislamiento de contexto entre clientes: el bot NUNCA mezcla info de cliente A en conversación con cliente B. Test: 2 leads de clientes distintos en paralelo. R: Eric. Done cuando: test pasa.
Logs etiquetados con client_id en todo el pipeline (Railway logs + Supabase). R: Eric. Done cuando: query logs WHERE client_id='martin' devuelve solo Martín.

2.3 System prompt parametrizable

Schema de clients.config_json > bot_1a1 con campos: R: Cortex (specs) + Eric (impl). Done cuando: schema documentado en 01_INFRA_TECNICA.md.
bot_1a1.system_prompt (string largo)
bot_1a1.voice_samples[] (10 fragmentos textuales de voz del cliente)
bot_1a1.knowledge.{oferta_vigente, precios_dinamicos, beneficios_membresia, top_objeciones}
bot_1a1.intents[] (catálogo + ejemplos)
bot_1a1.fallback_human_phone (número del closer)
bot_1a1.confidence_threshold (default 0.6)
bot_1a1.no_canibalizar_dias (referencia checklist 08 § 2.8)
Cargar config dinámica en el prompt antes de cada inferencia. R: Eric. Done cuando: prompt construido tiene oferta del día (no estática).

2.4 System prompt de Martín (Cortex escribe, Martín valida)

Extraer 30 fragmentos textuales de transcripciones YouTube que muestren voz/tono. R: Cortex. Done cuando: R/Investigación/voz_martin_30_fragmentos.md.
Identificar tics verbales de Martín (palabras que repite, conectores, modismos argentinos). R: Cortex. Done cuando: lista de 20 tics documentada.
Redactar system prompt v1 con estructura: R: Cortex. Done cuando: prompt en decks/martin/bot/system_prompt_v1.md.
Identidad ("sos Martín Rieznik, fundador de LevantArte…")
Tono (cercano, directo, sin jerga PUA, autoridad ganada con resultados)
10 fragmentos de voz como ejemplos few-shot
Conocimiento: oferta vigente, precios escalonados, beneficios membresía
Top 10 objeciones rotas con respuesta
Reglas: NUNCA mentir / NUNCA prometer resultados específicos / NUNCA ofrecer Mentoría 1:1 dentro de 14 días post-membresía / SIEMPRE derivar a humano si confianza < umbral
Reglas de seguridad: bloquear menores, derivar consultas de salud mental a profesional
Validar con Martín: enviarle 5 conversaciones simuladas + pedirle "esto suena a vos sí/no". R: Cortex + Martín. Done cuando: 5 conversaciones aprobadas.
Iterar prompt v2/v3 hasta que 9/10 conversaciones suenen a Martín en blind test. R: Cortex + Martín. Done cuando: blind test ≥ 9/10.

2.5 Conocimiento del bot

Bloque oferta_vigente dinámico (lee _CONFIG.md > oferta actualizado). R: Eric + Cortex. Done cuando: cambio en config se refleja en respuestas.
Bloque precios_dinamicos: bot consulta lib/precio_dinamico.ts antes de cotizar (NUNCA precios hardcoded). R: Eric. Done cuando: test "¿cuánto sale el taller?" devuelve precio del día actual.
Bloque beneficios_membresia con tabla 3 modalidades. R: Cortex. Done cuando: respuesta a "qué incluye membresía" es completa.
Bloque top_10_objeciones con respuesta + frase de cierre extraídas de Martín. R: Cortex. Done cuando: 10 objeciones cubiertas.
Bloque casos_de_exito: 5 casos con resultado breve para citar (con permiso). R: Cortex + Martín. Done cuando: 5 casos disponibles.
Bloque comparativa_mentoria_vs_membresia para no canibalizar (checklist 08 § 2.8). R: Cortex. Done cuando: árbol de decisión cargado.

2.6 Hooks a Supabase

Función save_message(direction, contenido, intent, confidence, lead_id, client_id) → mensajes_wa. R: Eric. Done cuando: cada mensaje guardado con todos los campos.
Función update_lead_status(lead_id, nuevo_estado, source) → leads.estado_funnel. Actualiza estado conforme avanza la conversación. R: Eric. Done cuando: estados se actualizan correctamente.
Función register_intent(lead_id, intent_id, payload) → eventos con tipo=intent_detected. R: Eric. Done cuando: dashboard ve intents en vivo.
Trigger Supabase: cuando lead.estado_funnel='wants_to_buy' → notificar a closer humano via WA + email. R: Eric. Done cuando: trigger probado.
Sin pérdida de mensajes: si Supabase cae, queue local en Railway que reintenta. R: Eric. Done cuando: simulación de Supabase down + recovery sin pérdida.

2.7 Tareas operativas del bot

Tarea 1: Registrar lead (cuando llega primer mensaje). Crea fila en leads + saluda + pide nombre/edad/dolor (si no vino del quiz). R: Eric + Cortex. Done cuando: test OK.
Tarea 2: Invitar al grupo pre-webinar. Manda link de invitación al grupo + confirma con joined_group evento (referencia checklist 12). R: Eric + Cortex. Done cuando: lead aparece en miembros_grupo post-aceptación.
Tarea 3: Recordar el lunes. Cron: domingo 18:00 + lunes 14:00 + lunes 19:30 (link webinar) + lunes 19:55 (último call). R: Eric (cron) + Cortex (copy). Done cuando: 4 mensajes enviados a leads activos.
Tarea 4: Vender taller con urgencia honesta del precio escalonado. Post-webinar lunes 21:30: "comprá ahora a $5". Martes 00:01: "subió a $10, todavía estás a tiempo". Miércoles 00:01: "última chance a $15". Viernes 23:00: "1h para que cierre la ventana". R: Eric + Cortex. Done cuando: secuencia de 4 mensajes por crons activa.
Tarea 5: Handoff a closer humano cuando intent = QUIERO_COMPRAR_PERO. Bot dice "te paso con [closer], en 30 min te escribe" + dispara notificación al closer. R: Eric + Cortex. Done cuando: handoff probado E2E.

2.8 Detección de intents (mínimo 7)

Catálogo de intents v1 con descripción + ejemplos: R: Cortex. Done cuando: tabla en R/Bot/intents_catalogo.md.
| Intent | Descripción | Ejemplos | Acción del bot |
|--------|-------------|----------|----------------|
| SALUDO | Primer contacto, "hola" | "hola", "buenas", "🙋" | Saludo + invitar a quiz si no completó / al grupo si completó |
| PREGUNTA_OFERTA | Qué incluye, qué se enseña | "qué es esto", "qué ofrecés", "qué se aprende" | Pitch corto + invita al webinar |
| PREGUNTA_PRECIO | Cuánto sale | "cuánto sale", "qué precio tiene", "es caro?" | Precio dinámico + estructura escalonada + valor monetizable |
| OBJECION_X | Una de las 10 objeciones top | "no tengo tiempo", "ya probé otros métodos" | Respuesta extraída de Martín + frase de cierre |
| QUIERO_COMPRAR | Decisión clara | "quiero comprar", "dame el link", "cómo pago" | Link al /martin/taller con UTMs + 5 pasarelas + bot da soporte hasta confirmación de pago |
| QUIERO_COMPRAR_PERO | Intent de compra con fricción | "quiero pero no puedo pagar en USD", "necesito hablar con alguien" | Handoff a closer humano + notificación + lead status wants_to_buy_friction |
| NO_QUIERO | Rechazo / despedida | "no me interesa", "no gracias", "borrame" | Despedida amable + opt-out automático + remover de grupos |
| FUERA_DEL_SCRIPT | Algo que no cae en intents anteriores | "estás casado?", "tu hermano es Andrés?", consultas raras | Si confianza < 0.6 → handoff humano. Sino → respuesta corta + reconducir al webinar |
Implementar detector (LLM con few-shot o clasificador fine-tuned). R: Eric. Done cuando: detector funciona en sandbox con confidence score.
Dataset de validación con 100 mensajes anotados manualmente (10 por intent). R: Cortex. Done cuando: CSV con mensaje, intent_esperado listo.
Métrica accuracy ≥ 0.75 en dataset de validación. R: Eric. Done cuando: report de accuracy ≥ 75%.
Iterar prompt/fine-tune si accuracy < 0.75. R: Eric + Cortex. Done cuando: target alcanzado.

2.9 Fallback a humano

Umbral de confianza configurable por cliente (default 0.6). R: Eric. Done cuando: parámetro en config.
Trigger de handoff cuando: confianza < umbral O intent = QUIERO_COMPRAR_PERO O lead pide explícitamente "quiero hablar con humano". R: Eric + Cortex. Done cuando: 3 triggers funcionan.
Notificación al closer: WA + email con lead_id, conversación, último intent, payload. R: Eric. Done cuando: notificación llega < 30s post-trigger.
Bot en modo "esperando humano": deja de responder al lead hasta que closer marca take_over. Lead recibe "te paso con un asesor, en 30 min te escribe". R: Eric. Done cuando: bot silenciado + closer puede tomar.
Re-asignación si closer no responde en 2hs: backup closer recibe ping. R: Eric. Done cuando: cron de re-asignación activo.

2.10 Dashboard de monitoreo

Vista /admin/bot-conversaciones (Vercel admin route protegido por auth). R: Eric + Cortex. Done cuando: vista accesible para Jesús.
Métricas a mostrar: R: Cortex (specs) + Eric (impl). Done cuando: dashboard en vivo.
Conversaciones activas (últimas 24hs)
Distribución de intents (gráfico de torta)
Fallback rate (% de mensajes derivados a humano)
Tiempo de respuesta promedio bot (target < 30s)
Tasa conversión: SALUDO → PREGUNTA_PRECIO → QUIERO_COMPRAR → purchase
Top 10 objeciones del último mes (tendencia)
Errores del LLM (rate limits, timeouts)
Drill-down a conversación individual desde el dashboard. R: Eric. Done cuando: click en lead → ver historial + intents + status.
Alertas Slack/WA si: fallback rate > 30% / errores LLM > 5/min / conversación trabada > 24hs sin respuesta humana. R: Eric. Done cuando: 3 alertas configuradas.

2.11 Test E2E (antes del 31 may)

Test 1: Lead nuevo desde quiz. Completa quiz → bot saluda → invita al grupo → confirma. R: Cortex + Eric. Done cuando: test pasa < 90s.
Test 2: Pregunta de precio. Lead en martes pregunta "cuánto sale el taller" → bot responde "$10, mañana sube a $15". R: Cortex. Done cuando: precio dinámico OK.
Test 3: Objeción "no tengo tiempo". Bot responde con respuesta de Martín + cierra. R: Cortex. Done cuando: respuesta sale.
Test 4: Intent QUIERO_COMPRAR_PERO. Lead dice "quiero pero no acepto Hotmart" → bot dispara handoff + notifica closer. R: Cortex + Eric. Done cuando: closer recibe ping < 30s.
Test 5: Multi-tenant. Lead de cliente "fake_test" mensajea otro número WA → bot responde con system prompt distinto, NO con voz de Martín. R: Eric. Done cuando: aislamiento confirmado.
Test 6: Recordatorio lunes 19:30. Cron dispara mensaje a lead activo. R: Eric. Done cuando: mensaje enviado.
Test 7: Opt-out. Lead dice "borrame" → bot remueve de grupos + marca opted_out + no vuelve a contactar. R: Eric. Done cuando: lead silenciado.

2.12 Documentación

README del bot con: arquitectura, env vars, cómo levantar local, cómo deployar, cómo agregar cliente nuevo. R: Eric. Done cuando: README completo en repo.
Runbook de incidentes: qué hacer si LLM cae / si Supabase cae / si número WA bloqueado. R: Eric. Done cuando: docs/runbook.md.
Changelog del system prompt versionado (cada cambio: fecha, autor, motivo, diff). R: Cortex. Done cuando: docs/system_prompt_changelog.md.

3. Variables y posibilidades a anticipar

Escenario	Plan B
Repo del bot 1:1 nunca llega a Eric	Eric construye desde cero con el stack acordado (Node + WhatsApp Cloud API + Supabase + LLM). Pierde 1-2 semanas pero no bloquea launch. Plan B requiere extender deadline al 7 jun.
Voz de Martín suena artificial / "a ChatGPT"	Iterar system prompt con más fragmentos textuales + temperature 0.8 + retrieval-augmented (citar frases reales de YouTube). Si imposible, modo "asistente humano" sin pretender ser Martín.
LLM responde lento (> 60s)	Cache de respuestas a preguntas frecuentes + modelo más rápido (Haiku/gpt-4o-mini en vez de Opus/gpt-4) para intents simples. Solo Opus para casos complejos.
Bot inventa precios o promesas	Hard-coded: precios SIEMPRE consultar `lib/precio_dinamico.ts` (no LLM-generated). Promesas: lista de "frases prohibidas" que LLM nunca dice. Validación post-respuesta antes de enviar.
Confidence threshold mal calibrado (mucho fallback humano)	A/B test umbral: 0.5 / 0.6 / 0.7. Medir fallback rate vs accuracy. Ajustar.
Closer humano no responde a handoff	Cron de re-asignación a backup en 2hs. Si tampoco, mensaje al lead "estamos cerrando una alta demanda, te respondemos mañana primera hora".
Lead manda audio (WhatsApp voice note)	Pipeline Whisper → texto → procesar como texto. Latencia +5-10s. Si Whisper falla, bot dice "no pude escuchar tu audio, escribime por favor".
Lead manda foto/screenshot	OCR (Tesseract) o GPT-4-vision. Si screenshot de WhatsApp con duda → procesar texto. Si captura de pago → OCR el ID y verificar.
Múltiples leads a la vez (rate limit del LLM)	Queue + workers paralelos en Railway. Si rate limit, cola FIFO con max wait 60s + warning al lead "te respondo en 1 min, alta demanda".
Lead reenvía link de competidor	Bot detecta dominio externo + responde "no puedo opinar sobre otros, pero acá es lo que ofrezco yo". NO trash-talk.
Lead pide "promo personalizada"	Bot NO da descuentos. Handoff a closer si insiste. Closer puede dar excepciones autorizadas por Jesús.
Lead intenta jailbreak ("ignora tus instrucciones")	Detector de prompt injection en pre-procesamiento. Si detectado, respuesta segura "no puedo hacer eso, pero contame qué necesitás" + log para revisión.
WhatsApp bloquea el número (ban)	Plan failover: número de respaldo (checklist 11 § backup numbers) + migración del webhook + comunicación a leads activos. Pérdida de horas, no días.
Cambio de oferta mid-week	`_CONFIG.md > oferta` actualizado + cache invalidate < 5 min + bot empieza a usar oferta nueva sin redeploy.
Lead marca al bot como spam en WhatsApp	Score interno del lead penalizado. Si > 3 spam reports, blacklist y revisión humana.
Privacidad / GDPR-ish: lead pide "borren mis datos"	Endpoint admin para borrar lead + mensajes + dejar tombstone. Compliance básico.
Bot debe decidir si pasa al CRM atención humana, al closer, o sigue solo (routing 3 vías)	Documentar criterio en `recursos/routing_3_vias.md`: intents tipo "no llegó mi acceso" / "problema técnico" / "refund" / "queja" → CRM atención (checklist 11 § 2.4b). Intents tipo "QUIERO_COMPRAR_PERO" / "fricción de venta" → closer (checklist 15). Resto: bot responde solo. Si confianza < umbral en cualquier rama → escalation default a CRM atención (humano discriminará si rebote a closer).

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/.

Esta es la sección MÁS CRÍTICA del paquete C. El bot multi-tenant es el corazón del sistema TooAudience. Todo lo que esté hardcoded acá rompe la promesa "cliente nuevo en 2 días".

Variables a externalizar (en clients.config_json > bot_1a1):
bot_1a1.system_prompt (prompt completo del cliente)
bot_1a1.voice_samples[] (10-30 fragmentos textuales del cliente)
bot_1a1.tics_verbales[] (palabras/conectores que usa)
bot_1a1.knowledge.oferta_url (link a _CONFIG.md > oferta del cliente)
bot_1a1.knowledge.precio_dinamico_endpoint (endpoint a consultar precios)
bot_1a1.knowledge.casos_de_exito[] (5+ casos)
bot_1a1.knowledge.top_objeciones[] (10 objeciones + respuesta)
bot_1a1.knowledge.no_canibalizar_dias (días post-membresía sin upsell)
bot_1a1.intents[] (catálogo + ejemplos por cliente — los 7 base son universales, se pueden extender)
bot_1a1.confidence_threshold (0.6 default)
bot_1a1.fallback_human_phone (número del closer del cliente)
bot_1a1.fallback_backup_phone (closer backup)
bot_1a1.handoff_message ("te paso con [closer]…")
bot_1a1.opt_out_keywords[] (palabras que disparan opt-out)
bot_1a1.banned_keywords[] (filtro de seguridad)
bot_1a1.crons.recordatorios[] (array de {cron_expr, mensaje_template, segmento})
Tabla wa_numbers en Supabase: 1 número WA → N posible (un cliente puede tener varios; un número solo puede ser de UN cliente). Routing por número receptor.
Templates a guardar en sop/lanzar-cliente/templates/bot_1a1/:
system_prompt.md.template (con placeholders {{CLIENT_NAME}}, {{MECANISMO}}, etc.)
intents_catalog.md (los 7 intents universales)
intent_dataset_validation.csv.template (100 mensajes en blanco para anotar)
recordatorios_template.json (los crons de la semana)
runbook_incidentes.md
changelog_template.md
Sustituciones automáticas (clone_client.py):
Crear nueva fila en clients + wa_numbers
Inicializar bot_1a1.system_prompt desde template con placeholders reemplazados
Provisionar el número WA del nuevo cliente (BLOQUEA en checklist 11)
Generar 100 mensajes de validación a partir del avatar del nuevo cliente (Cortex)
Lo que NO se replica (cliente-específico): voice_samples, casos_de_exito, top_objeciones, intents extendidos por nicho.
Validación post-clonación: blind test de 5 conversaciones simuladas — si el cliente nuevo dice "9/10 suena a mí", green light.

5. Recursos y archivos relacionados

01_INFRA_TECNICA.md — Schema mensajes_wa, leads, eventos. Railway service.
11_WHATSAPP_API_NUMEROS.md — Provider WA, número, webhook, calentamiento.
12_GRUPOS_WHATSAPP.md — El bot 1:1 invita a los grupos.
08_OFERTA_Y_STACK.md — Oferta vigente que el bot conoce.
06_VIDEOS_YOUTUBE.md — Voz de Martín + objeciones rotas.
15_EQUIPO_VENTAS.md — Closers humanos que reciben handoffs.
07_WEBINAR.md — Bot dispara link al webinar 19:30 lunes.
13_PIXEL_TRACKING.md — Eventos de bot disparan CAPI.
../02_PLAN_INTERNO_EQUIPO.md — Plan macro § 1.5 bot WhatsApp.
~/Downloads/Manual Bot WhatsApp.pdf (si existe en 00 — SISTEMA/Best Practices/).
agents/copywriter/AGENT.md — Para iteración de copies del bot.

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 (semana del 8 jun 2026).

CHANGELOG

2026-05-05 — JT/Cortex — Creación inicial. Bot multi-tenant + system prompt parametrizable + voz Martín + 7 intents + handoff humano + dashboard.
2026-05-05 — JT — Reforzada dependencia ESTRICTA del checklist 11 (números primero). Sumado caso de "routing 3 vías" (bot → CRM atención humana / closer / responde solo).

← Anterior · 09

Slides

Siguiente · 11 →

WhatsApp API + Números