EGA Futura » Capacitación y Soporte
Un caso se escala cuando el nivel que lo está atendiendo se quedó corto.
Corto puede significar dos cosas muy distintas: que le falta conocimiento técnico o que le falta autoridad para decidir.
Esa distinción es el corazón del tema, porque cada carencia se resuelve mandándolo a un lugar diferente.
Es el movimiento hacia el costado, hacia un equipo con más especialidad en el tema.
Se usa cuando el problema es técnicamente más complejo de lo que el primer nivel puede resolver.
La organización clásica en niveles de soporte, con un primer nivel que atiende todo y niveles siguientes cada vez más especializados, existe justamente para esto.
La lógica detrás es económica: el conocimiento profundo es caro y escaso, así que conviene reservarlo para lo que de verdad lo necesita.
Es el movimiento hacia arriba, hacia alguien con capacidad de decidir.
No se usa porque el caso sea difícil sino porque la salida implica una excepción, un costo o un compromiso que el que atiende no puede otorgar.
Un reintegro fuera de política, una prioridad que desplaza a otros clientes o una promesa de fecha son ejemplos típicos.
Confundir los dos tipos es un error frecuente: mandar hacia arriba un problema técnico solo agrega demora, porque el que decide tampoco sabe resolverlo.
El disparador más objetivo es el tiempo: un caso que lleva demasiado sin avanzar necesita otros ojos, independientemente de lo que diga quien lo atiende.
El segundo es el impacto, medido en cuánta gente o cuánto dinero está afectado.
El tercero es el pedido explícito del cliente, que conviene respetar aunque el equipo crea tener el caso bajo control.
El cuarto es el reintento fallido: cuando la misma solución ya se probó dos veces sin resultado, insistir una tercera casi nunca ayuda.
Un escalamiento sin contexto no ahorra tiempo, lo duplica, porque obliga al siguiente nivel a repetir el diagnóstico.
Conviene que viaje qué se probó, qué resultado dio cada intento y cuál es el impacto concreto sobre el cliente.
También conviene que viaje lo que ya se le prometió, para que el nivel siguiente no contradiga sin querer al anterior.
El anti patrón más común es usar el escalamiento como válvula de escape para sacarse de encima lo incómodo.
Se reconoce fácil: los casos escalados vuelven con la indicación de que faltaba información básica.
El antídoto es escribir criterios de escalamiento antes de necesitarlos, para que la decisión no dependa del ánimo del día.
Un caso escalado también puede bajar de nivel, y eso es sano, no un fracaso.
Cuando el nivel especializado identificó la causa y dejó escrita la solución, el seguimiento vuelve al equipo que trata con el cliente.
Ese retorno es además la forma en que el conocimiento baja: lo que hoy exigió un especialista, mañana lo resuelve el primer nivel.
El escalamiento se apoya en tres movimientos sobre el registro del caso, y cada uno corresponde a una de las formas descritas arriba.
El Ticket de servicio tiene un propietario que admite tanto una persona como un grupo.
El escalamiento funcional se materializa cambiando ese propietario por el grupo del nivel siguiente, con lo cual el caso queda disponible para el equipo especializado.
El campo Área funcional acompaña ese movimiento, porque reubica el caso dentro de la organización.
El campo Usuario asignado registra a la persona concreta que se hizo cargo dentro de ese nivel.
La Prioridad es obligatoria y toma cuatro valores: Crítica, Alta, Normal y Baja.
El valor por omisión es Normal, así que subir a Alta o a Crítica es una acción deliberada que deja rastro.
Vale la pena notar que la escala usa Normal y no Media, un detalle que importa al armar informes o filtros.
El Estado distingue dos formas de estar detenido, y esa distinción evita discusiones.
Esperando respuesta indica que la pelota está del lado del cliente, y En espera que la demora es interna.
Separar los dos permite medir el tiempo de atención sin cargarle al equipo las horas en que estuvo esperando al cliente.
El cierre también va en dos pasos, Resuelto y Cerrado, que separan la solución técnica de la conformidad final.
Existe un escalón adicional que no es de personas sino de naturaleza del registro.
El Incidente guarda la interrupción concreta que sufrió alguien, con su propio Deadline con fecha y hora.
El Problema guarda la causa de fondo, con campos para la Causa de origen, los Síntomas y la Solución temporal o alternativa.
Cuando varios incidentes comparten un origen, se vinculan a un mismo problema mediante un registro de relación dedicado.
Ese vínculo es lo que permite atender la urgencia y la causa en paralelo: el incidente se resuelve con la solución temporal y el problema sigue su propio curso.
El Artículo de conocimiento se relaciona tanto con tickets como con tareas, mediante registros de relación propios.
Esa relación es el mecanismo que convierte un caso resuelto por el nivel especializado en material reutilizable por el primer nivel.
No: reasignar cambia quién hace el trabajo dentro del mismo nivel, y escalar lo cambia de nivel.
Un caso puede reasignarse varias veces por disponibilidad sin haberse escalado ni una vez.
Lo más sano es que lo decida un criterio escrito y no una persona caso por caso.
Los criterios habituales combinan tiempo transcurrido, impacto y cantidad de intentos fallidos.
Es una parte, pero por sí sola no resuelve nada si el caso sigue en manos del mismo nivel.
La prioridad ordena la atención; el escalamiento cambia quién atiende.
El incidente es la interrupción que sufre alguien y el problema es la causa que la produce.
Un mismo problema puede estar detrás de decenas de incidentes, y por eso se registran por separado.
Los tres objetos del área son EGAFutura__Ticket_servicio__c, EGAFutura__Incidente__c y EGAFutura__Problema__c.
En los tres el campo OwnerId es Lookup(User,Group) y es obligatorio, así que el escalamiento funcional se implementa cambiando ese campo por el identificador del grupo destino.
El campo EGAFutura__Usuario_asignado__c, en cambio, es Lookup(User) en los tres y por lo tanto admite personas solamente.
Los tres objetos comparten el mismo juego de valores en EGAFutura__Estado__c y en EGAFutura__Prioridad__c.
Estado toma Nuevo, Asignado, En proceso, Esperando respuesta, En espera, Resuelto y Cerrado, con Nuevo por omisión.
Prioridad toma Crítica, Alta, Normal y Baja, con Normal por omisión.
En las dos listas la etiqueta y el valor almacenado son idénticos, tildes incluidas, así que un filtro en Apex tiene que escribir Crítica con tilde.
Las tres listas obligatorias del ticket son Estado, Prioridad y EGAFutura__Categoria__c, esta última con ocho valores y sin valor por omisión.
El incidente es el único con EGAFutura__Deadline__c, de tipo Date/Time.
El problema aporta EGAFutura__Causa_origen__c, EGAFutura__Sintomas__c y EGAFutura__Workaround__c, los tres Long Text Area.
El ticket es el único que se vincula al cliente, con EGAFutura__Cuenta__c y EGAFutura__Contacto__c.
El vínculo entre incidentes y problemas vive en EGAFutura__Relacion_Incidentes_Problemas__c.
La documentación se enlaza con EGAFutura__Relacion_Articulo_Ticket__c y EGAFutura__Relacion_Articulo_Tarea__c, sobre EGAFutura__Articulo_KB__c.
El etiquetado transversal usa EGAFutura__Relacion_Ticket_ser_EGA_Futura_Tag__c, que apunta a EGAFutura__EGA_Futura_Tag__c.
Al ser objetos de unión, todos ellos se consultan por sus relaciones hijas y no por un campo del ticket.