Você está aqui:
Ciclo de vida do SLA em uma organização de serviços de TI (exemplo)
Este exemplo mostra como um administrador de TI no Cumulus Bank usa o Gerenciamento de SLA para garantir que incidentes, problemas e solicitações de alteração sejam tratados de modo eficiente e de acordo com acordos de nível de serviço (SLAs).
Edições obrigatórias
| Disponível em: Lightning Experience |
| Disponível em: Edições Enterprise, Performance e Unlimited com o Serviço de TI Agentforce. |
Desafio de negócios
Paula é administradora de TI e quer garantir que problemas críticos de TI sejam resolvidos prontamente e que sua equipe atenda às metas de serviço para resolver problemas e alterações. Ela também quer fornecer à sua equipe cronogramas claros e automatizados para diferentes registros de serviço de TI com diferentes prioridades e uma maneira fácil de acompanhar visualmente essas cronogramas.
Se o destino for violado, ela quer que determinadas ações ocorram, como um email sendo enviado às partes interessadas e membros da equipe necessários para escalonamento.
Solução
Ela decide configurar o Gerenciamento de SLA para Serviço de TI Agentforce com políticas de SLA predefinidas para incidentes, problemas e alterações para fornecer cronogramas claros e automatizados para sua equipe de suporte de TI.
Configuração de SLA
Paula começa ativando o Gerenciamento de SLA e o controle de versões de SLA na configuração simplificada. Em seguida, ela cria as políticas predefinidas necessárias para incidentes, problemas e solicitações de alteração. Essa ação simples configura políticas padrão do setor, define os marcos, critérios de cancelamento, ações de escalação e aplica automaticamente regras de direito.
Ela também configura a opção de pausar manualmente marcos para evitar violações injustas quando os representantes de TI estão aguardando dependências externas ou de partes interessadas.
Ciclo de vida de SLA em ação
Com as políticas e regras em vigor, é assim que o sistema lida com um novo incidente de TI relatado por um funcionário.
| Fase | Ações |
|---|---|
| Criação de incidente | Um funcionário relata um problema de VPN por meio do portal de autoatendimento. O Salesforce registra automaticamente um registro de incidente com uma prioridade crítica e o atribui à fila de Incidente de prioridade crítica. |
| Entrada da política de SLA de incidente | O incidente entra na política de SLA de Suporte padrão para incidente e é atribuído ao marco Confirmar dentro com uma meta de tempo de 30 minutos e ao marco Resolver dentro com uma meta de tempo de 2 horas com base nas propriedades do registro. |
| Marco de incidente em andamento | Jake, um processador de TI, abre o registro, vê que o temporizador de SLA foi iniciado e reconhece o incidente. |
| Criação de problema | Depois de investigar, Jake descobre que muitos funcionários relataram o mesmo problema. Ele cria um registro de problema para o incidente. Ele também associa todos os incidentes semelhantes com a ajuda da Agentforce. |
| Entrada da política de SLA de problema | O registro de problema entra na política de SLA de Suporte padrão para problema. O sistema atribui um marco de Tempo de conclusão da causa raiz com uma meta de 24 horas para problemas de prioridade crítica. Esta é uma métrica-chave para medir o desempenho da equipe de Paula. |
| Pausar marcos | John, um processador de problemas, recebe o problema e começa a trabalhar nele. Ele descobre que precisa de contribuições de um fornecedor externo para resolver o problema. Para garantir que a linha do tempo do SLA seja rastreada com precisão e não seja violada devido a uma dependência externa, ele pausa manualmente o marco. |
| Concluição do marco de problema | Depois que John obtém as informações necessárias, ele retoma o temporizador, atualiza o registro do problema e cria uma solicitação de alteração para implementar a correção. |
| Recálculo e saída da política de problema | Após cada atualização de registro, a política de SLA verifica se há novos marcos. O registro permanece na política até que os critérios de saída definidos sejam atendidos. Depois que John cria a solicitação de alteração para implementar a correção, a análise de causa raiz do problema é concluída, o que significa que os critérios de saída para a política de SLA do problema são atendidos. |
| Entrada da política de SLA de solicitação de alteração | O registro de solicitação de alteração entra automaticamente na política de SLA de Suporte padrão para solicitação de alteração. O sistema atribui o marco Confirmação de alteração com uma meta de tempo de quatro horas. |
| Altere a conclusão do marco | Sara, um processador de alteração, conclui o marco atualizando o status da solicitação de alteração de Novo para um status em andamento. |
| Saída da política de incidente e solicitação de alteração | A política de Solicitação de alteração sai do SLA quando o status não é mais Novo. Para incidentes, depois que a solicitação de alteração é implementada, o status do incidente é resolvido e o registro do incidente sai da política de SLA. |
