CASO ANONIMIZADO · CPG

Mesa de servicios multi-actor sobre el grafo, con proveedores externos auto-registrados

Una organización líder de consumo masivo validó Supplier Service Desk migrando su mesa de servicios con proveedores externos desde una plataforma low-code legacy a EAFlow: auto-registro de proveedor externo, bandeja multi-rol con state machine DRAFT → ASIGNADO → RESOLUCIÓN → CIERRE, ruteo asistido por el grafo según sociedad y categoría, depuración masiva auditada de tickets fantasma y reportería de aging y SLA.

La validación mostró que la solución funciona sobre la operación del cliente y el valor que aporta: una mesa multi-actor gobernada sobre el grafo, con proveedores auto-registrados, ruteo asistido y una bandeja saneada con reportería de aging y SLA que vuelve a tener sentido.

El desafío

En un fabricante de consumo masivo que opera una mesa de servicios con proveedores externos, esa mesa suele vivir sobre una plataforma low-code legacy. El problema no es la falta de mesa: es que la mesa vive atrapada en estructuras propietarias del vendor, aislada del resto de la operación.

  • La mesa vive encerrada en la LCDP legacy: tipos de ticket, roles del centro de servicios, puntos focales por área y state machine quedan en estructuras propietarias; el costo crece y el upgrade es riesgoso.
  • La relación con el proveedor empieza por mail: para dar de alta a un proveedor externo, alguien manda un correo y lo registra en una planilla local, sin enlace del proveedor a su sociedad en un modelo gobernado.
  • El ruteo es por reglas hard-coded o por correo: decidir quién atiende cada ticket por sociedad y categoría se hace con reglas rígidas o con mails que se pierden entre áreas.
  • Los tickets fantasma se acumulan: abiertos en sistema pero resueltos por correo, se cierran uno por uno o nunca; la bandeja envejece y la reportería pierde sentido.
  • La operación vive en un mail saturado y los datos de proveedor se piden dos veces.

La mesa de servicios no se sostiene encerrada. Se sostiene con tickets gobernados, conectados a la sociedad, la categoría y el punto focal, con ruteo asistido y evidencia trazable.

La solución EAFlow

Supplier Service Desk es un acelerador vertical CPG construido sobre la solución transversal Operational Graph for Service Operations más Workflow + identidad federada y la capa común Operational Graph de EAFlow Platform, operando con identidad federada multi-actor para usuarios internos y auto-registro para proveedores externos. La validación cubrió, sobre la mesa de servicios de la operación del cliente:

  • Migración desde la plataforma low-code legacy preservando el modelo multi-actor. Tipos de ticket, roles del centro de servicios, puntos focales por área y state machine que vivían en la plataforma low-code legacy se migraron a EAFlow preservando el modelo de atención, sin reescribir el proceso desde cero.
  • Cada ticket conectado a la sociedad, la categoría y el punto focal. Originador, ticket, categoría, sociedad, rol CSC y punto focal de área quedan como entidades de primera clase del Operational Graph.
  • Auto-registro de proveedor externo: el proveedor se registra desde el portal, recibe credenciales por correo y queda enlazado a su sociedad en el grafo, sin mail al centro de servicios ni planilla local.
  • Bandeja multi-rol con state machine DRAFT → ASIGNADO → RESOLUCIÓN → CIERRE: Proveedor, Usuario Interno, Agente N1, Punto Focal N2/N3 y Usuario Avanzado ven la misma bandeja desde su rol; cada transición firmada por su autor.
  • Ruteo asistido por el grafo: el grafo conoce la sociedad, la categoría y el punto focal aplicable, y sugiere tipo y destinatario al originador, sin reglas hard-coded por país, con control humano.
  • Procedimiento controlado de depuración masiva: los tickets fantasma se resuelven con diagnóstico previo, actualización masiva auditada y verificación posterior, en lugar de cerrarse uno por uno.
  • Reportería operativa de aging y SLA: dashboard de bandejas, aging por categoría, tasa de cierre dentro de SLA y frescura de datos de proveedor.
  • Consulta gobernada sobre el corpus de tickets: tickets, estados, categorías y puntos focales se responden sobre el grafo, con cita al ticket y al nodo, siempre con control humano.

La cobertura de categorías, los puntos focales por área y el onboarding de proveedores se establecen por alcance acordado en discovery. El acelerador opera la mesa multi-actor; convive con la herramienta ITSM corporativa del cliente cuando existe, sin reemplazarla.

Qué se validó

La experiencia se ejecutó sobre la mesa de servicios con proveedores externos del cliente, migrada desde la plataforma low-code legacy. El centro de servicios recorrió el ciclo completo: migración del modelo multi-actor, auto-registro de proveedor, bandeja multi-rol con state machine, ruteo asistido por el grafo, procedimiento de depuración masiva auditada, reportería de aging y SLA y consulta gobernada — con los roles de Proveedor, Usuario Interno, Agente N1, Punto Focal N2/N3 y Usuario Avanzado sobre la misma mesa gobernada.

Capacidades demostradas

  • Operational Graph como base común de contexto.
  • Migración del modelo multi-actor desde la plataforma low-code legacy preservando estructura.
  • Trazabilidad originador ↔ ticket ↔ categoría ↔ sociedad ↔ rol CSC ↔ punto focal.
  • Auto-registro de proveedor externo enlazado a su sociedad (identidad federada multi-actor).
  • Bandeja multi-rol con state machine firmada por autor.
  • Ruteo asistido por el grafo, con control humano.
  • Procedimiento controlado de depuración masiva auditada.
  • Reportería de aging y SLA con frescura de datos de proveedor.
  • Consulta en lenguaje natural sobre el corpus de tickets, con cita a la fuente.

Resultado observado

La validación permitió comprobar el uso de EAFlow para gobernar la mesa de servicios multi-actor: pasar de estar atrapada en una plataforma low-code legacy a operar gobernada sobre el grafo, con proveedores auto-registrados y ruteo asistido. La relación con el proveedor dejó de empezar por mail y pasó a un auto-registro enlazado a su sociedad; los tickets fantasma dejaron de cerrarse uno por uno y pasaron a un procedimiento de depuración masiva auditada; y la operación dejó de vivir en un mail saturado para apoyarse en reportería de aging y SLA.

La validación confirmó que el acelerador migra y gobierna la mesa de servicios multi-actor preservando el modelo de atención del cliente, con identidad federada para internos y auto-registro para externos.

Por qué importa para otras organizaciones

El patrón se repite en organizaciones CPG que atienden a proveedores externos: la mesa vive en una plataforma low-code legacy, la relación con el proveedor empieza por mail, el ruteo es rígido y los tickets fantasma envejecen la bandeja. Migrar la mesa a un acelerador sobre el Operational Graph —preservando el modelo multi-actor, sin reescribir desde cero ni reemplazar el ERP— reduce el costo de mantenimiento y devuelve sentido a la reportería.

Empezar por una mesa multi-actor acotada es además una puerta de entrada de bajo riesgo: el mismo Operational Graph que gobierna la mesa de proveedores sostiene después una operación de servicios multi-dominio, contratos y cumplimiento por proveedor.

Cómo escala — soluciones relacionadas

La mesa gobernada y su corpus de tickets se reutilizan sobre el mismo Operational Graph: