Gobernar el SLA transversal: un caso, un reloj por reclamo

«Resuelto» es la palabra menos precisa de una operación de reclamos. Para el agente significa que marcó el hito. Para el sistema, que el registro pasó a un estado final. Para el regulador, que se emitió un acto que todavía debe notificarse y que admite impugnación. Para el usuario no significa nada hasta que la respuesta le llega. Cuatro definiciones conviviendo en el mismo expediente bastan para que un caso dado por terminado vuelva a la mesa.

Esta pieza trata ese punto y solo ese: cómo se gobierna el cierre de un caso cuando la conversación con el usuario puede continuar por una vía distinta de aquella por la que se cerró, y qué tiene que ser cierto en la configuración para que esa continuación no produzca un expediente nuevo.

Cerrar no detiene la secuencia regulatoria: abre el siguiente tramo

En Perú, la directiva de reclamos de usuarios de electricidad y gas natural establece que los actos administrativos emitidos por las empresas distribuidoras deben notificarse dentro de los cinco días hábiles contados desde el día siguiente de emitidos, y que el usuario dispone de quince días hábiles desde esa notificación para cuestionar lo resuelto mediante reconsideración o apelación (Osinergmin, 2014, y sus modificatorias; la última, Resolución N.º 014-2025-OS/CD). Entre el momento en que la operación considera el caso terminado y el momento en que el expediente queda firme hay, entonces, una ventana de semanas en la que el caso sigue jurídicamente vivo.

En Colombia el encuadre es distinto pero apunta a lo mismo. La empresa prestadora debe resolver peticiones, quejas y recursos dentro de 15 días hábiles contados desde la fecha de presentación; vencido ese término —salvo práctica de pruebas o demora auspiciada por el usuario— se entiende resuelto a favor del usuario, y dentro de las 72 horas siguientes la empresa debe reconocer los efectos del silencio administrativo positivo (Ley 142 de 1994, art. 158, subrogado por el Decreto-ley 2150 de 1995, art. 123). El plazo corre sobre la petición del usuario, no sobre el registro interno que la operación decidió abrir para atenderla.

De ahí la tesis de este artículo: el cierre no apaga el reloj, lo empuja al siguiente tramo. Y un reloj que sigue corriendo sobre un caso que la operación ya archivó es la definición exacta de una reapertura esperando ocurrir.

Los tres huecos por donde vuelve un caso cerrado

Las reaperturas rara vez nacen de una mala resolución técnica. Nacen de decisiones de gobierno que nadie tomó explícitamente.

• La resolución se comunicó por una sola vía. El expediente se cierra correctamente y la respuesta viaja únicamente por donde ocurrió el último contacto. El usuario que había iniciado por otra vía nunca se enteró, y su siguiente mensaje entra al sistema como algo nuevo.
• El hito se marcó, la conversación no se cerró. Las acciones sobre el caso están asociadas a la finalización de los hitos de nivel de servicio (SAP, KBA 3483775). Completar el hito es un acto del sistema; que el usuario acepte la respuesta es un hecho externo que el sistema no observa por sí solo.
• La ejecución operativa siguió su curso. Una acción de corte que avanza sobre un suministro con reclamo vigente convierte un asunto de facturación en uno de suministro y devuelve la gestión al inicio, con la agravante de que en Perú el corte por falta de pago del monto reclamado, mientras el procedimiento sigue en trámite y el usuario está al día en las obligaciones no reclamadas, es materia de queja ante el regulador (Osinergmin, 2014).

Ninguno de los tres se resuelve comprando más plataforma. Se resuelven definiendo qué significa «resuelto» y quién tiene autoridad para declararlo.

El estado del caso no es una etiqueta: gobierna el reloj

Aquí es donde la definición de negocio aterriza en configuración. En SAP Service Cloud Version 2 los estados del caso los mantiene el agente y pueden incluir valores como Open, In process, Customer Action, Completed o Closed; el esquema de estados es la colección que compone el proceso de soporte, y los valores de estado pueden determinar tanto un acuerdo de nivel de servicio como una regla de autoflow. Además, pueden mantenerse esquemas distintos según el segmento de cliente o el tipo de servicio (SAP Learning, s.f.).

Esa capacidad es la palanca de gobierno más directa para el problema de la reapertura. Dos decisiones concretas:

• Separar Completed de Closed. Completed puede marcar que la operación terminó su trabajo; Closed, que la ventana de impugnación pasó sin retorno. Cerrar ambos el mismo día borra la distinción que la norma sí hace.
• Usar Customer Action como estado real, no como cortesía. Mientras el balón está con el usuario —esperando su notificación, su conformidad o su recurso—, el caso no está terminado ni está en trabajo: está esperando, y el esquema debería decirlo.

Los hitos que se calculan sobre ese ciclo —revisión inicial, respuesta, finalización y resolución— son atributos del caso (SAP, KBA 3314998), y las reglas de determinación del nivel de servicio los computan sobre el objeto Case a partir de criterios como cuenta, país, clasificación ABC, estado del caso, prioridad, equipo de servicio, producto, categoría y campos personalizados, con horarios de operación y tiempos de reacción (SAP Learning, s.f.). Un solo juego de hitos por caso es lo que permite auditar el cierre contra un único vencimiento en vez de contra varios.

Que la insistencia del usuario no abra un expediente nuevo

La entrega anterior de esta serie mostró cómo el estado del caso se propaga cuando algo cambia. El corolario operativo es más mundano: cuando el usuario vuelve, hay que pegarlo al caso que ya existe.

Una interacción recibida por chat, teléfono, SMS, WhatsApp u otra vía soportada puede vincularse desde la sección de entidades del Agent Desktop a un caso existente del mismo interlocutor, y queda incorporada al timeline de ese caso (SAP, KBA 3576849). El Agent Desktop es el área central de trabajo del agente e integra la comunicación en una sola vista (con4PAS, s.f.; SAP, 2026), y la plataforma acompaña la disciplina con recomendación de casos similares dentro de sus capacidades documentadas de Narrow AI (SAP, 2026). La decisión, aun así, sigue siendo de proceso.

El modo de falla contrario también está documentado: los correos entrantes pueden generar casos duplicados cuando se rompe el hilo del mensaje, incluso existiendo ya un caso abierto por el mismo asunto (SAP, KBA 3579601). En una operación con picos de facturación, ese comportamiento suele ser la vía silenciosa por la que un caso resuelto reaparece con otro número.

El complemento vertical hace visible el riesgo. El add-on para utilities expone en la vista del agente objetos del negocio energético —cuenta contrato, contratos activos, documentos de corte, procesos de mudanza y órdenes de servicio— junto al caso (SAP, 2026). Con esos objetos a la vista, quien atiende una insistencia posterior ve que el suministro ya tiene un caso con documento de corte asociado antes de decidir si crea algo nuevo.

Qué definir antes de tocar la configuración

• Qué estado del esquema representa «trabajo terminado» y cuál representa «ventana de impugnación cerrada».
• El identificador de caso que se comunica al usuario en todos los puntos de contacto, incluido el que se entrega en la llamada.
• La condición de cierre: notificación emitida por la vía de origen además de la del último contacto, y todas las interacciones del período vinculadas al caso.
• Quién tiene autoridad para declarar resuelto y quién puede reclasificar un caso de facturación a suministro.
• Qué evento del sistema legado detiene una acción de corte cuando existe reclamo vigente.

Con el cierre gobernado y un solo juego de hitos por caso, queda la pregunta que cierra la serie: qué debe medir un operador de utilities para saber si el silo entre canales se cerró de verdad, y cuánto cuesta el canal duplicado mientras no lo hace. Es el tema de la próxima entrega.

Fuentes

• Ley 142 de 1994, artículo 158 — Régimen de los servicios públicos domiciliarios, término para responder peticiones, quejas y recursos. Congreso de la República de Colombia.
• Osinergmin (2014). Resolución de Consejo Directivo N.º 269-2014-OS/CD — Procedimiento Administrativo de Reclamos de los Usuarios de los Servicios Públicos de Electricidad y Gas Natural. https://www.osinergmin.gob.pe/seccion/centro_documental/PlantillaMarcoLegalBusqueda/OSINERGMIN-269-2014-OS-CD.pdf
• Osinergmin. ¿Cómo presentar un reclamo? — plazos de notificación e impugnación y causales de queja del usuario. https://www.osinergmin.gob.pe/Paginas/Folletos/folletos/como-presentar-reclamo.html
• SAP Learning (s. f., consultado en 2026). Creating the Statuses for Cases — Implementing and Using SAP Service Cloud Version 2. https://learning.sap.com/learning-journeys/implementing-and-using-sap-service-cloud-version-2/creating-the-statuses-for-cases_c1b217b6-9f4a-4b97-b5b7-cdac0081adc8
• SAP Learning (s. f., consultado en 2026). Configuring a Service Level Agreement — Implementing and Using SAP Service Cloud Version 2.
• SAP (2026). SAP Service Cloud Version 2 Feature Scope Description, 2026-04-01.
• SAP (2026). SAP Service Cloud Version 2, Add-On for Utilities, 2026-05-07.
• SAP (2026). Set Up Guide for SAP Service Cloud Version 2, 2026-05-12 — Narrow AI, Similar Case Recommendation.
• SAP Knowledge Base Article 3314998 — How the Duration for Service Level Agreements (SLAs) Work in SAP Service Cloud Version 2.
• SAP Knowledge Base Article 3576849 — How to Add an Interaction to a Case Timeline, Service Cloud V2.
• SAP Knowledge Base Article 3579601 — Inbound Emails Creating Duplicate Cases in SAP Service Cloud Version 2.
• SAP Knowledge Base Article 3483775 — Case Actions Associated On Service Level Milestones Completion.
• con4PAS (s.f.). SAP Service Cloud Version 2 versus SAP Service Cloud.