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 de negocio
Paula es una administradora de TI y desea asegurarse de que los problemas de TI crĆticos se solucionen rĆ”pidamente y que su equipo cumpla 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 email a las partes interesadas y los 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 sencilla acción configura polĆticas estĆ”ndar de la industria, 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 establecidas, 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 reporta 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 Confirmar en con un objetivo de tiempo de 30 minutos y el evento clave Resolver en con un objetivo de tiempo de 2 horas basĆ”ndose en las propiedades del registro. |
| Evento clave de incidente en curso | Jake, un responsable 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 la ayuda de Agentforce. |
| Entrada de polĆtica de SLA de problema | El registro del problema ingresa en la polĆtica de SLA de asistencia 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 desempeƱo 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 entradas de un proveedor externo para resolver el problema. Para asegurarse de que se realiza un seguimiento preciso de la cronologĆa de 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 | Cuando John obtiene 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 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 ingresa automĆ”ticamente en la polĆtica de SLA de asistencia estĆ”ndar para solicitud de cambio. 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 incidentes | La polĆtica Solicitud de cambio sale del SLA cuando el estado ya no es Nuevo. Para el incidente, 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. |

