Health Score Agent.
Customer health dinámico, calculado por IA, con señales tempranas que llegan antes que el churn.
Un agente Agentforce que ingesta señales de producto, soporte, engagement y financials en tiempo real, calcula un score multivariable, cambia el tier del cliente automáticamente y le dice al CSM exactamente qué hacer. Implementado por Solu en 10 a 16 semanas.
¿Qué hace el Health Score Agent?
Reemplaza el health score estático (regla de negocio fija, actualización semanal o mensual, sin contexto) por un score dinámico que se recalcula con cada señal nueva. Si un cliente baja el uso del producto un martes y abre tres tickets el miércoles, el agente lo detecta el miércoles — no en la review del viernes.
Para: CSMs, Customer Success Managers, Sales Ops y líderes de retención que necesitan priorizar la atención con datos reales en vez de intuición.
Cómo funciona
5 pasos, desde la ingesta de señales hasta el tracking del impacto de cada acción.
Ingesta continua de señales
El agente recibe datos de múltiples fuentes en tiempo real: uso del producto (logins, features usadas, frecuencia), tickets de soporte (volumen, severidad, tiempo de resolución), engagement (emails abiertos, meetings, portal de cliente) y datos financieros (pagos, facturas pendientes, consumo vs contrato).
Cálculo dinámico del score
Con cada señal nueva, el agente recalcula el health score ponderando todas las variables. No es un promedio simple: usa el contexto del segmento, el ciclo de vida del cliente y los patrones históricos de cuentas similares para definir qué peso tiene cada señal.
Cambio de tier automático
Cuando el score cruza un umbral configurable, el agente cambia el tier del cliente (verde → amarillo → rojo) y dispara la alerta correspondiente. Los umbrales se definen por segmento y se ajustan con los datos del piloto.
Sugerencia de acción
El agente no solo dice "este cliente está en riesgo". Genera una recomendación concreta: tipo de acción (check-in, escalación, oferta de retención), los 3 puntos clave del caso y el contexto necesario para que el CSM entre a la conversación preparado.
Tracking del impacto
Después de la acción, el agente mide si el score mejoró, se mantuvo o empeoró. Cada intervención alimenta el modelo: las acciones que funcionan se priorizan en futuras sugerencias, las que no se descartan.
Ejemplo real de interacción
Cliente "TechCorp" cae de verde a amarillo: uso del producto bajó 35% en 2 semanas + 4 tickets de severidad media abiertos en los últimos 5 días.
Genera alerta para el CSM con 3 puntos clave: (1) la caída de uso coincide con el release 4.2 — feature X que usaban dejó de funcionar, (2) 3 de los 4 tickets son sobre la misma funcionalidad, (3) el contrato renueva en 45 días. Sugiere: check-in urgente con foco en el bug del release + confirmar plan de renovación.
CSM hace el check-in con contexto completo. El equipo de producto prioriza el fix. En 10 días el uso se recupera, los tickets se cierran y el score vuelve a verde. Renovación confirmada.
Arquitectura técnica
Los 4 pilares del agente: datos, acciones, guardrails y canal de entrega.
Data
- Sales Cloud: Account, Opportunity, Contract, Renewal Date
- Service Cloud: Cases (volumen, severidad, SLA), CSAT por caso
- Product usage: telemetría de producto via Data Cloud (logins, features, sessions)
- Marketing Cloud / Engagement: open rate, meetings, portal activity
- ERP / Billing: pagos, consumo vs contrato, facturas pendientes
Actions
- Recalcular health score (invocable Apex / Flow)
- Cambiar tier de cuenta (update Account field)
- Crear tarea para el CSM con contexto y puntos clave
- Enviar alerta por Slack / email / in-app notification
- Generar resumen ejecutivo del caso para el CSM
- Registrar acción tomada y resultado (para feedback loop)
Guardrails
- Einstein Trust Layer: PII masking antes de enviar al LLM
- Umbrales de cambio de tier configurables por segmento
- Cooldown: no cambia tier más de 1 vez en 24-48 hrs (evita flip-flop)
- Escalación obligatoria: cuentas enterprise siempre requieren review humana antes de pasar a rojo
- Audit trail: log completo de cada cambio de score, tier y acción sugerida
- Zero data retention en el LLM
Channel
- Dashboard embebido en Sales Cloud (Account page layout)
- Alertas en Slack / Microsoft Teams
- Email digest diario/semanal para CS leadership
- Copilot sidebar: el CSM pregunta "¿por qué bajó el score de esta cuenta?" y el agente responde con contexto
Cómo se implementa
5 fases, 10-16 semanas. Equipo Solu + tu equipo de CS y datos.
Discovery y definición de señales
Mapeo de todas las fuentes de datos disponibles. Definición de las señales que componen el score (producto, soporte, engagement, financials). Priorización por disponibilidad y relevancia. Definición de segmentos y umbrales iniciales.
Data readiness y Data Cloud
Conexión de fuentes de datos a Data Cloud (si aplica). Limpieza y normalización de datos históricos. Validación de que las señales llegan con la frecuencia y calidad necesarias. Si no hay Data Cloud, configuración de los objetos y campos en Sales + Service Cloud.
Build del agente
Configuración en Agent Builder: role, topics, actions, prompts. Desarrollo de la lógica de scoring (Apex/Flow). Configuración de guardrails (cooldown, escalación, umbrales). Integración con canales de notificación (Slack, email). Testing con datos históricos.
Piloto controlado
Activación con un segmento acotado de cuentas (e.g., 50-100 cuentas mid-market). Los CSMs reciben alertas y sugerencias en paralelo a su proceso actual. Se mide: accuracy del score vs outcome real, tasa de acción sobre alertas, feedback del equipo de CS.
Rollout y optimización continua
Expansión al book completo. Tuning de pesos y umbrales con datos del piloto. Activación del feedback loop (tracking de impacto de acciones). Change management para el equipo de CS. Dashboard de performance para leadership.
Requisitos previos
Lo que necesitás tener (o que Solu te ayuda a configurar) antes de arrancar.
Sales Cloud Enterprise+
Con objetos Account, Opportunity y Contract configurados y con datos actualizados. Es la base sobre la que vive el score.
Agentforce License
Flex Credits (pay-per-use) o Agentforce Edition. El agente consume créditos por cada evaluación y sugerencia.
Al menos 2 fuentes de señales
Un health score con una sola variable no es health score. Mínimo: datos de producto + datos de soporte. Ideal: 4-5 fuentes.
Data Cloud
Para unificar las fuentes en un perfil por cuenta y tener ingesta en tiempo real. Sin Data Cloud se puede arrancar, pero con refresh manual o batch.
Service Cloud
Para incorporar tickets, CSAT y datos de soporte como señales del score. Si no tenés Service Cloud, se pueden ingestar datos de soporte vía API.
Historial de al menos 6 meses
Para calibrar umbrales y pesos con datos reales. Con menos datos el agente funciona, pero los umbrales iniciales son más arbitrarios.
KPIs Before / After
KPIs esperados al implementar este agente. Rangos referenciales para planificación; los resultados reales dependen del estado de los datos y la operación de cada empresa.
Riesgos y mitigaciones
Lo que puede salir mal y cómo lo prevenimos. Sin sorpresas.
Score inaccurate por señales faltantes
Si una fuente clave (e.g., telemetría de producto) no está conectada o tiene gaps, el score puede dar falsos positivos/negativos.
Mitigación: En discovery se mapean todas las fuentes y se priorizan las que tienen mayor impacto predictivo. El agente incluye un "confidence score" que baja cuando faltan datos, y alerta al equipo de CS que la evaluación es parcial.
Alert fatigue
Si los umbrales están mal calibrados, los CSMs reciben demasiadas alertas y dejan de prestarles atención.
Mitigación: Umbrales ajustables por segmento. Cooldown de 24-48 hrs entre cambios de tier. Piloto con grupo reducido para calibrar antes de rollout. Dashboard de "alert-to-action ratio" para monitorear la salud del sistema de alertas.
Baja adopción del equipo de CS
Los CSMs ignoran las sugerencias del agente porque no confían en el score o no cambian su workflow.
Mitigación: Change management desde la fase de discovery. Los CSMs participan en la definición de señales y umbrales. El piloto es con early adopters que retroalimentan. Las sugerencias incluyen "por qué" con datos concretos, no solo "qué hacer".
Datos sensibles en las sugerencias
El agente podría incluir información financiera confidencial en alertas compartidas por Slack o email.
Mitigación: Einstein Trust Layer con PII masking. Configuración de qué datos se incluyen en cada canal (Slack recibe resumen, CRM tiene el detalle completo). Audit trail de cada dato expuesto por canal.
Flip-flop de tier
El score oscila entre tiers por señales ruidosas (e.g., un spike temporal de tickets), generando confusión.
Mitigación: Cooldown obligatorio entre cambios de tier (configurable: 24-72 hrs). Smoothing temporal: el agente pondera la tendencia de los últimos N días, no solo el valor instantáneo. Review manual obligatoria para cuentas enterprise antes de cambiar a rojo.
Preguntas Frecuentes
Un health score estático usa reglas fijas (e.g., "si NPS > 8 y usage > 50% → verde"). El Health Score Agent recalcula con cada señal nueva, pondera por contexto del segmento y patrones históricos, detecta cambios en horas en vez de días, y genera sugerencias de acción concretas — no solo un número.
No es obligatorio, pero sí recomendado. Sin Data Cloud, el agente funciona con datos de Sales Cloud + Service Cloud (tickets, oportunidades, contratos). Con Data Cloud, se suma telemetría de producto, engagement digital y datos de billing en tiempo real, lo que mejora la accuracy del score significativamente.
Mínimo 2 categorías de señales (e.g., soporte + producto). Con 4-5 categorías (producto, soporte, engagement, financials, NPS) el score es mucho más preciso. Pero es mejor arrancar con 2-3 señales bien conectadas que esperar a tener 5 perfectas.
Tres cosas: (1) las alertas incluyen contexto y sugerencia concreta, no solo "cliente en riesgo", (2) los CSMs participan en la definición de señales y umbrales desde discovery, y (3) el piloto con early adopters genera evidencia interna de que las alertas son accionables. El "alert-to-action ratio" se monitorea como KPI del sistema.
En su versión base detecta riesgo actual basado en señales recientes. Con historial suficiente (6+ meses de datos) y Data Cloud, se pueden incorporar patrones predictivos: "cuentas que mostraron este patrón de señales históricamente churnearon en un 70% de los casos". Es una evolución natural del agente, no un desarrollo aparte.
Sí, pero con configuración diferente. Enterprise: umbrales más conservadores, review humana obligatoria antes de cambiar a rojo, más señales ponderadas. SMB: umbrales más agresivos, automatización completa (el agente puede disparar secuencias sin intervención humana), foco en escala. Los segmentos se definen en discovery.
10-16 semanas desde kick-off hasta agente en producción con datos reales. Si ya tenés Data Cloud configurado y las fuentes de datos conectadas, puede ser más rápido (8-10 semanas). El piloto controlado es parte del timeline — no se salta.
Si ya tenés Gainsight o Totango, el Health Score Agent puede complementarlos o reemplazarlos dependiendo del caso. Si los datos de CS ya viven en Salesforce y querés consolidar, el agente vive nativamente en la plataforma sin middleware adicional. Si preferís mantener la herramienta de CS, se puede integrar vía MuleSoft o API.
Tu health score, calculado en tiempo real, en 10 semanas.
Hablá con un CS Architect de Solu. En una sesión de discovery mapeamos tus señales y definimos el modelo de scoring para tu book.