Template de dados: Gestão 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 Jira Service Management
Atributos de Gerenciamento de Incidentes
| Nome | Descrição | ||
|---|---|---|---|
|
Atividade
ActivityName
|
O nome do evento específico ou da mudança de status ocorrida no incidente. | ||
|
Descrição
A atividade representa uma etapa ou evento específico no ciclo de vida do gerenciamento de incidentes, como 'Incident Created', 'Incident Assigned' ou 'Resolution Proposed'. Normalmente, elas são derivadas de transições de status ou de eventos de atualização registrados no histórico ou no changelog do issue do Jira. Analisar a sequência e a duração dessas atividades é um dos objetivos centrais do Process Mining e revela o fluxo real do processo, os gargalos e os desvios.
Por que é importante
As atividades são a espinha dorsal do mapa de processo, permitindo visualizar e analisar o ciclo de vida do incidente.
Onde obter
Derivado do histórico da issue no Jira e do changelog, capturando transições de status e atualizações de campos-chave.
Exemplos
Incidente atribuídoInvestigação IniciadaIncidente resolvido
|
|||
|
Hora de Início
EventTimestamp
|
A data e hora exatas em que a atividade ocorreu. | ||
|
Descrição
Este atributo registra o timestamp de cada atividade no ciclo de vida do incidente. É crucial para calcular durações, tempo de ciclo e tempos de espera entre as etapas do processo. Timestamps precisos permitem análises detalhadas de desempenho, acompanhamento de SLA e identificação de gargalos. Todas as métricas de desempenho, como tempo de resolução e duração do diagnóstico, derivam desses timestamps.
Por que é importante
Timestamps são essenciais para calcular todas as métricas baseadas em tempo, entender a duração do processo e descobrir gargalos de desempenho.
Onde obter
Esta é a data 'created' associada a cada entrada no changelog ou histórico da issue do Jira.
Exemplos
2023-10-26T10:00:00Z2023-10-26T10:05:14Z2023-10-27T14:30:00Z
|
|||
|
ID do incidente
IncidentId
|
O identificador único de cada ticket de incidente no Jira Service Management. | ||
|
Descrição
O ID do Incidente, frequentemente chamado de Issue Key no Jira, é o identificador único principal de cada incidente registrado. Ele conecta todas as atividades, comentários e alterações de status, desde a criação até o encerramento. No Process Mining, esse ID é essencial para reconstruir o ciclo de vida ponta a ponta de cada incidente, permitindo uma análise completa de todo o processo.
Por que é importante
Este é o identificador central usado para correlacionar todos os eventos relacionados em um único caso, sendo a base de qualquer análise de Process Mining.
Onde obter
Este é o campo padrão 'Key' da issue no Jira Service Management (ex.: 'ITSM-123').
Exemplos
INC-10234HELPDESK-5678OPS-9901
|
|||
|
Sistema de Origem
SourceSystem
|
O sistema do qual os dados foram extraídos. | ||
|
Descrição
Este atributo identifica a origem dos dados, que neste caso é o Jira Service Management. Ele é especialmente útil quando dados de vários sistemas são combinados para uma visão completa do processo. Informar o sistema de origem deixa a rastreabilidade dos dados clara e ajuda a diagnosticar problemas de qualidade ou de extração. Para este modelo, o valor é estático.
Por que é importante
Fornece contexto essencial sobre a origem dos dados, garantindo clareza e rastreabilidade, especialmente em análises com múltiplos sistemas.
Onde obter
Este é um valor estático que deve ser incluído durante o processo de extração de dados.
Exemplos
Jira Service ManagementJira Cloud
|
|||
|
Última Atualização de Dados
LastDataUpdate
|
O timestamp que indica a última vez que os dados foram atualizados a partir do sistema de origem. | ||
|
Descrição
Este atributo registra quando o conjunto de dados foi atualizado pela última vez. Ele fornece contexto essencial para quem está analisando o processo, deixando claro quão atuais estão os dados. Isso é especialmente importante em dashboards de monitoramento contínuo, em que informações atualizadas são essenciais para decisões no tempo certo. Normalmente, o valor é o mesmo para todos os eventos dentro de um mesmo lote de extração.
Por que é importante
Informa os usuários sobre a atualidade dos dados, o que é crucial para a relevância e a precisão da análise.
Onde obter
Este é o timestamp da execução de extração de dados, incluído durante o processo de transformação.
Exemplos
2023-10-27T08:00:00Z2023-10-28T08:00:00Z
|
|||
|
Data de criação
CreatedDate
|
A data e hora em que o incidente foi criado no sistema. | ||
|
Descrição
Este atributo marca o início oficial do ciclo de vida do incidente. É o timestamp de referência a partir do qual se calculam métricas como o tempo total de resolução. A data de criação é um valor estático de cada incidente e serve como ponto de partida do caso na análise de Process Mining.
Por que é importante
Serve como ponto de partida para todos os cálculos de tempo de ciclo ponta a ponta e para as medições de SLA.
Onde obter
O campo padrão 'Created' em um issue do Jira.
Exemplos
2023-10-26T09:58:12Z2023-11-01T15:20:05Z
|
|||
|
Data de Resolução
ResolutionDate
|
A data e hora em que o incidente foi marcado como resolvido. | ||
|
Descrição
Este atributo registra o timestamp em que o incidente foi movido pela primeira vez para um status de resolvido. Ele marca o fim da fase de trabalho ativo e é o ponto final usado no cálculo do Tempo para Resolução. Comparar a data de resolução com a data de criação fornece a principal medida de eficiência do processo. É também um componente-chave na determinação da conformidade com o SLA.
Por que é importante
Marca o fim do processo de resolução, permitindo calcular o tempo total de ciclo e o desempenho de SLA.
Onde obter
O campo padrão 'Resolved' em um issue do Jira.
Exemplos
2023-10-28T11:20:30Z2023-11-02T10:00:00Z
|
|||
|
Grupo de atribuição
AssignmentGroup
|
A equipe ou o grupo responsável pelo atendimento do incidente. | ||
|
Descrição
O Assignment Group representa a equipe atribuída ao incidente. Pode ser um nível de suporte como 'L1 Helpdesk', uma equipe especializada como 'Network Operations' ou mesmo uma equipe de desenvolvimento. Analisar transições entre grupos de atribuição é fundamental para entender escalonamentos e transferências. Isso permite medir o desempenho por equipe, identificar gargalos no nível da equipe e analisar dependências entre equipes.
Por que é importante
Crucial para analisar o desempenho das equipes, a vazão e o fluxo de trabalho entre diferentes níveis de suporte ou grupos especializados.
Onde obter
Isso geralmente é implementado como um campo personalizado no Jira, como 'Team' ou 'Assignment Group'. Em alguns casos, pode ser derivado de 'Components' do Jira ou de 'Project Roles'.
Exemplos
Suporte Nível 1Time de InfraestruturaAdministradores de Banco de Dados
|
|||
|
Prioridade
Priority
|
O nível de prioridade atribuído ao incidente, indicando a urgência da resolução. | ||
|
Descrição
A prioridade determina a velocidade necessária para tratar um incidente. Geralmente combina impacto e urgência e influencia diretamente as metas de SLA. Analisar os incidentes por prioridade ajuda a entender se os de alta prioridade estão sendo tratados mais rápido que os de baixa e se a priorização está sendo aplicada de forma consistente. É uma dimensão crítica para filtrar e comparar o desempenho do processo.
Por que é importante
Essencial para analisar o desempenho dos SLAs e verificar se os recursos estão alocados corretamente aos incidentes mais críticos.
Onde obter
O campo padrão 'Priority' em um issue do Jira.
Exemplos
Mais altaAltoMédioBaixo
|
|||
|
Responsável
Assignee
|
O usuário atualmente atribuído ao incidente. | ||
|
Descrição
O Assignee é o agente ou usuário responsável pelo incidente em determinado momento. Acompanhar mudanças no Assignee é essencial para analisar transferências, entender a distribuição da carga de trabalho e identificar quem participa de etapas específicas do processo. Esse atributo ajuda a responder perguntas sobre desempenho individual e alocação de recursos nas equipes de suporte.
Por que é importante
Ajuda a acompanhar a carga de trabalho individual, identificar gargalos ligados a agentes específicos e analisar o impacto das transferências no tempo de resolução.
Onde obter
O campo padrão 'Assignee' em um issue do Jira.
Exemplos
John SmithEmily JonesServiceDeskAgent1
|
|||
|
Status
Status
|
O estágio atual do incidente no ciclo de vida. | ||
|
Descrição
O campo Status indica o estado atual do incidente dentro do workflow definido, como 'Open', 'In Progress', 'Pending Customer' ou 'Resolved'. As mudanças de status são a principal fonte para gerar o log de atividades usado no Process Mining. Analisar o tempo gasto em cada status é fundamental para identificar gargalos e entender onde os incidentes passam mais tempo.
Por que é importante
Reflete diretamente o andamento do incidente e é a principal fonte para identificar etapas do processo e tempos de espera.
Onde obter
O campo padrão 'Status' em um issue do Jira.
Exemplos
Em ProgressoAguardando clienteResolvidoEncerrado
|
|||
|
Tempo de ciclo de resolução
IncidentResolutionCycleTime
|
O tempo total decorrido da criação até a resolução do incidente. | ||
|
Descrição
Esta é uma métrica calculada que representa a duração entre o 'CreatedDate' e o 'ResolutionDate'. É um dos KPIs mais importantes na gestão de incidentes, medindo diretamente a eficiência de todo o processo. Analisar essa métrica por dimensões como prioridade, grupo de atendimento ou componente ajuda a identificar os fatores que mais impactam o desempenho.
Por que é importante
Mede diretamente a eficiência ponta a ponta do processo de gestão de incidentes e é um KPI principal para acompanhamento de performance.
Onde obter
Calculado como ('ResolutionDate' - 'CreatedDate').
Exemplos
2h 30m1d 4h5d 1h 15m
|
|||
|
Autor
Reporter
|
O usuário que criou ou reportou o incidente. | ||
|
Descrição
O Reporter é a pessoa — muitas vezes o usuário final ou outro sistema — que registrou o incidente. Analisar incidentes por Reporter ajuda a identificar usuários ou áreas que enfrentam problemas com frequência. Também é útil para entender padrões de comunicação, especialmente ao analisar atividades como 'Waiting for Customer' e 'Customer Responded'.
Por que é importante
Ajuda a analisar as origens dos incidentes, identificar padrões ligados a usuários ou departamentos específicos e entender atrasos na interação com o cliente.
Onde obter
O campo padrão 'Reporter' em um issue do Jira.
Exemplos
Alice JohnsonBob Williamsmonitoring-tool@example.com
|
|||
|
Categoria da causa raiz
RootCauseCategory
|
A classificação da causa raiz do incidente. | ||
|
Descrição
Este atributo registra a razão fundamental pela qual o incidente ocorreu, como 'Software Defect', 'Hardware Failure' ou 'User Error'. Geralmente é preenchido após a investigação e é essencial para uma boa gestão de problemas e para prevenir incidentes futuros. Analisar as categorias de causa raiz ajuda a identificar fragilidades sistêmicas e priorizar iniciativas de melhoria. Uma taxa alta de causas raiz 'Unknown' pode indicar a necessidade de processos de investigação mais robustos.
Por que é importante
Permite analisar a causa raiz e ajuda a mudar de uma postura reativa para uma abordagem proativa, ao identificar e tratar as origens dos incidentes.
Onde obter
Este é quase sempre um campo personalizado no Jira. O nome e as opções dependem muito da configuração específica de cada organização.
Exemplos
Erro de configuraçãoInterrupção de redeBug de software
|
|||
|
Componente
Component
|
O sistema, a aplicação ou a parte da infraestrutura afetada pelo incidente. | ||
|
Descrição
Componentes são subseções de um projeto do Jira usadas para agrupar issues em partes menores, como 'User Interface', 'Database' ou 'API'. Analisar incidentes por componente ajuda a identificar quais partes do sistema são mais propensas a problemas. Essas informações são valiosas para análise de causa raiz e podem orientar iniciativas de melhoria de serviço ou redução de dívida técnica.
Por que é importante
Permite filtrar e analisar pelo produto afetado ou pela área do sistema afetada, ajudando a identificar pontos críticos de tecnologia.
Onde obter
O campo padrão 'Components' em um issue do Jira.
Exemplos
Serviço de autenticaçãoDashboard de relatóriosMobile App
|
|||
|
É Retrabalho
IsRework
|
Indica se o incidente teve retrabalho, por exemplo, se foi reaberto. | ||
|
Descrição
Este atributo booleano calculado identifica incidentes que voltaram para uma etapa anterior do processo, geralmente por terem sido reabertos após a resolução. Ciclos de retrabalho são uma fonte relevante de ineficiência e insatisfação do cliente. Esse indicador facilita a quantificação da taxa de retrabalho e ajuda a direcionar a análise sobre por que os incidentes não estão sendo resolvidos corretamente na primeira vez.
Por que é importante
Evidencia problemas de qualidade e ineficiências do processo ao sinalizar incidentes que exigem retrabalho, apoiando diretamente a análise de retrabalho.
Onde obter
Calculado detectando sequências específicas de transições de status no event log, como 'Resolved' -> 'Reopened'.
Exemplos
verdadeirofalse
|
|||
|
Gravidade
Severity
|
A medida do impacto do incidente no negócio. | ||
|
Descrição
A gravidade define o quanto um incidente impacta o negócio, de um único usuário afetado até a indisponibilidade de um sistema crítico. Enquanto a prioridade dita a ordem de atendimento, a gravidade indica o impacto para o negócio. Analisar por gravidade ajuda a entender o desempenho do processo nos incidentes que mais importam e, muitas vezes, é usada em conjunto com prioridade para uma análise mais precisa.
Por que é importante
Oferece uma visão do impacto no negócio, permitindo análises focadas nos incidentes que mais prejudicam as operações.
Onde obter
Normalmente, é um campo personalizado no Jira, pois não é um campo padrão do sistema. Consulte a configuração do projeto no Jira Service Management.
Exemplos
CríticoGraveLeveTrivial
|
|||
|
ID do problema vinculado
LinkedProblemId
|
O identificador de um ticket de problema vinculado a este incidente. | ||
|
Descrição
Incidentes que são sintomas de um problema maior geralmente são vinculados a um chamado de Problema. Este campo armazena o ID desse Problema associado. Analisar esses vínculos ajuda a entender a relação entre incidentes e problemas, medir a eficácia do processo de gestão de problemas e identificar incidentes recorrentes que exigem uma correção definitiva.
Por que é importante
Conecta incidentes a problemas subjacentes, permitindo analisar como a organização trata as causas raiz para prevenir incidentes futuros.
Onde obter
Essa informação fica na seção 'Issue Links' de uma issue do Jira.
Exemplos
PROB-123PROB-456Nenhum
|
|||
|
Meta de Tempo para Resolução
TimeToResolutionTarget
|
A meta de duração do SLA para resolver o incidente. | ||
|
Descrição
Este atributo define o tempo máximo esperado para que um incidente de determinada prioridade ou tipo seja resolvido. Ele é a referência para comparar o tempo real de resolução e verificar a conformidade com o SLA. Normalmente, esse valor é definido dinamicamente com base em regras que consideram fatores como prioridade, severidade ou tipo de incidente. É fundamental para qualquer dashboard de monitoramento de desempenho de SLA.
Por que é importante
Define a referência para medir a conformidade com o SLA, servindo de base para o KPI de Taxa de Violação de SLA de Incidentes.
Onde obter
Isso é derivado da configuração de SLA no Jira Service Management. É necessário identificar a meta específica (por exemplo, 'Time to resolution').
Exemplos
4h8h3d
|
|||
|
Número de transferências
HandoffCount
|
O número de vezes que o incidente foi reatribuído a outro grupo ou usuário. | ||
|
Descrição
Esta métrica calculada conta quantas vezes os campos 'Assignee' ou 'AssignmentGroup' mudaram ao longo do ciclo de vida do incidente. Um número alto de repasses costuma indicar ineficiências no processo, falta de resolução no primeiro contato ou lacunas de conhecimento, o que prolonga o tempo de resolução. Analisar esse KPI ajuda a simplificar o processo de atribuição e melhorar a colaboração entre as equipes.
Por que é importante
Quantifica o atrito e a ineficiência causados por reatribuições, ajudando a identificar oportunidades de melhoria no processo.
Onde obter
Calculado contando o número de alterações nos campos 'Assignee' ou 'AssignmentGroup' no changelog da issue.
Exemplos
015
|
|||
|
Resolução
Resolution
|
O resultado final ou o motivo da resolução do incidente. | ||
|
Descrição
O campo Resolution explica por que um incidente foi movido para o estado de resolvido. Resoluções comuns incluem 'Fixed', 'Duplicate', 'Won't Do' e 'Cannot Reproduce'. Analisar a distribuição dos tipos de resolução gera insights sobre a qualidade dos chamados recebidos e a eficácia do processo de resolução. Por exemplo, um número alto de 'Duplicate' pode indicar um problema na criação ou na triagem do incidente.
Por que é importante
Dá contexto ao desfecho do incidente, ajudando a categorizar as resoluções e a identificar tendências sobre a forma como os incidentes são encerrados.
Onde obter
O campo padrão 'Resolution' em um issue do Jira. Esse campo normalmente é definido quando o issue é movido para a categoria de status 'Done'.
Exemplos
ConcluídoCorrigidoDuplicadoNão será corrigido
|
|||
|
Tipo de chamado
IssueType
|
O tipo de issue, como Incident, Service Request ou Problem. | ||
|
Descrição
O Jira usa Tipos de issue para diferenciar tipos de tarefas. Em um contexto de Gestão de Incidentes, o tipo principal é "Incident", mas outros como "Sub-task" também podem ser relevantes. Esse atributo é fundamental para filtrar o conjunto de dados e incluir apenas incidentes, garantindo que a análise de Process Mining foque no processo correto.
Por que é importante
Garante que a análise esteja corretamente focada nos incidentes, separando-os de outros tipos de trabalho, como solicitações de serviço ou mudanças.
Onde obter
O campo padrão 'Issue Type' em um issue do Jira.
Exemplos
IncidenteSuporte de TIBug
|
|||
|
Tipo de solicitação do cliente
CustomerRequestType
|
O tipo específico de solicitação enviada pelo cliente no portal de serviço. | ||
|
Descrição
Este campo categoriza as solicitações pela ótica do cliente, como exibido no portal do Jira Service Management (por exemplo, 'Report a system issue'). Ele fornece uma classificação amigável do incidente, que pode ser diferente do 'Issue Type' interno. Analisar esse atributo traz insights sobre como os clientes percebem e reportam problemas, ajudando a aprimorar o portal e a oferta de serviços.
Por que é importante
Oferece uma visão centrada no cliente das categorias de incidentes, útil para analisar a demanda e melhorar a experiência do cliente.
Onde obter
O campo 'Customer Request Type', específico de projetos do Jira Service Management.
Exemplos
Obter ajuda de TI > Reportar um problema no sistemaE-mail > Solicitação de acesso
|
|||
|
Violação de SLA
SlaBreach
|
Indica se o tempo de resolução do incidente ultrapassou a meta de SLA. | ||
|
Descrição
Este atributo booleano calculado indica se um incidente violou o SLA de 'Time to Resolution'. Ele é verdadeiro quando o 'IncidentResolutionCycleTime' é maior que o 'TimeToResolutionTarget'. Esse indicador simplifica a análise e a visualização, permitindo filtrar e agregar facilmente para calcular o KPI de Taxa de Violação de SLA. É a principal métrica de resultado no dashboard de monitoramento de SLA.
Por que é importante
Fornece um resultado claro e binário para o desempenho de SLA, facilitando o cálculo das taxas de violação e a identificação de áreas problemáticas.
Onde obter
Calculado como ('IncidentResolutionCycleTime' > 'TimeToResolutionTarget').
Exemplos
verdadeirofalse
|
|||
Atividades de Gerenciamento de Incidentes
| Atividade | Descrição | ||
|---|---|---|---|
|
Aguardando Cliente
|
Marca o momento em que a equipe de suporte aguarda informações ou ação do cliente. É inferido quando o status muda para um estado de espera específico, como "Waiting for customer". | ||
|
Por que é importante
Isolar esse tempo em espera (on-hold) é essencial para medir o SLA com precisão, já que ele costuma ser excluído do cálculo do tempo de resolução. Ajuda a analisar atrasos na resposta do cliente.
Onde obter
Inferido pelo histórico de mudanças de status do chamado. O evento corresponde ao momento em que o status muda para 'Waiting for customer' ou estado semelhante.
Captura
Identifique o timestamp da transição de status para 'Waiting for customer'.
Tipo de evento
inferred
|
|||
|
Incidente criado
|
Marca o início oficial do ciclo de vida do incidente, quando o incidente é reportado e um novo issue é criado no Jira. Esse evento é capturado explicitamente quando um novo issue do tipo "Incident" é registrado no sistema. | ||
|
Por que é importante
Este é o evento inicial principal do processo. Analisar o tempo dessa atividade até a resolução é fundamental para medir o tempo de ciclo geral e a aderência ao SLA.
Onde obter
Este é um evento explícito capturado a partir do timestamp 'created' da issue de incidente no Jira. O evento de criação da issue fica registrado no histórico.
Captura
Use o timestamp de criação do chamado.
Tipo de evento
explicit
|
|||
|
Incidente encerrado
|
Representa o fechamento administrativo final do ticket após ter sido resolvido e verificado. É inferido pela transição de status para 'Closed'. | ||
|
Por que é importante
Este é o evento terminal do processo. Analisar o tempo entre 'Resolved' e 'Closed' pode revelar atrasos na limpeza administrativa ou em processos de confirmação do usuário.
Onde obter
Inferido pelo histórico de mudanças de status do chamado. O evento corresponde ao momento em que o status transita para o estado final 'Closed'.
Captura
Identifique o timestamp da transição de status para 'Closed'.
Tipo de evento
inferred
|
|||
|
Incidente reatribuído
|
Ocorre quando um incidente é transferido de um agente ou grupo para outro após a atribuição inicial. Esse evento é inferido a partir de qualquer alteração nos campos "Assignee" ou "Assigned Group". | ||
|
Por que é importante
Acompanhar reatribuições é crucial para a análise de repasses. Um número alto de reatribuições costuma indicar ineficiências do processo, lacunas de conhecimento ou roteamento inicial incorreto, levando a atrasos na resolução.
Onde obter
Inferido pelo histórico do chamado ao detectar qualquer atualização no campo 'Assignee' depois de ter sido preenchido pela primeira vez. Cada alteração constitui um evento de reatribuição.
Captura
Identifique alterações posteriores no campo 'Assignee' após a atribuição inicial.
Tipo de evento
inferred
|
|||
|
Incidente resolvido
|
Esta atividade marca a confirmação de que o incidente foi resolvido com sucesso e o serviço foi restabelecido. Geralmente coincide com a transição para o status 'Resolved'. | ||
|
Por que é importante
Este é o principal marco de sucesso do processo. A duração até esse ponto é o KPI mais comum, representando o Tempo para Resolução (TTR).
Onde obter
Inferido pela mudança de status para 'Resolved'. Em muitos workflows, este é o mesmo evento que 'Resolution Proposed', representando o principal ponto de resolução.
Captura
Identifique o timestamp da transição de status para 'Resolved'.
Tipo de evento
inferred
|
|||
|
Investigação Iniciada
|
Indica que o agente designado começou de fato a trabalhar no diagnóstico do incidente. Normalmente é inferido quando o status do incidente muda de 'Open' ou 'New' para 'In Progress'. | ||
|
Por que é importante
Este marco importante sinaliza o início dos esforços ativos de resolução. Medir o tempo até essa atividade ajuda a identificar atrasos iniciais de fila e problemas de disponibilidade de recursos.
Onde obter
Inferido pelo histórico de mudanças de status do chamado. O evento é marcado no momento em que o status transita para um estado que representa trabalho ativo, como 'In Progress'.
Captura
Identifique o timestamp da transição de status para 'In Progress'.
Tipo de evento
inferred
|
|||
|
Resolução proposta
|
Esta atividade indica que uma solução foi identificada e implementada, e o incidente aguarda confirmação ou validação final. Ela é inferida a partir da transição de status para 'Resolved'. | ||
|
Por que é importante
Este é um marco importante que indica o fim do trabalho ativo da equipe de suporte. Muitas vezes, é o evento que para o relógio do SLA.
Onde obter
Inferido pelo histórico de mudanças de status do chamado. O evento é marcado no momento em que o status transita para 'Resolved' ou um estado equivalente.
Captura
Identifique o timestamp da transição de status para 'Resolved'.
Tipo de evento
inferred
|
|||
|
Cliente respondeu
|
Indica que o cliente forneceu as informações solicitadas e o incidente pode avançar. É inferido quando o status sai de 'Waiting for customer' e volta para um status ativo. | ||
|
Por que é importante
Esta atividade marca o fim de um atraso causado pelo cliente. Analisar a duração entre 'Waiting For Customer' e este evento revela o tempo médio de resposta do cliente.
Onde obter
Inferido pelo histórico de mudanças de status do chamado. O evento ocorre quando o status transita de 'Waiting for customer' para um status como 'In Progress', geralmente após o cliente adicionar um comentário.
Captura
Detectar mudança de status de 'Waiting for customer' para 'In Progress'.
Tipo de evento
inferred
|
|||
|
Comentário adicionado
|
Representa qualquer comunicação ou anotação em que um usuário adiciona um comentário ao ticket do incidente. É um evento explícito capturado sempre que um comentário é postado. | ||
|
Por que é importante
Analisar a frequência de comentários pode revelar padrões de comunicação, eficiência da colaboração e a complexidade de um incidente. Também evidencia incidentes que exigem comunicação excessiva.
Onde obter
Este é um evento explícito. O Jira armazena cada comentário com timestamp e autor, disponível pelo histórico de comentários da issue ou via API.
Captura
Use o timestamp de cada comentário adicionado ao chamado.
Tipo de evento
explicit
|
|||
|
Escalado para a equipe especializada
|
Indica que o incidente foi escalado para uma equipe especializada (ex.: Nível 2, Desenvolvimento) para suporte avançado. É inferido por uma alteração em um campo personalizado 'Support Team' ou por uma reatribuição específica. | ||
|
Por que é importante
Destaca incidentes que exigem conhecimento especializado e acompanha o fluxo entre diferentes níveis de suporte. Isso ajuda a identificar gargalos em equipes especializadas e analisar padrões de escalonamento.
Onde obter
Inferido pelo histórico do chamado ao acompanhar mudanças em um campo personalizado que representa o time designado ou ao identificar uma mudança de 'Assignee' para um membro de um grupo de especialistas conhecido.
Captura
Detectar uma alteração em um campo personalizado de 'Assigned Team' ou mudanças específicas de responsável.
Tipo de evento
inferred
|
|||
|
Incidente atribuído
|
Esta atividade indica a atribuição inicial do incidente a um agente de suporte ou a um grupo para atendimento. Ela é capturada ao rastrear a primeira vez em que os campos 'Assignee' ou 'Assigned Group' são preenchidos. | ||
|
Por que é importante
Mede o tempo de resposta inicial e de atribuição, componente-chave das métricas de SLA. Ajuda a identificar atrasos antes de começar a investigação ativa.
Onde obter
Inferido pelo histórico do chamado ao identificar a primeira alteração no campo 'Assignee' em que o valor anterior era 'Unassigned'.
Captura
Detectar a primeira atualização no campo 'Assignee' no histórico da issue.
Tipo de evento
inferred
|
|||
|
Incidente priorizado
|
Representa a definição da prioridade e/ou gravidade do incidente, que determina sua urgência e impacto no negócio. Normalmente é inferido da primeira vez que os campos 'Priority' ou 'Severity' são preenchidos ou atualizados após a criação. | ||
|
Por que é importante
Acompanhar a priorização ajuda a analisar se os incidentes estão sendo avaliados com agilidade e consistência. Atrasos nessa etapa impactam diretamente o cálculo de SLA e a alocação de recursos.
Onde obter
Inferido pelo log de histórico do chamado, que rastreia mudanças em todos os campos. Procure a primeira atualização no campo 'Priority' ou em um 'Severity' personalizado após o evento de criação do chamado.
Captura
Detectar a primeira alteração no campo 'Priority' no histórico da issue.
Tipo de evento
inferred
|
|||
|
Incidente reaberto
|
Representa uma situação em que um incidente previamente resolvido é reativado porque o problema voltou a ocorrer ou a correção foi ineficaz. É inferido por uma mudança de status de 'Resolved' ou 'Closed' de volta para um status aberto. | ||
|
Por que é importante
Incidentes reabertos medem diretamente a qualidade da resolução e são um indicador primário de retrabalho. Analisar esses eventos ajuda a identificar fechamentos prematuros e soluções ineficazes.
Onde obter
Inferido pelo histórico de mudanças de status do chamado. O evento é registrado quando o status sai de um estado terminal como 'Resolved' ou 'Closed' e volta para 'Open' ou 'In Progress'.
Captura
Detectar mudança de status de 'Resolved' ou 'Closed' para um status aberto.
Tipo de evento
inferred
|
|||
|
Vinculado ao ticket de problema
|
Ocorre quando um incidente é vinculado a um issue do tipo "Problema" para análise de causa raiz. É um evento explícito capturado quando é criado um link "relates to" ou "caused by" para um issue do tipo Problema. | ||
|
Por que é importante
Acompanhar esse vínculo é essencial para entender com que eficácia a organização transita da mitigação do incidente para a análise da causa raiz e a prevenção.
Onde obter
Este é um evento explícito registrado no histórico de links da issue. Cada criação de link possui um timestamp e pode ser filtrada para links do tipo de issue 'Problem'.
Captura
Use o timestamp da criação de um link do chamado para um chamado do tipo 'Problem'.
Tipo de evento
explicit
|
|||
|
Workaround fornecido
|
Representa a aplicação de uma correção temporária para restaurar o serviço enquanto uma solução definitiva é desenvolvida. Pode ser inferido por uma mudança de status ou por um comentário específico. | ||
|
Por que é importante
Medir o tempo para oferecer uma solução de contorno é um indicador essencial da velocidade de restauração do serviço. Ajuda a diferenciar mitigação temporária de resolução definitiva.
Onde obter
Isso costuma ser inferido. Pode ser uma transição para o status 'Workaround Provided' ou a inclusão de um comentário público com palavras-chave específicas como 'workaround'.
Captura
Identifique uma transição de status específica ou uma palavra-chave em um comentário.
Tipo de evento
inferred
|
|||