Seu Template de Dados para Gestão de Problemas

Zendesk Support
Seu Template de Dados para Gestão de Problemas

Seu Template de Dados para Gestão de Problemas

Este template oferece uma estrutura completa para mapear o ciclo de vida da sua gestão de problemas dentro do Zendesk Support. Ele descreve os atributos essenciais, marcos do processo e a lógica de extração necessária para identificar gargalos na análise de causa raiz. Seguindo esta estrutura, você poderá construir um log de eventos de alta qualidade para obter insights profundos sobre o processo.
  • Atributos recomendados para análise detalhada
  • Principais atividades do processo e transições de status
  • Guia de extração para dados do Zendesk Support
É novo em event logs? Saiba como criar um event log para Process Mining.

Atributos de Gestão de Problemas

Estes campos de dados recomendados fornecem o contexto necessário para analisar categorias de tickets, níveis de prioridade e responsabilidades ao longo de todo o ciclo de vida de resolução de problemas.
5 Obrigatório 8 Recomendado 7 Opcional
Nome Descrição
Atividade
ActivityName
O nome do evento ou ação realizada no registro de problema.
Descrição

Este atributo captura a etapa ou ação específica realizada durante o ciclo de vida do registro de problema. Exemplos incluem mudanças de status como de "Aberto" para "Pendente", mudanças de atribuição ou etapas específicas de workflow como "Contorno Publicado".

Na análise, isso forma os nós do mapa de processo. A sequência dessas atividades permite que os analistas visualizem o fluxo de trabalho, identifiquem gargalos e meçam o tempo gasto entre etapas específicas do processo.

Por que é importante

Define o "quê" do processo, habilitando a visualização do fluxo e a análise de variantes.

Onde obter

Derivado de Zendesk Ticket Audits ou Ticket Metrics

Exemplos
Registro de Problema IniciadoInvestigação IniciadaWorkaround Publicado
Hora de Início
EventTimestamp
A data e hora específicas em que uma atividade ocorreu.
Descrição

Este atributo registra o momento exato em que uma atividade ocorreu no sistema Zendesk. Ele fornece a dimensão temporal necessária para sequenciar os eventos corretamente e calcular as durações entre as etapas.

Na análise, isso é crítico para calcular tempos de ciclo, identificar atrasos, verificar a conformidade com SLAs e visualizar o processo ao longo do tempo. Sem carimbos de data/hora precisos, é impossível entender a velocidade do processo de resolução de problemas.

Por que é importante

Permite ordenar as atividades e calcular todos os KPIs baseados em tempo.

Onde obter

Auditorias de Ticket do Zendesk, campo 'created_at'

Exemplos
2023-10-12T08:30:00Z2023-10-12T09:15:22Z
Registro de Problema
ProblemRecordId
O identificador numérico exclusivo atribuído ao ticket de problema no Zendesk.
Descrição

Este atributo representa a chave exclusiva do registro de problema no sistema Zendesk Support. Ele serve como o ID de Caso central para o Process Mining, permitindo que todos os eventos, atualizações e interações subsequentes sejam agrupados em uma única instância de processo.

Na análise, este ID é usado para identificar distintamente cada jornada de investigação de problema, da criação ao encerramento. Ele permite a correlação de incidentes relacionados e o rastreamento do ciclo de vida do problema por diversos níveis de suporte.

Por que é importante

É a chave obrigatória fundamental para agrupar eventos em casos para qualquer análise de process mining.

Onde obter

Objeto de Ticket do Zendesk, campo 'id' onde o tipo é 'problem'

Exemplos
1045293849921
Sistema de Origem
SourceSystem
O nome do sistema de onde os dados se originaram.
Descrição

Este atributo identifica a plataforma de software da qual os dados do processo foram extraídos. Neste contexto, ele será preenchido invariavelmente com "Zendesk Support".

Na análise, especialmente ao combinar dados de múltiplos sistemas (ex: Zendesk e Jira), este campo permite que analistas filtrem ou agrupem dados por sua origem. Isso garante a linhagem dos dados e a rastreabilidade em visões de processos que abrangem vários sistemas.

Por que é importante

Garante a linhagem dos dados e suporta configurações de process mining multi-sistema.

Onde obter

Definido estaticamente na extração

Exemplos
Zendesk Support
Última Atualização de Dados
LastDataUpdate
O carimbo de data/hora que indica quando o registro de problema foi modificado pela última vez.
Descrição

Este atributo reflete o momento mais recente em que os dados do registro de problema foram atualizados no sistema de origem. É diferente do timestamp do evento, pois refere-se ao nível do registro e não ao nível da atividade.

Na análise, isso ajuda a determinar o quão atualizados estão os dados. É usado para identificar se o conjunto de dados é recente ou se há atrasos de sincronização entre o sistema de origem e o ambiente de Process Mining.

Por que é importante

Rastreia a atualização dos dados e auxilia em estratégias de carga incremental.

Onde obter

Objeto de Ticket do Zendesk, campo 'updated_at'

Exemplos
2023-11-01T14:20:00Z
Categoria da causa raiz
RootCauseCategory
A causa raiz identificada para o problema (ex: Defeito de Código, Erro de Configuração).
Descrição

Este atributo captura o diagnóstico final do que causou o problema. Geralmente é preenchido durante a atividade "Causa Raiz Identificada".

Na análise, isso é usado para gerar o relatório de "Precisão da Categorização de Problemas" e para analisar tendências de falhas no sistema. Ajuda a gestão a entender se deve focar em qualidade de código, estabilidade de infraestrutura ou gestão de fornecedores.

Por que é importante

Permite analisar padrões de falha e orientar esforços de melhoria a longo prazo.

Onde obter

Campos Personalizados de Ticket do Zendesk

Exemplos
Bug de softwareErro de configuraçãoErro do usuário
Categoria do Problema
ProblemCategory
A classificação do problema (ex: Software, Hardware, Rede).
Descrição

Este atributo categoriza o problema com base no serviço afetado ou na tecnologia envolvida. Geralmente é um campo de menu suspenso personalizado nos formulários do Zendesk.

Na análise, isso é usado no dashboard de "Precisão da Categorização de Problemas". Comparar esta categoria inicial com a causa raiz final ajuda a identificar se a triagem inicial está roteando os problemas corretamente para as equipes certas.

Por que é importante

Permite segmentar por tecnologia ou serviço de negócio.

Onde obter

Campos Personalizados de Ticket do Zendesk

Exemplos
Banco de dadosUI/UXInfraestrutura de Rede
Contagem de Incidentes Relacionados
RelatedIncidentCount
O número de tickets de incidentes vinculados a este registro de problema.
Descrição

Este atributo conta quantos tickets de incidentes individuais estão associados a este registro de problema. No Zendesk, isso é gerenciado pelo campo "problem_id" nos tickets de incidentes que vinculam de volta a este registro.

Na análise, esta é a métrica principal para "Correlação e Impacto de Incidentes". Ajuda a priorizar problemas que afetam o maior número de usuários, orientando decisões estratégicas sobre quais correções trarão o maior ROI em termos de redução do volume de tickets.

Por que é importante

Indica a magnitude e o impacto do problema nos usuários.

Onde obter

API de Tickets do Zendesk, contagem de tickets onde type='incident' e problem_id=EsteID

Exemplos
015342
Data de vencimento do SLA
SlaDueDate
A data e hora limite para que o problema seja resolvido.
Descrição

Este atributo representa o prazo final para resolução com base na configuração do Acordo de Nível de Serviço (SLA). Geralmente é calculado com base na prioridade e no momento em que o ticket foi criado.

Na análise, isso é comparado com o tempo real de resolução para calcular a "Taxa de Aderência ao SLA de Problemas". Ele alimenta o dashboard de "Desempenho e Risco de SLA", destacando casos que estão próximos ou que já excederam o tempo permitido.

Por que é importante

É fundamental para medir a conformidade e o desempenho contratual.

Onde obter

Endpoint de Métricas de Ticket ou Políticas de SLA do Zendesk

Exemplos
2023-12-01T17:00:00Z
Grupo de suporte
SupportGroup
A equipe ou departamento atualmente atribuído ao registro de problema.
Descrição

Este atributo identifica o grupo específico de agentes responsável pelo problema em um determinado momento. Ele muda à medida que o ticket é transferido de uma equipe para outra.

Na análise, isso é crucial para o dashboard de "Análise de Transferência entre Grupos de Suporte". Permite medir o desempenho por equipe, identificar gargalos durante as transferências e analisar a distribuição da carga de trabalho dos recursos.

Por que é importante

Habilita a análise organizacional e a identificação de gargalos entre departamentos.

Onde obter

Objeto de Ticket do Zendesk, campo 'group_id' (resolvido para nome)

Exemplos
Suporte N2Equipe de Banco de DadosOperações de rede
Nome do Responsável
AssigneeName
O agente específico atribuído para trabalhar no problema.
Descrição

Este atributo contém o nome do usuário individual que é atualmente o responsável pelo registro de problema. Ele oferece visibilidade detalhada sobre quem realizou ações específicas.

Na análise, isso ajuda a entender a carga de trabalho e o desempenho individual. Embora a análise por grupo seja comum, os dados por atribuído podem destacar necessidades de treinamento ou identificar indivíduos que são particularmente eficazes na resolução de causas raiz complexas.

Por que é importante

Habilita a análise de recursos em nível individual.

Onde obter

Objeto de Ticket do Zendesk, campo 'assignee_id' (resolvido para nome)

Exemplos
John DoeJane SmithSistema
Prioridade
Priority
O nível de urgência atribuído ao registro de problema.
Descrição

Este atributo indica a importância relativa do problema, tipicamente categorizado como Baixa, Normal, Alta ou Urgente. Ele define os acordos de nível de serviço (SLAs) esperados e a alocação de recursos.

Na análise, isso é usado para segmentar o processo e comparar o desempenho entre diferentes níveis de urgência. Por exemplo, ajuda a verificar se problemas "Urgentes" estão de fato sendo resolvidos mais rápido do que os de prioridade "Baixa", conforme exigido pelo dashboard de "Velocidade de Investigação de Causa Raiz".

Por que é importante

É essencial para segmentar casos, analisar a adesão ao SLA e priorizar recursos.

Onde obter

Objeto de Ticket do Zendesk, campo 'priority'

Exemplos
UrgenteAltoNormalBaixo
Status do Problema
ProblemStatus
O estado atual do registro de problema em seu ciclo de vida.
Descrição

Este atributo mostra o status atual do problema, como Novo, Aberto, Pendente, Resolvido ou Fechado. Ele reflete o progresso da investigação.

Na análise, isso é usado para filtrar casos abertos versus encerrados. É vital para o dashboard de "Monitoramento de Registros de Problemas Estagnados" para identificar quais casos ativos não estão avançando pelo ciclo de vida de status esperado.

Por que é importante

Permite filtrar casos pelo seu estado de conclusão.

Onde obter

Objeto de Ticket do Zendesk, campo 'status'

Exemplos
novoopenpendingresolvidofechado
Assunto do Problema
ProblemSubject
O resumo curto ou título do registro de problema.
Descrição

Este atributo contém o resumo em texto inserido quando o problema foi criado. Geralmente descreve o sintoma ou o assunto sendo investigado.

Na análise, isso fornece contexto ao analista ao detalhar casos específicos. Técnicas de mineração de texto também podem ser aplicadas aqui para agrupar problemas semelhantes ou identificar temas recorrentes que não são capturados pelos campos de categoria estruturados.

Por que é importante

Fornece contexto legível para casos individuais.

Onde obter

Objeto de Ticket do Zendesk, campo 'subject'

Exemplos
Incapaz de processar pagamentos na região UEPicos de latência no servidor de loginFalha na exportação de dados para administradores
Contorno Ativo
WorkaroundActive
Um sinalizador indicando se um workaround foi fornecido ou publicado.
Descrição

Este atributo booleano indica se uma correção temporária foi documentada para o problema. Geralmente é derivado da presença de uma atividade "Contorno Publicado" ou de uma caixa de seleção específica no formulário.

Na análise, isso é usado para o dashboard de "Conformidade de Publicação de Contornos". Ele mede com que frequência a equipe de suporte oferece alívio imediato aos usuários enquanto a investigação de longo prazo continua.

Por que é importante

É chave para medir a mitigação do impacto no usuário durante as investigações.

Onde obter

Derivado da presença da atividade 'Workaround Publicado' ou Campo Personalizado

Exemplos
verdadeirofalse
Duração da Investigação
InvestigationDuration
O tempo decorrido desde o início da investigação até a identificação da causa raiz.
Descrição

Este atributo calculado mede a duração da fase central de diagnóstico. Ele calcula a diferença de tempo entre a atividade "Investigação Iniciada" e a atividade "Causa Raiz Identificada".

Na análise, esta é a métrica principal para a "Duração Média da Análise de Causa Raiz". Permite o benchmarking da velocidade diagnóstica entre diferentes grupos de suporte e categorias de problemas.

Por que é importante

Mede a eficiência do processo de diagnóstico.

Onde obter

Calculado na ferramenta de Process Mining: Timestamp(Causa Raiz) - Timestamp(Início da Investigação)

Exemplos
48 horas5 dias
Está Estagnado
IsStale
Sinaliza se o problema está sem atividade há mais de 14 dias.
Descrição

Este atributo calculado identifica registros que não foram atualizados recentemente. Ele compara a data atual (ou data da análise) com o carimbo de data/hora da última atividade.

Na análise, isso alimenta o dashboard de "Monitoramento de Registros de Problemas Estagnados". Ajuda os gestores a isolar rapidamente casos negligenciados que congestionam o backlog e que podem exigir fechamento administrativo ou reatribuição.

Por que é importante

Ajuda a identificar desperdícios no processo e itens de trabalho negligenciados.

Onde obter

Calculado na ferramenta de Process Mining: (Agora - LastDataUpdate) > 14 dias

Exemplos
verdadeirofalse
ID da Requisição de Mudança
ChangeRequestId
O identificador da requisição de mudança vinculada para implementar a correção.
Descrição

Este atributo vincula o registro de problema a um registro de Gestão de Mudanças (potencialmente em outro sistema ou em um tipo de ticket diferente). Ele indica que um processo formal de mudança foi iniciado.

Na análise, isso alimenta o dashboard de "Taxa de Iniciação de Requisição de Mudança". Ajuda a rastrear a transição do diagnóstico para a implementação, garantindo que as causas raiz identificadas resultem em ações formais de mudança.

Por que é importante

Vincula o processo de problema ao processo de gestão de mudanças.

Onde obter

Campos Personalizados de Ticket do Zendesk ou Tickets Vinculados

Exemplos
CR-1002CHG00394
ID do Artigo de Conhecimento
KnowledgeArticleId
O ID do artigo da base de conhecimento criado ou vinculado ao problema.
Descrição

Este atributo armazena a referência a um artigo do Zendesk Guide ou item de conhecimento externo. Ele indica que o conhecimento adquirido com o problema foi capturado.

Na análise, a presença deste campo é usada para calcular a "Taxa de Integração com a Base de Conhecimento". Isso verifica se a organização está fechando o ciclo de aprendizado ao documentar soluções para referência futura.

Por que é importante

Mede a eficácia dos processos de gestão do conhecimento.

Onde obter

Campos Personalizados de Ticket do Zendesk ou Conteúdo Vinculado

Exemplos
360045889KB-2991
Tem PIR
HasPostImplementationReview
Sinaliza se uma Revisão Pós-Implementação foi realizada.
Descrição

Este atributo indica se o processo de resolução do problema incluiu uma fase de revisão. Ele é derivado verificando se a atividade "Revisão Pós-Implementação Realizada" existe no histórico do caso.

Na análise, isso alimenta o dashboard de "Cobertura de Revisão Pós-Implementação". É uma métrica de conformidade que garante que a organização está aprendendo com seus problemas mais críticos.

Por que é importante

Valida a conformidade com processos de melhoria contínua.

Onde obter

Derivado da presença da atividade 'Revisão Pós-Implementação Realizada'

Exemplos
verdadeirofalse
Obrigatório Recomendado Opcional

Atividades de Gestão de Problemas

Capture estas etapas essenciais e mudanças de status para visualizar o fluxo de ponta a ponta, da identificação à correção definitiva.
8 Recomendado 4 Opcional
Atividade Descrição
Atribuído ao Grupo de Suporte
O encaminhamento do registro de problema para uma equipe técnica ou departamento específico. Isso é rastreado quando o campo ID do Grupo no ticket é atualizado.
Por que é importante

Fundamental para o dashboard de Análise de Transferência entre Grupos, medindo tempos de espera entre departamentos.

Onde obter

Monitore alterações no campo "group_id" no log de auditoria do ticket.

Captura

Registrado quando a transação de Mudança de Atribuição de Grupo é executada

Tipo de evento explicit
Causa raiz identificada
O ponto em que a causa raiz do problema é determinada. Isso geralmente é capturado quando um campo de texto personalizado "Causa Raiz" ou uma categoria de menu suspenso é preenchido pelo agente.
Por que é importante

Um marco crucial para o dashboard de Velocidade de Investigação de Causa Raiz e para medir a eficiência do diagnóstico.

Onde obter

Monitore alterações em campos personalizados rotulados como "Causa Raiz", "RCA" ou "Fonte do Problema" para valores não nulos.

Captura

Comparar o preenchimento de campos personalizados

Tipo de evento inferred
Correção Permanente Aplicada
Significa que a solução técnica foi implementada no ambiente. Isso geralmente é rastreado por uma transição de status personalizada ou uma tag específica antes que o ticket seja totalmente resolvido.
Por que é importante

Essencial para o dashboard de Eficiência de Implementação de Correção, medindo o tempo do diagnóstico ao deploy.

Onde obter

Inferido de uma tag específica (ex: 'fix_deployed') ou de um campo personalizado de status, se existir.

Captura

Monitore tags ou menus suspensos de status personalizados

Tipo de evento inferred
Investigação Iniciada
Marca a transição de um estado passivo "Novo" para um estado de trabalho ativo. Isso indica que um agente reconheceu o problema e iniciou o diagnóstico.
Por que é importante

Usado para calcular as métricas de Registro de Problema Estagnado e é o ponto de partida para o KPI de Duração Média da Análise de Causa Raiz.

Onde obter

Inferido quando o status do ticket muda de 'New' para 'Open' ou 'Pending'.

Captura

Comparar campo de status antes/depois

Tipo de evento inferred
Registro de Problema Encerrado
O evento final do ciclo de vida onde o ticket é bloqueado e nenhuma outra alteração pode ser feita. No Zendesk, isso costuma ocorrer automaticamente 4 dias após o estado "Resolvido".
Por que é importante

Marca o fim absoluto do ciclo de vida do registro e é utilizado para retenção de dados e relatórios históricos.

Onde obter

Derivado da mudança de status do ticket para 'Closed'.

Captura

Registrado quando o status muda para Fechado

Tipo de evento explicit
Registro de Problema Iniciado
A criação inicial do ticket de problema dentro do Zendesk Support. Este evento captura o carimbo de data/hora de quando o problema foi registrado pela primeira vez no sistema, geralmente iniciando a instância do processo.
Por que é importante

Estabelece o horário de início para o Ciclo de Resolução de Ponta a Ponta e serve como base para todas as métricas de lead time.

Onde obter

Derivado do timestamp 'created_at' no objeto do ticket ou da primeira entrada no log de auditoria.

Captura

Registrado quando a transação de Criação de Ticket é executada

Tipo de evento explicit
Resolução Verificada
A marcação formal do problema como Resolvido. No Zendesk, isso ocorre quando o status padrão do sistema é definido como "Resolvido", indicando que a correção foi verificada e o caso está completo.
Por que é importante

O ponto principal para cálculos de Desempenho e Risco de SLA e Taxa de Aderência ao SLA de Problemas.

Onde obter

Derivado da mudança de status do ticket para 'Solved'.

Captura

Registrado quando o status muda para Solved

Tipo de evento explicit
Workaround Publicado
A ação de documentar e compartilhar uma correção temporária para o problema. No Zendesk, isso costuma ser capturado por uma tag específica ou um campo de seleção personalizado indicando que um contorno está disponível.
Por que é importante

Suporta o dashboard de Conformidade de Publicação de Contornos, garantindo que o alívio temporário seja oferecido aos usuários durante investigações longas.

Onde obter

Monitore a inclusão da tag "workaround_published" ou a alteração em um campo booleano personalizado chamado "Workaround".

Captura

Comparar valores de campos personalizados ou tags

Tipo de evento inferred
Change Request Iniciada
Indica que um processo formal de gestão de mudança foi iniciado. Geralmente inferido quando o campo 'ID da Change Request' é preenchido ou um ticket do tipo 'Mudança' é vinculado.
Por que é importante

Rastreia a Taxa de Iniciação de Requisição de Mudança e vincula a Gestão de Problemas aos workflows de Gestão de Mudanças.

Onde obter

Monitore atualizações em um campo personalizado como "change_reference" ou a criação de um tipo de link "problem_change".

Captura

Monitore o campo personalizado para entrada de ID externo

Tipo de evento inferred
Investigação de Problema Reaberta
Ocorre quando um registro de problema marcado anteriormente como Resolvido retorna para um estado Aberto ou ativo. Isso indica uma correção que falhou ou uma resolução rejeitada.
Por que é importante

Suporta o KPI de Taxa de Reabertura de Problemas e ajuda a identificar problemas de qualidade no processo de resolução.

Onde obter

Inferido quando o status volta de 'Solved' para 'Open', 'New' ou 'Pending'.

Captura

Comparar campo de status antes/depois

Tipo de evento inferred
Proposta de Solução Elaborada
A criação de um artigo na base de conhecimento baseado na investigação do problema. Isso é inferido pelo uso do app Zendesk Knowledge Capture ou pelo link para um novo artigo.
Por que é importante

Suporta o KPI de Taxa de Integração com a Base de Conhecimento, garantindo o aprendizado organizacional.

Onde obter

Monitore eventos relacionados à integração "Knowledge Capture" ou tags como "kcs_draft".

Captura

Derivado de tags específicas do sistema ou eventos de vínculo

Tipo de evento inferred
Revisão Pós-Implementação Realizada
Confirmação de que a revisão retrospectiva foi concluída após a correção. Geralmente é um checkbox ou campo de data atualizado pelo coordenador do processo.
Por que é importante

Necessário para o KPI de Frequência de Revisão Pós-Implementação, garantindo a conformidade com os padrões de qualidade.

Onde obter

Monitore atualizações em uma caixa de seleção personalizada "PIR Concluído" ou campo de data "Data PIR".

Captura

Monitore o preenchimento de campos personalizados

Tipo de evento inferred
Recomendado Opcional

Guias de Extração

Como obter seus dados do Zendesk Support