> Melhoria contínua de processos > Gerenciamento de problemas > Zendesk Support > Template de dados

Seu Template de dados de gerenciamento de problemas

Zendesk Support

Atributos do gerenciamento de problemas (19) Atividades de gerenciamento de problemas (12) Guias de extração (3)

Seu Template de dados de gerenciamento de problemas

Este Template oferece uma estrutura completa para mapear o ciclo de vida do gerenciamento de problemas no Zendesk Support. Ele apresenta os atributos essenciais, os marcos do processo e a lógica de extração necessários para identificar gargalos na análise de causa raiz. Seguindo essa estrutura, você pode criar um Event Log de alta qualidade para obter insights mais profundos sobre o processo.

Atributos recomendados para uma análise detalhada
Principais atividades do processo e transições de status
Orientações para extrair dados do Zendesk Support

Novo em Event Logs? Aprenda como criar um Event Log de Process Mining.

Baixar Template

Atributos do gerenciamento de problemas

Estes campos de dados recomendados fornecem o contexto necessário para analisar categorias de tickets, níveis de prioridade e responsáveis durante todo o ciclo de vida da resolução de problemas.

5 Obrigatório 8 Recomendado 6 Opcional

	Nome	Descrição
	Atividade ActivityName	O nome do evento ou da ação realizada no registro de problema.
Descrição Esse atributo registra a etapa ou ação específica realizada durante o ciclo de vida do registro de problema. Os exemplos incluem mudanças de status, como de 'Open' para 'Pending', alterações de atribuição ou etapas específicas do Workflow, como 'Workaround Published'. 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 isso importa Ele define o 'o quê' do processo, permitindo visualizar o fluxo do processo e analisar suas variantes. Onde obter Derivado de auditorias de tickets ou métricas de tickets do Zendesk Exemplos Registro de problema criadoInvestigação iniciadaSolução alternativa publicada
	Horário de início EventTimestamp	A data e hora específicas em que uma atividade ocorreu.
Descrição Esse atributo registra o momento exato em que uma atividade ocorreu no sistema Zendesk. Ele fornece a dimensão temporal necessária para ordenar os eventos corretamente e calcular as durações entre as etapas. Na análise, é essencial para calcular tempos de ciclo, identificar atrasos, verificar a conformidade com SLAs e visualizar o processo ao longo do tempo. Sem carimbos de data e hora precisos, é impossível entender a velocidade do processo de resolução de problemas. Por que isso importa Ele permite ordenar as atividades e calcular todos os KPIs baseados em tempo. Onde obter Auditorias de tickets 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 Esse atributo representa a chave exclusiva do registro de problema no sistema Zendesk Support. Ele funciona como o ID central do caso para o Process Mining, permitindo agrupar todos os eventos, atualizações e interações subsequentes em uma única instância do processo. Na análise, esse ID é usado para identificar de forma exclusiva cada jornada de investigação do problema, desde a criação até o fechamento. Ele permite correlacionar incidentes relacionados e acompanhar o ciclo de vida do problema pelos diferentes níveis de suporte. Por que isso importa É a chave obrigatória fundamental para agrupar eventos em casos em qualquer análise de Process Mining. Onde obter Objeto Zendesk Ticket, campo 'id' quando o tipo é 'problem' Exemplos 1045293849921
	Sistema de origem SourceSystem	O nome do sistema de onde os dados foram originados.
Descrição Esse atributo identifica a plataforma de software da qual os dados do processo foram extraídos. Neste contexto, ele será preenchido consistentemente com 'Zendesk Support'. Na análise, especialmente ao combinar dados de vários sistemas, como Zendesk e Jira, esse campo permite que os analistas filtrem ou agrupem os dados pela origem. Ele garante a linhagem e a rastreabilidade dos dados em visões de processo que envolvem vários sistemas. Por que isso importa Ele garante a linhagem dos dados e dá suporte a configurações de Process Mining com vários sistemas. Onde obter Definido durante a extração Exemplos Zendesk Support
	Última atualização dos dados LastDataUpdate	O carimbo de data e hora que indica quando o registro de problema foi modificado pela última vez.
Descrição Esse atributo reflete o momento mais recente em que os dados do registro de problema foram atualizados no sistema de origem. Ele é diferente do carimbo de data e hora do evento, pois se refere ao nível do registro, e não ao nível da atividade. Na análise, ajuda a determinar a atualidade dos dados. É usado para identificar se o conjunto de dados está atualizado ou se há atrasos de sincronização entre o sistema de origem e o ambiente de Process Mining. Por que isso importa Ele acompanha a atualidade dos dados e ajuda nas estratégias de carregamento incremental. Onde obter Objeto Zendesk Ticket, campo 'updated_at' Exemplos 2023-11-01T14:20:00Z
	Categoria da causa raiz RootCauseCategory	A causa subjacente identificada para o problema, por exemplo, defeito no código ou erro de configuração.
Descrição Esse atributo registra o diagnóstico final da causa do problema. Normalmente, ele é preenchido durante a atividade 'Root Cause Identified'. Na análise, é usado para gerar o relatório de precisão da categorização de problemas e analisar tendências de falhas do sistema. Ele ajuda a gestão a entender se deve concentrar esforços na qualidade do código, na estabilidade da infraestrutura ou na gestão de fornecedores. Por que isso importa Ele permite analisar padrões de falha e direcionar esforços de melhoria de longo prazo. Onde obter Campos personalizados do Zendesk Ticket Exemplos Bug de softwareErro de configuraçãoErro do usuário
	Categoria do problema ProblemCategory	A classificação do problema, por exemplo, Software, Hardware ou Rede.
Descrição Esse atributo categoriza o problema com base no serviço ou na pilha de tecnologia afetada. Normalmente, ele é um campo de lista suspensa personalizado nos formulários do Zendesk. Na análise, é usado para o Dashboard de precisão da categorização de problemas. Comparar essa categoria inicial com a causa raiz final ajuda a identificar se a triagem inicial está encaminhando os problemas corretamente para as equipes certas. Por que isso importa Ele permite segmentar por tecnologia ou serviço de negócio. Onde obter Campos personalizados do Zendesk Ticket Exemplos Banco de dadosUI/UXInfraestrutura de rede
	Data de vencimento do SLA SlaDueDate	A data e hora limite até as quais o problema deve ser resolvido.
Descrição Esse atributo representa o prazo para a resolução com base na configuração do Acordo de Nível de Serviço. Normalmente, ele é calculado com base na prioridade e no horário de criação do ticket. Na análise, é comparado com o tempo real de resolução para calcular a 'Taxa de aderência ao SLA de problemas'. Ele alimenta o Dashboard de performance e risco de SLA, destacando casos que estão próximos de exceder ou já ultrapassaram o tempo permitido. Por que isso importa É essencial para medir a conformidade e a performance contratual. Onde obter Métricas de tickets do Zendesk ou endpoint de políticas de SLA Exemplos 2023-12-01T17:00:00Z
	Grupo de suporte SupportGroup	A equipe ou o departamento atualmente responsável pelo registro de problema.
Descrição Esse atributo identifica o grupo específico de agentes responsável pelo problema em determinado momento. Ele muda conforme o ticket é transferido de uma equipe para outra. Na análise, é essencial para o Dashboard de análise de transferências entre grupos de suporte. Ele permite medir a performance por equipe, identificar gargalos durante as transferências e analisar a distribuição da carga de trabalho entre os recursos. Por que isso importa Ele permite analisar a organização e identificar gargalos entre departamentos. Onde obter Objeto Zendesk Ticket, campo 'group_id' (resolvido para o nome) Exemplos Suporte L2Equipe de banco de dadosOperações de rede
	Nome do responsável AssigneeName	O agente específico responsável por trabalhar no problema.
Descrição Esse atributo contém o nome do usuário responsável pelo registro de problema naquele momento. Ele oferece visibilidade detalhada sobre quem realizou ações específicas. Na análise, ajuda a entender a carga de trabalho e a performance individuais. Embora a análise por grupo seja comum, os dados por responsável podem destacar necessidades de treinamento ou pessoas particularmente eficazes na resolução de causas raiz complexas. Por que isso importa Ele permite analisar os recursos no nível individual. Onde obter Objeto Zendesk Ticket, campo 'assignee_id' (resolvido para o nome) Exemplos John DoeJane SmithSistema
	Prioridade Priority	O nível de urgência atribuído ao registro de problema.
Descrição Esse atributo indica a importância relativa do problema, normalmente categorizada como Baixa, Normal, Alta ou Urgente. Ele orienta os acordos de nível de serviço esperados e a alocação de recursos. Na análise, é usado para segmentar o processo e comparar a performance entre diferentes níveis de urgência. Por exemplo, ajuda a verificar se os problemas 'Urgentes' estão realmente sendo resolvidos mais rapidamente do que os de prioridade 'Baixa', conforme exigido pelo Dashboard de velocidade da investigação da causa raiz. Por que isso importa É essencial para segmentar casos, analisar a aderência a SLAs e priorizar recursos. Onde obter Objeto Zendesk Ticket, campo 'priority' Exemplos UrgenteAltoNormalBaixo
	Quantidade de incidentes relacionados RelatedIncidentCount	O número de tickets de incidentes vinculados a este registro de problema.
Descrição Esse 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 aponta de volta para este registro. Na análise, essa é a principal métrica de 'Correlação e impacto dos incidentes'. Ela ajuda a priorizar os problemas que afetam o maior número de usuários, orientando decisões estratégicas sobre quais correções gerarão o maior ROI em termos de redução do volume de tickets. Por que isso importa Ele indica a dimensão e o impacto do problema sobre os usuários. Onde obter API Zendesk Tickets, contagem de tickets em que type='incident' e problem_id=ThisID Exemplos 015342
	Status do problema ProblemStatus	O estado atual do registro de problema no seu ciclo de vida.
Descrição Esse atributo mostra o status atual do problema, como Novo, Aberto, Pendente, Resolvido ou Fechado. Ele reflete o progresso da investigação. Na análise, é usado para filtrar casos abertos e fechados. É essencial para o Dashboard de monitoramento de registros de problemas parados, que identifica quais casos ativos não estão avançando pelo ciclo de vida de status esperado. Por que isso importa Ele permite filtrar casos pelo estado de conclusão. Onde obter Objeto Zendesk Ticket, campo 'status' Exemplos novoabertopendenteresolvidofechado
	Assunto do problema ProblemSubject	O resumo curto ou título do registro de problema.
Descrição Esse atributo contém o resumo em texto inserido quando o problema foi criado. Normalmente, ele descreve o sintoma ou a questão investigada. Na análise, fornece contexto ao analista ao detalhar casos específicos. Técnicas de mineração de texto também podem ser aplicadas para agrupar problemas semelhantes ou identificar temas recorrentes que não são capturados pelos campos estruturados de categoria. Por que isso importa Ele fornece contexto legível para os casos individuais. Onde obter Objeto Zendesk Ticket, campo 'subject' Exemplos Não é possível processar pagamentos na região da UEPicos de latência no servidor de loginFalha na exportação de dados para usuários administradores
	Contorno ativo WorkaroundActive	Um indicador que mostra se um contorno foi fornecido ou publicado.
Descrição Este atributo booleano indica se uma correção temporária foi documentada para o problema. Geralmente, ele é derivado da presença da atividade 'Contorno publicado' ou de uma caixa de seleção específica no formulário. Na análise, ele é usado no Dashboard 'Conformidade com a publicação de contornos'. A métrica mostra 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 isso importa Ele é essencial para medir a mitigação do impacto sobre os usuários durante as investigações. Onde obter Derivado da presença da atividade 'Contorno publicado' ou de um campo personalizado Exemplos truefalse
	Está obsoleto IsStale	Indica se o problema ficou mais de 14 dias sem atividade.
Descrição Este atributo calculado identifica registros que não foram atualizados recentemente. Ele compara a data atual, ou a data da análise, com o registro de data e hora da última atividade. Na análise, ele alimenta o Dashboard 'Monitoramento de registros de problemas obsoletos'. Isso ajuda os gestores a localizar rapidamente casos negligenciados que ocupam espaço no backlog e podem exigir encerramento administrativo ou redistribuição. Por que isso importa Ele ajuda a identificar desperdícios no processo e itens de trabalho negligenciados. Onde obter Calculado na ferramenta de Process Mining: (Now - LastDataUpdate) > 14 dias Exemplos truefalse
	ID da solicitação de mudança ChangeRequestId	O identificador da solicitação de mudança vinculada para implementar a correção.
Descrição Esse atributo vincula o registro de problema a um registro de Gestão de Mudanças, possivelmente em outro sistema ou em um tipo diferente de ticket. Ele indica que um processo formal de mudança foi iniciado. Na análise, dá suporte ao Dashboard de taxa de início de solicitações de mudança. Ele ajuda a acompanhar 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 isso importa Ele conecta o processo de problemas ao processo de gerenciamento de mudanças. Onde obter Campos personalizados de tickets do Zendesk ou tickets vinculados Exemplos CR-1002CHG00394
	ID do artigo da base de conhecimento KnowledgeArticleId	O ID do artigo da base de conhecimento criado ou vinculado ao problema.
Descrição Esse atributo armazena a referência a um artigo do Zendesk Guide ou a um item de conhecimento externo. Ele indica que o conhecimento obtido com o problema foi registrado. Na análise, a presença desse campo é usada para calcular a 'Taxa de integração da base de conhecimento'. Ele verifica se a organização está fechando o ciclo de aprendizado ao documentar soluções para consultas futuras. Por que isso importa Ele mede a eficácia dos processos de gestão do conhecimento. Onde obter Campos personalizados do Zendesk Ticket ou conteúdo vinculado Exemplos 360045889KB-2991
	Tem PIR HasPostImplementationReview	Indica se foi realizada uma Revisão Pós-Implementação.
Descrição Este atributo indica se o processo de resolução do problema incluiu uma etapa de revisão. Ele é derivado da verificação da existência da atividade 'Revisão Pós-Implementação realizada' no histórico do caso. Na análise, ele dá suporte ao Dashboard 'Cobertura da Revisão Pós-Implementação'. É uma métrica de conformidade que garante que a organização esteja aprendendo com seus principais problemas. Por que isso importa Ele valida a conformidade com os processos de melhoria contínua. Onde obter Derivado da presença da atividade 'Revisão Pós-Implementação realizada' Exemplos truefalse

Obrigatório Recomendado Opcional

Atividades de gerenciamento de problemas

Registre estas etapas essenciais do processo e mudanças de status para visualizar o fluxo completo, da identificação inicial do problema à implementação da correção permanente.

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 é acompanhado quando o campo Group ID do ticket é atualizado.
Por que isso importa Essencial para o Dashboard de análise de transferências entre grupos de suporte, permitindo medir os tempos de espera entre departamentos. Onde obter Monitore mudanças no campo 'group_id' do log de auditoria do ticket. Captura Registrado quando a transação Group Assignment Change é executada Tipo de evento explicit
	Causa raiz identificada	O momento em que a causa subjacente do problema é determinada. Normalmente, isso é registrado quando um campo de texto personalizado 'Root Cause' ou uma categoria de lista suspensa é preenchido pelo agente.
Por que isso importa Um marco essencial para o Dashboard de velocidade da investigação da causa raiz e para medir a eficiência do diagnóstico. Onde obter Monitore alterações nos campos personalizados chamados 'Root Cause', 'RCA' ou 'Problem Source' em busca de valores não nulos. Captura Compare os valores dos campos personalizados para verificar o preenchimento Tipo de evento inferred
	Correção permanente aplicada	Indica que a solução técnica foi implantada no ambiente. Normalmente, isso é acompanhado por meio de uma transição de status personalizada ou de uma tag específica antes que o ticket seja totalmente resolvido.
Por que isso importa Essencial para o Dashboard de eficiência da implementação da correção, que mede o tempo entre o diagnóstico e a implantação. Onde obter Inferido a partir de uma tag específica, como 'fix_deployed', ou de um campo de status personalizado, se existir. Captura Monitore tags ou listas suspensas de status personalizadas Tipo de evento inferred
	Investigação iniciada	Marca a transição de um estado passivo, 'Novo', para um estado ativo de trabalho. Isso indica que um agente reconheceu o problema e iniciou o diagnóstico.
Por que isso importa Usado para calcular métricas de registros de problemas parados e serve como ponto de partida para o KPI de duração média da análise da causa raiz. Onde obter Inferido quando o status do ticket muda de 'Novo' para 'Aberto' ou 'Pendente'. Captura Compare o campo de status antes e depois Tipo de evento inferred
	Registro de problema criado	A criação inicial do ticket de problema no Zendesk Support. Esse evento registra o carimbo de data e hora em que o problema foi registrado pela primeira vez no sistema, geralmente iniciando a instância do processo.
Por que isso importa Define o horário de início do ciclo de resolução de ponta a ponta e serve como base para todas as métricas subsequentes de lead time. Onde obter Derivado do carimbo de data e hora 'created_at' no objeto do ticket ou da primeira entrada no log de auditoria do ticket. Captura Registrado quando a transação Ticket Created é executada Tipo de evento explicit
	Registro de problema fechado	O evento final do ciclo de vida, quando o ticket é bloqueado e nenhuma outra alteração pode ser feita. No Zendesk, isso geralmente acontece automaticamente 4 dias após o estado Solved.
Por que isso importa Marca o fim absoluto da vida do registro e é usado para retenção de dados e relatórios históricos. Onde obter Derivado da mudança do status do ticket para 'Closed'. Captura Registrado quando o status muda para Closed Tipo de evento explicit
	Resolução verificada	O registro formal do problema como Resolvido. No Zendesk, isso ocorre quando o status padrão do sistema é definido como 'Solved', indicando que a correção foi verificada e o caso foi concluído.
Por que isso importa É o principal ponto final para os cálculos de performance e risco de SLA e da taxa de aderência ao SLA de problemas. Onde obter Derivado da mudança do status do ticket para 'Solved'. Captura Registrado quando o status muda para Solved Tipo de evento explicit
	Solução alternativa publicada	A ação de documentar e compartilhar uma correção temporária para o problema. No Zendesk, isso geralmente é registrado por meio de uma tag específica ou de um campo de seleção personalizado que indica a disponibilidade de uma solução alternativa.
Por que isso importa Dá suporte ao Dashboard de conformidade da publicação de soluções alternativas, garantindo que um alívio temporário seja oferecido aos usuários durante investigações longas. Onde obter Monitore a adição da tag 'workaround_published' ou uma alteração em um campo booleano personalizado chamado 'Workaround'. Captura Compare os valores de campos personalizados ou tags Tipo de evento inferred
	Investigação do problema reaberta	Ocorre quando um registro de problema anteriormente marcado como Resolvido retorna ao estado Aberto ou a um estado ativo. Isso indica uma correção malsucedida ou uma resolução rejeitada.
Por que isso importa Dá suporte ao 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 passa de 'Solved' novamente para 'Open', 'New' ou 'Pending'. Captura Compare o campo de status antes e depois Tipo de evento inferred
	Rascunho da solução proposto	A criação de um artigo da base de conhecimento com base na investigação do problema. Isso é inferido pelo uso do aplicativo Zendesk Knowledge Capture ou pelo vínculo de um novo artigo.
Por que isso importa Dá suporte ao KPI de taxa de integração da base de conhecimento, garantindo o aprendizado organizacional. Onde obter Monitore eventos relacionados à integração 'Knowledge Capture' ou tags como 'kcs_draft'. Captura Derive a partir de tags específicas do sistema ou de eventos de vínculo Tipo de evento inferred
	Revisão pós-implementação realizada	Confirma que uma revisão retrospectiva foi concluída após a correção. Normalmente, isso é registrado por meio de uma caixa de seleção ou de um campo de data atualizado pelo coordenador do processo.
Por que isso importa Necessário para o KPI de frequência da revisão pós-implementação, garantindo a conformidade com os padrões de qualidade. Onde obter Monitore atualizações na caixa de seleção personalizada 'PIR Completed' ou no campo de data 'PIR Date'. Captura Monitore o campo personalizado em busca da conclusão Tipo de evento inferred
	Solicitação de mudança iniciada	Indica que um processo formal de gestão de mudanças foi acionado para corrigir o problema. Isso geralmente é inferido quando um campo personalizado 'Change Request ID' é preenchido ou quando um ticket do tipo 'Change' é vinculado.
Por que isso importa Acompanha a taxa de início de solicitações de mudança e conecta os Workflows de Gestão de Problemas e 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 vínculo 'problem_change'. Captura Monitore o campo personalizado em busca da entrada de um ID externo Tipo de evento inferred

Recomendado Opcional

Guias de extração

Como obter seus dados do Zendesk Support

Etapas

Faça login na sua instância do Zendesk e acesse a interface de relatórios do Explore pelo menu de produtos.
Clique na pasta Queries, ou Reports nas versões mais recentes, e selecione New query.
Quando for solicitado a selecionar um conjunto de dados, escolha Support, depois Updates History e, em seguida, Support: Updates History [default]. Esse conjunto contém os registros de eventos necessários para Process Mining, em vez de apenas dados do estado atual.
No painel Metrics, adicione Count (Tickets) ou Count (Updates) para garantir que os dados sejam carregados.
No painel Filters, adicione um filtro para Ticket > Ticket type e selecione Problem para restringir o conjunto de dados ao processo de gerenciamento de problemas.
No painel Rows, adicione os seguintes atributos nesta ordem específica para definir a estrutura do Event Log: Ticket > Ticket ID, Time - Timestamp > Update - Timestamp, Updater > Updater name e Changes > Changes - Field name.
Para criar a coluna Activity Name, você precisa criar um Standard Calculated Attribute. Clique no ícone Calculation na barra lateral direita, selecione Standard calculated attribute, dê a ele o nome Activity Mapper e cole o código fornecido na seção Query abaixo.
Adicione este novo atributo Activity Mapper ao painel Rows. Filtre esse atributo para excluir valores NULL e remover ruídos irrelevantes do sistema.
Adicione outros atributos ao painel Rows para dar contexto: Ticket > Priority, Ticket > Group, Ticket > Status e todos os campos personalizados necessários para a análise de causa raiz ou categoria, como Ticket > Ticket tags ou campos personalizados específicos.
Defina o intervalo de tempo no painel Filters usando Time - Timestamp > Update - Date para abranger o período de análise desejado, como Last 6 Months.
Clique no ícone Visualization type e selecione Table. Verifique se a tabela está sem pivot ou plana, caso essa opção esteja disponível, ou simplesmente confirme que todos os atributos estão na seção Rows.
Exporte o resultado clicando em Export > CSV. Verifique se a opção Keep attribute formatting está marcada para preservar os formatos de registro de data e hora no ProcessMind.

Configuração

Dataset: Support: Updates History (Crítico: não use o conjunto de dados padrão Tickets, pois ele mostra apenas o estado atual).
Filtro de tempo: Update - Date (Recomendação: últimos 90 a 180 dias, dependendo do volume).
Tipo de ticket: filtre estritamente por Problem para evitar misturar Incidents e Service Requests.
Limite de linhas: as exportações do Zendesk Explore geralmente são limitadas a 50.000 linhas. Se o conjunto de dados exceder esse limite, use o filtro Update - Date para exportar blocos mensais menores e mesclá-los externamente.
Campos personalizados: identifique os Field IDs específicos de Root Cause, Change Request e Workaround na sua instância do Zendesk, pois eles não são campos padrão do sistema.
Permissões do sistema: é necessária uma licença Explore Viewer ou Explore Professional.

a Consulta de exemplo config

IF ([Changes - Field name] = "status" AND [Changes - New value] = "New") THEN "Problem Record Logged"
ELIF ([Changes - Field name] = "group_id") THEN "Assigned to Support Group"
ELIF ([Changes - Field name] = "status" AND [Changes - Previous value] = "New" AND [Changes - New value] = "Open") THEN "Investigation Commenced"
ELIF ([Changes - Field name] = "tags" AND CONTAINS([Changes - New value], "workaround_available")) THEN "Workaround Published"
ELIF ([Changes - Field name] = "[Your Root Cause Field Name]") THEN "Root Cause Identified"
ELIF ([Changes - Field name] = "[Your Change Request ID Field Name]") OR ([Changes - Field name] = "type" AND [Changes - New value] = "change") THEN "Change Request Initiated"
ELIF ([Changes - Field name] = "tags" AND CONTAINS([Changes - New value], "fix_deployed")) THEN "Permanent Fix Applied"
ELIF ([Changes - Field name] = "[Your Knowledge Article Linked Field]") THEN "Proposed Solution Drafted"
ELIF ([Changes - Field name] = "status" AND [Changes - New value] = "Solved") THEN "Resolution Verified"
ELIF ([Changes - Field name] = "status" AND [Changes - Previous value] = "Solved" AND [Changes - New value] = "Open") THEN "Problem Investigation Reopened"
ELIF ([Changes - Field name] = "[Your PIR Completed Checkbox Field]") THEN "Post-Implementation Review Conducted"
ELIF ([Changes - Field name] = "status" AND [Changes - New value] = "Closed") THEN "Problem Record Closed"
ELSE NULL
ENDIF

Etapas

Confirmação dos pré-requisitos: verifique se sua organização tem o complemento Zendesk Data Sharing habilitado. Confirme se você tem credenciais de acesso somente leitura ao banco de dados replicado do Zendesk, geralmente hospedado no Snowflake ou no Amazon Redshift.
Conecte-se ao banco de dados: use seu cliente SQL preferido, como DBeaver, DataGrip ou a interface web nativa do Snowflake/Redshift, para estabelecer uma conexão com seu data warehouse do Zendesk usando as credenciais fornecidas.
Identifique os campos personalizados: antes de executar a consulta, identifique os IDs exclusivos dos campos personalizados usados no seu processo de gerenciamento de problemas. No Zendesk, acesse Admin Center e vá para Objects and rules > Tickets > Fields. Encontre os campos 'Root Cause', 'Change Request ID', 'Workaround Published', 'Permanent Fix Applied' e 'Post-Implementation Review' para obter os IDs específicos de cada campo. Eles serão usados para substituir os marcadores na consulta.
Revise a consulta SQL: a consulta fornecida usa uma Common Table Expression (CTE) chamada ProblemTickets para primeiro selecionar e filtrar todos os registros de problemas. Isso melhora a performance e a legibilidade. Em seguida, a parte principal da consulta usa UNION ALL para combinar os resultados de 12 instruções SELECT separadas, uma para cada atividade necessária.
Personalize a consulta: abra um novo editor de consultas e cole o script SQL completo. Modifique os marcadores no script:
- Na CTE ProblemTickets, defina o intervalo de datas desejado substituindo '[YYYY-MM-DD]'.
- Para cada atividade que depende de um campo personalizado, substitua os IDs de exemplo, como [Your 'Root Cause Category' field_id] e [Your 'Change Request ID' field_id], pelos IDs reais identificados na etapa 3.
Execute a consulta: execute o script SQL modificado no banco de dados. O tempo de execução varia de acordo com o intervalo de datas e o volume de dados dos tickets.
Investigue a lógica de 'Proposed Solution Drafted': a consulta pressupõe que a elaboração de uma solução é registrada pelo preenchimento de um campo personalizado chamado [Your 'KB Article ID' field_id]. Se o seu processo for diferente, por exemplo, se usar uma tag ou um comentário específico, você precisará ajustar essa parte da consulta.
Valide os dados: quando a consulta for concluída, faça uma breve revisão dos resultados. Verifique se a quantidade de linhas é razoável, confirme se todas as colunas estão presentes e procure valores NULL inesperados em colunas críticas, como ProblemRecordId e EventTimestamp.
Exporte o Event Log: exporte todo o conjunto de resultados do seu cliente SQL para um arquivo CSV. Verifique se o arquivo usa codificação UTF-8 e se os cabeçalhos das colunas correspondem aos nomes dos atributos exigidos pela sua ferramenta de Process Mining.
Prepare o upload: antes de fazer o upload, verifique o arquivo CSV em busca de problemas de formatação. Confirme se os valores de data e hora na coluna EventTimestamp estão em um formato consistente, como YYYY-MM-DD HH24:MI:SS.

Configuração

Pré-requisitos: esta extração exige o complemento Zendesk Data Sharing e acesso SQL direto aos dados replicados em uma instância do Snowflake ou Amazon Redshift.
Filtro de tipo de ticket: a consulta está pré-configurada para analisar apenas tickets cujo type é 'problem'. Isso é essencial para isolar o processo de gerenciamento de problemas de incidentes e outros tipos de ticket.
Filtragem por intervalo de datas: é altamente recomendável filtrar os dados por um período específico para controlar a performance. A consulta inclui o marcador created_at >= '[YYYY-MM-DD]' na CTE inicial. Para uma primeira análise, um intervalo de 3 a 6 meses costuma ser adequado.
Configuração de campos personalizados: esta extração depende muito da configuração específica do seu Zendesk. Você precisa identificar e inserir o field_id correto dos campos personalizados que registram atividades como 'Root Cause Identified', 'Change Request Initiated' e 'Workaround Published'. A consulta falhará ou não retornará dados para essas atividades se os IDs de exemplo não forem substituídos.
Latência dos dados: os dados no banco replicado não são atualizados em tempo real. Normalmente, há um atraso de algumas horas entre a ocorrência de um evento no Zendesk e sua disponibilização no data warehouse. Tenha isso em mente ao analisar atividades muito recentes.

a Consulta de exemplo sql

WITH ProblemTickets AS (
  SELECT
    t.id,
    t.created_at,
    t.updated_at,
    t.priority,
    g.name AS group_name,
    u.name AS assignee_name,
    t.status,
    (SELECT COUNT(*) FROM problem_incident_links pil WHERE pil.problem_id = t.id) AS related_incident_count,
    t.due_at AS sla_due_date,
    cf_cat.value AS problem_category,
    cf_root.value AS root_cause_category
  FROM tickets t
  LEFT JOIN users u ON t.assignee_id = u.id
  LEFT JOIN groups g ON t.group_id = g.id
  LEFT JOIN custom_field_values cf_cat ON t.id = cf_cat.ticket_id AND cf_cat.custom_field_id = [Your 'Problem Category' field_id]
  LEFT JOIN custom_field_values cf_root ON t.id = cf_root.ticket_id AND cf_root.custom_field_id = [Your 'Root Cause Category' field_id]
  WHERE t.type = 'problem'
  AND t.created_at >= '[YYYY-MM-DD]' -- Set start date for the extraction
)
-- 1. Problem Record Logged
SELECT
  pt.id AS "ProblemRecordId",
  'Problem Record Logged' AS "ActivityName",
  pt.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  'new' AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ProblemTickets pt

UNION ALL

-- 2. Assigned to Support Group
SELECT
  pt.id AS "ProblemRecordId",
  'Assigned to Support Group' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  pt.status AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'group'

UNION ALL

-- 3. Investigation Commenced
SELECT
  pt.id AS "ProblemRecordId",
  'Investigation Commenced' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  'open' AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'status' AND tme.value = 'open' AND tme.previous_value = 'new'

UNION ALL

-- 4. Workaround Published
SELECT
  pt.id AS "ProblemRecordId",
  'Workaround Published' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  pt.status AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'custom_field' AND tme.field_name = '[Your ''Workaround Published'' custom field name]' AND tme.value IS NOT NULL -- Example: checkbox being checked or field being filled

UNION ALL

-- 5. Root Cause Identified
SELECT
  pt.id AS "ProblemRecordId",
  'Root Cause Identified' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  pt.status AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'custom_field' AND tme.field_name = '[Your ''Root Cause Category'' custom field name]' AND tme.value IS NOT NULL

UNION ALL

-- 6. Change Request Initiated
SELECT
  pt.id AS "ProblemRecordId",
  'Change Request Initiated' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  pt.status AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'custom_field' AND tme.field_name = '[Your ''Change Request ID'' custom field name]' AND tme.value IS NOT NULL

UNION ALL

-- 7. Permanent Fix Applied
SELECT
  pt.id AS "ProblemRecordId",
  'Permanent Fix Applied' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  pt.status AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'custom_field' AND tme.field_name = '[Your ''Permanent Fix Applied'' custom field name]' AND tme.value IS NOT NULL -- Assumes a custom field indicates this status

UNION ALL

-- 8. Proposed Solution Drafted
SELECT
  pt.id AS "ProblemRecordId",
  'Proposed Solution Drafted' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  pt.status AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'custom_field' AND tme.field_name = '[Your ''KB Article ID'' custom field name]' AND tme.value IS NOT NULL

UNION ALL

-- 9. Resolution Verified
SELECT
  pt.id AS "ProblemRecordId",
  'Resolution Verified' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  'solved' AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'status' AND tme.value = 'solved'

UNION ALL

-- 10. Problem Investigation Reopened
SELECT
  pt.id AS "ProblemRecordId",
  'Problem Investigation Reopened' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  'open' AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'status' AND tme.value = 'open' AND tme.previous_value IN ('pending', 'solved')

UNION ALL

-- 11. Post-Implementation Review Conducted
SELECT
  pt.id AS "ProblemRecordId",
  'Post-Implementation Review Conducted' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  pt.status AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'custom_field' AND tme.field_name = '[Your ''Post-Implementation Review'' custom field name]' AND tme.value IS NOT NULL -- Assumes a checkbox or date field

UNION ALL

-- 12. Problem Record Closed
SELECT
  pt.id AS "ProblemRecordId",
  'Problem Record Closed' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  'closed' AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'status' AND tme.value = 'closed' AND tme.previous_value = 'solved';

Etapas

Pré-requisitos: verifique se o Python 3.6 ou superior está instalado no seu sistema. Instale as bibliotecas requests e pandas necessárias executando pip install requests pandas no terminal ou no prompt de comando.
Gere um token da API do Zendesk: faça login no Zendesk Support como administrador. Acesse Central de administração > Aplicativos e integrações > APIs > API do Zendesk. Na seção Acesso por token, clique em 'Adicionar token de API' para criar um novo token. Copie esse token imediatamente e armazene-o com segurança, pois ele não será exibido novamente.
Configure o script Python: crie um novo arquivo Python, por exemplo, extract_zendesk_problems.py, e copie para ele o script completo fornecido na seção Query. Atualize as variáveis de espaço reservado no início do script: ZENDESK_SUBDOMAIN, ZENDESK_EMAIL, ZENDESK_API_TOKEN e START_TIME. Na execução inicial, defina START_TIME como o timestamp Unix da data de início desejada para a extração.
Mapeie os IDs dos campos personalizados: identifique os IDs numéricos dos campos personalizados usados no seu processo de Gerenciamento de Problemas. Você pode encontrá-los acessando Central de administração > Objetos e regras > Tickets > Campos e verificando a URL ou as propriedades do campo. Atualize o dicionário CUSTOM_FIELD_MAPPING no script com os IDs específicos da sua instância.
Execute o script: execute o script no terminal usando o comando python extract_zendesk_problems.py. O script começará a buscar dados na API de Exportação Incremental do Zendesk.
Monitore a execução: o script exibirá o andamento, incluindo o número de tickets processados e o timestamp atual que está sendo consultado. Ele tratará automaticamente os limites de requisições da API, fazendo pausas quando necessário.
Recuperação e transformação dos dados: primeiro, o script recupera todos os tickets de problema criados ou atualizados desde START_TIME. Em seguida, busca o histórico completo de auditoria de cada ticket de problema, contendo todas as alterações históricas.
Geração do Event Log: o script processa cada evento de auditoria, mapeando alterações de campos, como status, grupo ou campos personalizados, para as atividades de negócio definidas. Ele também busca e armazena em cache os nomes de usuários e grupos para enriquecer os dados.
Tratamento de cargas incrementais: após a carga inicial completa, atualize a variável START_TIME nas execuções seguintes com o end_time exibido ao final da execução anterior bem-sucedida. Assim, você buscará apenas dados novos e atualizados, sem duplicação.
Revise o resultado: quando o script for concluído, ele gerará um arquivo chamado zendesk_problem_event_log.csv no mesmo diretório. Esse arquivo CSV contém o Event Log estruturado, pronto para análise.
Prepare o upload: abra o arquivo CSV em uma ferramenta de planilhas para verificar o conteúdo. Confirme se todas as colunas obrigatórias (ProblemRecordId, ActivityName, EventTimestamp, SourceSystem, LastDataUpdate) estão presentes e preenchidas corretamente antes de fazer o upload para o ProcessMind.

Configuração

Credenciais da API do Zendesk: o script exige o subdomínio do Zendesk, o endereço de e-mail do usuário associado ao token da API e o próprio token da API para autenticação.
Hora de início: a variável START_TIME é um timestamp de época Unix que define o ponto inicial da extração de dados. Na primeira execução, defina-a como uma data no passado, por exemplo, 6 meses atrás, para obter dados históricos. Nas execuções seguintes, use a hora de término da execução anterior para buscar dados incrementalmente.
Mapeamento de campos personalizados: o dicionário CUSTOM_FIELD_MAPPING é essencial. Você precisa substituir os IDs de espaço reservado pelos IDs reais dos campos personalizados da sua instância do Zendesk para capturar corretamente atividades como 'Solução alternativa publicada' e 'Causa raiz identificada'.
Filtro por tipo de ticket: o script está configurado para processar apenas tickets cujo type seja 'problem'. Assim, incidentes, tarefas e perguntas ficam fora do Event Log de gerenciamento de problemas.
Limitação de requisições da API: o script inclui uma função básica time.sleep(60) para tratar erros 429 'Too Many Requests'. Talvez seja necessário ajustar essa pausa de acordo com o seu plano do Zendesk e o volume de dados extraído.
Pré-requisitos: é necessário ter um ambiente Python 3 com as bibliotecas requests e pandas para executar o script. O token da API deve estar associado a uma conta com permissão para ler dados de tickets.

a Consulta de exemplo python

import requests
import pandas as pd
import time
import json
from datetime import datetime

class=class="hl-string">"hl-comment"># --- CONFIGURATION --- 
class=class="hl-string">"hl-comment"># Replace with your Zendesk subdomain, email, and API token
ZENDESK_SUBDOMAIN = class="hl-string">'[your_subdomain]'
ZENDESK_EMAIL = class="hl-string">'[your_email@example.com]'
ZENDESK_API_TOKEN = class="hl-string">'[your_zendesk_api_token]'

class=class="hl-string">"hl-comment"># Start time for the incremental export (Unix epoch timestamp)
class=class="hl-string">"hl-comment"># Example: 1641013200 is for Jan 1, 2022 00:00:00 GMT
START_TIME = 1641013200

class=class="hl-string">"hl-comment"># Map your custom field IDs to the corresponding activity names
class=class="hl-string">"hl-comment"># Find IDs in Admin Center > Objects and rules > Tickets > Fields
CUSTOM_FIELD_MAPPING = {
    class="hl-string">'[Your Workaround Published Field ID]': class="hl-string">'Workaround Published',
    class="hl-string">'[Your Root Cause Identified Field ID]': class="hl-string">'Root Cause Identified',
    class="hl-string">'[Your Change Request Initiated Field ID]': class="hl-string">'Change Request Initiated',
    class="hl-string">'[Your Permanent Fix Applied Field ID]': class="hl-string">'Permanent Fix Applied',
    class="hl-string">'[Your Proposed Solution Drafted Field ID]': class="hl-string">'Proposed Solution Drafted',
    class="hl-string">'[Your Post-Implementation Review Field ID]': class="hl-string">'Post-Implementation Review Conducted'
}

class=class="hl-string">"hl-comment"># --- SCRIPT --- 
BASE_URL = fclass="hl-string">'https://{ZENDESK_SUBDOMAIN}.zendesk.com/api/v2'
API_USER = fclass="hl-string">'{ZENDESK_EMAIL}/token'

class=class="hl-string">"hl-comment"># Caching for user and group lookups to reduce API calls
user_cache = {}
group_cache = {}

session = requests.Session()
session.auth = (API_USER, ZENDESK_API_TOKEN)

def get_user_name(user_id):
    if not user_id: return None
    if user_id in user_cache:
        return user_cache[user_id]
    try:
        response = session.get(fclass="hl-string">'{BASE_URL}/users/{user_id}.json')
        response.raise_for_status()
        user_cache[user_id] = response.json()[class="hl-string">'user'][class="hl-string">'name']
        return user_cache[user_id]
    except requests.exceptions.RequestException:
        return str(user_id) class=class="hl-string">"hl-comment"># Return ID if lookup fails

def get_group_name(group_id):
    if not group_id: return None
    if group_id in group_cache:
        return group_cache[group_id]
    try:
        response = session.get(fclass="hl-string">'{BASE_URL}/groups/{group_id}.json')
        response.raise_for_status()
        group_cache[group_id] = response.json()[class="hl-string">'group'][class="hl-string">'name']
        return group_cache[group_id]
    except requests.exceptions.RequestException:
        return str(group_id) class=class="hl-string">"hl-comment"># Return ID if lookup fails

def fetch_tickets(start_time):
    tickets_url = fclass="hl-string">'{BASE_URL}/incremental/tickets.json'
    params = {class="hl-string">'start_time': start_time, class="hl-string">'include': class="hl-string">'metric_sets'}
    all_tickets = []
    while tickets_url:
        try:
            print(fclass="hl-string">"Fetching from: {tickets_url}")
            response = session.get(tickets_url, params=params)
            class=class="hl-string">"hl-comment"># params are only needed for the first request
            params = {}
            if response.status_code == 429:
                print(class="hl-string">"Rate limit reached. Waiting for 60 seconds.")
                time.sleep(60)
                continue
            response.raise_for_status()
            data = response.json()
            all_tickets.extend(data.get(class="hl-string">'tickets', []))
            tickets_url = data.get(class="hl-string">'next_page')
            if not data.get(class="hl-string">'end_of_stream', True):
                 class=class="hl-string">"hl-comment"># Wait a moment before the next page request to be safe
                 time.sleep(1)
            else:
                print(fclass="hl-string">"End of stream reached. Final timestamp: {data.get('end_time')}")
                tickets_url = None
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error fetching tickets: {e}")
            break
    return all_tickets

def process_ticket_audits(ticket, event_log):
    ticket_id = ticket[class="hl-string">'id']
    audits_url = fclass="hl-string">'{BASE_URL}/tickets/{ticket_id}/audits.json'
    try:
        response = session.get(audits_url)
        response.raise_for_status()
        audits = response.json().get(class="hl-string">'audits', [])
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Error fetching audits for ticket {ticket_id}: {e}")
        return

    base_attributes = {
        class="hl-string">'ProblemRecordId': ticket_id,
        class="hl-string">'SourceSystem': class="hl-string">'Zendesk Support',
        class="hl-string">'LastDataUpdate': ticket[class="hl-string">'updated_at'],
        class="hl-string">'Priority': ticket.get(class="hl-string">'priority'),
        class="hl-string">'RelatedIncidentCount': ticket.get(class="hl-string">'metric_set', {}).get(class="hl-string">'replies', 0), class=class="hl-string">"hl-comment"># Using replies as a proxy if incident_count is not available
        class="hl-string">'SlaDueDate': ticket.get(class="hl-string">'due_at'),
        class="hl-string">'ProblemCategory': next((f[class="hl-string">'value'] for f in ticket.get(class="hl-string">'custom_fields', []) if f.get(class="hl-string">'id') == class="hl-string">'[Your Problem Category Field ID]'), None)
    }

    class=class="hl-string">"hl-comment"># 1. Problem Record Logged
    event_log.append({
        **base_attributes,
        class="hl-string">'ActivityName': class="hl-string">'Problem Record Logged',
        class="hl-string">'EventTimestamp': ticket[class="hl-string">'created_at'],
        class="hl-string">'SupportGroup': get_group_name(ticket.get(class="hl-string">'group_id')),
        class="hl-string">'AssigneeName': get_user_name(ticket.get(class="hl-string">'assignee_id')),
        class="hl-string">'ProblemStatus': class="hl-string">'new',
        class="hl-string">'RootCauseCategory': None
    })

    class=class="hl-string">"hl-comment"># Process audit trail for other activities
    for audit in audits:
        audit_ts = audit[class="hl-string">'created_at']
        for event in audit.get(class="hl-string">'events', []):
            activity_name = None
            field_name = event.get(class="hl-string">'field_name')
            value = event.get(class="hl-string">'value')
            previous_value = event.get(class="hl-string">'previous_value')

            class=class="hl-string">"hl-comment"># 2. Assigned to Support Group
            if field_name == class="hl-string">'group_id' and value is not None:
                activity_name = class="hl-string">'Assigned to Support Group'
            
            class=class="hl-string">"hl-comment"># 3. Investigation Commenced (New -> Open)
            elif field_name == class="hl-string">'status' and value == class="hl-string">'open' and previous_value == class="hl-string">'new':
                activity_name = class="hl-string">'Investigation Commenced'

            class=class="hl-string">"hl-comment"># 4-9. Activities from Custom Fields
            elif str(field_name) in CUSTOM_FIELD_MAPPING and value is not None and value not in [False, class="hl-string">'0', class="hl-string">'']:
                activity_name = CUSTOM_FIELD_MAPPING[str(field_name)]

            class=class="hl-string">"hl-comment"># 10. Resolution Verified (Any -> Solved)
            elif field_name == class="hl-string">'status' and value == class="hl-string">'solved':
                activity_name = class="hl-string">'Resolution Verified'
            
            class=class="hl-string">"hl-comment"># 11. Problem Investigation Reopened (Solved/Closed -> Open)
            elif field_name == class="hl-string">'status' and value == class="hl-string">'open' and previous_value in [class="hl-string">'solved', class="hl-string">'closed']:
                activity_name = class="hl-string">'Problem Investigation Reopened'

            class=class="hl-string">"hl-comment"># 12. Problem Record Closed (Any -> Closed)
            elif field_name == class="hl-string">'status' and value == class="hl-string">'closed':
                activity_name = class="hl-string">'Problem Record Closed'

            if activity_name:
                class=class="hl-string">"hl-comment"># Find the state of attributes at the time of the event
                temp_status = value if field_name == class="hl-string">'status' else None
                temp_group = get_group_name(value) if field_name == class="hl-string">'group_id' else None
                temp_assignee = get_user_name(value) if field_name == class="hl-string">'assignee_id' else None
                temp_root_cause = value if str(field_name) == class="hl-string">'[Your Root Cause Category Field ID]' else None

                event_log.append({
                    **base_attributes,
                    class="hl-string">'ActivityName': activity_name,
                    class="hl-string">'EventTimestamp': audit_ts,
                    class="hl-string">'SupportGroup': temp_group,
                    class="hl-string">'AssigneeName': temp_assignee,
                    class="hl-string">'ProblemStatus': temp_status,
                    class="hl-string">'RootCauseCategory': temp_root_cause
                })

def main():
    print(class="hl-string">"Starting Zendesk Problem ticket extraction...")
    tickets = fetch_tickets(START_TIME)
    problem_tickets = [t for t in tickets if t.get(class="hl-string">'type') == class="hl-string">'problem']
    print(fclass="hl-string">"Found {len(problem_tickets)} problem tickets to process.")

    event_log_data = []
    for i, ticket in enumerate(problem_tickets):
        print(fclass="hl-string">"Processing ticket {i+1}/{len(problem_tickets)}: ID {ticket['id']}")
        process_ticket_audits(ticket, event_log_data)

    if not event_log_data:
        print(class="hl-string">"No events were generated. Exiting.")
        return

    df = pd.DataFrame(event_log_data)

    class=class="hl-string">"hl-comment"># Post-processing to fill forward null values for state attributes
    df = df.sort_values(by=[class="hl-string">'ProblemRecordId', class="hl-string">'EventTimestamp']).reset_index(drop=True)
    df[class="hl-string">'SupportGroup'] = df.groupby(class="hl-string">'ProblemRecordId')[class="hl-string">'SupportGroup'].fillna(method=class="hl-string">'ffill')
    df[class="hl-string">'AssigneeName'] = df.groupby(class="hl-string">'ProblemRecordId')[class="hl-string">'AssigneeName'].fillna(method=class="hl-string">'ffill')
    df[class="hl-string">'ProblemStatus'] = df.groupby(class="hl-string">'ProblemRecordId')[class="hl-string">'ProblemStatus'].fillna(method=class="hl-string">'ffill')
    df[class="hl-string">'RootCauseCategory'] = df.groupby(class="hl-string">'ProblemRecordId')[class="hl-string">'RootCauseCategory'].fillna(method=class="hl-string">'ffill')

    class=class="hl-string">"hl-comment"># Define column order
    column_order = [
        class="hl-string">'ProblemRecordId', class="hl-string">'ActivityName', class="hl-string">'EventTimestamp', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate',
        class="hl-string">'Priority', class="hl-string">'SupportGroup', class="hl-string">'AssigneeName', class="hl-string">'ProblemStatus', class="hl-string">'RelatedIncidentCount',
        class="hl-string">'SlaDueDate', class="hl-string">'ProblemCategory', class="hl-string">'RootCauseCategory'
    ]
    df = df[column_order]

    output_filename = class="hl-string">'zendesk_problem_event_log.csv'
    df.to_csv(output_filename, index=False, date_format=class="hl-string">'%Y-%m-%dT%H:%M:%SZ')
    print(fclass="hl-string">"Extraction complete. Event log saved to {output_filename}")

if __name__ == class="hl-string">'__main__':
    main()

Pronto para começar?

Transforme a estabilidade da sua TI aplicando este Template hoje ao seu ambiente Zendesk. Nossa equipe está disponível para ajudar você a aprimorar a extração dos dados e iniciar sua jornada de Process Mining.

Voltar ao guia de melhoria Baixar Template

Otimize seu gerenciamento de problemas para corrigir falhas de TI mais rapidamente

Reduza os ciclos de resolução em 30% e corrija os gargalos de TI.

Comece seu teste grátis

Não é necessário cartão de crédito. Configure em poucos minutos.

Seu Template de dados de gerenciamento de problemas

Seu Template de dados de gerenciamento de problemas

Atributos do gerenciamento de problemas

Atividades de gerenciamento de problemas

Guias de extração

Exportação do histórico de atualizações do Zendesk Explore

Etapas

Configuração

a Consulta de exemplo config

Consulta SQL via Zendesk Data Sharing

Etapas

Configuração

a Consulta de exemplo sql

Extração em Python usando a API de Exportação Incremental

Etapas

Configuração

a Consulta de exemplo python

Pronto para começar?

Otimize seu gerenciamento de problemas para corrigir falhas de TI mais rapidamente

Seu Template de dados de gerenciamento de problemas

Seu Template de dados de gerenciamento de problemas

Atributos do gerenciamento de problemas

Atividades de gerenciamento de problemas

Guias de extração

Exportação do histórico de atualizações do Zendesk Explore

Etapas

Configuração

a Consulta de exemplo config

Consulta SQL via Zendesk Data Sharing

Etapas

Configuração

a Consulta de exemplo sql

Extração em Python usando a API de Exportação Incremental

Etapas

Configuração

a Consulta de exemplo python

Pronto para começar?

Otimize seu gerenciamento de problemas para corrigir falhas de TI mais rapidamente

Valorizamos sua privacidade