---
name: diagnostico-inicial
description: "First diagnosis of a customer from its WhatsApp conversations: understand the business, classify activities, measure by seller and by who starts, open deep dives with a comparison group, end in 2 North Stars + 3 actions. Use when a customer or a new seller line is connected, or before an onboarding or value session (diagnóstico inicial)."
license: "Proprietary. Free to use with a Frepi account. See LICENSE."
metadata:
  author: "frepi-ai"
  version: "1"
---

# Diagnóstico inicial (camino al «aha»)

Método probado el 19/10/2026 con dos clientes: un distribuidor B2B de equipos de protección personal
y un distribuidor farmacéutico que vende a droguerías. Se ejecuta con las herramientas de Frepi sobre el
workspace actual.
Todo es estimación por palabras clave hasta que exista AI Scan; decirlo siempre.

## Antes de empezar

- Este método necesita las conversaciones de WhatsApp del workspace (tablas `conversation_message`,
  `contact`, `seller_line`). Lista las tablas primero; si no existen, detente y dilo: el workspace aún
  no tiene líneas conectadas.
- Las cifras de ejemplo son de otros clientes, anonimizadas. Nunca las presentes como datos de este
  workspace.

## Reglas que no se negocian

1. **Leer antes de contar.** Las sorpresas grandes (tráfico interno, traspasos de cartera, pérdidas
   silenciosas) solo aparecen leyendo mensajes crudos.
2. **Probar la hipótesis del cliente, no discutirla.** Medirla y decir si se sostiene. Matar una creencia
   falsa también es un aha (en un cliente, «respondemos lento» era falso: la mediana de primera respuesta era de pocos minutos).
3. **Buscar lo que NO pasa:** silencio del cliente, falta de seguimiento, clientes que dejaron de recibir
   contacto. Ahí suele estar el valor.
4. **Toda relación lleva grupo de comparación** (semanas sin contacto, clientes sin seguimiento…).
   Sin baseline no hay conclusión.
5. **Nombres, citas y clientes reales del propio cliente.** Una cita real vale más que diez gráficos.
6. **Seguridad:** si aparecen contraseñas o credenciales en los mensajes, avisar sin repetirlas.
7. **Si trabajas por MCP, pasa `project_id` en cada llamada** (la credencial puede tener otro workspace
   por defecto).

## Paso 0 · Entrar y ubicarse
- `bi_list_tables`, `seller_line` (asesores y fecha de conexión), volumen por línea × `capture_source`
  (`coex_history` = historia importada, `live_webhook`/`coex_echo` = en vivo) × dirección, rango de fechas.
- Si hay un asesor recién conectado: ¿trajo historia? ¿de quién era el número antes? (en un cliente, la línea
  de una asesora nueva había sido de otro asesor y los clientes seguían escribiéndole por su nombre).

## Paso 1 · Entender el negocio
- Muestras aleatorias: ~120 mensajes de clientes y ~110 de asesores por línea (texto > 25 caracteres,
  `ORDER BY md5(id::text)`), top 40 contactos por volumen con su nombre guardado.
- Salida: **ficha del negocio** — qué venden, a quién, por qué canales (WhatsApp, visitas, web/marketplace,
  links de pago), roles internos (cartera, coordinación, precios), sistemas que aparecen, y el **motion de
  venta** (¿el cliente pide solo o el asesor empuja?).
- Separar audiencia: interno / cliente / proveedor / aliado (por nombre + números de los asesores +
  señales: quien nos manda precios «+ IVA» suele ser proveedor; quien habla con todas las líneas suele ser
  interno). Todo lo demás se mide solo con clientes.

## Paso 2 · Tipificar
- Catálogo de 8–12 actividades sacado de la lectura (no de una plantilla). Ejemplo (distribuidor farmacéutico): pedido, consulta
  de precio/disponibilidad, oferta proactiva, check-in, competencia, pago y cartera, entrega, reclamo,
  alta en la plataforma, coordinación interna.
- Unidad: **conversación-día** (contacto × línea × día). **Quién inicia** = primer mensaje del día.
  Excluir respuestas automáticas (horario, «gracias por comunicarte»).
- Clase propia para lo que el asesor manda **solo en imagen** (ofertas/flyers): el texto no lo ve.
- Validar: muestrear el «sin clasificar» y ajustar reglas hasta que baje de ~15–25%.

## Paso 3 · Cuantificar
- Volumen por actividad × asesor × quién inicia, % de lo que inicia cada lado, **% con respuesta del
  cliente** en lo que inicia el asesor.
- Velocidad: mediana de primera respuesta, % < 15 min, **% de solicitudes > 24 h sin respuesta** (horario
  hábil, cliente que inicia o retoma tras 2 h).
- Tendencia semanal: clientes que escriben vs **clientes contactados proactivamente** por semana.

## Paso 4 · Deep dives (menú; abrir los que el paso 3 señale)
- **A · ¿Qué contacto proactivo termina en pedido?** Semanas cliente×línea con oferta en texto / check-in /
  solo imagen / sin contacto → % con pedido. (En un cliente: sin contacto ≈5%, oferta en texto ≈20–30%, solo imagen ≈ nada.)
- **B · Cobertura y traspasos de cartera.** Clientes activos antes vs contactados después; clientes cuyo
  silencio supera 2× su ritmo habitual = en riesgo (lista con nombres).
- **C · Conversión de cotizaciones** por tipo de cliente (recurrente/conocido/nuevo) × seguimiento × velocidad
  × motivo de no compra. (En un cliente: recurrente ≈60% vs nuevo ≈20%; seguimiento a un cliente nuevo que calla ≈35% vs ≈5% sin seguimiento.)
- **D · Pago y cartera** (links, vencidas, abonos, cupo, intereses).
- **E · Pedido → entrega → reclamo** (reprogramaciones, faltantes, fecha corta, devoluciones).
- **F · Competencia** (citas con nombre del competidor y precio; poco volumen, alta gravedad).
- **G · Adopción de canal propio** (marketplace/web: quién habla de él, quién pide por él, problemas de acceso).

## Paso 5 · Síntesis
- **2 North Star**: una de resultado y una adelantada que el equipo controla. Línea base + meta propuesta
  (validar con el cliente).
- **3 acciones** con números y con la lista de clientes/conversaciones donde aplicarlas.
- Cautelas explícitas (estimado por palabras clave, canales no visibles, sesgo de selección).

## Patrones SQL que funcionan
- Clientes: `contact` excluyendo los números de `seller_line` y nombres internos/proveedores.
- Conversación-día: `GROUP BY owner_number_id, contact_id, message_date::date` con
  `string_agg(lower(body)) FILTER (WHERE direction=...)` para texto del cliente (`cb`) y del asesor (`ab`),
  `(array_agg(direction ORDER BY message_date))[1]` para quién inicia.
- Evitar subconsultas correlacionadas sobre tablas grandes (timeout): `WITH ... AS MATERIALIZED` + un solo
  `JOIN` con agregados `FILTER`.
- Fechas vuelven como `YYYY-MM-DDT00:00:00.000`.

## Salida: dos productos distintos, nunca mezclarlos

**Reporte = BI.** El entregable al cliente es SIEMPRE un reporte refrescable en Frepi, en su workspace (skill
`crear-reporte`):
consultas guardadas («<Cliente> ·») + islas de datos (convención v3) + `.as-of`. Contiene números y la
evidencia que los respalda: North Star, actividades, deep dives con baseline, listas accionables
(clientes en riesgo, conversaciones para leer, con enlace a Conversaciones) y las 3 acciones.

**Documento = contexto (memoria, scaffolding).** Lo que aprendimos para que un agente o el equipo
trabaje mejor después: ficha del negocio, catálogo de tipificación con sus reglas, roles internos,
definiciones, cautelas, decisiones, alertas de seguridad (sin repetir credenciales). Va a la memoria
(Memoria/KPIs/Operación del workspace, HANDOFF, memoria del agente), no a un «reporte». Un documento
interno NO es BI y no se llama reporte.

En el chat solo va el resumen y los enlaces.