Eventos en tiempo real: un cambio, todos los canales
Arquitectura orientada a eventos en SAP: cómo un cambio de estado en el caso se propaga de inmediato a teléfono, portal y WhatsApp en utilities de LATAM.
· 12 min de lectura
Un reclamo por factura alta entra el lunes por WhatsApp. El martes, el mismo cliente llama al call center porque nadie le respondió. El miércoles abre un caso en el portal de autoservicio. Tres registros, tres agentes, tres respuestas parcialmente contradictorias, y un solo suscriptor que ya perdió la confianza en la distribuidora.
El problema casi nunca es de las personas que atienden. Es de arquitectura. Cada canal consulta periódicamente el estado del caso en lugar de enterarse cuando el estado cambia. Esa diferencia —preguntar contra escuchar— es la que decide si la omnicanalidad de una utility es real o es un conjunto de sistemas corriendo en paralelo sobre el mismo cliente.
En la entrega anterior de esta serie tratamos cómo asignar el caso correcto al agente correcto sin perder tiempo en la cola. Aquí abordamos el mecanismo que sostiene esa asignación una vez el caso está vivo: cómo un cambio de estado se propaga de inmediato a todos los canales y extensiones conectadas.
Sondear cuesta más de lo que parece
El patrón por defecto en muchas implementaciones de atención en utilities de la región es el polling: el portal consulta el estado del caso a intervalos cortos; el bot de WhatsApp, con otra frecuencia; el tablero de supervisión, mucho más espaciado. El resultado tiene tres costos simultáneos.
El primero es la latencia estructural: entre que un agente cierra el corte indebido y que el portal lo refleja, hay una ventana en la que el cliente ve información vieja y vuelve a reclamar. El segundo es el consumo: miles de llamadas por hora que en su mayoría responden “nada cambió”, saturando APIs que fueron dimensionadas para otro perfil de tráfico. El tercero es el más caro: cada canal construye su propia versión del estado, y ninguna es autoritativa.
La alternativa es invertir la dirección. En lugar de que los canales pregunten, el sistema de origen publica un evento cuando algo ocurre, y quien esté suscrito lo recibe. SAP Sales and Service Cloud V2 expone precisamente ese modelo: notificaciones de eventos y webhooks como parte de su marco de extensibilidad, junto con trabajos externos y API REST (SAP Community — Extensibility Overview, SAP Sales and Service Cloud V2, 2025). Sobre esa base, el caso creado, el caso actualizado o el incumplimiento de SLA pueden publicarse hacia un bróker de eventos para que las extensiones reaccionen en tiempo real en vez de sondear cambios periódicamente (Spadoom, s.f.).
Qué es el bróker y por qué no es una cola más
SAP ofrece hoy varias piezas para esto y conviene nombrarlas con precisión, porque la nomenclatura cambió. SAP Event Mesh es el servicio de mensajería en SAP BTP, heredero de lo que se llamó SAP Cloud Platform Enterprise Messaging (SAP-samples, GitHub, s.f.). Existe además la capacidad Event Mesh integrada dentro de SAP Integration Suite, orientada a publicar y consumir eventos de negocio entre aplicaciones (SAP Help Portal — Integration Suite, s.f.). Y para escenarios de mayor escala está SAP Integration Suite, advanced event mesh, construido sobre Solace PubSub+, con tópicos jerárquicos, entrega garantizada, filtrado de eventos, patrón publish-subscribe y consumidores en competencia, con soporte de MQTT, AMQP, JMS y REST (SAP Learning, s.f.).
Esa última lista no es decoración técnica. Para una distribuidora, el tópico jerárquico es lo que permite que un evento de “reconexión ejecutada” llegue solo a los suscriptores de esa zona y ese tipo de caso; la entrega garantizada es lo que evita que un evento se pierda cuando el bot de WhatsApp está caído; y los consumidores en competencia son lo que permite escalar la atención sin duplicar el procesamiento del mismo evento.
El evento es un contrato, no un mensaje suelto
Aquí es donde la mayoría de los proyectos regionales tropieza. Se habilita el bróker, se publican los primeros eventos, funciona en la demostración, y seis meses después nadie sabe qué versión del payload consume el bot de cobranzas. Un evento sin gobierno se degrada más rápido que una API sin gobierno, porque el productor no ve a sus consumidores.
Las mismas disciplinas que exigimos a las APIs del flujo AMI hacia SAP IS-U aplican al plano de eventos, y con más urgencia:
- Versionar el esquema del evento. La falta de control de versiones genera comportamientos inconsistentes: un consumidor que asumía un campo obligatorio empieza a fallar en silencio cuando el productor lo vuelve opcional.
- Exponer solo lo necesario. Un evento de “caso actualizado” no necesita transportar el histórico de consumo ni datos comerciales sensibles del suscriptor. Mínimo privilegio también en el payload: el consumidor que requiera detalle lo pide por API autenticada.
- Definir auditoría y monitoreo activo. Sin trazabilidad de qué evento se publicó, quién lo consumió y cuál falló, la reconciliación de un reclamo disputado se vuelve un ejercicio de arqueología.
- Acotar el consumo. La ausencia de límites produce riesgo de saturación interna: una extensión mal diseñada que reintenta indefinidamente puede degradar el bróker para todos los canales.
Lo que está en juego no es la experiencia, es el plazo regulatorio
En Colombia, las empresas prestadoras deben resolver peticiones, quejas y recursos dentro de quince días hábiles contados desde su presentación; vencido ese término, y salvo demora auspiciada por el usuario o práctica de pruebas, opera el silencio administrativo positivo y el reclamo se entiende resuelto a favor del suscriptor, con setenta y dos horas para reconocer sus efectos (Ley 142 de 1994, art. 158, subrogado por el Decreto 2150 de 1995, art. 123). En Perú, la atención de reclamos de electricidad y gas natural se rige por la directiva aprobada mediante Resolución N.º 269-2014-OS/CD y sus modificatorias —entre ellas la Resolución N.º 014-2025-OS/CD—, con plazos diferenciados según la materia reclamada (OSINERGMIN, 2014; 2025).
Traducido a operación: cuando el mismo reclamo existe tres veces con tres fechas de presentación distintas, la empresa no está gestionando un problema de servicio al cliente. Está gestionando tres relojes regulatorios independientes, y basta que uno se venza para que el ajuste de facturación se pierda por procedimiento, no por evidencia técnica. La propagación inmediata del estado no es una mejora cosmética de la experiencia: es el control que mantiene un solo reloj corriendo.
Por dónde empezar sin rehacer el paisaje
En nuestra práctica SAP recomendamos no arrancar publicando todo el catálogo de eventos disponible. El camino que sostiene presupuestos acotados es acotado también: elegir dos o tres eventos de alto impacto —caso creado, cambio de estado, incumplimiento de SLA—, definir su esquema versionado antes de la primera integración, conectar un solo canal consumidor, medir latencia y eventos fallidos durante un ciclo de facturación completo, y recién entonces sumar canales.
Lo que se gana en ese primer ciclo no es velocidad. Es una definición compartida de qué significa que un caso “cambió”, que hasta ahora cada canal interpretaba a su manera.
Resuelto esto, queda la pregunta que cierra el ciclo y que abordaremos en la próxima entrega: cómo gobernar el SLA transversal para que un caso resuelto en un canal no reabra el reclamo en otro.
Fuentes
- SAP Help Portal — Event Mesh (capacidad en SAP Integration Suite): https://help.sap.com/docs/integration-suite/sap-integration-suite/event-mesh
- SAP Learning — Introducing SAP Integration Suite, Advanced Event Mesh: https://learning.sap.com/courses/sap-integration-suite/introducing-sap-integration-suite-advanced-event-mesh-1
- SAP Community — Extensibility Overview: SAP Sales and Service Cloud V2 (2025): https://community.sap.com/t5/crm-and-cx-blog-posts-by-sap/extensibility-overview-sap-sales-and-service-cloud-v2/ba-p/13964854
- SAP-samples — Event Mesh Client Java Samples (renombramiento de SAP Cloud Platform Enterprise Messaging): https://github.com/SAP-samples/event-mesh-client-java-samples
- Spadoom — SAP Service Cloud V2: what’s different: https://www.spadoom.com/en/blog/sap-service-cloud-v2-whats-different/
- Ley 142 de 1994, art. 158 (subrogado por el Decreto 2150 de 1995, art. 123) — Normograma: https://www.cancilleria.gov.co/sites/default/files/Normograma/docs/ley_0142_1994_pr005.htm
- OSINERGMIN — Resolución de Consejo Directivo N.º 269-2014-OS/CD: https://www.gob.pe/institucion/osinergmin/normas-legales/633593-269-2014-os-cd
¿Este análisis mapea un mercado donde ya operas o estás evaluando entrar?
Revisamos tu caso específico, mapeamos los riesgos que aplican, y te decimos honestamente si es oportunidad para ti —sin pitch comercial, solo discusión técnica y estratégica.
