Seu template de dados para gestão de solicitações de serviço
Seu template de dados para gestão de solicitações de serviço
- Atributos recomendados para análise abrangente
- Principais atividades para monitorar na descoberta de processos
- Orientação sobre extração de dados do seu sistema de origem
Atributos de gestão de solicitações de serviço
| Nome | Descrição | ||
|---|---|---|---|
|
ID da Solicitação de Serviço
ServiceRequestID
|
O identificador exclusivo para cada solicitação de serviço. | ||
|
Descrição
O ID da Solicitação de Serviço identifica exclusivamente cada solicitação individual. Ele serve como o fio condutor que liga todos os eventos subsequentes, desde o registro inicial até o fechamento final, permitindo uma análise completa e de ponta a ponta da jornada de cada solicitação.
Por que é importante
Este é o identificador de caso essencial que conecta todas as atividades relacionadas em uma única instância de processo, permitindo a análise de ponta a ponta.
Onde obter
Esta é a chave primária do objeto Solicitação de Serviço, geralmente encontrada como ServiceReqNumber na tabela ServiceReq.
Exemplos
SR-0012345SR-0012346SR-0012347
|
|||
|
Nome da Atividade
ActivityName
|
O nome do evento ou tarefa que ocorreu em um ponto específico do ciclo de vida da solicitação de serviço. | ||
|
Descrição
Este atributo descreve uma etapa específica ou mudança de status, como "Enviado para Aprovação". Analisar a sequência e frequência das atividades é fundamental para entender o fluxo, identificar gargalos e descobrir desvios do procedimento padrão.
Por que é importante
Define as etapas no mapa de processo, permitindo visualizar fluxos, retrabalhos, gargalos e desvios.
Onde obter
Normalmente derivado de mudanças de status, entradas de journal ou descrições de eventos de auditoria no Ivanti Service Manager.
Exemplos
Solicitação de Serviço CriadaSolicitação aprovadaSolicitação de Serviço ResolvidaSolicitação de Serviço Encerrada
|
|||
|
Tempo do Evento
EventTime
|
O timestamp que indica quando uma atividade ou evento específico ocorreu. | ||
|
Descrição
A Hora do Evento (Event Time) é o registro preciso de quando uma atividade ocorreu. Esse timestamp é fundamental para ordenar os eventos e serve de base para cálculos de tempo de ciclo, espera e duração.
Por que é importante
Este timestamp é essencial para ordenar os eventos cronologicamente e calcular todas as métricas de duração, que são a chave para a análise de desempenho.
Onde obter
Encontrado em logs de auditoria, entradas de diário ou registros de mudança de status da requisição.
Exemplos
2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:22:00Z
|
|||
|
Sistema de Origem
SourceSystem
|
O sistema do qual os dados foram extraídos. | ||
|
Descrição
Este atributo identifica a origem dos dados do processo. Para esta visão, o valor será constante, indicando que todos os dados vêm do Ivanti Service Manager, o que garante a linhagem clara dos dados.
Por que é importante
Oferece contexto sobre a origem dos dados, garantindo análises precisas em ambientes com múltiplos sistemas.
Onde obter
Este é geralmente um valor estático adicionado durante o processo de extração de dados para rotular a origem do dataset.
Exemplos
Ivanti Service Manager
|
|||
|
Última Atualização de Dados
LastDataUpdate
|
O timestamp da atualização de dados mais recente do sistema de origem. | ||
|
Descrição
Este atributo indica quando os dados foram extraídos do Ivanti. Ele dá contexto sobre quão atualizados estão os dados analisados e o que se pode esperar da cobertura temporal.
Por que é importante
Informa sobre a atualidade dos dados, crucial para decisões baseadas na performance mais recente do processo.
Onde obter
Valor gerado e aplicado ao conjunto de dados no momento da extração.
Exemplos
2024-05-20T12:00:00Z2024-05-21T12:00:00Z
|
|||
|
Agente atribuído
AssignedAgent
|
O usuário individual ou agente atribuído à solicitação de serviço. | ||
|
Descrição
O Agente Atribuído é a pessoa específica responsável por trabalhar na solicitação de serviço. Este atributo permite a análise em nível individual, útil para gestão de desempenho, equilíbrio de carga de trabalho e identificação de necessidades de treinamento. Rastrear reatribuições entre agentes é fundamental para calcular KPIs como "Média de Reatribuições por Solicitação" e entender as ineficiências do processo.
Por que é importante
Permite analisar a carga de trabalho, performance e padrões de reatribuição, o que pode indicar carências em treinamento ou falhas no roteamento inicial.
Onde obter
Geralmente encontrado em um campo como "Owner". Isso pode mudar a cada reatribuição e deve ser registrado no event log.
Exemplos
Alice JohnsonBob WilliamsCharlie BrownDiana Prince
|
|||
|
Equipe designada
AssignedTeam
|
A equipe ou grupo de suporte atualmente atribuído para tratar a solicitação de serviço. | ||
|
Descrição
Este atributo identifica a equipe responsável em cada momento. Analisar transferências, tempo por equipe e volume de chamados é crucial para entender a distribuição de carga de trabalho, identificar gargalos e avaliar o desempenho do time.
Por que é importante
Rastreia responsabilidades e transferências, ajudando a analisar atrasos entre equipes, equilíbrio de carga e quais times são gargalos no processo.
Onde obter
Geralmente armazenado em um campo como "OwnerTeam" no objeto da Solicitação de Serviço ou em registros de atribuição relacionados.
Exemplos
Service Desk de TIOperações de redeSuporte de RHGestão de Facilities
|
|||
|
Event End Time
EventEndTime
|
O timestamp que indica quando uma atividade foi concluída. | ||
|
Descrição
O Event End Time marca a conclusão de uma atividade. A duração entre o Event Time (início) e o Event End Time representa o tempo de processamento daquela atividade específica. Isso é crucial para identificar quais etapas do processo consomem mais tempo, ajudando a localizar gargalos e áreas de melhoria.
Por que é importante
Permite calcular a duração de atividades individuais, essencial para achar gargalos e tarefas demoradas.
Onde obter
Pode não ser um campo distinto; costuma ser o horário de início da atividade seguinte no mesmo caso.
Exemplos
2023-10-26T10:05:00Z2023-10-26T11:45:00Z2023-10-28T09:00:00Z
|
|||
|
Prazo Final do SLA
SLADeadline
|
O timestamp no qual se espera que a solicitação de serviço seja resolvida. | ||
|
Descrição
O Prazo de SLA é a data e hora calculadas em que uma solicitação de serviço deve ser resolvida para cumprir o acordo de nível de serviço. Comparar o tempo real de resolução com este prazo é a base para medir a aderência ao SLA.
Por que é importante
É a referência para medir a performance real, apoiando o cálculo de adesão ao SLA e achando requisições em risco.
Onde obter
Frequentemente um campo calculado no Ivanti, armazenado em campos relacionados ao SLA ou Oferta, como "ResolutionTargetDateTime".
Exemplos
2023-10-27T17:00:00Z2023-10-28T09:00:00Z2023-11-02T12:00:00Z
|
|||
|
Prioridade
Priority
|
O nível de prioridade atribuído à solicitação de serviço. | ||
|
Descrição
A Prioridade indica urgência (Baixa, Média, Alta, Crítica). É vital para avaliar se o processo agiliza o que é importante. A análise compara tempos de ciclo e SLA entre níveis de prioridade.
Por que é importante
Crucial para avaliar a eficácia da estratégia de priorização e garantir que requisições críticas sejam resolvidas mais rápido que as de baixa prioridade.
Onde obter
Um campo padrão no objeto de requisição, geralmente chamado de 'Prioridade'.
Exemplos
1 - Crítico2 - Alto3 - Médio4 - Baixo
|
|||
|
Status da solicitação de serviço
ServiceRequestStatus
|
O status da solicitação de serviço no momento do evento. | ||
|
Descrição
Este atributo captura o estado da solicitação, como "Registrada", "Em andamento", "Pendente", "Resolvida" ou "Fechada". Analisar o tempo em cada status revela gargalos, como solicitações que ficam tempo demais em estado "Pendente".
Por que é importante
Oferece um retrato do estado da requisição a qualquer momento, essencial para calcular o tempo em cada etapa e achar paradas.
Onde obter
Um campo padrão no objeto de requisição, comumente chamado de 'Status'.
Exemplos
RegistradoAtivoAguardando o clienteAtendidoEncerrado
|
|||
|
Status do SLA
SLAStatus
|
Indica se a requisição foi resolvida dentro do prazo do SLA. | ||
|
Descrição
Atributo derivado que sinaliza se a solicitação cumpriu ou violou o SLA. É a base para o dashboard de Performance de SLA e para o KPI de Taxa de Aderência, comparando a data de resolução com o prazo estipulado.
Por que é importante
Mede diretamente a performance em relação aos compromissos de serviço, essencial para avaliar a qualidade e manter a confiança do usuário.
Onde obter
Calculado comparando 'Data/Hora de Resolução' com o 'Prazo de SLA'. Se for menor ou igual, o status é 'Cumprido'; caso contrário, é 'Violado'.
Exemplos
AtingidoViolado
|
|||
|
Tempo de Ciclo
CycleTime
|
O tempo total desde a criação da solicitação de serviço até sua resolução final. | ||
|
Descrição
O Tempo de Ciclo mede a duração do primeiro evento (Criação) ao evento de resolução. É um dos KPIs mais importantes de eficiência. Esta métrica é usada em Dashboards para monitorar a performance geral e identificar tendências.
Por que é importante
Este é um KPI primário para medir a eficiência do processo de ponta a ponta e reflete diretamente a experiência do serviço do ponto de vista do usuário.
Onde obter
Calculado subtraindo o timestamp de criação do timestamp de resolução de cada requisição.
Exemplos
25920000060480000086400000
|
|||
|
Timestamp da resolução
ResolutionDateTime
|
A data e hora em que a solicitação de serviço foi oficialmente resolvida. | ||
|
Descrição
Atributo de nível de caso que marca o momento final da entrega do serviço ou correção do problema, antes do fechamento formal. É o ponto final para o cálculo do tempo de ciclo de ponta a ponta e vital para medir a eficiência e aderência ao SLA.
Por que é importante
Define o ponto final para o cálculo do tempo de ciclo, um KPI essencial para a eficiência da entrega de serviços.
Onde obter
Um campo de data/hora específico no objeto de requisição, frequentemente chamado de 'ResolvedDateTime' ou similar.
Exemplos
2023-10-28T10:15:00Z2023-10-29T11:00:00Z2023-11-01T16:30:00Z
|
|||
|
Tipo de solicitação de serviço
ServiceRequestType
|
A classificação ou categoria da solicitação de serviço. | ||
|
Descrição
Este atributo categoriza a solicitação (ex: hardware, instalação de software, troca de senha). É uma dimensão crítica para análise, permitindo comparar desempenho, tempos de ciclo e aderência ao SLA entre diferentes serviços, ajudando a focar melhorias.
Por que é importante
Segmentar o processo por tipo de solicitação permite uma análise direcionada, revelando se certos tipos de solicitações são mais propensos a atrasos, retrabalho ou violações de SLA.
Onde obter
Geralmente um campo como 'Serviço' ou 'Categoria'. Verifique a documentação do Ivanti para nomes como
Exemplos
Nova requisição de hardwareAcesso a softwareModificação de contaConsulta de informação
|
|||
|
Canal
Channel
|
O método ou canal pelo qual a solicitação de serviço foi enviada. | ||
|
Descrição
O canal indica como a solicitação de serviço foi criada, por exemplo, via Portal de Autoatendimento, E-mail, Telefone ou automaticamente por outro sistema. Analisar volumes e tempos de resolução por canal traz insights sobre quais meios são mais eficientes e quais exigem melhorias ou treinamento de usuários.
Por que é importante
Ajuda a entender o comportamento do usuário e a eficiência dos canais, orientando decisões sobre estratégia de entrega e automação.
Onde obter
Geralmente armazenado em um campo do tipo "Fonte" ou "Criado por" no objeto de Solicitação de Serviço.
Exemplos
Self ServiceEmailTelefoneEntrada direta
|
|||
|
Categoria de resolução
ResolutionCategory
|
Uma classificação da resolução fornecida para a requisição de serviço. | ||
|
Descrição
A Categoria de Resolução oferece uma forma estruturada de classificar como uma solicitação de serviço foi resolvida. Geralmente é uma classificação hierárquica (ex: Categoria, Subcategoria) que auxilia na análise de causa raiz. Por exemplo, pode destacar problemas recorrentes, que podem ser usados para melhorar serviços ou criar artigos na base de conhecimento.
Por que é importante
Gera insights sobre o tipo de resolução, ajudando a identificar problemas comuns, melhorias de serviço e candidatos à automação.
Onde obter
Geralmente armazenado em campos preenchidos na resolução, como 'Categoria de Resolução' ou um campo de código de fechamento.
Exemplos
Treinamento de usuário necessárioSoftware implantadoHardware reparadoAcesso concedido
|
|||
|
Contagem de atribuições
AssignmentCount
|
O número total de vezes que uma solicitação de serviço foi atribuída ou reatribuída. | ||
|
Descrição
Esta métrica conta as atividades de atribuição. Um número alto de reatribuições, o famoso "ping-pong de tickets", indica falhas no roteamento, falta de resolução no primeiro contato ou papéis indefinidos, sendo essencial para o KPI de Média de Reatribuições.
Por que é importante
Quantifica transferências ineficientes e problemas de roteamento. Uma contagem alta é um forte indício de tempos de resolução prolongados e frustração dos usuários.
Onde obter
Calculado contando as ocorrências de atividades de atribuição para cada ID de requisição durante a preparação dos dados.
Exemplos
12345
|
|||
|
Contagem de Reaberturas
ReopenCount
|
O número de vezes que uma solicitação de serviço resolvida foi reaberta. | ||
|
Descrição
Este atributo é um contador incrementado sempre que uma solicitação resolvida ou fechada volta a ficar ativa. Um número alto de reaberturas indica baixa qualidade na resolução ou problemas recorrentes, alimentando o KPI de Taxa de Retrabalho.
Por que é importante
Mede o retrabalho e é um indicador de qualidade. Números altos sugerem que a solução inicial não foi eficaz.
Onde obter
Normalmente um campo contador no objeto de Solicitação de Serviço que é incrementado por uma regra de negócio quando o status muda. Pode se chamar "ReopenCounter".
Exemplos
0123
|
|||
|
Departamento do solicitante
RequestorDepartment
|
O departamento de negócio do usuário que enviou a solicitação de serviço. | ||
|
Descrição
Este atributo identifica o departamento (ex: Vendas, Financeiro, RH) que iniciou a solicitação. Permite analisar a qualidade e a demanda por área, ajudando a ver se certos departamentos têm tempos de resolução maiores ou maior volume de chamados.
Por que é importante
Permite analisar o consumo e a qualidade do serviço por unidade de negócio, ajudando a identificar tendências ou problemas específicos de departamentos.
Onde obter
Normalmente recuperado do perfil do usuário solicitante. O campo pode ser "Department" no objeto Profile.Employee.
Exemplos
FinançasVendasMarketingTecnologia da Informação
|
|||
|
É Retrabalho
IsRework
|
Uma flag booleana indicando se a requisição de serviço envolveu atividades de retrabalho. | ||
|
Descrição
Esta flag calculada é ativada se uma solicitação mostra sinais de retrabalho, como reaberturas ou loops de atividades. Ela simplifica o cálculo do KPI de Taxa de Retrabalho e ajuda a filtrar processos ineficientes nos dashboards.
Por que é importante
Ajuda a identificar e quantificar requisições que exigem esforço extra não planejado, destacando falhas de qualidade.
Onde obter
Derivado dos dados. A lógica pode se basear no atributo 'ReopenCount' ser maior que zero ou pela detecção de sequências como múltiplos eventos de 'Atribuído ao Agente'.
Exemplos
verdadeirofalse
|
|||
|
Nome do Fornecedor
VendorName
|
O nome do fornecedor externo envolvido na resolução da solicitação. | ||
|
Descrição
Este atributo identifica o fornecedor terceirizado envolvido na solicitação. É essencial para medir e comparar o desempenho de diferentes fornecedores e identificar gargalos causados por dependências externas.
Por que é importante
Permite analisar a performance de terceiros e seu impacto nos tempos de resolução, auxiliando na gestão de fornecedores.
Onde obter
Pode ser um campo em um objeto de tarefa associado à solicitação ou um campo específico na própria Solicitação de Serviço se um fornecedor estiver atribuído.
Exemplos
Suporte DellOracle ConsultingMicrosoft Premiernulo
|
|||
Atividades de gestão de solicitações de serviço
| Atividade | Descrição | ||
|---|---|---|---|
|
Solicitação atribuída à equipe
|
A solicitação de serviço é atribuída a uma equipe de suporte específica. Isso é capturado ao observar o preenchimento ou alteração do campo "OwnerTeam" no registro da Solicitação de Serviço. | ||
|
Por que é importante
Este evento é crucial para analisar o desempenho por equipe, distribuição de carga e tempos de transferência. Ajuda a identificar quais times são gargalos no processo.
Onde obter
Rastreado por alterações no campo "OwnerTeam" no histórico de auditoria ou journal da Solicitação de Serviço.
Captura
Um evento de atualização no campo 'Equipe Proprietária', geralmente registrado em uma trilha de auditoria.
Tipo de evento
explicit
|
|||
|
Solicitação Atribuída ao Agente
|
Um agente específico assume a responsabilidade pela requisição. Esta atividade é geralmente identificada quando o campo 'Proprietário' (Owner) é preenchido ou atualizado pela primeira vez. | ||
|
Por que é importante
Marca o fim do tempo de espera inicial ou fila. Medir a duração até aqui ajuda a identificar problemas de alocação de recursos e alimenta o dashboard de Carga de Trabalho.
Onde obter
Identificado pelo preenchimento ou alteração do campo 'Proprietário' (Owner) no histórico.
Captura
O primeiro registro de data e hora em que o campo "Owner" é preenchido com o nome de um agente após a criação ou atribuição de equipe.
Tipo de evento
inferred
|
|||
|
Solicitação de Serviço Criada
|
Esta atividade marca o início do ciclo de vida da solicitação de serviço quando um novo pedido é formalmente enviado e registrado no Ivanti. Este evento é capturado quando um novo registro é criado, gerando um ID exclusivo. | ||
|
Por que é importante
Este é o principal evento de início do processo. Analisar o tempo deste ponto até a resolução é fundamental para medir o tempo de ciclo e a eficiência geral.
Onde obter
Capturado a partir do timestamp de criação do registro da Solicitação de Serviço (ex: campo CreatedDateTime no objeto ServiceReq).
Captura
O evento de criação de registro na tabela ServiceReq, identificado pelo seu timestamp de criação.
Tipo de evento
explicit
|
|||
|
Solicitação de Serviço Encerrada
|
A solicitação de serviço está oficialmente fechada e nenhuma outra ação pode ser tomada. Isso geralmente ocorre de forma automática após um período definido no estado "Resolvido", representando a conclusão final do ciclo de vida. | ||
|
Por que é importante
Esta atividade é o fim definitivo do processo. O tempo entre "Resolvido" e "Fechado" pode evidenciar atrasos na confirmação ou em processos automáticos do sistema.
Onde obter
Identificado pela mudança do campo 'Status' para 'Fechado', com seu respectivo timestamp.
Captura
Detecção de atualização do campo 'Status' para 'Fechado' via histórico de auditoria.
Tipo de evento
inferred
|
|||
|
Solicitação de Serviço Resolvida
|
A solicitação de serviço é considerada resolvida e a solução foi entregue ao usuário. Este é um marco principal capturado por uma mudança de status para "Resolvido", interrompendo cronômetro de SLA. | ||
|
Por que é importante
Ponto final crítico para medir o tempo de resolução e adesão ao SLA. A duração desde a criação até esta atividade é um KPI central para o desempenho do processo.
Onde obter
Identificado pela mudança do campo 'Status' para 'Resolvido', com seu respectivo timestamp.
Captura
Detecção de atualização do campo 'Status' para 'Resolvido' via histórico de auditoria.
Tipo de evento
inferred
|
|||
|
Fornecedor externo acionado
|
O atendimento da solicitação de serviço foi repassado a um fornecedor externo ou terceiro. Isso geralmente é capturado por uma mudança de status para "Aguardando Terceiros" ou similar. | ||
|
Por que é importante
Esta atividade é essencial para medir o desempenho do fornecedor e seu impacto no tempo de ciclo geral. Permite analisar atrasos de terceiros e alimenta o dashboard de Duração da Atividade de Fornecedores Externos.
Onde obter
Identificado pela mudança para um status como 'Aguardando Terceiros' ou 'Pendente Fornecedor'.
Captura
Detecção de mudança no campo 'Status' para um estado de 'aguardando fornecedor'.
Tipo de evento
inferred
|
|||
|
Informação fornecida pelo usuário
|
O solicitante forneceu as informações necessárias, permitindo que o agente retome o trabalho. Isso é capturado quando a solicitação sai de um status de "Aguardando Cliente" e volta para um estado ativo. | ||
|
Por que é importante
Este evento fecha o ciclo do pedido de informação. O tempo entre pedir e receber os dados é um componente crítico dos atrasos e loops de retrabalho no processo.
Onde obter
Identificado quando o status muda de 'Aguardando Cliente' para um estado ativo, como 'Em Andamento'.
Captura
Detecção de mudança de status de 'aguardando usuário' para um estado ativo.
Tipo de evento
inferred
|
|||
|
Informação solicitada ao usuário
|
O agente atribuído precisa de mais informações do solicitante para prosseguir com o atendimento. Isso é capturado quando o status da solicitação é atualizado para um estado como "Aguardando Cliente". | ||
|
Por que é importante
Esta atividade destaca atrasos causados por informações iniciais incompletas. Rastrear sua frequência e duração é fundamental para a Análise de Impacto de Pedidos de Informação e para identificar áreas de melhoria.
Onde obter
Identificado pela mudança para um status como 'Aguardando Cliente' ou 'Pendente'.
Captura
Detecção de mudança no campo 'Status' para um estado de 'aguardando usuário'.
Tipo de evento
inferred
|
|||
|
Prioridade Alterada
|
A prioridade da solicitação de serviço foi atualizada após sua criação inicial. Este evento é capturado a partir do log de auditoria ou histórico que rastreia mudanças no nível do campo. | ||
|
Por que é importante
Rastrear mudanças de prioridade é vital para a Visão Geral de Eficácia de Priorização. Ajuda a ver se as escalações são geridas corretamente e se a prioridade inicial foi precisa.
Onde obter
Evento explícito capturado do histórico de auditoria do registro de Solicitação de Serviço, que registra alterações no campo "Prioridade".
Captura
Um evento de atualização no campo 'Prioridade' registrado na trilha de auditoria do sistema.
Tipo de evento
explicit
|
|||
|
Solicitação aprovada
|
A solicitação de serviço recebeu todas as aprovações necessárias e agora pode prosseguir para o atendimento. Este evento é capturado quando o workflow de aprovação termina com sucesso, alterando o status da solicitação. | ||
|
Por que é importante
Esta atividade marca um marco importante, sinalizando o fim da fase de aprovação e o início do atendimento. Permite medir a eficiência do próprio processo de aprovação.
Onde obter
Identificado pela mudança de 'Aguardando Aprovação' para 'Aprovado' ou 'Atendido'. Pode ser um evento explícito no objeto
Captura
Uma mudança no campo 'Status' do registro da requisição de um estado de aprovação para um estado ativo.
Tipo de evento
inferred
|
|||
|
Solicitação de serviço atendida
|
Todas as tarefas de atendimento foram concluídas. Isso é identificado por uma mudança de status para 'Atendido' (Fulfilled), que geralmente precede o status final de 'Resolvido'. | ||
|
Por que é importante
Este marco indica a conclusão do trabalho técnico. É um ponto-chave para medir o tempo de tratamento ativo antes da confirmação final e fechamento.
Onde obter
Identificado pela mudança do campo 'Status' para 'Atendido' (Fulfilled).
Captura
Uma mudança no campo 'Status' para 'Atendido' (Fulfilled) detectada no histórico do registro.
Tipo de evento
inferred
|
|||
|
Solicitação de serviço cancelada
|
A solicitação de serviço foi cancelada pelo usuário ou por um agente antes da resolução. Este é um estado final alternativo capturado por uma mudança de status para "Cancelado" ou "Retirado". | ||
|
Por que é importante
Representa um encerramento fora do padrão. Analisar por que os pedidos são cancelados pode revelar problemas no próprio processo de solicitação ou mudanças nas necessidades dos usuários.
Onde obter
Identificado pela mudança do campo 'Status' para 'Cancelado'.
Captura
Detecção de atualização do campo 'Status' para 'Cancelado' via histórico de auditoria.
Tipo de evento
inferred
|
|||
|
Solicitação de serviço reaberta
|
Uma requisição resolvida anteriormente foi reativada porque o problema persiste ou a solução foi insatisfatória. Isso ocorre quando o status muda de 'Resolvido' para um estado ativo como 'Ativo' ou 'Atribuído'. | ||
|
Por que é importante
Esta atividade é um indicador direto de retrabalho e baixa qualidade na resolução de primeira. Analisar eventos de reabertura ajuda a identificar fraquezas no processo e melhorar o KPI de Taxa de Retrabalho de Solicitações.
Onde obter
Identificado via histórico quando o status muda de 'Resolvido' ou 'Fechado' para um estado ativo.
Captura
Uma mudança de status de um estado final ('Resolvido', 'Fechado') para um estado aberto ('Ativo', 'Atribuído').
Tipo de evento
inferred
|
|||
|
Solicitação enviada para aprovação
|
A solicitação de serviço foi enviada para as aprovações necessárias antes de ser atendida. Isso é geralmente inferido quando o status muda para "Enviado" ou "Pendente de Aprovação", disparando um workflow de aprovação. | ||
|
Por que é importante
Rastrear esta atividade ajuda a identificar atrasos na fase de aprovação. Esperas longas aqui podem ser um gargalo crítico que atrasa a resolução final.
Onde obter
Identificado pela mudança para 'Submetido' ou 'Aguardando Aprovação'. Pode vir dos objetos
Captura
Uma mudança no campo 'Status' da requisição para um estado pendente de aprovação.
Tipo de evento
inferred
|
|||