Template de dados: Gerenciamento de Incidentes
Seu Template de Dados de Gestão de Incidentes
- Atributos recomendados para coletar
- Atividades-chave a monitorizar
- Orientações de extração para o Gerenciamento de Problemas do ServiceNow
Atributos de Gerenciamento de Incidentes
| 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
|
|||
Atividades de Gerenciamento de Incidentes
| 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
|
|||