Seu Template de Dados para Gestão de Problemas
Seu Template de Dados para Gestão de Problemas
- Atributos recomendados para análise detalhada
- Principais atividades do processo e transições de status
- Guia de extração para dados do Zendesk Support
Atributos de Gestão de Problemas
| 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
|
|||
Atividades de Gestão de Problemas
| 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
|
|||