Usted estĆ” aquĆ:
Ciclo de vida de SLA en una organizaciĆ³n de servicios de TI (Ejemplo)
Este ejemplo muestra cĆ³mo un administrador de TI de Cumulus Bank utiliza GestiĆ³n de SLA para asegurarse de que los incidentes, problemas y solicitudes de cambio se gestionan de forma eficiente y de acuerdo con acuerdos de nivel de servicio (SLA).
Ediciones necesarias
| Disponible en: Lightning Experience |
| Disponible en: Ediciones Enterprise, Performance y Unlimited con Agentforce IT Service. |
Reto comercial
Paula es una administradora de TI y desea asegurarse de que los problemas crĆticos de TI se solucionan rĆ”pidamente y que su equipo cumple los objetivos de servicio para resolver problemas y cambios. TambiĆ©n desea proporcionar a su equipo cronologĆas claras y automatizadas para diferentes registros de servicio de TI con diferentes prioridades y una forma visual sencilla de realizar un seguimiento de estas cronologĆas.
Si se incumple el objetivo, desea que se realicen ciertas acciones, como el envĆo de un correo electrĆ³nico a las partes interesadas y miembros del equipo requeridos para su distribuciĆ³n.
SoluciĆ³n
Decide configurar GestiĆ³n de SLA para Agentforce IT Service con polĆticas de SLA predefinidas para incidentes, problemas y cambios para proporcionar cronologĆas claras y automatizadas para su equipo de asistencia de TI.
ConfiguraciĆ³n de SLA
Paula comienza activando GestiĆ³n de SLA y VersiĆ³n de SLA desde la configuraciĆ³n simplificada. A continuaciĆ³n crea las polĆticas predefinidas necesarias para incidentes, problemas y solicitudes de cambio. Esta acciĆ³n sencilla configura polĆticas estĆ”ndar del sector, define los eventos clave, los criterios de cancelaciĆ³n, las acciones de distribuciĆ³n y aplica automĆ”ticamente reglas de asignaciĆ³n.
TambiĆ©n configura la opciĆ³n para poner en pausa manualmente eventos clave para evitar infracciones injustas cuando los representantes de TI estĆ”n esperando dependencias externas o de partes interesadas.
Ciclo de vida de SLA en acciĆ³n
Con las polĆticas y reglas vigentes, este es el modo en que el sistema gestiona un nuevo incidente de TI reportado por un empleado.
| Etapa | Acciones |
|---|---|
| CreaciĆ³n de incidentes | Un empleado informa de un problema de VPN a travĆ©s del portal de autoservicio. Salesforce registra automĆ”ticamente un registro de incidente con una prioridad crĆtica y lo asigna a la cola Incidente de prioridad crĆtica. |
| Entrada de polĆtica de SLA de incidente | El incidente entra en la polĆtica de SLA de asistencia estĆ”ndar para incidentes y se le asigna el evento clave Reconocer dentro con un objetivo de tiempo de 30 minutos y el evento clave Resolver dentro con un objetivo de tiempo de 2 horas basĆ”ndose en las propiedades del registro. |
| Evento clave de incidente en curso | Jake, un empleado de TI, abre el registro, ve que se iniciĆ³ el temporizador de SLA y reconoce el incidente. |
| CreaciĆ³n de problemas | DespuĆ©s de investigar, Jake encuentra que muchos empleados reportaron el mismo problema. Crea un registro de problema para el incidente. TambiĆ©n asocia todos los incidentes similares con Ć©l con la ayuda de Agentforce. |
| Entrada de polĆtica de SLA de problema | El registro de problema entra en la polĆtica de SLA de compatibilidad estĆ”ndar para problemas. El sistema asigna un evento clave Tiempo de finalizaciĆ³n de causa raĆz con un objetivo de 24 horas para problemas de prioridad crĆticos. Esta es una mediciĆ³n clave para medir el rendimiento del equipo de Paula. |
| Eventos clave en pausa | John, un solucionador de problemas, recibe el problema y comienza a trabajar en Ć©l. Se da cuenta de que necesita la entrada de un proveedor externo para resolver el problema. Para asegurarse de que se realiza un seguimiento preciso de la cronologĆa del SLA y no se infringe debido a una dependencia externa, realiza una pausa manual en el evento clave. |
| FinalizaciĆ³n de evento clave de problema | DespuĆ©s de que John obtenga la informaciĆ³n requerida, reanuda el temporizador, actualiza el registro del problema y crea una solicitud de cambio para implementar la soluciĆ³n. |
| Nuevo cĆ”lculo y salida de la polĆtica de problemas | DespuĆ©s de cada actualizaciĆ³n de registro, la polĆtica de SLA comprueba nuevos eventos clave. El registro permanece en la polĆtica hasta que se cumplan los criterios de salida definidos. DespuĆ©s de que John cree la solicitud de cambio para implementar la soluciĆ³n, el anĆ”lisis de causa raĆz para el problema estĆ” completo, lo que significa que se cumplen los criterios de salida para la polĆtica de SLA del problema. |
| Entrada de polĆtica de SLA de solicitud de cambio | El registro de solicitud de cambio entra automĆ”ticamente en la polĆtica de SLA de solicitud de cambio de compatibilidad estĆ”ndar. El sistema asigna el evento clave Reconocimiento de cambio con un objetivo de tiempo de 4 horas. |
| Cambiar finalizaciĆ³n de evento clave | Sara, una realizadora de cambios, completa el evento clave actualizando el estado de la solicitud de cambio de Nuevo a un estado en curso. |
| Solicitud de cambio y Salida de polĆtica de incidente | La polĆtica Solicitud de cambio sale del SLA cuando el estado ya no es Nuevo. Para incidentes, una vez implementada la solicitud de cambio, se resuelve el estado del incidente y el registro del incidente sale de la polĆtica de SLA. |
