Informe mensual: por qué los acuerdos se ganan o se pierden
Que hace
El agente de IA Grow2.ai analiza cada negocio cerrado del CRM y genera un informe mensual sobre las causas de las victorias y las pérdidas. El conocimiento sobre por qué un negocio se ganó o se perdió deja de vivir solo en las cabezas de los vendedores y pasa a un documento que lee todo el equipo — desde el director comercial hasta los product managers y marketing. En lugar de recopilar datos manualmente de distintas fuentes antes de cada retro, el departamento obtiene una narrativa estructurada con segmentos y citas ya preparados.
Esto es lo que hace el agente en un ciclo:
- Obtiene la lista de negocios cerrados durante el período de reporte (won y lost), con filtrado por pipeline y equipo.
- Extrae para cada negocio el historial de correspondencia, transcripciones de llamadas, notas de los vendedores, campos de calificación, duración de las etapas y el propietario del negocio.
- Combina los datos con métricas de comportamiento del data warehouse: visitas al sitio, eventos de producto, actividad en el trial.
- Clasifica las causas de pérdida y los factores de victoria según la taxonomía acordada con el equipo — precio, timing, competidor, fit del producto, calidad del proceso de venta, factores políticos internos del cliente.
- Extrae objeciones recurrentes, señales de riesgo y formulaciones de los clientes en forma de citas, con indicación del negocio y la etapa en que se expresaron.
- Segmenta los resultados por tipo de cliente, fuente del lead, producto, vendedor y duración del ciclo.
- Consolida todo en un informe structured markdown: TL;DR de una página, insights clave, análisis de negocios individuales y anexos con datos raw.
Lo que la automatización no hace
- No realiza entrevistas win/loss con el cliente. Una conversación cualitativa con un cliente perdido sigue requiriendo una persona real y habilidades de entrevistador.
- No reemplaza al analista de sales ni toma decisiones. Las conclusiones estratégicas sobre ICP, precios o prioridades de producto quedan en manos del equipo.
- No predice el futuro. El informe describe qué ocurrió y por qué, pero no pronostica el resultado de los negocios abiertos ni genera el scoring del pipeline actual.
El documento lo leen el director comercial, el head of sales, los product managers y marketing. El equipo de sales recibe retroalimentación sin revisar manualmente el CRM antes de cada retro. El product manager ve señales de conversaciones reales con clientes perdidos. Marketing entiende qué segmentos se ganan con mayor facilidad y dónde falla el messaging o el targeting.
Como funciona
El agente de IA de Grow2.ai funciona según un calendario (una vez al mes o por el disparador de cierre de acuerdos) y atraviesa cuatro etapas: recopilación de datos, normalización, análisis a través del LLM, generación del informe. La implementación consiste en código personalizado en Python o TypeScript con orquestación a través de un motor de workflow o un script por cron, sin constructores visuales no-code debido a la complejidad de los prompts y el volumen de datos.
Flujo técnico
- Recopilación de datos. El script accede al CRM (HubSpot, Salesforce, Pipedrive) a través de REST API y extrae todos los acuerdos con estado closed_won o closed_lost del período. Por cada acuerdo se obtienen las entidades asociadas: contactos, notas, actividades, hilos de email.
- Enriquecimiento desde data warehouse. Al acuerdo se añaden datos de comportamiento: páginas del sitio, eventos de producto, estado del trial. La fuente es Snowflake, BigQuery, réplica de Postgres o data mart de BI.
- Transcripciones de llamadas. Si el equipo tiene conectados Gong, Fireflies, tldv o Otter, el agente extrae las transcripciones y notas de los acuerdos a través de su API.
- Normalización y chunking. Los datos en bruto se convierten en un único objeto JSON por acuerdo y se dividen en bloques semánticos para el LLM.
- Análisis a través del modelo de IA. Cada acuerdo pasa por varios prompts: clasificación según la taxonomía, extracción de citas y objeciones, evaluación de los factores de victoria o pérdida. Los resultados se almacenan en un JSON estructurado.
- Agregación. Los resultados de todos los acuerdos se agrupan en segmentos, se calculan los patrones, se identifican los temas y señales recurrentes.
- Generación del informe. El prompt final convierte los datos estructurados en una narrativa de 5-10 páginas con TL;DR, insights, análisis de los acuerdos clave y anexos.
- Entrega. El informe listo se publica en Notion, Confluence o se envía al canal de Slack del equipo de ventas.
Pasos de implementación
- Acordar la taxonomía de causas de pérdida y factores de victoria con el head of sales (1-2 reuniones).
- Obtener acceso read-only al CRM, data warehouse y al sistema de grabación de llamadas.
- Recopilar un dataset de 30-50 acuerdos cerrados del período anterior para calibrar los prompts.
- Desarrollar el pipeline de recopilación y normalización de datos.
- Configurar los prompts para el modelo de lenguaje y validar la calidad de la clasificación en una muestra anotada.
- Ejecutar el primer informe manualmente, revisarlo con el equipo y ajustar la taxonomía y los prompts.
- Programar el pipeline y configurar las alertas de fallos.
Componentes
Componente | Función | Elección típica |
|---|---|---|
Conector CRM | Fuente de acuerdos y actividades | HubSpot, Salesforce, Pipedrive API |
Data warehouse | Métricas de comportamiento | Snowflake, BigQuery, Postgres |
LLM | Análisis, clasificación, narrativa | LLM |
Orquestación | Calendario y pipeline | orquestador o script de Python + cron |
Almacenamiento de resultados | Archivo de informes | Notion, Confluence, S3 |
La calidad del informe depende de dos cosas: la limpieza de los datos en el CRM (completitud de los campos, causas de pérdida, notas de llamadas) y la coherencia de la taxonomía. Si el 40% de los acuerdos tiene el campo de causa de pérdida vacío, el LLM no podrá compensarlo completamente: recuperará parte de la información a partir de la correspondencia y las llamadas, pero la precisión disminuirá. Antes del lanzamiento se realiza una auditoría de la completitud de los datos y se eliminan las brechas críticas.
Requisitos previos
La implementación se apoya en el acceso a los datos de CRM, data warehouse y la disposición básica del equipo para el análisis de win/loss. Cuanto más limpios y completos sean los datos de entrada, más sólido será el informe de salida.
Acceso y datos
- CRM con historial de operaciones. Mínimo 6 meses con los campos básicos completados (etapa, fecha de cierre, propietario, motivo de pérdida). HubSpot, Salesforce, Pipedrive se conectan a través de las API estándar.
- Data warehouse o data mart de BI. Snowflake, BigQuery, réplica de Postgres o equivalente con datos de producto y de comportamiento. Opcional, pero mejora la calidad del análisis.
- Transcripciones de llamadas. Gong, Fireflies, tldv, Otter o sistema interno. Sin transcripciones, el informe se construye sobre la correspondencia y las notas, pero pierde matices.
- Taxonomía acordada. Lista de motivos de pérdida y factores de victoria del head of sales — 8-15 categorías para cada parte.
- Cuenta de servicio con permisos de solo lectura en CRM, data warehouse y el sistema de grabación de llamadas.
- Plataforma de publicación del informe — Notion, Confluence o el canal de Slack del equipo de ventas.
Preparación del equipo
- Head of sales o RevOps como owner del proyecto, dispuesto a participar en la calibración de la taxonomía y la validación de los primeros informes.
- Un empleado técnico o contratista para las integraciones y el soporte del pipeline.
- El equipo de sales, dispuesto a recibir y discutir las conclusiones — sin una cultura de análisis de win/loss, el informe se convierte en un archivo que nadie abre.
Plazos
2-4 semanas desde el kickoff hasta el primer informe automático. La primera semana — acuerdo de taxonomía y auditoría de datos, la segunda — desarrollo del pipeline y calibración de los prompts, la tercera y la cuarta — lanzamiento piloto, revisión con el equipo y puesta en calendario.
Problemas
- No vemos señales de fuga de clientes
- Tiempo en informes manuales
- Conocimiento en cabezas, no en documentos
FAQ
¿En cuánto tiempo se puede lanzar la solución?
El plazo estándar es de 2-4 semanas desde el kickoff hasta el primer informe automático. La primera semana se destina a la alineación de la taxonomía de causas de pérdida y la auditoría de datos en el CRM. La segunda, al desarrollo del pipeline de recopilación y la calibración de los prompts para el modelo de IA. La tercera y la cuarta, al informe piloto, la discusión con el equipo y la programación en el calendario. Si el CRM tiene brechas serias en los campos de notas y causas de pérdida, se añadirán 1-2 semanas para la limpieza de datos.
¿Qué hacer si en el CRM no se registran las causas de pérdida?
Esta es una situación típica y se resuelve de forma parcial. El agente de IA recuperará parte de las causas a partir de la correspondencia, las notas y las transcripciones de llamadas — allí los clientes suelen mencionar lo que no aparece en los campos. Sin embargo, si el 40% de los acuerdos tiene campos vacíos y no hay grabaciones de llamadas, la precisión de la clasificación disminuirá. En estos casos, en paralelo con la automatización se introduce la disciplina de completar los campos al cerrar el acuerdo — de lo contrario, cualquier herramienta dará un resultado débil.
¿Cuáles son los principales riesgos y dónde falla la automatización?
Tres riesgos principales. El primero — basura en la entrada: campos vacíos, ausencia de notas y llamadas producen un informe débil. El segundo — taxonomía inconsistente: si el equipo interpreta las categorías «precio» y «competidor» de manera diferente, las conclusiones resultan confusas. El tercero — ausencia de una cultura de análisis win/loss: incluso un informe técnicamente perfecto sin discusión en el retro se convierte en un archivo que nadie abre. Los tres riesgos se eliminan en la etapa de preparación, no del pipeline.
¿Es adecuada la solución para nuestro sector?
La solución es universal para los equipos de ventas B2B con un ciclo de acuerdo de al menos un mes. Funciona mejor en SaaS y Tech, donde existen datos de producto y grabaciones de llamadas con compradores. En sectores con ciclos muy cortos — e-commerce, retail — el valor es menor, porque el foco se desplaza hacia la conversión del embudo y el análisis de cohortes, en lugar del análisis de acuerdos individuales. Para servicios B2B, agencias y software enterprise el formato aplica sin modificaciones.
¿Se puede recibir el informe con más frecuencia que una vez al mes?
Sí, el equipo configura la frecuencia. Una vez por semana funciona en equipos con un alto volumen de acuerdos — a partir de 50 cierres por semana. Con volúmenes menores, el informe semanal ofrece una base estadística débil: es mejor acumular datos durante un mes o un trimestre. Adicionalmente, se pueden configurar alertas para acuerdos individuales con patrones inusuales — por ejemplo, la pérdida ante un cliente importante con un alto lead score.
¿Qué hacer con los acuerdos de ciclo muy corto?
Los acuerdos con un ciclo inferior a dos semanas se agregan en una sección aparte sin un análisis profundo de cada uno. Para ellos, el énfasis recae en los patrones agregados: fuentes de leads, objeciones típicas en el primer contacto, conversión por segmentos. El análisis profundo se reserva para los acuerdos de ciclo largo, donde hay más datos de correspondencia, llamadas y etapas, y existe más material para analizar.
Quieres esto en tu negocio?
Reserva una auditoria gratuita — te mostraremos como funcionara esta automatizacion para ti.