Template de dados: Gerenciamento de Incidentes

Gerenciamento de Problemas do ServiceNow
Template de dados: Gerenciamento de Incidentes

Seu Template de Dados de Gestão de Incidentes

Este Template oferece um guia completo para coletar os dados necessários para analisar e otimizar seu processo de Gestão de Incidentes. Ele lista os atributos essenciais a coletar, as atividades-chave a acompanhar e orientações práticas sobre como extrair essas informações do seu sistema de origem. Use este recurso para montar um Event Log robusto para análise aprofundada e melhoria do processo.
  • Atributos recomendados para coletar
  • Atividades-chave a monitorizar
  • Orientações de extração para o Gerenciamento de Problemas do ServiceNow
É novo em event logs? Saiba como criar um event log para Process Mining.

Atributos de Gerenciamento de Incidentes

Estes são os campos de dados recomendados para incluir no seu Event Log e permitir uma análise completa do seu processo de Gerenciamento de Incidentes.
5 Obrigatório 4 Recomendado 11 Opcional
Nome Descrição
ID do incidente
IncidentId
O identificador único de cada registro de incidente, servindo como chave primária para acompanhar todo o ciclo de vida.
Descrição

O ID do Incidente é o número de referência único atribuído a todo incidente registrado no ServiceNow. Ele funciona como o identificador central do caso, ligando todas as atividades, atualizações e comunicações desde a criação até o encerramento do incidente.

Na análise de Process Mining, esse ID é fundamental. Ele permite que a ferramenta una a sequência de eventos de cada caso, formando a base para descobrir mapas de processo, analisar variantes e calcular durações ponta a ponta. Sem um ID de Incidente exclusivo por caso, seria impossível rastrear a jornada de um incidente ao longo do processo de resolução.

Por que é importante

Este é o ID essencial do incidente que conecta todos os eventos do seu ciclo de vida, possibilitando a análise ponta a ponta do processo.

Onde obter

Tabela incident do ServiceNow, campo number.

Exemplos
INC0010001INC0010045INC0010239
Nome da Atividade
ActivityName
O nome do evento ou da tarefa que ocorreu em um momento do ciclo de vida do incidente.
Descrição

O nome da atividade descreve uma etapa específica ou uma mudança de estado no processo de gerenciamento de incidentes, como 'Incidente criado', 'Atribuído ao agente' ou 'Incidente encerrado'. Esses dados normalmente são derivados de mudanças em campos-chave do incidente, como 'State' ou 'Assignment Group', ou de entradas específicas de log.

Esse atributo é crucial para construir o mapa de processo. Ele define os nós no grafo do processo, permitindo que os analistas visualizem o fluxo dos incidentes, identifiquem caminhos comuns, descubram gargalos entre atividades e analisem variantes do processo. A granularidade e a precisão desses nomes de atividades impactam diretamente a qualidade da análise do processo.

Por que é importante

Define as etapas no mapa do processo, base para toda a análise e visualização de Process Mining.

Onde obter

Este é um atributo derivado, normalmente gerado pela lógica de transformação de dados com base em alterações nos campos state, assignment_group e assigned_to nas tabelas sys_audit ou incident.

Exemplos
Incidente criadoGrupo de atribuição alteradoResolução propostaIncidente encerrado
Tempo do Evento
EventTime
O timestamp preciso que indica quando a atividade ocorreu.
Descrição

Event Time, também conhecido como timestamp, registra a data e a hora exatas em que uma atividade foi concluída ou um status foi alterado. No ServiceNow, isso geralmente é capturado no campo sys_updated_on para cada mudança registrada na trilha de auditoria.

Esse atributo é essencial para ordenar os eventos corretamente e para todas as análises baseadas em tempo. Ele é usado para calcular tempos de ciclo, tempos de fila e durações entre atividades, fundamentais para identificar gargalos, medir a performance contra SLAs e entender a eficiência do processo. A precisão desses timestamps é crítica para a validade de qualquer métrica baseada em duração.

Por que é importante

Esse timestamp ordena todas as atividades em ordem cronológica e permite calcular métricas baseadas em duração, como tempos de ciclo e gargalos.

Onde obter

Tabela sys_audit do ServiceNow: campo sys_created_on ou o campo sys_updated_on da tabela incident para o último estado.

Exemplos
2023-04-15T10:05:21Z2023-04-15T11:22:00Z2023-04-16T09:00:30Z
Sistema de Origem
SourceSystem
O sistema do qual esses dados foram extraídos.
Descrição

Esse atributo identifica a origem dos dados do incidente, que, neste caso, é o ServiceNow Problem Management. Geralmente é um valor estático adicionado durante a extração e a transformação dos dados.

Em ambientes onde dados de vários sistemas podem ser combinados para análise, esse campo é crítico para a linhagem e a segregação dos dados. Ele ajuda a garantir que métricas e processos sejam analisados no contexto correto e permite que analistas comparem processos entre diferentes sistemas de origem.

Por que é importante

Fornece contexto essencial sobre a origem dos dados, garantindo a linhagem dos dados e permitindo interpretação correta em ambientes com múltiplos sistemas.

Onde obter

Normalmente é um valor estático adicionado durante o processo de extração de dados.

Exemplos
Gerenciamento de Problemas do ServiceNowServiceNow
Última Atualização de Dados
LastDataUpdate
O timestamp que indica quando os dados para este registo foram atualizados pela última vez a partir do sistema de origem.
Descrição

Esse atributo registra a data e a hora da extração ou atualização mais recente dos dados do ServiceNow. É um campo de metadados que reflete a atualidade dos dados analisados, não um evento do processo em si.

Essa informação é vital para entender a atualidade da análise. Ela informa quão atuais são os dados, o que é importante para dashboards operacionais e para decisões baseadas em eventos recentes. Ajuda a ajustar expectativas sobre a relevância e a atualidade dos dados.

Por que é importante

Informa os usuários sobre a atualidade dos dados, algo crítico para a relevância e a precisão da análise.

Onde obter

Esse timestamp é gerado e preenchido pela ferramenta ou processo de extração no momento do carregamento dos dados.

Exemplos
2023-10-27T02:00:00Z2023-10-28T02:00:00Z
Atribuído A
AssignedTo
O usuário ou agente atualmente atribuído ao incidente.
Descrição

Esse atributo identifica o analista de suporte responsável pelo incidente em um determinado momento. Essa informação é essencial para entender a distribuição de carga de trabalho, o desempenho dos analistas e as transferências entre pessoas.

Na análise, 'Assigned To' ajuda a visualizar a alocação de recursos e identificar analistas sobrecarregados. Também é usado no Dashboard 'Transferências e Reatribuições' para acompanhar quantas vezes um incidente muda de responsável, o que pode indicar ineficiência ou lacunas de conhecimento. Analisar o tempo de resolução por analista também pode destacar quem tem melhor desempenho ou quem precisa de treinamento adicional.

Por que é importante

Permite analisar carga de trabalho, performance de agentes e repasses individuais, fundamentais para entender a eficiência no uso de recursos.

Onde obter

Tabela incident do ServiceNow, campo assigned_to.

Exemplos
Beth AnglinDavid LooHoward Johnson
Estado do incidente
IncidentState
O status atual do incidente em seu ciclo de vida.
Descrição

O Incident State indica a etapa atual do incidente, como 'New', 'In Progress', 'On Hold' ou 'Resolved'. Mudanças de estado costumam ser a principal fonte para gerar atividades no Event Log para Process Mining.

Analisar o tempo gasto em cada estado é uma forma poderosa de identificar gargalos. Por exemplo, uma longa permanência em 'On Hold' pode indicar dependências de fatores externos ou de usuários. A sequência das mudanças de estado também forma a base do mapa de processo, mostrando como os incidentes avançam rumo à resolução.

Por que é importante

Acompanha o andamento do incidente e é chave para analisar o tempo gasto em cada etapa e identificar gargalos do processo.

Onde obter

Tabela incident do ServiceNow, campo incident_state ou state.

Exemplos
NovoEm ProgressoAguardando informações do usuárioResolvidoEncerrado
Grupo de atribuição
AssignmentGroup
A equipe ou o grupo de suporte responsável pelo tratamento do incidente.
Descrição

O Assignment Group representa a equipe de agentes responsável por resolver o incidente. Muitas vezes, os incidentes são encaminhados entre diferentes grupos, como do Service Desk Nível 1 para uma equipe de rede especializada de Nível 2.

Esse atributo é essencial para analisar transferências entre equipes e identificar gargalos sistêmicos. O Dashboard 'Handoff and Reassignment Rate' depende bastante desses dados para mostrar quais equipes costumam estar envolvidas em transferências. Ele também permite comparar a performance entre diferentes grupos de suporte e ajuda a entender onde está a especialização em resolução dentro da organização.

Por que é importante

Isso registra qual equipe é responsável, permitindo analisar performance, carga de trabalho e as transferências entre grupos.

Onde obter

Tabela incident do ServiceNow, campo assignment_group.

Exemplos
Service DeskSuporte de RedeAdministradores de banco de dados
Prioridade
Priority
O nível de prioridade do incidente, que determina a urgência necessária da resposta.
Descrição

Priority é um campo fundamental no ServiceNow que determina a ordem e a velocidade de tratamento de um incidente. Normalmente, ele é derivado do impacto e da urgência do incidente e influencia diretamente as metas de SLA.

Esse atributo é fundamental para segmentação e análise de performance. O dashboard 'SLA Compliance Overview' usa Priority para avaliar se incidentes de alta prioridade estão sendo resolvidos dentro dos prazos-alvo. Analisar o tempo de ciclo por prioridade ajuda a confirmar que incidentes críticos realmente estão sendo tratados mais rápido do que os menos importantes. É uma dimensão crítica para praticamente todos os KPIs e dashboards.

Por que é importante

Permite segmentar incidentes por importância para o negócio, algo essencial para monitorar a conformidade de SLA e alocar recursos.

Onde obter

Tabela incident do ServiceNow, campo priority.

Exemplos
1 - Crítico2 - Alta3 - Moderada4 - Baixa
Categoria
Category
A classificação de alto nível do incidente, como Hardware, Software ou Rede.
Descrição

A Category fornece uma classificação ampla da natureza do incidente. Isso, muitas vezes em combinação com uma subcategoria, ajuda a direcionar o incidente para a equipe de suporte correta e é usado para relatórios e análise de tendências.

Para Process Mining, esse atributo é crucial nos Dashboards 'Incident Categorization Accuracy' e 'Recurring Incident Volume'. Ao analisar incidentes em que a categoria é alterada no meio do processo, as organizações podem identificar problemas na triagem inicial. Filtrar o mapa de processo por categoria também pode revelar se certos tipos de incidentes seguem caminhos de resolução diferentes ou enfrentam gargalos específicos.

Por que é importante

Permite analisar tipos de incidente, ajuda a medir a assertividade da categorização e é vital para roteamento e análise de tendências.

Onde obter

Tabela incident do ServiceNow, campo category.

Exemplos
HardwareSoftwareRedeBanco de dados
Código de resolução
ResolutionCode
Um código que indica como o incidente foi finalmente resolvido.
Descrição

O 'Resolution Code' especifica a natureza da solução aplicada — por exemplo, se foi resolvido pelo usuário, com base em um erro conhecido, ou se foi fornecido um workaround (solução de contorno). Esse campo normalmente é preenchido pelo analista ao encerrar o incidente.

Esse atributo alimenta diretamente o Dashboard 'Eficácia por Tipo de Resolução'. Ele permite analisar quantos incidentes são encerrados com correções permanentes versus soluções temporárias, um indicador-chave de qualidade do serviço e estabilidade no longo prazo. Uma taxa alta de workarounds pode indicar que problemas subjacentes não estão sendo tratados adequadamente.

Por que é importante

Esclarece o método de resolução, permitindo analisar correções permanentes versus workarounds temporários e apoiando a análise de causa raiz.

Onde obter

Tabela incident do ServiceNow, campo close_code ou um campo customizado de código de resolução.

Exemplos
Resolvido (solução de contorno)Resolvido (permanente)Não resolvido (cancelado pelo usuário)Erro conhecido
Data de vencimento do SLA
SlaDueDate
A data e hora limite para que o incidente seja resolvido conforme seu SLA.
Descrição

O 'SLA Due Date' é um timestamp calculado que representa o prazo de resolução de um incidente. Essa data é determinada pelo Service Level Agreement (SLA) associado às características do incidente, como a prioridade.

Esse atributo é essencial para o Dashboard 'Visão Geral de Conformidade com SLA' e para o KPI 'Taxa de Violação de SLA em Incidentes Críticos'. Serve como referência para comparar com o tempo real de resolução. Analisar incidentes próximos ao prazo do SLA pode ajudar no escalonamento proativo e na priorização.

Por que é importante

Define a meta de resolução, viabilizando medir a conformidade de SLA e identificar incidentes em risco de violar suas metas.

Onde obter

Esse valor geralmente está na tabela task_sla, que se relaciona à tabela incident. O campo planned_end_time é o timestamp relevante.

Exemplos
2023-05-20T17:00:00Z2023-06-01T09:00:00Z
Gravidade
Severity
O nível de impacto no negócio causado pelo incidente.
Descrição

A severidade define o quanto um incidente impacta as operações do negócio. Junto com a urgência, ela costuma ser usada para calcular automaticamente a prioridade do incidente.

Na análise, a severidade é uma dimensão-chave no Dashboard 'SLA Compliance Overview'. Ela ajuda as organizações a entender se estão cumprindo os níveis de serviço nos incidentes mais críticos. Oferece uma visão de performance orientada ao negócio, complementando a visão operacional fornecida pela prioridade.

Por que é importante

Mede o impacto no negócio de um incidente, oferecendo um critério crucial para priorizar esforços e analisar a performance em questões críticas.

Onde obter

Tabela incident do ServiceNow, campo severity.

Exemplos
1 - Alto2 - Média3 - Baixa
ID do problema
ProblemId
O identificador do registro de Problem associado, caso o incidente esteja vinculado a um problema maior.
Descrição

O 'Problem ID' vincula um incidente a um registro correspondente no módulo de Problem Management. Isso é feito quando o incidente é identificado como sintoma de um problema maior e subjacente, que afeta vários usuários ou serviços.

Esse vínculo é fundamental para o Dashboard 'Volume de Incidentes Recorrentes' e para o KPI 'Taxa de Incidentes Recorrentes'. Ele permite agrupar incidentes que têm a mesma causa raiz, medir o impacto total do problema e acompanhar a eficácia dos esforços de resolução. Um número alto de incidentes vinculados a problemas indica um ambiente de suporte reativo.

Por que é importante

Vincula incidentes à causa raiz, essencial para analisar recorrências e medir o impacto do gerenciamento de problemas.

Onde obter

Tabela incident do ServiceNow, campo problem_id.

Exemplos
PRB0040001PRB0040015PRB0040102
Item de Configuração
ConfigurationItem
O componente, serviço ou ativo de TI específico afetado pelo incidente.
Descrição

O Configuration Item (CI) é o ativo da Configuration Management Database (CMDB) afetado pelo incidente. Pode ser um servidor, aplicação, laptop ou dispositivo de rede.

Analisar incidentes por CI é extremamente valioso para identificar ativos ou serviços não confiáveis. Ajuda a apontar quais partes da infraestrutura de TI estão gerando mais incidentes, o que pode orientar investimentos em atualizações ou substituições. Em Process Mining, filtrar por CI pode revelar se incidentes relacionados a aplicações críticas são tratados de forma diferente ou mais eficiente do que os demais.

Por que é importante

Identifica o ativo afetado, ajudando a apontar componentes problemáticos na infraestrutura de TI e direcionar os esforços de melhoria.

Onde obter

Tabela incident do ServiceNow, campo cmdb_ci.

Exemplos
SAP ERP ProductionOracle DB Server 05Serviço de e-mail
Número de reatribuições
ReassignmentCount
O número de vezes que o incidente foi reatribuído a um grupo ou agente diferente.
Descrição

Este campo acompanha o total de vezes que um incidente foi transferido entre diferentes grupos de atribuição. É uma medida direta do atrito do processo e costuma ser usada como indicador-chave de desempenho.

Esse atributo é o principal insumo para o Dashboard 'Taxa de Transferência e Reatribuição' e para o KPI 'Média de Transferências por Incidente'. Um número alto de reatribuições geralmente indica problemas como roteamento inicial incorreto, falta de capacitação em algum nível de suporte ou falta de clareza na responsabilidade do processo. Reduzir esse número é um objetivo comum em iniciativas de melhoria, pois normalmente leva a tempos de resolução mais rápidos.

Por que é importante

Mede diretamente as transferências no processo, um indicador-chave de ineficiência, roteamento incorreto e oportunidades de melhoria.

Onde obter

Tabela incident do ServiceNow, campo reassignment_count.

Exemplos
0135
Reaberto
IsReopened
Um indicador informando se um incidente foi reaberto após a resolução.
Descrição

Esse indicador booleano é definido como true se o estado de um incidente for revertido para um estado ativo (por exemplo, 'In Progress') após ter atingido um estado 'Resolved' ou 'Closed'. Normalmente, isso é identificado pela presença da atividade 'Incident Reopened' no Event Log.

Incidentes reabertos são um forte indicativo de resoluções incompletas ou ineficazes. Analisar esses casos ajuda a identificar encerramentos prematuros ou problemas recorrentes que não foram corrigidos adequadamente na primeira tentativa. Uma taxa alta de reabertura afeta negativamente a satisfação do usuário e a produtividade da equipe, tornando este um indicador-chave de qualidade.

Por que é importante

Este indicador identifica falhas no processo de resolução, destacando incidentes que exigiram trabalho adicional após serem considerados resolvidos.

Onde obter

Calculado verificando a sequência de atividades de cada incidente para ver se um estado 'open' vem após um estado 'resolved'.

Exemplos
verdadeirofalse
SLA violado
IsSlaBreached
Um indicador que mostra se a resolução do incidente ultrapassou a data prevista no SLA.
Descrição

Este é um atributo booleano calculado que sinaliza incidentes que violaram o Service Level Agreement. Ele é derivado da comparação entre o timestamp real de resolução e o 'SLA Due Date'. Se o horário de resolução for posterior ao prazo, o indicador é definido como true.

Esse atributo é a base do Dashboard 'Visão Geral de Conformidade com SLA' e de KPIs relacionados. Ele simplifica a análise ao converter uma comparação temporal complexa em uma dimensão simples de verdadeiro/falso, facilitando filtrar todos os incidentes com violação e analisar suas características comuns, como categoria, grupo de atribuição ou prioridade.

Por que é importante

Simplifica a análise de conformidade de SLA, permitindo filtrar e explorar com profundidade todos os incidentes que não cumpriram suas metas.

Onde obter

Calculado comparando o timestamp 'Resolved At' com o timestamp 'SlaDueDate'. (Resolved At > SlaDueDate).

Exemplos
verdadeirofalse
Solicitante
CallerId
O usuário que abriu o incidente.
Descrição

O Caller identifica o usuário final ou cliente afetado que registrou o incidente. Essa informação dá contexto sobre quem está sendo impactado por interrupções de serviço.

Embora nem sempre esteja no centro do fluxo do processo, analisar incidentes por Caller pode revelar se pessoas ou áreas específicas estão sendo afetadas de forma desproporcional. Isso pode indicar necessidade de treinamento ou problemas locais de ambiente. Também fornece um canal direto com o cliente para pesquisas de satisfação e comunicação.

Por que é importante

Identifica o usuário impactado, permitindo análise por área ou indivíduo e fornecendo contexto para a comunicação com o usuário.

Onde obter

Tabela incident do ServiceNow, campo caller_id.

Exemplos
Abel TuterCarolina PashDon Goodliffe
Tempo de Ciclo
CycleTime
A duração total desde a criação do incidente até o fechamento.
Descrição

O tempo de ciclo é uma métrica calculada que representa a duração ponta a ponta do processo de gerenciamento de incidentes para um único caso. Normalmente, é obtido pela diferença entre os timestamps 'Closed' e 'Created'.

Esse é um dos KPIs mais fundamentais em Process Mining, alimentando diretamente o dashboard 'Incident Resolution Cycle Time'. Analisar a média do tempo de ciclo, bem como sua distribuição, ajuda a medir a eficiência geral, definir referências de desempenho e identificar o impacto de mudanças no processo. Ao segmentar essa métrica por atributos como prioridade ou categoria, fica mais claro quais tipos de incidentes demoram mais para serem resolvidos.

Por que é importante

Este KPI central mede a eficiência ponta a ponta do processo e é usado para identificar casos de longa duração e acompanhar o desempenho geral.

Onde obter

Calculado subtraindo o primeiro timestamp de evento do último timestamp de evento para cada Incident ID.

Exemplos
2592008640001209600
Obrigatório Recomendado Opcional

Atividades de Gerenciamento de Incidentes

Estes são os principais passos e marcos do processo que devem ser capturados no seu Event Log para descobrir e otimizar o processo com mais precisão.
6 Recomendado 7 Opcional
Atividade Descrição
Grupo de atribuição alterado
Representa um repasse em que um incidente é transferido de um grupo de suporte para outro. Isso é capturado observando mudanças subsequentes no campo 'assignment_group' após seu preenchimento inicial.
Por que é importante

Reatribuições frequentes podem sinalizar roteamento inicial incorreto, complexidade do processo ou lacunas de conhecimento. Essa atividade é crítica para medir o KPI 'Repasses médios por incidente'.

Onde obter

Inferido a partir da tabela 'sys_audit' ao rastrear qualquer alteração no campo 'assignment_group' após a atribuição inicial.

Captura

Identifique cada alteração com carimbo de data e hora no campo 'assignment_group' registrada no log de auditoria.

Tipo de evento inferred
Incidente atribuído ao grupo
Esta atividade ocorre quando um incidente é atribuído a um grupo de suporte específico para tratamento. É uma etapa-chave do roteamento e é capturada quando há mudanças no campo 'assignment group'.
Por que é importante

Acompanhar as atribuições é essencial para analisar as transferências, os tempos de fila de cada grupo e identificar ineficiências de roteamento ou gargalos.

Onde obter

Inferido a partir da tabela 'sys_audit' ao rastrear quando o campo 'assignment_group' na tabela 'incident' é preenchido ou alterado.

Captura

Use o timestamp do log de auditoria para alterações no campo 'assignment_group'.

Tipo de evento inferred
Incidente criado
Marca o início do ciclo de vida do incidente quando um novo registro é criado formalmente no ServiceNow. Esse evento é capturado explicitamente usando o carimbo de data e hora de criação do registro do incidente.
Por que é importante

Este é o principal evento de início do processo. Analisar o tempo dessa atividade até a resolução é fundamental para medir o tempo de ciclo total e a conformidade com o SLA.

Onde obter

O timestamp 'sys_created_on' na tabela 'incident' serve como o timestamp explícito do evento para esta atividade.

Captura

Use o timestamp 'sys_created_on' do registro do incidente.

Tipo de evento explicit
Incidente encerrado
Esta é a atividade final do ciclo de vida, indicando que o incidente está totalmente resolvido e confirmado, sem necessidade de novas ações. O evento é capturado explicitamente pelo timestamp de encerramento.
Por que é importante

Como evento final do processo, essa atividade é essencial para calcular a duração total do ciclo de vida do incidente e analisar o tempo gasto no pós-resolução.

Onde obter

O timestamp 'closed_at' na tabela 'incident' serve como o timestamp explícito do evento. Normalmente, é preenchido quando o campo 'state' muda para 'Closed'.

Captura

Use o timestamp 'closed_at' do registro do incidente.

Tipo de evento explicit
Resolução proposta
Marca o momento em que um agente de suporte aplicou uma correção e moveu o incidente para o estado 'Resolved'. É um marco importante antes do encerramento final.
Por que é importante

Esta atividade sinaliza o fim do trabalho ativo e o início da fase de confirmação. O tempo entre ela e 'Incident Closed' pode revelar atrasos na confirmação ou verificação pelo usuário.

Onde obter

Inferido a partir da tabela 'sys_audit' quando o campo 'state' na tabela 'incident' muda para 'Resolved'. O timestamp 'resolved_at' geralmente é preenchido nesse momento.

Captura

Use o timestamp quando o campo 'state' se tornar 'Resolved' ou o timestamp 'resolved_at'.

Tipo de evento inferred
Trabalho Iniciado
Indica que um agente começou a investigar ou trabalhar ativamente no incidente. Geralmente é inferido quando o estado do incidente muda de 'New' ou 'Assigned' para um estado ativo como 'In Progress'.
Por que é importante

Este marco indica o fim do tempo de espera inicial em fila e o início do trabalho ativo de resolução. Medir o tempo até o início do trabalho é essencial para a análise de gargalos.

Onde obter

Inferido a partir da tabela 'sys_audit' ao identificar quando o campo 'state' na tabela 'incident' muda para um valor que representa trabalho ativo, como 'In Progress'.

Captura

Identifique o timestamp quando o campo 'state' muda para 'In Progress' ou valor semelhante.

Tipo de evento inferred
Aguardando confirmação do usuário
O incidente está em estado pendente, aguardando o usuário confirmar se a resolução proposta foi bem-sucedida. Isso normalmente é inferido a partir de um estado específico, como 'Awaiting User Info', após ter sido resolvido.
Por que é importante

Esse estado pode se tornar um grande gargalo se os usuários demorarem a responder. Medir o tempo gasto nessa atividade ajuda a identificar falhas de comunicação e oportunidades de automatizar o encerramento.

Onde obter

Inferido a partir da tabela 'sys_audit' ao identificar uma mudança para um estado de pendência específico após a resolução. O nome do estado pode ser personalizado, como 'Awaiting Caller'.

Captura

Identifique o timestamp quando 'state' muda para um valor que indique espera por resposta do usuário.

Tipo de evento inferred
Comentário de suporte adicionado
Um agente de suporte adiciona uma work note ou um comentário visível ao usuário. Esse é um evento explícito registrado no activity stream do incidente.
Por que é importante

Registra a comunicação e os esforços de investigação da equipe de suporte. Analisar a frequência e o momento dessas mensagens gera insights sobre o processo de investigação.

Onde obter

Capturado da tabela 'sys_journal_field', que registra entradas dos campos 'work_notes' e 'comments' na tabela 'incident'.

Captura

Use o timestamp de criação das entradas de journal em que o elemento é 'work_notes' ou 'comments'.

Tipo de evento explicit
Incidente atribuído ao agente
Representa o momento em que um agente específico dentro de um grupo de suporte assume a responsabilidade pelo incidente. Isso é capturado monitorando mudanças no campo 'assigned_to'.
Por que é importante

Isso oferece uma visão granular da carga de trabalho dos agentes e da resolução no primeiro contato. Ajuda a determinar por quanto tempo os incidentes aguardam até que um agente inicie o trabalho após a atribuição a um grupo.

Onde obter

Inferido a partir da tabela 'sys_audit' ao rastrear quando o campo 'assigned_to' na tabela 'incident' é preenchido ou alterado.

Captura

Use o timestamp do log de auditoria para alterações no campo 'assigned_to'.

Tipo de evento inferred
Incidente categorizado
Representa a classificação inicial do incidente, quando campos como Category, Subcategory e Priority são definidos. Esse evento costuma ser inferido pela trilha de auditoria quando esses campos são preenchidos pela primeira vez ou atualizados logo após a criação.
Por que é importante

Classificar corretamente é crucial para o roteamento e a priorização. Acompanhar essa atividade ajuda a analisar as taxas de reclassificação e seu impacto no tempo de resolução.

Onde obter

Inferido a partir da tabela 'sys_audit' ao identificar a primeira alteração em campos como 'category', 'subcategory' ou 'priority' para um determinado incidente.

Captura

Identifique no log de auditoria o timestamp da primeira atualização nos campos de classificação.

Tipo de evento inferred
Incidente escalado
Ocorre quando a prioridade ou severidade de um incidente aumenta, exigindo resposta mais rápida ou recursos diferentes. Isso é inferido ao detectar um aumento no valor do campo 'priority'.
Por que é importante

Escalonamentos geralmente indicam que um incidente é mais grave do que o previsto inicialmente ou que está perto de violar o SLA. Analisar esses eventos ajuda a entender exceções no processo.

Onde obter

Inferido a partir da tabela 'sys_audit' ao identificar uma alteração no campo 'priority' para um valor de maior urgência.

Captura

Detecte quando o valor do campo 'priority' aumenta (por exemplo, de '3 - Moderate' para '2 - High').

Tipo de evento inferred
Incidente reaberto
Ocorre quando o usuário informa que o problema persiste após ser marcado como resolvido. Isso é inferido quando o estado do incidente muda de 'Resolved' de volta para um estado ativo, como 'In Progress'.
Por que é importante

Incidentes reabertos indicam falhas na resolução e representam retrabalho. Monitorar essa atividade é vital para medir a qualidade da resolução e a taxa de resolução na primeira tentativa.

Onde obter

Inferido a partir da tabela 'sys_audit' ao detectar a transição do campo 'state' de 'Resolved' de volta para um estado ativo, como 'In Progress' ou 'Assigned'.

Captura

Identifique o timestamp quando 'state' passa de 'Resolved' para um valor ativo.

Tipo de evento inferred
Incidente vinculado a um problema
Esta atividade ocorre quando um incidente é formalmente associado a um registro de problema, indicando que ele faz parte de um problema maior, subjacente. Isso é inferido quando o campo 'problem_id' no registro do incidente está preenchido.
Por que é importante

Vincular a um Problema é um passo essencial para sair do modo reativo e avançar para a análise proativa de causa raiz. Isso dá suporte ao dashboard 'Recurring Incident Volume'.

Onde obter

Inferido ao detectar quando o campo de referência 'problem_id' na tabela 'incident' é preenchido com um valor.

Captura

Identifique no log de auditoria o timestamp em que o campo 'problem_id' é preenchido.

Tipo de evento inferred
Recomendado Opcional

Guias de Extração

Como extrair seus dados do Gerenciamento de Problemas do ServiceNow