Seu Template de dados de gestão de incidentes

Jira Service Management
Seu Template de dados de gestão de incidentes

Seu Template de dados de gestão de incidentes

Este Template oferece uma abordagem estruturada para reunir os dados essenciais à análise do seu processo de gestão de incidentes. Ele apresenta os principais atributos a coletar, as atividades importantes a acompanhar e orientações práticas para extrair essas informações do sistema de origem. Assim, você garante todos os componentes necessários para começar a otimizar seus Workflows de resolução de incidentes.
  • Atributos recomendados para coleta
  • Principais atividades a acompanhar
  • Orientações para extração no Jira Service Management
Novo em Event Logs? Aprenda como criar um Event Log de Process Mining.

Atributos de Gestão de Incidentes

Estes são os campos de dados recomendados para incluir no seu Event Log e realizar uma análise completa do seu processo de gestão de incidentes.
5 Obrigatório 6 Recomendado 12 Opcional
Nome Descrição
Atividade
ActivityName
O nome do evento específico ou da alteração de status que ocorreu com o incidente.
Descrição

A atividade representa uma etapa ou evento distinto no ciclo de vida do gerenciamento de incidentes, como 'Incident Created', 'Incident Assigned' ou 'Resolution Proposed'. Normalmente, essas atividades são derivadas de mudanças de status ou de eventos de atualização específicos registrados no histórico ou no changelog do problema no Jira. Analisar a sequência e a duração dessas atividades é o principal objetivo do Process Mining, revelando o fluxo real do processo, os gargalos e os desvios.

Por que isso importa

As atividades formam a base do mapa do processo, permitindo visualizar e analisar o ciclo de vida do incidente.

Onde obter

Derivado do histórico do problema e dos dados do changelog do Jira, capturando mudanças de status e atualizações de campos importantes.

Exemplos
Incidente atribuídoInvestigação iniciadaIncidente resolvido
Hora de início
EventTimestamp
A data e a hora exatas em que a atividade ocorreu.
Descrição

Esse atributo registra o registro de data e hora de cada atividade no ciclo de vida do incidente. Ele é essencial para calcular durações, tempos de ciclo e tempos de espera entre diferentes etapas do processo. Registros de data e hora precisos permitem uma análise detalhada da performance, o monitoramento de SLA e a identificação de gargalos. Todas as métricas de performance, como tempo de resolução e duração do diagnóstico, são derivadas desses registros.

Por que isso importa

Os registros de data e hora são essenciais para calcular todas as métricas baseadas em tempo, entender a duração do processo e descobrir gargalos de performance.

Onde obter

Esta é a data de 'criação' associada a cada entrada no changelog ou histórico do chamado do Jira.

Exemplos
2023-10-26T10:00:00Z2023-10-26T10:05:14Z2023-10-27T14:30:00Z
ID do incidente
IncidentId
O identificador exclusivo de cada ticket de incidente no Jira Service Management.
Descrição

O ID do incidente, geralmente chamado de Issue Key no Jira, funciona como o identificador exclusivo principal de cada incidente reportado. Ele conecta todas as atividades, comentários e alterações de status associadas desde o momento da criação até o encerramento final. No Process Mining, esse ID é essencial para reconstruir o ciclo de vida completo de cada incidente, permitindo uma análise abrangente de todo o processo.

Por que isso importa

Esse é o identificador principal usado para correlacionar todos os eventos relacionados em um único caso, sendo a base de qualquer análise de Process Mining.

Onde obter

Esse é o campo padrão 'Key' de um problema no Jira Service Management, por exemplo, '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 em ambientes onde dados de vários sistemas são combinados para oferecer uma visão holística do processo. Especificar o sistema de origem garante a clareza da linhagem dos dados e ajuda a diagnosticar problemas de qualidade ou extração. Para este modelo, o valor seria estático.

Por que isso importa

Fornece um contexto essencial sobre a origem dos dados, garantindo clareza e rastreabilidade, especialmente em análises que envolvem vários sistemas.

Onde obter

Este é um valor estático que deve ser adicionado durante o processo de extração dos dados.

Exemplos
Jira Service ManagementJira Cloud
Última atualização dos dados
LastDataUpdate
O registro de data e hora que indica quando os dados foram atualizados pela última vez a partir do sistema de origem.
Descrição

Este atributo registra quando o conjunto de dados foi atualizado pela última vez. Ele fornece um contexto importante para quem analisa o processo, garantindo que a atualização dos dados seja considerada. Isso é especialmente importante em Dashboards de monitoramento contínuo, nos quais informações atualizadas são essenciais para tomar decisões no momento certo. O valor normalmente é o mesmo para todos os eventos de um único lote de extração de dados.

Por que isso importa

Informa aos usuários se os dados estão atualizados, algo essencial para a relevância e a precisão da análise.

Onde obter

Este é o registro de data e hora da execução da extração de dados, adicionado durante o processo de transformação dos dados.

Exemplos
2023-10-27T08:00:00Z2023-10-28T08:00:00Z
Data de criação
CreatedDate
A data e a hora em que o incidente foi criado pela primeira vez no sistema.
Descrição

Este atributo marca o início oficial do ciclo de vida do incidente. Ele é o registro de data e hora de referência para calcular métricas gerais, como o tempo total de resolução. A data de criação é um valor estático para cada incidente e serve como ponto de partida para todo o caso na análise de Process Mining.

Por que isso importa

Serve como ponto de partida para todos os cálculos de tempo de ciclo de ponta a ponta e para as medições de SLA.

Onde obter

O campo padrão 'Created' de um chamado do Jira.

Exemplos
2023-10-26T09:58:12Z2023-11-01T15:20:05Z
Data de resolução
ResolutionDate
A data e a hora em que o incidente foi marcado como resolvido.
Descrição

Este atributo registra o momento em que o incidente foi movido pela primeira vez para um status de resolução. Ele marca o fim da fase de trabalho ativo e é o ponto final para calcular o Time to Resolution. Comparar a data de resolução com a data de criação fornece a principal medida da eficiência do processo. Esse também é um componente essencial para determinar a conformidade com o SLA.

Por que isso importa

Marca o fim do processo de resolução, permitindo calcular o tempo total de ciclo e a performance do SLA.

Onde obter

O campo padrão 'Resolved' de um chamado do Jira.

Exemplos
2023-10-28T11:20:30Z2023-11-02T10:00:00Z
Grupo responsável
AssignmentGroup
A equipe ou o grupo responsável por tratar o incidente.
Descrição

O grupo responsável representa a equipe atribuída ao incidente. Pode ser um nível de suporte, como 'L1 Helpdesk', uma equipe especializada, como 'Network Operations', ou uma equipe de desenvolvimento. Analisar as transições entre grupos responsáveis é essencial para entender escalonamentos e transferências no processo. Isso permite medir a performance das equipes, identificar gargalos no nível da equipe e analisar dependências entre equipes.

Por que isso importa

É essencial para analisar a performance das equipes, o throughput e o fluxo de trabalho entre diferentes níveis de suporte ou grupos especializados.

Onde obter

Geralmente é implementado como um campo personalizado no Jira, como 'Team' ou 'Assignment Group'. Em alguns casos, pode ser derivado de Jira Components ou Project Roles.

Exemplos
Suporte de nível 1Equipe 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. Ela geralmente combina impacto e urgência e influencia diretamente as metas de SLA. Analisar os incidentes por prioridade ajuda a entender se os incidentes de alta prioridade estão sendo tratados mais rapidamente que os de baixa prioridade e se a priorização está sendo aplicada de forma consistente. É uma dimensão essencial para filtrar e comparar a performance do processo.

Por que isso importa

É essencial para analisar a performance do SLA e verificar se os recursos estão sendo alocados corretamente aos incidentes mais críticos.

Onde obter

O campo padrão 'Priority' de um chamado do Jira.

Exemplos
Mais altoAltoMédioBaixo
Responsável
Assignee
O usuário atualmente responsável por trabalhar no incidente.
Descrição

O responsável é o agente ou usuário encarregado do incidente em determinado momento. Acompanhar as mudanças de responsável é essencial para analisar transferências, entender a distribuição da carga de trabalho e identificar quais pessoas estão envolvidas em etapas específicas do processo. Este atributo ajuda a responder perguntas sobre a performance individual e a alocação de recursos nas equipes de suporte.

Por que isso importa

Ajuda a acompanhar a carga de trabalho individual, identificar gargalos relacionados a agentes específicos e analisar o impacto das transferências no tempo de resolução.

Onde obter

O campo padrão 'Assignee' de um chamado do Jira.

Exemplos
John SmithEmily JonesServiceDeskAgent1
Status
Status
A etapa atual do incidente em seu ciclo de vida.
Descrição

O campo Status indica o estado atual de um 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 registro de atividades usado no Process Mining. Analisar o tempo gasto em cada status é fundamental para identificar gargalos e entender onde os incidentes permanecem por mais tempo.

Por que isso importa

Reflete diretamente o progresso do incidente e é a principal fonte para identificar etapas do processo e tempos de espera.

Onde obter

O campo padrão 'Status' de um chamado do Jira.

Exemplos
Em andamentoAguardando o clienteResolvidoFechado
Categoria da causa raiz
RootCauseCategory
A classificação da causa raiz subjacente do incidente.
Descrição

Este atributo registra o motivo fundamental pelo qual o incidente ocorreu, como 'Software Defect', 'Hardware Failure' ou 'User Error'. Normalmente, ele é preenchido após a investigação e é essencial para o gerenciamento eficaz de problemas e a prevenção de incidentes futuros. Analisar as categorias de causa raiz ajuda a identificar fragilidades sistêmicas e priorizar iniciativas de melhoria. Uma taxa elevada de causas raiz 'Unknown' pode indicar a necessidade de melhorar os processos de investigação.

Por que isso importa

Permite analisar a causa raiz, ajudando a passar de uma abordagem reativa para uma abordagem proativa ao identificar e tratar as fontes dos incidentes.

Onde obter

Quase sempre é um campo personalizado no Jira. O nome e as opções dependem muito da configuração específica da organização.

Exemplos
Erro de configuraçãoIndisponibilidade da redeBug de software
Componente
Component
O sistema, aplicativo ou parte da infraestrutura afetada pelo incidente.
Descrição

Os componentes são subseções de um projeto do Jira usadas para agrupar chamados em partes menores, como 'User Interface', 'Database' ou 'API'. Analisar os incidentes por componente ajuda a identificar quais partes de um sistema estão mais sujeitas a problemas. Essas informações são valiosas para a análise de causa raiz e podem orientar iniciativas de melhoria do serviço ou redução da dívida técnica.

Por que isso importa

Permite filtrar e analisar com base na área específica do produto ou sistema afetada, ajudando a identificar pontos críticos de tecnologia.

Onde obter

O campo padrão 'Components' de um chamado do Jira.

Exemplos
Serviço de autenticaçãoDashboard de relatóriosAplicativo móvel
Contagem de transferências
HandoffCount
O número de vezes que o incidente foi reatribuído a um grupo ou usuário diferente.
Descrição

Esta métrica calculada conta quantas vezes os campos 'Assignee' ou 'AssignmentGroup' mudaram durante o ciclo de vida do incidente. Uma contagem elevada de transferências geralmente indica ineficiência no processo, falta de resolução no primeiro contato ou lacunas de conhecimento, levando a tempos de resolução mais longos. Analisar esse KPI ajuda a simplificar o processo de atribuição e melhorar a colaboração entre as equipes.

Por que isso importa

Quantifica o atrito e a ineficiência do processo causados por reatribuições, ajudando a identificar oportunidades de melhoria.

Onde obter

Calculado contando o número de alterações nos campos 'Assignee' ou 'AssignmentGroup' no changelog do chamado.

Exemplos
015
É retrabalho
IsRework
Um indicador que mostra se o incidente passou por retrabalho, como ser reaberto.
Descrição

Este atributo booleano calculado identifica incidentes que retornaram a uma etapa anterior do processo, geralmente por terem sido reabertos após a resolução. Os ciclos de retrabalho são uma fonte significativa de ineficiência e insatisfação do cliente. Esse indicador permite quantificar facilmente a taxa de retrabalho e concentrar a análise nos motivos pelos quais os incidentes não estão sendo resolvidos corretamente na primeira vez.

Por que isso importa

Evidencia problemas de qualidade e ineficiências do processo ao sinalizar incidentes que exigem trabalho repetido, apoiando diretamente a análise de retrabalho.

Onde obter

Calculado detectando sequências específicas de transições de status no registro de eventos, como 'Resolved' -> 'Reopened'.

Exemplos
truefalse
ID do problema vinculado
LinkedProblemId
O identificador de um chamado de problema vinculado a este incidente.
Descrição

Incidentes que são sintomas de um problema maior e subjacente geralmente são vinculados a um chamado de Problem. Este campo armazena o ID desse Problem associado. Analisar esses vínculos ajuda a entender a relação entre incidentes e problemas, medir a eficácia do processo de gerenciamento de problemas e identificar incidentes recorrentes que exigem uma correção permanente.

Por que isso importa

Conecta os incidentes aos problemas subjacentes, permitindo analisar com que eficácia a organização trata as causas raiz para evitar incidentes futuros.

Onde obter

Essas informações são armazenadas na seção 'Issue Links' de um chamado do Jira.

Exemplos
PROB-123PROB-456Nenhum
Meta de tempo para resolução
TimeToResolutionTarget
A duração-alvo do SLA para resolver o incidente.
Descrição

Este atributo define o tempo máximo esperado para resolver um incidente de determinada prioridade ou tipo. Ele é a referência usada para comparar o tempo real de resolução e determinar a conformidade com o SLA. Esse valor normalmente é definido de forma dinâmica com base em regras que consideram fatores como prioridade, severidade ou tipo de chamado. Ele é fundamental para qualquer Dashboard de monitoramento da performance do SLA.

Por que isso importa

Fornece a referência para medir a conformidade com o SLA e serve de base para o KPI Incident SLA Breach Rate.

Onde obter

É derivado da configuração de SLA no Jira Service Management. A meta específica, por exemplo, 'Time to resolution', deve ser identificada.

Exemplos
4h8h3d
Relator
Reporter
O usuário que criou ou relatou o incidente inicialmente.
Descrição

O relator é a pessoa, geralmente um usuário final ou outro sistema, que registrou o incidente pela primeira vez. Analisar os incidentes por relator pode ajudar a identificar usuários ou departamentos que enfrentam problemas com frequência. Também pode ser usado para entender padrões de comunicação, especialmente ao analisar atividades como 'Waiting for Customer' e 'Customer Responded'.

Por que isso importa

Ajuda a analisar as fontes dos incidentes, identificar padrões relacionados a usuários ou departamentos específicos e entender atrasos na interação com o cliente.

Onde obter

O campo padrão 'Reporter' de um chamado do Jira.

Exemplos
Alice JohnsonBob Williamsmonitoring-tool@example.com
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 um status de resolução. As resoluções comuns incluem 'Fixed', 'Duplicate', 'Won't Do' ou 'Cannot Reproduce'. Analisar a distribuição dos tipos de resolução pode gerar insights sobre a qualidade dos chamados recebidos e a eficácia do processo de resolução. Por exemplo, um número elevado de resoluções 'Duplicate' pode indicar um problema na criação ou na triagem dos incidentes.

Por que isso importa

Fornece contexto sobre o resultado de um incidente, ajudando a categorizar as resoluções e identificar tendências na forma como os incidentes são encerrados.

Onde obter

O campo padrão 'Resolution' de um chamado do Jira. Esse campo normalmente é preenchido quando um chamado é movido para uma categoria de status 'Done'.

Exemplos
ConcluídoCorrigidoDuplicadoNão será corrigido
Severidade
Severity
A medida do impacto do incidente sobre o negócio.
Descrição

A severidade define o impacto que um incidente tem sobre o negócio, desde o impacto em um único usuário até uma interrupção crítica do sistema. Enquanto a prioridade determina a ordem do trabalho, a severidade informa o impacto geral no negócio. Analisar por severidade ajuda a entender a performance do processo para os incidentes mais relevantes para o negócio e costuma ser combinado com a prioridade para uma análise mais detalhada.

Por que isso importa

Oferece uma visão do impacto no negócio, permitindo uma análise focada 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íticoGraveMenorTrivial
Tipo de chamado
IssueType
O tipo de chamado, como Incident, Service Request ou Problem.
Descrição

O Jira usa Issue Types para diferenciar vários tipos de tarefas. No contexto de Gerenciamento de Incidentes, o tipo principal é 'Incident', mas outros, como 'Sub-task', também podem ser relevantes. Esse atributo é essencial para filtrar o conjunto de dados e incluir apenas incidentes, garantindo que a análise de Process Mining esteja focada no processo correto.

Por que isso importa

Garante que a análise esteja corretamente limitada aos 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' de um chamado do Jira.

Exemplos
IncidenteAjuda de TIBug
Tipo de solicitação do cliente
CustomerRequestType
O tipo específico de solicitação enviada pelo cliente por meio do portal de serviços.
Descrição

Este campo categoriza as solicitações do ponto de vista do cliente, conforme apresentadas no portal do Jira Service Management, por exemplo, 'Report a system issue'. Ele fornece uma classificação do incidente mais fácil de entender para o usuário, que pode ser diferente do 'Issue Type' interno. Analisar esse atributo pode gerar insights sobre como os clientes percebem e relatam problemas, ajudando a melhorar o design do portal e as ofertas de serviços.

Por que isso importa

Oferece uma visão das categorias de incidentes centrada no cliente, ú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 > Relatar um problema no sistemaE-mail > Solicitação de acesso
Violação do SLA
SlaBreach
Um indicador que mostra se o tempo de resolução do incidente ultrapassou a meta do SLA.
Descrição

Este atributo booleano calculado indica se um incidente violou o SLA de 'Time to Resolution'. O valor é verdadeiro quando 'IncidentResolutionCycleTime' é maior que 'TimeToResolutionTarget'. Esse indicador simplifica a análise e a visualização, permitindo filtrar e agregar dados facilmente para calcular o KPI geral de SLA Breach Rate. Ele é a principal medida de resultado do Dashboard de Monitoramento da Performance do SLA.

Por que isso importa

Fornece um resultado binário claro sobre a performance do 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
truefalse
Obrigatório Recomendado Opcional

Atividades de Gestão de Incidentes

Estas são as principais etapas e marcos do processo que você deve registrar no seu Event Log para realizar uma descoberta e uma análise precisas dos seus Workflows de resolução de incidentes.
7 Recomendado 8 Opcional
Atividade Descrição
Aguardando o cliente
Marca o momento em que a equipe de suporte aguarda informações ou uma ação do cliente. É inferido a partir de uma mudança de status para um status específico de espera, como 'Waiting for customer'.
Por que isso importa

Isolar esse tempo 'em espera' é essencial para medir o SLA com precisão, pois ele costuma ser excluído dos cálculos de tempo de resolução. Isso ajuda a analisar atrasos na resposta do cliente.

Onde obter

É inferido a partir do histórico de alterações de status do problema. O evento corresponde ao registro de data e hora em que o status muda para 'Waiting for customer' ou um estado semelhante.

Captura

Identifique o registro de data e hora da mudança de status para 'Waiting for customer'.

Tipo de evento inferred
Incidente criado
Marca o início oficial do ciclo de vida do incidente, quando um relatório é enviado e um novo problema é criado no Jira. Esse evento é capturado explicitamente quando um novo problema do tipo 'Incident' é registrado no sistema.
Por que isso importa

Esse é o principal evento de início do processo. Analisar o tempo entre essa atividade e a resolução é fundamental para medir o tempo total do ciclo e a adesão ao SLA.

Onde obter

Esse é um evento explícito, capturado a partir do registro de data e hora 'created' do problema no Jira. O evento de criação do problema é registrado no histórico do problema.

Captura

Use o registro de data e hora de criação do problema.

Tipo de evento explicit
Incidente encerrado
Representa o encerramento administrativo final do ticket do incidente depois que ele foi resolvido e verificado. É inferido a partir da mudança de status para 'Closed'.
Por que isso importa

Esse é o evento final do processo. Analisar o tempo entre 'Resolved' e 'Closed' pode revelar atrasos na limpeza administrativa ou nos processos de confirmação do usuário.

Onde obter

É inferido a partir do histórico de alterações de status do problema. O evento corresponde ao registro de data e hora em que o status muda para o estado final 'Closed'.

Captura

Identifique o registro de data e hora da mudança 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 no campo 'Assignee' ou 'Assigned Group'.
Por que isso importa

Acompanhar reatribuições é essencial para analisar transferências. Um número elevado de reatribuições geralmente indica ineficiências no processo, lacunas de conhecimento ou roteamento inicial incorreto, levando a atrasos na resolução.

Onde obter

É inferido a partir do histórico do problema, detectando qualquer atualização no campo 'Assignee' depois que ele foi preenchido pela primeira vez. Cada alteração constitui um evento de reatribuição.

Captura

Identifique as alterações posteriores no campo 'Assignee' após a atribuição inicial.

Tipo de evento inferred
Incidente resolvido
Essa atividade confirma que o incidente foi resolvido com sucesso e que o serviço foi restaurado. Muitas vezes, ela coincide com a mudança para o status 'Resolved'.
Por que isso importa

Esse é o principal marco de sucesso do processo. A duração até esse ponto é o KPI mais comum e representa o tempo até a resolução, ou TTR.

Onde obter

É inferido a partir da mudança de status para 'Resolved'. Em muitos Workflows, esse é o mesmo evento que 'Resolution Proposed', representando o principal ponto de resolução.

Captura

Identifique o registro de data e hora da mudança de status para 'Resolved'.

Tipo de evento inferred
Investigação iniciada
Indica que um agente atribuído começou a trabalhar ativamente no diagnóstico do incidente. Normalmente, é inferido quando o status do problema muda de 'Open' ou 'New' para 'In Progress'.
Por que isso importa

Esse marco importante indica o início dos esforços ativos de resolução. Medir o tempo até essa atividade ajuda a identificar atrasos iniciais em filas e problemas de disponibilidade de recursos.

Onde obter

É inferido a partir do histórico de alterações de status do problema. O registro de data e hora do evento corresponde ao momento em que o status muda para um estado que representa trabalho ativo, como 'In Progress'.

Captura

Identifique o registro de data e hora da mudança de status para 'In Progress'.

Tipo de evento inferred
Resolução proposta
Essa atividade indica que uma resolução foi identificada e implementada e que o incidente aguarda confirmação ou validação final. Ela é inferida a partir da mudança de status para 'Resolved'.
Por que isso importa

Esse é um marco importante que indica o fim do trabalho ativo da equipe de suporte. Muitas vezes, é o evento que interrompe a contagem do SLA.

Onde obter

É inferido a partir do histórico de alterações de status do problema. O registro de data e hora do evento corresponde ao momento em que o status muda para 'Resolved' ou um estado equivalente.

Captura

Identifique o registro de data e hora da mudança de status para 'Resolved'.

Tipo de evento inferred
Cliente respondeu
Indica que o cliente forneceu as informações solicitadas e que o incidente pode avançar. É inferido quando o status sai de 'Waiting for customer' e volta para um status ativo.
Por que isso importa

Essa atividade marca o fim de um atraso causado pelo cliente. Analisar a duração entre 'Waiting For Customer' e esse evento revela o tempo médio de resposta do cliente.

Onde obter

É inferido a partir do histórico de alterações de status do problema. O evento ocorre quando o status muda de 'Waiting for customer' para um status como 'In Progress', geralmente depois que o cliente adiciona um comentário.

Captura

Detecte a mudança de status de 'Waiting for customer' para 'In Progress'.

Tipo de evento inferred
Comentário adicionado
Representa qualquer evento de comunicação ou registro de observação em que um usuário adiciona um comentário ao ticket do incidente. É um evento explícito, capturado sempre que um comentário é publicado.
Por que isso importa

Analisar a frequência dos comentários pode gerar insights sobre padrões de comunicação, eficiência da colaboração e complexidade de um incidente. Também pode destacar incidentes que exigem comunicação excessiva.

Onde obter

Esse é um evento explícito. O Jira armazena cada comentário com registro de data e hora e autor, disponíveis no histórico de comentários do problema ou pela API.

Captura

Use o registro de data e hora de cada comentário adicionado ao problema.

Tipo de evento explicit
Escalonado para uma equipe especializada
Indica que o incidente foi escalonado para uma equipe especializada, como Tier 2 ou Desenvolvimento, para receber suporte avançado. Isso é inferido a partir de uma alteração em um campo personalizado 'Support Team' ou de uma reatribuição específica.
Por que isso importa

Destaca incidentes que exigem conhecimento especializado e acompanha o fluxo entre diferentes níveis de suporte. Isso ajuda a identificar gargalos nas equipes especializadas e analisar padrões de escalonamento.

Onde obter

É inferido a partir do histórico do problema, acompanhando alterações em um campo personalizado que representa a equipe atribuída ou identificando uma alteração no campo 'Assignee' para um membro de um grupo especializado conhecido.

Captura

Detecte uma alteração em um campo personalizado de 'Assigned Team' ou alterações específicas no responsável.

Tipo de evento inferred
Incidente atribuído
Essa atividade representa a atribuição inicial do incidente a um agente ou grupo de suporte para tratamento. Ela é capturada acompanhando o primeiro momento em que o campo 'Assignee' ou 'Assigned Group' é preenchido.
Por que isso importa

Mede o tempo de resposta e de atribuição inicial, que é um componente importante das métricas de SLA. Ajuda a identificar atrasos antes do início da investigação ativa.

Onde obter

É inferido a partir do histórico do problema, identificando a primeira alteração no campo 'Assignee' cujo valor anterior era 'Unassigned'.

Captura

Detecte a primeira atualização do campo 'Assignee' no histórico do problema.

Tipo de evento inferred
Incidente priorizado
Representa a definição da prioridade e/ou da severidade do incidente, que determina sua urgência e seu impacto no negócio. Normalmente, é inferido a partir do primeiro momento em que os campos 'Priority' ou 'Severity' são preenchidos ou atualizados após a criação.
Por que isso importa

Acompanhar a priorização ajuda a analisar se os incidentes são avaliados com rapidez e consistência. Atrasos nessa etapa podem afetar diretamente os cálculos de SLA e a alocação de recursos.

Onde obter

É inferido a partir do histórico do problema, que registra alterações em todos os campos. Procure a primeira atualização do campo 'Priority' ou de um campo personalizado 'Severity' após o evento de criação do problema.

Captura

Detecte a primeira alteração no campo 'Priority' do histórico do problema.

Tipo de evento inferred
Incidente reaberto
Representa uma situação em que um incidente anteriormente resolvido é reativado porque o problema voltou a ocorrer ou a correção foi ineficaz. É inferido a partir de uma mudança de status de 'Resolved' ou 'Closed' de volta para um status aberto.
Por que isso importa

Incidentes reabertos são uma medida direta da qualidade da resolução e um indicador principal de retrabalho. Analisar esses eventos ajuda a identificar encerramentos prematuros e soluções ineficazes.

Onde obter

É inferido a partir do histórico de alterações de status do problema. O evento é registrado quando o status muda de um estado final, como 'Resolved' ou 'Closed', de volta para 'Open' ou 'In Progress'.

Captura

Detecte a mudança de status de 'Resolved' ou 'Closed' para um status aberto.

Tipo de evento inferred
Solução temporária fornecida
Representa a implementação de uma correção temporária para restaurar o serviço enquanto uma solução permanente está sendo desenvolvida. Isso pode ser inferido a partir de uma mudança de status ou de um comentário específico.
Por que isso importa

Medir o tempo necessário para fornecer uma solução temporária é um indicador importante da velocidade de restauração do serviço. Isso ajuda a diferenciar uma mitigação temporária de uma resolução permanente.

Onde obter

Esse evento costuma ser inferido. Pode corresponder a uma mudança para o status 'Workaround Provided' ou à adição de um comentário público contendo palavras-chave específicas, como 'workaround'.

Captura

Identifique uma mudança de status específica ou uma palavra-chave em um comentário.

Tipo de evento inferred
Vinculado a um ticket de problema
Ocorre quando um incidente é vinculado a um problema para análise de causa raiz. É um evento explícito, capturado quando um link 'relates to' ou 'caused by' é criado para um problema do tipo 'Problem'.
Por que isso importa

Acompanhar esse vínculo é essencial para entender com que eficácia a organização passa da mitigação do incidente para a análise e a prevenção da causa raiz.

Onde obter

Esse é um evento explícito registrado no histórico de links do problema. Cada criação de link tem um registro de data e hora e pode ser filtrada para links com problemas do tipo 'Problem'.

Captura

Use o registro de data e hora da criação de um link do problema com um problema do tipo 'Problem'.

Tipo de evento explicit
Recomendado Opcional

Guias de extração

Como obter seus dados do Jira Service Management

Pronto para começar?

Use este Template de dados para transformar sua gestão de incidentes, identificar ineficiências e reduzir o tempo de resolução. Comece a otimizar seu processo hoje.

Otimize a gestão de incidentes e resolva incidentes mais rapidamente

Reduza o MTTR em 35% e aumente a satisfação dos usuários com processos mais simples.

Começar o teste grátis

Não é necessário cartão de crédito • Configuração em 5 minutos