Monitoreo del embudo

La automatización resuelve tres problemas relacionados del equipo de ventas: un pronóstico deshonesto, leads perdidos y follow-ups olvidados. El agente trabaja en segundo plano, sin ser solicitado — revisa el embudo a una frecuencia definida (normalmente una vez al día por la mañana) y emite alertas solo cuando detecta un riesgo. El responsable no abre el CRM manualmente: las oportunidades relevantes llegan a él con contexto.

Qué hace exactamente el agente

1. Lee el embudo desde el CRM. Se conecta a HubSpot, Pipedrive, Salesforce, Close, Zoho u otra fuente a través de la API o el conector del orquestador.
2. Calcula la antigüedad de las oportunidades por etapa. Si una oportunidad lleva 14 días en la etapa «Demo scheduled» cuando el plazo promedio es de 3 días, eso es una señal. Los tiempos estándar se configuran una vez en base a datos históricos.
3. Encuentra los follow-ups olvidados. Busca oportunidades con actividad de hace más de N días, pero en estado activo o con alta probabilidad.
4. Compara con el patrón histórico. La desviación respecto a la velocidad típica del embudo se resalta por separado — por ejemplo, si el gestor suele realizar el demo en 2 días y aquí lleva 10.
5. Genera el resumen. Lista de oportunidades, importe en riesgo, recomendación para cada una: recordársela al gestor, revisar la probabilidad, cerrar como lost, solicitar una actualización al cliente.
6. Envía una alerta. Un mensaje corto con enlaces directos a las fichas de oportunidades en Slack, Telegram o e-mail. Un mensaje al día, no un flujo de notificaciones.

El informe es breve — 5–15 oportunidades, no todo el embudo. El responsable abre el mensaje por la mañana, dedica unos minutos, delega en los gestores o revisa el pronóstico de la semana.

Qué no hace el agente

• No escribe correos a los clientes ni les llama en nombre de la empresa.
• No cambia las etapas de las oportunidades ni las probabilidades sin confirmación de una persona.
• No elabora un pronóstico trimestral — solo destaca las oportunidades que corren el riesgo de quedar fuera del pronóstico actual.
• No sustituye el pipeline review semanal — lo complementa entre reuniones.
• No hace coaching de los gestores — para eso existen automatizaciones separadas.

Configuraciones típicas

Solo / equipo 1–5

Uno o dos gestores o ventas founder-led. El agente se conecta a un único CRM (frecuentemente HubSpot Free o Pipedrive), revisa un único embudo, envía una alerta a Telegram o al correo personal. La lógica es simple: oportunidades en una etapa durante más de X días, follow-up no realizado en más de Y días. Sin control de acceso por roles — un único destinatario. Implementación en 1–2 días, mantenimiento casi nulo. Ahorra horas semanales que antes se dedicaban a revisar fichas manualmente, y captura oportunidades que de otro modo se «perderían» por el extremo del embudo. Se justifica cuando el fundador es responsable directo de las ventas y gestiona un número considerable de oportunidades.

SMB / 6–30 personas

Equipo de ventas con 3–8 gestores y un responsable. El agente lee las oportunidades por propietario, genera dos informes distintos: uno para el responsable (oportunidades en riesgo en todo el equipo) y otro para cada gestor (sus propias oportunidades bloqueadas). Se añaden umbrales por importe — alerta solo para oportunidades por encima de un ARR determinado. Canal — Slack con un canal privado exclusivo para el sales lead. Implementación en un fin de semana, requiere configurar las etapas del embudo con los tiempos estándar correctos. Empieza a amortizarse a partir del segundo mes: menos oportunidades perdidas en mitad del embudo y un pronóstico trimestral más preciso.

Enterprise / 30+

Varios equipos (inbound, outbound, account managers), segmentación por regiones o productos, integración con el sistema BI. El agente opera en múltiples canales: Slack para alertas operativas, informe semanal consolidado para el VP Sales en PDF, los datos se escriben en el data warehouse para análisis. Se añaden reglas por segmento — las oportunidades enterprise y las oportunidades SMB tienen distintos tiempos estándar. Se conecta a Salesforce con un modelo de roles: el gestor solo ve sus propias oportunidades, el team lead ve a su equipo, el director ve el agregado. La implementación es más compleja: 2–4 semanas con la participación de sales ops y el data-team. Se justifica cuando el embudo contiene cientos de oportunidades y el control manual es imposible.

Arquitectura

La automatización se construye sobre un stack no-code: orquestador (motor de workflow, Make, Zapier), CRM como fuente de datos, LLM para analizar la dinámica y generar el texto de la alerta, canal de entrega de mensajes. El agente de IA basado en un modelo de IA o modelo similar se encarga de la «narrativa»: convierte una tabla de 15 negocios en un mensaje legible donde se dice no solo «qué está bloqueado», sino también «por qué es importante precisamente hoy».

Sobre esto opera una capa de reglas (CRM API + orquestador) y una capa de interpretación (LLM + prompt del sistema con las normas del equipo). La separación es importante: las reglas detectan los candidatos, el LLM elimina el ruido. Sin la capa LLM se obtiene una alerta cron ordinaria; sin la capa de reglas, los tokens se consumen en cada negocio y el costo de propiedad crece sin beneficio.

Flujo de datos por pasos

1. Disparador por calendario.Cron en el orquestador ejecuta el workflow una vez al día por la mañana, normalmente a las 8:00 según el horario del equipo. La frecuencia se ajusta al ritmo de ventas: diariamente para ciclos cortos, 2–3 veces por semana para los largos.
2. Exportación de negocios. Solicitud al CRM: todos los negocios abiertos en etapas determinadas durante los últimos 60–90 días con los campos de propietario, importe, fecha de última modificación, fecha de última actividad y notas del manager.
3. Normalización de datos. Los datos se unifican en una estructura común: etapa → norma de tiempo en la etapa → tiempo real en la etapa → indicador de riesgo → contexto de actividad.
4. Regla de detección. Se aplican umbrales: tiempo en la etapa > norma × 2, días desde la última actividad > N, alta probabilidad en CRM sin acciones del manager, importe elevado sin movimiento.
5. Capa LLM. El agente de IA recibe la lista de candidatos con indicadores y contexto (historial del equipo, dinámica típica, tamaño del negocio, tone of voice del responsable) y genera un mensaje breve con priorización. En este paso se filtran los casos ruidosos.
6. Entrega. El resumen se envía al canal correspondiente: Slack channel #sales-alerts, chat de Telegram del responsable, e-mail digest. Los negocios se incluyen con enlaces directos a las fichas en el CRM.
7. Registro. Cada envío queda registrado: quién lo recibió, qué negocios fueron destacados, si hubo reacción (si se abrió la ficha, si cambió el estado). A partir de estos logs se ajustan los umbrales posteriormente.

Por qué la capa de IA y no una regla simple

El CRM puede enviar alerts por sí mismo siguiendo reglas, pero solo literales: «negocio con más de 14 días». La tarea aquí es distinta: distinguir un negocio bloqueado por el cliente (importante) de uno bloqueado porque el manager está de vacaciones (no importante hoy). El LLM lee las notas, la última actividad y el contexto, y deja en el resumen solo lo que realmente requiere reacción. Esto reduce el alert fatigue, la forma más rápida de destruir cualquier sistema de monitorización.

Además, el LLM genera texto legible: no «Deal #12345 overdue», sino «El contrato con Acme lleva tres semanas bloqueado en la etapa de demo; en la última conversación el cliente solicitó la propuesta comercial: parece que olvidaron enviarla». La diferencia en la formulación determina si el responsable seguirá abriendo el mensaje un mes después del lanzamiento.

Enfoques alternativos

La elección depende de la etapa: con un número reducido de negocios al mes, el control manual funciona. Con el crecimiento del embudo comienzan a perderse leads, y las alertas integradas ayudan parcialmente. Cuando hay más de cincuenta negocios activos simultáneamente, sin la capa de IA hay ruido o se pierden casos. La opción intermedia es usar tanto las alertas del CRM como el agente: las alertas del CRM para SLA estrictos (por ejemplo, respuesta al cliente en 24 horas), el agente para contexto cualitativo y priorización.

Seguridad y compliance

El agente de IA trabaja con datos de negocios y clientes, por lo que los requisitos básicos son: la API-key del CRM se almacena en el secret manager del orquestador, no en el workflow abierto; el proveedor de LLM no utiliza los datos para entrenamiento (modo enterprise o data-processing addendum con Anthropic, OpenAI, Mistral); los logs se depuran de PII o se conservan no más de 30 días. A Slack/Telegram solo se envían resúmenes breves: los datos completos del negocio permanecen en el CRM. Si la empresa está sujeta al GDPR o regímenes similares, es necesario verificar que la región de procesamiento de datos coincida con los requisitos y que el DPA esté firmado con el proveedor de LLM. Para equipos internos basta con el modelo de roles básico en el lado del CRM: el agente hereda sus restricciones.

Qué debe estar listo antes del inicio

1. CRM con etapas del embudo correctamente configuradas. No cinco a ojo — etapas reales por las que pasan los tratos. HubSpot, Pipedrive, Salesforce, Close, Zoho — cualquiera que tenga API y campos estables.
2. Historial de tratos de al menos 3 meses. El agente lo usa para calcular los tiempos estándar de cada etapa. Sin historial, las alertas serán demasiado frecuentes o demasiado escasas — no hay base para calibrar.
3. Canal para notificaciones. Slack workspace o Telegram bot con acceso para el responsable. El e-mail funciona, pero peor — se pierde fácilmente en el flujo, la tasa de apertura es menor.
4. Un destinatario responsable. Una persona que lea la alerta matutina y reaccione. Sin esto, la automatización se convierte en otro canal silencioso y muere en silencio.
5. Orquestador no-code.Plataforma low-code self-hosted, Make o Zapier. La elección depende del presupuesto, los requisitos de alojamiento de datos y el stack del equipo.
6. Disciplina en la introducción de datos en el CRM. Los gestores deben cerrar actividades, mover los tratos por etapas y asignar probabilidades correctas. Sin esto, la señal tendrá ruido y el agente se quejará de tratos que en realidad están en orden.
7. Consentimiento para el procesamiento de datos por parte del proveedor de LLM. Documento breve del abogado o nota en el contrato indicando que los datos de los tratos se envían a la nube del proveedor del modelo.

Qué NO se requiere

• Un data-team dedicado o un analista a full-time.
• Un stack de BI propio (Tableau, Power BI, Looker).
• Un modelo ML personalizado — un LLM de propósito general es suficiente.
• Migrar a un nuevo CRM — el agente trabaja con el actual, sea cual sea.
• Cambiar los procesos de ventas — el agente se integra en el workflow existente, no impone uno nuevo.

Posibles escollos

• Mala higiene del CRM. Si la mitad de los tratos lleva meses en la etapa «New» porque nadie limpia el embudo, el agente los alertará cada día. La primera semana tras el lanzamiento es de limpieza; después, ajuste fino de los umbrales.
• Umbrales demasiado sensibles. Si empieza con time-on-stage × 1.5, obtendrá decenas de alertas al día y el responsable desconectará el canal. Empiece con × 2–3 y reduzca gradualmente a medida que crece la confianza en la señal.
• Sin propietario del proceso. Si la alerta va «al departamento» y no a una persona concreta, no habrá reacción. Un destinatario, un responsable — de lo contrario, el sistema muere en silencio al cabo de un mes.
• LLM sin contexto del equipo. Si no se proporciona al agente la duración media del trato, el tamaño típico de ARR y el tone of voice del equipo, destacará todo por igual y escribirá en términos genéricos. Un prompt de sistema breve con los estándares es obligatorio.
• Mezcla de funciones en un solo workflow. Si el agente alerta, escribe correos a los clientes y mueve tratos al mismo tiempo, ya no es monitorización. Divida las funciones en workflow separados; este es solo para alerta temprana.