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

Seu Template de dados de gestão de problemas

Zendesk Support

Atributos de Gestão de Problemas(19) Atividades de Gestão de Problemas(12) Guias de extração(3)

Seu Template de dados de gestão de problemas

Este Template oferece uma estrutura completa para mapear o ciclo de vida da gestão 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. Com essa estrutura, você pode criar um Event Log de alta qualidade e obter insights mais detalhados 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

Novidade em Event Logs? Saiba como criar um Event Log para Process Mining.

Baixar Template

Atributos de Gestão de Problemas

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

5 Obrigatório 8 Recomendado 6 Opcional

	Nome	Descrição
	Atividade ActivityName	Nome do evento ou da ação realizada no registro do problema.
Descrição Este atributo registra a etapa ou ação específica realizada durante o ciclo de vida do registro do problema. Alguns exemplos são mudanças de status, como 'Aberto' para 'Pendente', mudanças de atribuição ou etapas específicas do Workflow, como 'Solução paliativa publicada'. Na análise, as atividades formam os nós do mapa de processo. A sequência delas permite que analistas visualizem o fluxo de trabalho, identifiquem gargalos e meçam o tempo entre etapas específicas do processo. Por que isso importa Define o 'que' acontece no processo, permitindo visualizar o fluxo do processo e analisar variantes. Onde encontrar Derivado de auditorias de chamados ou métricas de chamados do Zendesk Exemplos Registro do problema criadoInvestigação iniciadaSolução paliativa publicada
	Hora de início EventTimestamp	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 ordenar os eventos corretamente e calcular a duração entre etapas. Na análise, é essencial para calcular tempos de ciclo, identificar atrasos, verificar o cumprimento do SLA e visualizar o processo ao longo do tempo. Sem registros precisos de data e hora, não é possível entender a velocidade do processo de resolução de problemas. Por que isso importa Permite ordenar as atividades e calcular todos os KPIs baseados em tempo. Onde encontrar Auditorias de chamados do Zendesk, campo 'created_at' Exemplos 2023-10-12T08:30:00Z2023-10-12T09:15:22Z
	Registro do problema ProblemRecordId	Identificador numérico exclusivo atribuído ao chamado de problema no Zendesk.
Descrição Este atributo representa a chave exclusiva do registro do problema no Zendesk Support. Ele funciona como o ID do caso central 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 identifica cada investigação de problema, da criação ao 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 encontrar Objeto Ticket do Zendesk, campo 'id' quando o tipo é 'problem' Exemplos 1045293849921
	Sistema de origem SourceSystem	Nome do sistema de onde os dados vieram.
Descrição Este atributo identifica a plataforma de software da qual os dados do processo foram extraídos. Neste contexto, ele será preenchido sempre com 'Zendesk Support'. Na análise, especialmente ao combinar dados de vários sistemas, como Zendesk e Jira, esse campo permite que analistas filtrem ou agrupem os dados pela origem. Ele garante a linhagem e a rastreabilidade dos dados em visualizações de processos que abrangem vários sistemas. Por que isso importa Garante a linhagem dos dados e dá suporte a configurações de Process Mining com vários sistemas. Onde encontrar Definido durante a extração Exemplos Zendesk Support
	Última atualização dos dados LastDataUpdate	Registro de data e hora que indica quando o registro do problema foi modificado pela última vez.
Descrição Este atributo indica quando os dados do registro do problema foram atualizados pela última vez no sistema de origem. Ele é diferente do registro de data e hora do evento, pois se refere ao registro, e não à atividade. Na análise, ajuda a determinar se os dados estão atualizados. Também permite 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 Acompanha a atualização dos dados e ajuda a definir estratégias de carregamento incremental. Onde encontrar Objeto Ticket do Zendesk, 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 Este atributo registra o diagnóstico final da causa do problema. Geralmente, ele é preenchido durante a atividade "Causa raiz identificada". Na análise, é usado para gerar o relatório de precisão da categorização de problemas e analisar tendências nas falhas do sistema. Ajuda a gestão a entender se deve priorizar a qualidade do código, a estabilidade da infraestrutura ou a gestão de fornecedores. Por que isso importa Permite analisar padrões de falha e direcionar iniciativas de melhoria de longo prazo. Onde encontrar Campos personalizados de tickets do Zendesk Exemplos Bug de softwareErro de configuraçãoErro do usuário
	Categoria do problema ProblemCategory	Classificação do problema (por exemplo, software, hardware ou rede).
Descrição Este atributo categoriza o problema com base no serviço ou na tecnologia afetada. Normalmente, é um campo suspenso personalizado nos formulários do Zendesk. Na análise, ele é usado no Dashboard de precisão da categorização de problemas. Comparar a categoria inicial com a causa raiz identificada ajuda a verificar se a triagem inicial encaminha os problemas para as equipes certas. Por que isso importa Permite segmentar os dados por tecnologia ou serviço de negócios. Onde encontrar Campos personalizados de tickets do Zendesk Exemplos Banco de dadosInterface e experiência do usuárioInfraestrutura de rede
	Contagem de incidentes relacionados RelatedIncidentCount	Número de chamados de incidente vinculados a este registro do problema.
Descrição Este atributo conta quantos chamados de incidente estão associados a este registro do problema. No Zendesk, essa associação é feita pelo campo 'problem_id' dos chamados de incidente, que aponta para este registro. Na análise, é a principal métrica de correlação e impacto de incidentes. Ajuda a priorizar problemas que afetam o maior número de usuários e orienta decisões estratégicas sobre quais correções podem gerar o maior retorno sobre o investimento ao reduzir o volume de chamados. Por que isso importa Indica a dimensão do problema e seu impacto nos usuários. Onde encontrar API de chamados do Zendesk: contagem de chamados em que type='incident' e problem_id=ThisID Exemplos 015342
	Data limite do SLA SlaDueDate	Data e hora limite para a resolução do problema.
Descrição Este atributo representa o prazo de resolução definido pela configuração do Acordo de Nível de Serviço. Geralmente, ele é calculado com base na prioridade e no horário de criação do chamado. Na análise, é comparado com o tempo real de resolução para calcular a taxa de cumprimento do SLA de problemas. Ele alimenta o Dashboard de performance e risco do SLA, destacando casos que estão perto de ultrapassar o prazo ou já o ultrapassaram. Por que isso importa É essencial para medir a Conformidade e a performance contratual. Onde encontrar Endpoint de métricas de tickets ou políticas de SLA do Zendesk Exemplos 2023-12-01T17:00:00Z
	Grupo de suporte SupportGroup	Equipe ou departamento atualmente responsável pelo registro do problema.
Descrição Este atributo identifica o grupo específico de agentes responsável pelo problema em determinado momento. Ele muda quando o chamado é transferido de uma equipe para outra. Na análise, é essencial para o Dashboard de análise de transferências entre grupos de suporte. Permite medir a performance por equipe, identificar gargalos nas transferências e analisar a distribuição da carga de trabalho entre os recursos. Por que isso importa Permite analisar a organização e identificar gargalos entre departamentos. Onde encontrar Objeto Ticket do Zendesk, campo 'group_id' (resolvido para o nome) Exemplos Suporte de nível 2Equipe de banco de dadosOperações de rede
	Nome do responsável AssigneeName	Agente específico responsável por trabalhar no problema.
Descrição Este atributo contém o nome da pessoa atualmente responsável pelo registro do problema. Ele permite identificar com mais precisão quem realizou cada ação. Na análise, ajuda a entender a carga de trabalho e a performance individuais. Embora seja comum analisar os dados por grupo, os dados por responsável podem revelar necessidades de treinamento ou destacar pessoas particularmente eficazes na resolução de causas raiz complexas. Por que isso importa Permite analisar os recursos no nível individual. Onde encontrar Objeto Ticket do Zendesk, campo 'assignee_id' (resolvido para o nome) Exemplos João da SilvaMaria SouzaSistema
	Prioridade Priority	Nível de urgência atribuído ao registro do problema.
Descrição Este atributo indica a importância relativa do problema, geralmente classificada como Baixa, Normal, Alta ou Urgente. Ele orienta os acordos de nível de serviço (SLAs) 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 sendo resolvidos mais rapidamente do que os de prioridade 'Baixa', conforme esperado pelo Dashboard de velocidade da investigação da causa raiz. Por que isso importa É essencial para segmentar casos e analisar o cumprimento do SLA e a priorização de recursos. Onde encontrar Objeto Ticket do Zendesk, campo 'priority' Exemplos UrgenteAltaNormalBaixa
	Status do problema ProblemStatus	Estado atual do registro do problema no ciclo de vida.
Descrição Este atributo mostra o status atual do problema, como Novo, Aberto, Pendente, Resolvido ou Fechado. Ele reflete o andamento da investigação. Na análise, é usado para filtrar casos abertos ou fechados. É essencial para o Dashboard de monitoramento de registros de problemas parados, que identifica casos ativos que não estão avançando pelo ciclo de status esperado. Por que isso importa Permite filtrar casos pelo estado de conclusão. Onde encontrar Objeto Ticket do Zendesk, campo 'status' Exemplos novoabertopendenteresolvidofechado
	Assunto do problema ProblemSubject	Resumo curto ou título do registro do problema.
Descrição Este atributo contém o resumo em texto inserido quando o problema foi criado. Geralmente, ele descreve o sintoma ou a questão investigada. Na análise, oferece contexto aos analistas ao aprofundarem a análise de casos específicos. Também é possível aplicar técnicas de mineração de texto para agrupar problemas semelhantes ou identificar tópicos recorrentes que não aparecem nos campos estruturados de categoria. Por que isso importa Oferece contexto legível para cada caso. Onde encontrar Objeto Ticket do Zendesk, 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
	ID da solicitação de mudança ChangeRequestId	O identificador da solicitação de mudança vinculada à implementação da correção.
Descrição Este atributo vincula o registro do problema a um registro de gestão de mudanças, possivelmente em outro sistema ou em outro tipo de ticket. Isso indica que um processo formal de mudança foi iniciado. Na análise, ele dá suporte ao Dashboard de taxa de abertura de solicitações de mudança. Ajuda a acompanhar a passagem do diagnóstico para a implementação e a garantir que as causas raiz identificadas resultem em ações formais de mudança. Por que isso importa Vincula o processo de gestão de problemas ao processo de gestão de mudanças. Onde encontrar 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 Este atributo armazena a referência a um artigo do Zendesk Guide ou a outro conteúdo externo de conhecimento. Ele indica que o conhecimento obtido com o problema foi registrado. Na análise, a presença deste campo é usada para calcular a taxa de integração da base de conhecimento. Isso verifica se a organização está fechando o ciclo de aprendizado ao documentar soluções para consulta futura. Por que isso importa Mede a eficácia dos processos de gestão do conhecimento. Onde encontrar Campos personalizados de tickets do Zendesk ou conteúdo vinculado Exemplos 360045889KB-2991
	Sem atividade recente IsStale	Indica se o problema ficou sem atividade por mais de 14 dias.
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 a data e hora da última atividade. Na análise, ele alimenta o Dashboard de monitoramento de registros de problemas sem atividade recente. Ajuda os gestores a identificar rapidamente casos esquecidos que aumentam o backlog e podem precisar ser encerrados administrativamente ou reatribuídos. Por que isso importa Ajuda a identificar desperdícios no processo e itens de trabalho esquecidos. Onde encontrar Calculado na ferramenta de Process Mining: (Agora - Última atualização dos dados) > 14 dias Exemplos truefalse
	Solução alternativa ativa WorkaroundActive	Indica se uma solução alternativa foi fornecida ou publicada.
Descrição Este atributo booleano indica se uma correção temporária foi documentada para o problema. Muitas vezes, ele é derivado da presença da atividade "Solução alternativa publicada" ou de uma caixa de seleção específica no formulário. Na análise, é usado no Dashboard de conformidade da publicação de soluções alternativas. 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 isso importa É essencial para medir a redução do impacto sobre os usuários durante as investigações. Onde encontrar Derivado da presença da atividade "Solução alternativa publicada" ou de um campo personalizado Exemplos truefalse
	Tem revisão pós-implementação 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, dá suporte ao Dashboard de cobertura de revisões pós-implementação. É uma métrica de conformidade que verifica se a organização está aprendendo com os problemas mais importantes. Por que isso importa Verifica a conformidade com os processos de melhoria contínua. Onde encontrar Derivado da presença da atividade "Revisão pós-implementação realizada" Exemplos truefalse

Obrigatório Recomendado Opcional

Atividades de Gestão 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 de uma solução permanente.

8 Recomendado 4 Opcional

	Atividade	Descrição
	Atribuído ao grupo de suporte	Encaminhamento do registro do problema para uma equipe técnica ou departamento específico. Esse evento é acompanhado quando o campo Group ID do chamado é atualizado.
Por que isso importa Essencial para o Dashboard de análise de transferências entre grupos de suporte, que mede o tempo de espera entre departamentos. Onde encontrar Monitore as mudanças no campo 'group_id' do registro de auditoria do chamado. Coleta Registrado quando a transação Group Assignment Change é executada Tipo de evento explicit
	Causa raiz identificada	Momento em que a causa subjacente do problema é determinada. Isso costuma ser registrado quando o agente preenche um campo de texto personalizado 'Root Cause' ou uma categoria em uma lista suspensa.
Por que isso importa Marco essencial para o Dashboard de velocidade da investigação da causa raiz e para medir a eficiência do diagnóstico. Onde encontrar Monitore alterações nos campos personalizados chamados 'Root Cause', 'RCA' ou 'Problem Source' para identificar valores preenchidos. Coleta Compare os valores dos campos personalizados para verificar o preenchimento Tipo de evento inferred
	Correção definitiva aplicada	Indica que a solução técnica foi implantada no ambiente. Isso geralmente é acompanhado por uma mudança de status personalizada ou por uma tag específica antes de o chamado ser totalmente resolvido.
Por que isso importa Essencial para o Dashboard de eficiência da implementação de correções, que mede o tempo entre o diagnóstico e a implantação. Onde encontrar Inferido a partir de uma tag específica, como 'fix_deployed', ou de um campo de status personalizado, se houver. Coleta Monitore tags ou listas suspensas de status personalizadas Tipo de evento inferred
	Investigação iniciada	Marca a passagem do estado passivo 'Novo' para um estado de trabalho ativo. Isso indica que um agente reconheceu o problema e começou o diagnóstico.
Por que isso importa Usado para calcular as métricas de registros de problemas parados e marca o início do KPI de duração média da análise de causa raiz. Onde encontrar Inferido quando o status do chamado muda de 'Novo' para 'Aberto' ou 'Pendente'. Coleta Compare o campo de status antes e depois Tipo de evento inferred
	Registro do problema criado	Criação inicial do chamado de problema no Zendesk Support. Esse evento registra o timestamp em que o problema foi incluído no sistema pela primeira vez e geralmente inicia 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 de referência para todas as métricas subsequentes de tempo de atravessamento. Onde encontrar Derivado do timestamp 'created_at' no objeto do chamado ou da primeira entrada no registro de auditoria do chamado. Coleta Registrado quando a transação Ticket Created é executada Tipo de evento explicit
	Registro do problema fechado	Evento final do ciclo de vida, quando o chamado é bloqueado e não pode mais ser alterado. No Zendesk, isso geralmente acontece automaticamente 4 dias após o estado Resolvido.
Por que isso importa Marca o fim definitivo do ciclo de vida do registro e é usado para retenção de dados e relatórios históricos. Onde encontrar Derivado da mudança do status do chamado para 'Fechado'. Coleta Registrado quando o status muda para Fechado Tipo de evento explicit
	Resolução verificada	Registro 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 foi concluído.
Por que isso importa Principal ponto final para os cálculos de performance e risco do SLA e para a taxa de cumprimento do SLA de problemas. Onde encontrar Derivado da mudança do status do chamado para 'Resolvido'. Coleta Registrado quando o status muda para Resolvido Tipo de evento explicit
	Solução paliativa publicada	Ação de documentar e compartilhar uma correção temporária para o problema. No Zendesk, isso costuma ser registrado por uma tag específica ou por um campo de seleção personalizado que indica a disponibilidade de uma solução paliativa.
Por que isso importa Dá suporte ao Dashboard de conformidade da publicação de soluções paliativas, ajudando a garantir que os usuários recebam um alívio temporário durante investigações longas. Onde encontrar Monitore a inclusão da tag 'workaround_published' ou a alteração de um campo booleano personalizado chamado 'Workaround'. Coleta Compare os valores do campo personalizado ou da tag Tipo de evento inferred
	Investigação do problema reaberta	Ocorre quando um registro de problema marcado anteriormente como Resolvido volta ao estado Aberto ou a um estado ativo. Isso indica que a correção falhou ou que a resolução foi rejeitada.
Por que isso importa Dá suporte ao KPI de taxa de reabertura de problemas e ajuda a identificar falhas de qualidade no processo de resolução. Onde encontrar Inferido quando o status muda de 'Resolvido' para 'Aberto', 'Novo' ou 'Pendente'. Coleta Compare o campo de status antes e depois Tipo de evento inferred
	Rascunho da solução proposta criado	Criação de um artigo na base de conhecimento com base na investigação do problema. Isso é inferido pelo uso do aplicativo Zendesk Knowledge Capture ou pela vinculação de um novo artigo.
Por que isso importa Dá suporte ao KPI de taxa de integração com a base de conhecimento e ajuda a promover o aprendizado organizacional. Onde encontrar Monitore eventos relacionados à integração 'Knowledge Capture' ou tags como 'kcs_draft'. Coleta Derive a informação de tags específicas do sistema ou de eventos de vinculação Tipo de evento inferred
	Revisão pós-implementação realizada	Confirmação de que uma revisão retrospectiva foi concluída após a correção. Normalmente, o coordenador do processo atualiza uma caixa de seleção ou um campo de data.
Por que isso importa Necessário para o KPI de frequência de revisões pós-implementação e para garantir a Conformidade com os padrões de qualidade. Onde encontrar Monitore atualizações na caixa de seleção personalizada 'PIR Completed' ou no campo de data 'PIR Date'. Coleta Monitore o campo personalizado para confirmar a conclusão Tipo de evento inferred
	Solicitação de mudança iniciada	Indica que um processo formal de gestão de mudanças foi iniciado para corrigir o problema. Isso costuma ser inferido quando um campo personalizado 'Change Request ID' é preenchido ou quando um chamado 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 encontrar Monitore atualizações em um campo personalizado, como 'change_reference', ou a criação de um link do tipo 'problem_change'. Coleta Monitore o campo personalizado para identificar a inclusão de um ID externo Tipo de evento inferred

Recomendado Opcional

Guias de extração

Como obter seus dados do Zendesk Support

Etapas

Acesse sua instância do Zendesk e abra 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 solicitado a escolher um conjunto de dados, selecione Support, depois Updates History e, por fim, Support: Updates History [default]. Esse conjunto de dados contém os registros de eventos necessários para Process Mining, e não 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 limitar o conjunto de dados ao processo de Gestão de Problemas.
No painel Rows, adicione os seguintes atributos nesta ordem para definir a estrutura do registro de eventos: Ticket > Ticket ID, Time - Timestamp > Update - Timestamp, Updater > Updater name e Changes > Changes - Field name.
Para criar a coluna Activity Name, crie um Standard Calculated Attribute. Clique no ícone Calculation na barra lateral direita, selecione Standard calculated attribute, dê o nome Activity Mapper e cole o código fornecido na seção Query abaixo.
Adicione o 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 os campos personalizados necessários para a análise de causa raiz ou de categorias, como Ticket > Ticket tags ou campos personalizados específicos.
No painel Filters, defina o período usando Time - Timestamp > Update - Date para abranger o intervalo desejado para a análise, como Last 6 Months.
Clique no ícone Visualization type e selecione Table. Se a opção estiver disponível, deixe a tabela sem pivotamento ou em formato simples. Caso contrário, confirme que todos os atributos estão na seção Rows.
Exporte o resultado clicando em Export > CSV. Marque a opção Keep attribute formatting para preservar os formatos de data e hora usados pelo ProcessMind.

Configuração

Conjunto de dados: Support: Updates History (Importante: não use o conjunto de dados padrão Tickets, pois ele mostra apenas o estado atual).
Filtro de data e hora: Update - Date (Recomendação: últimos 90 a 180 dias, conforme o volume).
Tipo de chamado: Filtre apenas por Problem para não misturar incidentes e solicitações de serviço.
Limite de linhas: As exportações do Zendesk Explore costumam ter um limite de 50.000 linhas. Se o conjunto de dados ultrapassar esse limite, use o filtro Update - Date para exportar períodos mensais menores e depois combine os arquivos externamente.
Campos personalizados: Identifique os IDs dos campos de causa raiz, solicitação de mudança e solução alternativa 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.

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

Confirme os pré-requisitos: Verifique se o complemento Zendesk Data Sharing está habilitado na sua organização. Confirme também que 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 o cliente SQL de sua preferência, como DBeaver, DataGrip ou a interface web nativa do Snowflake/Redshift, para se conectar ao data warehouse do Zendesk com as credenciais fornecidas.
Identifique os campos personalizados: Antes de executar a consulta, identifique os IDs exclusivos dos campos personalizados usados no processo de Gestão de Problemas. No Zendesk, acesse Admin Center e vá para Objects and rules > Tickets > Fields. Localize os campos 'Root Cause', 'Change Request ID', 'Workaround Published', 'Permanent Fix Applied' e 'Post-Implementation Review' para obter os respectivos IDs. Você usará esses IDs no lugar dos marcadores da consulta.
Revise a consulta SQL: A consulta fornecida usa uma expressão de tabela comum (CTE) chamada ProblemTickets para selecionar e filtrar primeiro todos os registros de problemas. Isso melhora o desempenho e a legibilidade. Em seguida, a consulta principal 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. Altere os marcadores no script:
- Na CTE ProblemTickets, defina o período 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: Rode o script SQL alterado no banco de dados. O tempo de execução varia conforme o período e o volume de dados dos chamados.
Verifique a lógica de 'Proposed Solution Drafted': A consulta pressupõe que a elaboração de uma solução é registrada no campo personalizado [Your 'KB Article ID' field_id]. Se o seu processo for diferente, por exemplo, se usar uma tag ou um comentário específico, ajuste essa parte da consulta.
Valide os dados: Quando a consulta terminar, faça uma revisão rápida dos resultados. Confira se há uma quantidade razoável de linhas, se todas as colunas estão presentes e se existem valores NULL inesperados em colunas importantes, como ProblemRecordId e EventTimestamp.
Exporte o registro de eventos: Exporte todo o conjunto de resultados do cliente SQL para um arquivo CSV. Use a codificação UTF-8 e confirme que os cabeçalhos das colunas correspondem aos nomes de atributos exigidos pela ferramenta de Process Mining.
Prepare o arquivo para carregamento: Antes de carregar o arquivo, verifique se o CSV tem problemas de formatação. Confirme que os valores de data e hora na coluna EventTimestamp seguem 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 do Amazon Redshift.
Filtro de tipo de chamado: A consulta está configurada para analisar apenas chamados cujo type seja 'problem'. Isso é essencial para separar o processo de Gestão de Problemas dos incidentes e de outros tipos de chamado.
Filtro de período: Recomendamos filtrar os dados por um período específico para controlar o desempenho. A consulta inclui o marcador created_at >= '[YYYY-MM-DD]' na CTE inicial. Para uma primeira análise, um período de 3 a 6 meses costuma ser adequado.
Configuração de campos personalizados: Esta extração depende bastante da configuração específica do seu Zendesk. Identifique e informe o field_id correto dos campos personalizados que registram atividades como 'Root Cause Identified', 'Change Request Initiated' e 'Workaround Published'. Se os IDs de exemplo não forem substituídos, a consulta poderá falhar ou não retornar dados para essas atividades.
Latência dos dados: Os dados do banco replicado não são atualizados em tempo real. Em geral, há um atraso de algumas horas entre a ocorrência de um evento no Zendesk e sua inclusão no data warehouse. Considere esse intervalo ao analisar atividades muito recentes.

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: Confirme que o Python 3.6 ou superior está instalado no seu sistema. Instale as bibliotecas necessárias, requests e pandas, executando pip install requests pandas no terminal ou no prompt de comando.
Gere um token da API do Zendesk: Acesse o Zendesk Support como administrador. Vá para Admin Center > Apps and integrations > APIs > Zendesk API. Na seção Token Access, clique em 'Add API token' para criar um token. Copie-o imediatamente e guarde-o em um local seguro, pois ele não será exibido novamente.
Configure o script Python: Crie um arquivo Python, como extract_zendesk_problems.py, e copie nele o script completo fornecido na seção Query. Atualize as variáveis de exemplo no início do script: ZENDESK_SUBDOMAIN, ZENDESK_EMAIL, ZENDESK_API_TOKEN e START_TIME. Na primeira execução, defina START_TIME como o timestamp Unix da data inicial desejada para a extração.
Associe os IDs dos campos personalizados: Identifique os IDs numéricos dos campos personalizados usados no processo de Gestão de Problemas. Para encontrá-los, acesse Admin Center > Objects and rules > Tickets > Fields e confira o URL ou as propriedades dos campos. Atualize o dicionário CUSTOM_FIELD_MAPPING no script com os IDs da sua instância.
Execute o script: Rode o script no terminal com o comando python extract_zendesk_problems.py. Ele começará a buscar dados na API Zendesk Incremental Export.
Acompanhe a execução: O script exibirá o andamento, incluindo o número de chamados processados e o timestamp dos dados que está buscando. Ele também respeitará automaticamente os limites de requisições da API, fazendo pausas quando necessário.
Recupere e transforme os dados: Primeiro, o script recupera todos os chamados de problema criados ou atualizados desde START_TIME. Depois, busca o histórico completo de auditoria de cada chamado, que contém todas as alterações anteriores.
Gere o registro de eventos: O script processa cada evento de auditoria e associa as alterações de campos, como status, grupo ou campos personalizados, às atividades de negócio definidas. Também busca e armazena em cache os nomes de usuários e grupos para enriquecer os dados.
Faça carregamentos incrementais: Após o carregamento inicial completo, atualize a variável START_TIME nas execuções seguintes com o valor de end_time exibido ao final da execução anterior bem-sucedida. Assim, você carrega apenas dados novos e atualizados, sem duplicações.
Revise o resultado: Quando o script terminar, ele criará o arquivo zendesk_problem_event_log.csv no mesmo diretório. Esse arquivo CSV contém o registro de eventos estruturado e pronto para análise.
Prepare o arquivo para carregamento: Abra o CSV em uma ferramenta de planilhas e confira o conteúdo. Antes de carregar os dados no ProcessMind, confirme que todas as colunas necessárias (ProblemRecordId, ActivityName, EventTimestamp, SourceSystem, LastDataUpdate) estão presentes e preenchidas corretamente.

Configuração

Credenciais da API do Zendesk: Para autenticação, o script precisa do subdomínio do Zendesk, do endereço de e-mail do usuário associado ao token da API e do próprio token.
Hora de início: A variável START_TIME é um timestamp Unix que define o início da extração de dados. Na primeira execução, defina uma data passada, como seis meses atrás, para obter dados históricos. Nas execuções seguintes, use a hora final da execução anterior para buscar os dados de forma incremental.
Mapeamento de campos personalizados: O dicionário CUSTOM_FIELD_MAPPING é essencial. Atualize os IDs de exemplo com os IDs reais dos campos personalizados da sua instância do Zendesk para registrar corretamente atividades como 'Workaround Published' e 'Root Cause Identified'.
Filtro de tipo de chamado: O script está configurado para processar apenas chamados cujo type seja 'problem'. Assim, incidentes, tarefas e dúvidas ficam fora do registro de eventos de Gestão de Problemas.
Limite de requisições da API: O script inclui uma função básica time.sleep(60) para lidar com erros 429 'Too Many Requests'. Talvez seja necessário ajustar a duração da pausa conforme seu plano do Zendesk e o volume de dados extraídos.
Pré-requisitos: Para executar o script, é necessário ter um ambiente Python 3 com as bibliotecas requests e pandas. O token da API deve estar associado a uma conta com permissão para ler os dados dos chamados.

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 de TI aplicando este Template ao seu ambiente Zendesk. Nossa equipe pode ajudar você a ajustar a extração de dados e dar os primeiros passos com Process Mining.

Voltar ao guia de melhoria

Baixar Template

Otimize a Gestão de Problemas para corrigir falhas de TI mais rápido

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

Começar o teste grátis

Não é necessário informar cartão de crédito. Configuração em poucos minutos.

Seu Template de dados de gestão de problemas

Seu Template de dados de gestão de problemas

Atributos de Gestão de Problemas

Atividades de Gestão de Problemas

Guias de extração

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

Etapas

Configuração

Consulta de exemplo config

Consulta SQL pelo Zendesk Data Sharing

Etapas

Configuração

Consulta de exemplo sql

Extração em Python usando a API Incremental Export

Etapas

Configuração

Consulta de exemplo python

Pronto para começar?

Otimize a Gestão de Problemas para corrigir falhas de TI mais rápido