Caso de Éxito (Estructura): Agente de Cobro de Documentos de Clientes para Onboarding
Estado: ESTRUCTURA. Las secciones marcadas con [PILOT DATA] se completan únicamente con resultados medidos de un compromiso real — nunca con estimaciones.
Evidencia de ejecución en seco (simulada / SIMULATED). Nuestro simulador determinista de pilotos ya ejercita esta misma pila de agente de extremo a extremo: durante una ejecución en seco simulada de 14 días solicitó y revisó 79 documentos de clientes, redactó 37 recordatorios de seguimiento a lo largo de la escalera solicitud→recordatorio→requerimiento firme (cada toque asentado en docs_chase.jsonl, cada borrador superó el filtro de tono de frases prohibidas), pausó 9 cobros por prórrogas prometidas por el cliente, omitió automáticamente 4 documentos que ya habían sido recibidos, y escaló 29 documentos al propietario humano de onboarding (más de 14 días de antigüedad, más de 30 días, o tope de contactos agotado). Estimado simulado (simulated data): todas las cifras provienen de una ejecución en seco simulada contra datos sintéticos (synthetic data). No participaron clientes ni documentos reales.
El cliente
Pequeña firma de contabilidad/abogacía/servicios profesionales (personaje ficticio usado para esta estructura), con un responsable de onboarding cuya semana se fuga reclamando a clientes documentos fiscales, cartas compromiso firmadas y archivos KYC. Cada nuevo cliente recibe una lista de verificación; cada lista se convierte en una hilera de correos de recordatorio redactados a mano, anotados en una hoja de cálculo y abandonados en cuanto las cosas se ponen ocupadas. [CLIENT NAME PENDING CONTRACT]
El problema
- El responsable de onboarding reclama cada documento faltante a mano — horas cada semana recordando quién debe qué, redactando recordatorios y reenviando listas de verificación en lugar de hacer trabajo facturable
- El reclamo es inconsistente: algunos clientes reciben recordatorios amables semanales, otros no oyen nada durante semanas, y el onboarding se atasca en silencio — el incómodo correo «aún necesitamos tu formulario fiscal» es siempre el que se escapa
- Los modos de falla son hostiles para las relaciones: los clientes que prometen «lo envío el viernes» reciben reclamos de todos modos, los documentos que ya llegaron vuelven a ser reclamados, y tras semanas de insistencia lo que sufre no es la lista de verificación sino la relación
Lo que desplegamos
Un DocCollectionAgent que ejecuta nuestro ciclo estándar sobre una política de reclamo determinista cuyas salvaguardas viven en código, no en el prompt:
- una escalera determinista solicitud→recordatorio→requerimiento firme en código: cada documento pendiente avanza de primera solicitud, a recordatorio amable, a requerimiento firme según los días pendientes calculados — el nivel lo decide el estado de la lista de verificación, nunca el criterio del LLM
- los documentos recibidos/exentos JAMÁS vuelven a ser reclamados: una vez que un documento llega o queda exento de la lista, queda fuera de alcance permanentemente — el agente no puede insistir por algo que ya enviaste (en la ejecución en seco simulada se omitieron automáticamente 4 documentos ya recibidos)
- pausa por prórroga prometida: si el cliente promete entregar los documentos en una fecha, la escalera se pausa hasta esa fecha en lugar de acosar a quien ya se comprometió
- escalamiento duro a humanos a partir del día 14: cualquier documento que siga pendiente después de 14 días escala al propietario humano de onboarding (y otra vez pasados 30 días, o cuando se agota el tope de contactos) — el agente entrega en el momento correcto en lugar de escalar el tono
- un tope de 4 contactos por documento en código: ningún cliente puede ser insistido más de cuatro veces por el mismo elemento, sea lo que sea que calcule la escalera
- un filtro de tono de frases prohibidas sobre cada borrador: lenguaje acusatorio, amenazante o de ultimátum nunca puede llegar a un cliente — todo lo que activaría el filtro se escala a un humano en lugar de enviarse
- un registro auditable en
docs_chase.jsonl: cada toque redactado queda asentado con marca de tiempo, documento, lista de verificación, nivel y texto del mensaje
Marco de resultados (completar durante/después del piloto)
| Métrica | Antes | Después | Fuente |
|---|---|---|---|
| Horas del responsable de onboarding dedicadas a reclamar documentos por mes | [PILOT DATA] | [PILOT DATA] | hojas de tiempo del cliente |
| Días promedio hasta recolectar cada documento solicitado | [PILOT DATA] | [PILOT DATA] | reportes del sistema de listas de verificación |
| % de documentos pendientes contactados a tiempo | [PILOT DATA] | [PILOT DATA] | registro auditable docs_chase.jsonl |
| Documentos escalados a humanos antes de dañar la relación | — | [PILOT DATA] | registros de escalamiento |
| Costo por toque de reclamo | [PILOT DATA] | [PILOT DATA] | registro de tokens |
Ajuste a los precios
El cobro de documentos corre sobre nuestro modelo de tarifa de plataforma más uso: $450/mes de tarifa de plataforma + $4.00 por documento recolectado (un documento solicitado recibido tras un toque del agente dentro del ciclo). Como cada toque es una decisión determinista pequeña con una huella de tokens mínima, el ejemplo interno resuelto simulado supera con holgura nuestro piso obligatorio de margen del 30% — con un ~86% de margen de contribución por documento recolectado según el estimado simulado de la ejecución en seco (simulated dry-run estimate — ver reports/pricing_model.md §7, y precios). Los documentos que un cliente declina enviar jamás se facturan, así que los ingresos solo provienen de colecciones limpias y exitosas — el precio alinea nuestro incentivo con la velocidad de onboarding del cliente.
Por qué importa la política de reclamo determinista
En el cobro de documentos, un mensaje de insistencia de más puede costar la relación con el cliente que el onboarding debía iniciar. El nivel de la escalera, la exclusión de recibidos/exentos, la pausa por prórroga, la entrega al día 14 y el tope de contactos viven todos en código determinista que el modelo de lenguaje no puede sobrescribir — el LLM solo redacta dentro de un nivel que el planificador ya eligió, y cada borrador debe superar el filtro de tono de frases prohibidas antes de existir como candidato. A un cliente que promete el viernes se le deja en paz hasta el viernes, un documento ya recibido nunca vuelve a mencionarse, y cada toque es atribuible a su registro de lista de verificación, su regla de antigüedad y un ciclo del loop.
Sección de lecciones aprendidas
[POST-PILOTO: listar las 3 lecciones principales de data/loops/<proyecto>/ — reales, textualmente.]
SIMULATED DATA — todas las cifras de ejecución en seco de esta página son estimados simulados contra datos sintéticos (synthetic data); ninguna proviene de un compromiso real todavía.