Outage / Incident Communicator.
Comunicación proactiva en incidentes masivos. Carga del contact center -70% durante peak.
El agente custom que detecta incidentes masivos (corte de luz, caída de servicio, app caída), identifica clientes afectados, comunica proactivamente multicanal, absorbe consultas entrantes con contexto del incidente y coordina compensación. Para telco, utilities, banca y SaaS B2B.
¿Qué hace Outage / Incident Communicator?
Outage / Incident Communicator recibe señales de monitoreo (PagerDuty, Datadog, SCADA), identifica la base de clientes afectados, comunica proactivamente por el canal preferido de cada cliente, absorbe las consultas entrantes con contexto del incidente y coordina compensación post-resolución. Reduce la carga del contact center hasta un 70% durante picos de incidentes.
Cómo funciona paso a paso
De la detección a la compensación. 5 pasos, comunicación en menos de 90 segundos.
Detección del incidente
Recibe alerta de PagerDuty, Datadog, SCADA o sistema de monitoreo. Clasifica severidad (P1-P4) y componente afectado.
Identificación base afectada
Mapea componente fallido a clientes impactados vía Component_Catalog y Affected_Customer_DMO. Segmenta por SLA y plan.
Comunicación wave
Envía notificación proactiva por canal preferido de cada cliente: push, WhatsApp, email, SMS, banner in-app. ETA estimado y status page.
Absorción de consultas
Consultas entrantes durante el incidente se responden automáticamente con contexto actualizado del incidente. Cases se vinculan al Incident__c.
Resolución y compensación
Al resolver, envía wave de cierre. Aplica compensación según SLA (descuento, crédito, extensión). Genera draft de post-mortem.
Ejemplo de interacción real
Arquitectura del agente
Los cuatro pilares que hacen funcionar a Outage / Incident Communicator dentro de tu org de Salesforce.
Data
Fuentes de grounding
- Monitoring (PagerDuty/Datadog/SCADA)
- Incident__c + severity
- Affected_Customer_DMO
- Channel_Preference_DMO
- Component_Catalog + SLA
- Compensation_Policy
Actions
Lo que el agente ejecuta
- Classify severity P1-P4
- Resolve affected customer base
- Route by channel preference
- Compose and send message
- Link incoming cases to incident
- Apply compensation
- Publish status page
- Draft post-mortem
Guardrails
Controles de confianza
- Multi-source confirmation
- Approval waves grandes (>50k)
- Rate limit 2 mensajes/hora
- Consent operativo vs marketing
- Cap compensación por incidente
Channels
Dónde opera el agente
- Push (APNs / FCM)
- WhatsApp (Meta WABA)
- Email (Marketing Cloud)
- SMS (Twilio)
- Banner in-app
- Status page
Requiere Data Cloud: Sí (Affected_Customer_DMO + Channel_Preference_DMO)
Requiere Einstein Trust Layer: Sí (incluido en Agentforce)
Implementación en 5 fases
De discovery a producción. Outage / Incident Communicator operativo en 14 semanas.
Discovery y mapping
Workshop SRE + CX. Mapeo componente-a-cliente. Catálogo de componentes con SLA. Templates de comunicación pre-aprobados. Política de compensación.
Data readiness
Mapping componente-a-cliente poblado. Identity resolution. Channel_Preference_DMO configurado. Integración con monitoring tools.
Agent build
Topics de incidente, integración monitoring, logic de segmentación, canales de comunicación, absorción de cases, compensación automation.
Piloto dry-run
Simulación de incidentes P1-P4 con base real. Validación de segmentación, canales, timing y compensación. Sin envío a clientes reales.
Go-live
Primer incidente real comunicado. Governance post-incidente con SRE + CX. Refinamiento de templates y tiempos.
Equipo típico de implementación
Requisitos para arrancar
Lo que necesitás tener listo antes de poner Outage / Incident Communicator en producción.
Datos mínimos
- Mapping componente-a-cliente
- Identity resolution multicanal
- Catálogo de componentes con SLA
- Templates de comunicación pre-aprobados
Licencias
- Service Cloud Enterprise o superior
- Agentforce for Service (Flex Credits)
- Data Cloud (obligatorio)
- Marketing Cloud Engagement
Integraciones
- PagerDuty / Datadog / Splunk
- Marketing Cloud (email waves)
- WhatsApp WABA
- Status page
- MuleSoft (billing compensación)
Org readiness
- SRE approval process definido
- Templates regulatorios aprobados
- Consent operativo separado de marketing
- Component catalog actualizado
KPIs: antes y después
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.
| Métrica | Antes | Después | Cambio |
|---|---|---|---|
| Volumen no atendido en incidente | 60% | 5% | -55 ppt |
| CSAT durante incidentes | 2.5/5 | 3.8/5 | +1.3 puntos |
| Carga contact center en peak | Baseline | -70% | Reducción |
| Detección a primer mensaje | 30+ minutos | <90 segundos | -95%+ |
| Opt-out post-comunicación | N/A | <2% | Bajo |
| Time-to-value | N/A | Primer incidente real | Inmediato |
Riesgos comunes y cómo los mitigamos
Falso positivo: incidente inexistente
Alerta de monitoreo errónea dispara comunicación masiva. Clientes confundidos, credibilidad dañada.
Mitigación: Multi-source confirmation obligatoria para P1/P2. Approval gate para waves de más de 50k clientes. Retracción automática con template de corrección.
Hallucination de ETA o componente
El agente comunica un ETA o componente incorrecto. Cliente espera algo que no va a pasar.
Mitigación: ETA y componente siempre desde Incident__c, nunca generados por el LLM. Templates pre-aprobados con placeholders. Trust Layer con grounding obligatorio.
Sobre-comunicación y fatiga
Demasiados mensajes durante el incidente. Clientes hacen opt-out del canal operativo.
Mitigación: Rate limit de 2 mensajes por hora por cliente. Consolidación de updates. Separación clara de consent operativo vs marketing. Monitoreo de opt-out en tiempo real.
Costos Twilio/WhatsApp en pico
Wave de 100k+ mensajes genera pico de costos no presupuestados.
Mitigación: Priorización de canales por costo (push primero, SMS último). Cap de gasto por incidente. Presupuesto separado para comunicación de incidentes. Dashboard de costos en tiempo real.
Compliance consent LATAM
Mensajes operativos confundidos con marketing. Reclamo regulatorio o multa.
Mitigación: Consent operativo separado de marketing en base de datos. Templates regulatorios aprobados por Legal por país. Audit trail de cada envío con base legal.
Preguntas Frecuentes
Para incidentes P1/P2 exige confirmación de al menos 2 fuentes (ej: PagerDuty + spike de cases entrantes). Para waves de más de 50k clientes requiere approval de SRE Lead. P3/P4 pueden dispararse con una sola fuente si el component catalog tiene mapping confirmado.
Sí. Integramos con sistemas SCADA vía MuleSoft o API directa. La alerta de SCADA se traduce a un Incident__c en Salesforce con componente, zona geográfica y severidad. El mapping componente-a-cliente resuelve qué clientes notificar.
Depende de la política. Para clientes con SLA contractual (premium, enterprise), la compensación se aplica automáticamente según la fórmula del contrato. Para base masiva, se puede configurar compensación automática hasta cierto monto o requerir approval.
El agente detecta que el case corresponde a un incidente activo, vincula el case al Incident__c y responde con contexto actualizado (qué pasó, ETA, compensación). No escala a humano salvo que el cliente insista. Al resolverse, cierra los cases vinculados.
Sí. Conectamos vía webhooks o API. PagerDuty envía la alerta con severity y componente. Datadog puede enviar anomalías de métricas. Ambas fuentes se usan para la confirmación multi-source que evita falsos positivos.
14 semanas de discovery a go-live. El piloto en semanas 10-12 es un dry-run (simulación sin envío a clientes reales). El valor se ve en el primer incidente real post go-live: la reducción de carga del contact center es inmediata.
Comunicá antes de que el cliente llame.
Hablá con un Service Architect de Solu. En discovery mapeamos tus componentes, canales y política de compensación.