> Melhoria contínua de processos > Gestão de Incidentes > Zendesk Support > Template de dados

Seu Template de dados para gerenciamento de incidentes

Zendesk Support

Atributos de Gestão de Incidentes (23) Atividades de Gestão de Incidentes (13) Guias de extração (4)

Seu Template de dados para gerenciamento de incidentes

Este Template oferece uma visão estruturada dos dados essenciais necessários para analisar seu processo de gerenciamento de incidentes com eficiência. Ele apresenta os principais atributos a serem coletados, as atividades críticas a serem acompanhadas e orientações práticas para extrair esses dados do Zendesk Support. Use-o para garantir que seu projeto de Process Mining comece com um conjunto de dados completo e confiável.

Atributos recomendados para coleta
Principais atividades a acompanhar no mapeamento do processo
Orientações práticas para extração de dados

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

Baixar Template

Atributos de Gestão de Incidentes

Estes são os campos de dados recomendados para incluir no seu Event Log e realizar uma análise detalhada do seu processo de gestão de incidentes.

5 Obrigatório 7 Recomendado 11 Opcional

	Nome	Descrição
	ID do incidente TicketId	O identificador exclusivo gerado pelo sistema para cada ticket de incidente.
Descrição O Incident ID é a chave primária que identifica exclusivamente cada caso de incidente no Zendesk Support. Ele funciona como o CaseId do Process Mining, conectando todas as atividades, alterações de status e comunicações relacionadas desde a criação do incidente até o seu encerramento. Na análise, esse ID é essencial para reconstruir a jornada completa de cada incidente. Ele permite agregar os dados de eventos para acompanhar métricas como tempo total de resolução, número de transferências e cumprimento dos acordos de nível de serviço em cada caso. Ao agrupar os eventos por esse ID, os analistas podem visualizar os fluxos do processo, identificar caminhos comuns e detectar desvios do procedimento padrão. Por que isso importa Este é o identificador essencial que conecta todos os eventos a um único incidente, permitindo rastrear todo o ciclo de vida e analisar a performance do processo com precisão. Onde obter API de Tickets do Zendesk (/api/v2/tickets/{id}), campo id. Exemplos 19428230113521941055
	Timestamp do evento EventTimestamp	A data e a hora exatas em que a atividade ocorreu.
Descrição Este timestamp registra o momento exato em que um evento ocorreu no ciclo de vida do incidente, como quando um comentário foi adicionado ou o status foi alterado. Ele fornece a ordem cronológica de todas as atividades dentro de um caso. Este atributo é fundamental para qualquer análise de Process Mining baseada em tempo. Ele é usado para calcular os tempos de ciclo entre atividades, identificar tempos de espera, medir a duração total do caso e analisar a performance do processo em diferentes períodos. Timestamps precisos são essenciais para criar um mapa do processo animado, que mostra o fluxo dos casos ao longo do tempo, e para criar Dashboards de performance que acompanham KPIs como o tempo médio de resolução. Por que isso importa Os timestamps fornecem o contexto cronológico de todas as atividades, permitindo calcular durações, identificar gargalos e analisar a performance do processo ao longo do tempo. Onde obter API de auditorias de tickets do Zendesk (/api/v2/tickets/{ticket_id}/audits), campo created_at de cada evento de auditoria. Exemplos 2023-04-15T10:00:00Z2023-04-15T10:05:12Z2023-04-16T14:30:00Z
	Atividade ActivityName	O nome da atividade de negócio ou do evento que ocorreu em um ponto específico do ciclo de vida do incidente.
Descrição Este atributo descreve uma etapa ou ação específica realizada no processo de gerenciamento de incidentes, como 'Incident Created', 'Ticket Assigned to Agent' ou 'Incident Resolved'. Essas atividades são derivadas dos dados do Event Log ou da trilha de auditoria do Zendesk, onde as alterações do sistema são registradas. No Process Mining, a sequência dessas atividades forma o mapa do processo, que é a base de toda a análise. Ao analisar o fluxo das atividades, as organizações podem descobrir os caminhos reais percorridos pelos incidentes, identificar gargalos entre etapas, medir ciclos de retrabalho, como reabrir um ticket resolvido, e verificar a conformidade com um processo padrão definido. Por que isso importa A sequência de atividades define o fluxo do processo, que é o núcleo da análise de Process Mining para identificar ineficiências, desvios e oportunidades de melhoria. Onde obter Derivado de eventos da API de auditorias de tickets do Zendesk. Por exemplo, um evento Change no campo de status pode ser mapeado para 'Status Changed'. Exemplos Incidente criadoTicket atribuído a um agenteStatus alterado para pendenteIncidente resolvidoIncidente encerrado
	Sistema de origem SourceSystem	O sistema do qual os dados do incidente foram extraídos.
Descrição Este atributo identifica a origem dos dados do processo. Nesta visualização, o valor seria estático, por exemplo, 'Zendesk Support', indicando que todos os eventos e atributos foram obtidos desse sistema. Em ambientes que combinam dados de vários sistemas, este campo é essencial para distinguir as diferentes fontes de dados. Ele ajuda a garantir a integridade dos dados e permite análises específicas por origem, como comparar o processo de gerenciamento de incidentes no Zendesk com o de outra ferramenta de ITSM. Por que isso importa Identifica a origem dos dados, o que é essencial para a governança de dados e para análises que combinam dados de vários sistemas de origem. Onde obter Valor estático definido durante a transformação dos dados para identificar a origem dos dados. Exemplos Zendesk SupportZendesk
	Última atualização dos dados LastDataUpdate	O timestamp que indica quando os dados deste processo foram atualizados pela última vez.
Descrição Este atributo registra a data e a hora da extração ou atualização mais recente dos dados no sistema de origem. Normalmente, é um único valor aplicado a todo o conjunto de dados de um determinado ciclo de atualização. Essa informação é essencial para a governança de dados e para os usuários da análise de Process Mining. Ela contextualiza a atualidade dos dados, ajudando os analistas a entender se estão visualizando as informações mais recentes disponíveis. Isso é especialmente importante para monitorar a performance operacional e tomar decisões no momento certo com base na análise. Por que isso importa Fornece um contexto importante sobre a atualidade dos dados, garantindo que os usuários entendam quão recente é a análise e quando os dados foram obtidos pela última vez. Onde obter Timestamp gerado pelo processo de ETL/pipeline de dados após a conclusão da atualização dos dados. Exemplos 2023-10-27T08:00:00Z2023-10-28T08:00:00Z
	Agente atribuído Assignee	O agente de suporte atualmente responsável pelo atendimento do incidente.
Descrição Este atributo identifica o agente específico responsável pelo incidente em determinado momento. Alterações no responsável são eventos importantes que indicam a transferência do trabalho de uma pessoa para outra. Analisar o agente atribuído ajuda a entender a distribuição da carga de trabalho, a performance individual e os padrões de colaboração. Acompanhar as alterações nesse campo é essencial para calcular o KPI 'Average Handoffs per Incident' e identificar situações em que os incidentes são transferidos repetidamente, o que pode indicar lacunas de conhecimento ou roteamento ineficiente. Por que isso importa Identifica o agente responsável, permitindo analisar a carga de trabalho e acompanhar as transferências, o que é essencial para identificar ineficiências no processo. Onde obter API de Tickets do Zendesk, campo assignee_id. As alterações são registradas na API de auditorias de tickets. Exemplos John SmithJane DoeAutomação da central de serviços
	Canal de registro Channel	O canal pelo qual o incidente foi reportado inicialmente, como 'Email', 'Web' ou 'API'.
Descrição Este atributo registra o método usado pelo usuário final ou pelo sistema para criar o ticket de incidente. Entender o canal é importante para analisar as origens dos incidentes e adaptar o processo de suporte de acordo com cada uma delas. Analisar os incidentes por canal pode revelar padrões diferentes. Por exemplo, incidentes reportados por telefone podem ter tempos de resolução menores do que os recebidos por e-mail. Essas informações apoiam o Dashboard 'Incident Throughput Volume' e ajudam no planejamento de recursos e na otimização dos canais. Por que isso importa Ajuda a analisar o volume de incidentes e a performance do processo por origem, permitindo melhorias específicas por canal e uma melhor alocação de recursos. Onde obter API de Tickets do Zendesk, campo via.channel. Exemplos webe-mailapitelefone
	Grupo atribuído AssignedGroup	O time ou grupo de suporte atualmente responsável pelo incidente.
Descrição Este atributo indica qual time é responsável pelo incidente. Os incidentes geralmente passam por diferentes níveis de suporte ou grupos especializados, por exemplo, do 'L1 Support' para o 'Network Team'. Essa é uma dimensão importante para analisar transferências e identificar gargalos. Ao monitorar como os incidentes circulam entre os grupos, os analistas podem medir dependências entre times, calcular os tempos de fila de equipes específicas e otimizar as regras de roteamento. Isso apoia diretamente o Dashboard 'Handoffs and Rework Analysis'. Por que isso importa Acompanha a responsabilidade dos times, o que é essencial para analisar transferências entre equipes, identificar gargalos específicos de cada time e medir tempos de fila. Onde obter API de Tickets do Zendesk, campo group_id. As alterações são registradas na API de auditorias de tickets. Exemplos Suporte L1Equipe de rede L2Infraestrutura L3Faturamento
	Hora de término do evento EventEndTime	O registro de data e hora que indica quando uma atividade foi concluída.
Descrição A hora de término do evento marca a conclusão de uma atividade. Nos dados do Event Log, o horário de término de uma atividade costuma ser inferido como o horário de início da próxima atividade na sequência do caso. Para a última atividade de um caso, o horário de término pode ser igual ao horário de início. Este atributo é essencial para calcular a duração de atividades individuais (ProcessingTime) e o tempo de espera entre atividades. Essas informações são a base da análise de gargalos, permitindo que os analistas vejam não apenas quanto tempo uma etapa leva, mas também por quanto tempo o caso ficou parado antes do início dessa etapa. Por que isso importa Permite calcular a duração das atividades e os tempos de espera, o que é fundamental para realizar uma análise detalhada de gargalos e identificar atrasos no processo. Onde obter Calculado como o horário de início do evento seguinte dentro do mesmo caso. O horário de término do último evento pode ser igual ao horário de início ou ao horário de encerramento do caso. Exemplos 2023-04-15T10:05:12Z2023-04-16T14:30:00Z2023-04-16T18:00:00Z
	Prioridade TicketPriority	O nível de prioridade atribuído ao incidente, como 'Low', 'Normal', 'High' ou 'Urgent'.
Descrição A prioridade de um incidente determina a urgência necessária para a resposta e a resolução. É um fator importante para priorizar o trabalho e alocar recursos dentro do time de suporte. Na análise de processos, a prioridade é usada para segmentar os incidentes e comparar seus fluxos e sua performance. Por exemplo, os analistas podem verificar se incidentes 'Urgent' são realmente resolvidos mais rapidamente do que os de prioridade 'Low'. Ela também é usada para monitorar a conformidade com os SLAs, que muitas vezes são definidos com base nos níveis de prioridade. O KPI 'Priority Change Rate' depende do acompanhamento das alterações nesse campo. Por que isso importa Este atributo é essencial para segmentar a análise, avaliar a eficácia da priorização e monitorar a conformidade com os SLAs em diferentes níveis de urgência. Onde obter API de Tickets do Zendesk, campo priority. As alterações são registradas na API de auditorias de tickets. Exemplos baixonormalaltourgente
	Status do SLA SlaStatus	O status atual do Acordo de Nível de Serviço (SLA) do incidente.
Descrição Este atributo indica se um incidente está no caminho certo para cumprir as metas de SLA definidas, se já ultrapassou esses limites ou se os cronômetros do SLA estão pausados. O Zendesk acompanha automaticamente as métricas de SLA com base nas políticas configuradas. Este é um atributo essencial para o Dashboard 'Monitoramento da Conformidade com o SLA'. Ele fornece uma medida direta da performance em relação aos compromissos de serviço. Ao analisar quando e por que os SLAs são violados, as organizações podem identificar pontos fracos no processo e melhorar a confiabilidade do serviço. Ele dá suporte direto ao KPI 'Taxa de Adesão ao SLA de Incidentes'. Por que isso importa Mede diretamente a performance em relação aos compromissos de serviço, permitindo analisar violações de SLA e fazer um monitoramento proativo para melhorar a conformidade. Onde obter API de Métricas de Tickets do Zendesk (/api/v2/ticket_metrics.json), derivada de campos como sla_policy, breached_at etc. Exemplos AtivoPausadoSLA violadoAtendido
	Status do ticket TicketStatus	O status do ticket de incidente no momento do evento, como 'Open', 'Pending' ou 'Solved'.
Descrição Este atributo reflete o estado do ticket de incidente em diferentes pontos do seu ciclo de vida. Os status padrão do Zendesk incluem new, open, pending, on-hold, solved e closed. Acompanhar as alterações nesse campo é uma das principais formas de gerar atividades para o Process Mining. Analisar o status do ticket é fundamental para entender o processo. Isso ajuda a identificar quanto tempo os incidentes permanecem em determinados estados, como 'Pending', que geralmente indica espera pela resposta do cliente. Também é essencial para definir a conclusão do caso e calcular os tempos de resolução. Por que isso importa Acompanhar as alterações de status é essencial para entender a evolução do processo, identificar tempos de espera e definir os pontos inicial e final do ciclo de vida do incidente. Onde obter API de Tickets do Zendesk, campo status. As alterações são registradas na API de auditorias de tickets. Exemplos novoabertopendenteresolvidofechado
	Avaliação de satisfação SatisfactionRating	A avaliação de satisfação fornecida pelo usuário final depois que o incidente foi resolvido.
Descrição Este atributo registra o feedback do cliente sobre a experiência de suporte, normalmente coletado por meio de uma pesquisa depois que o ticket é resolvido. As avaliações mais comuns no Zendesk são 'Bom' ou 'Ruim'. Embora não seja uma medida direta da eficiência do processo, a avaliação de satisfação fornece uma métrica de resultado essencial. No Process Mining, ela pode ser correlacionada com as variantes do processo para entender quais caminhos de resolução levam a uma maior satisfação do cliente. Por exemplo, incidentes com mais transferências recebem avaliações menores? Por que isso importa Fornece uma métrica de resultado importante que pode ser correlacionada com as características do processo para entender como a performance do processo afeta a satisfação do usuário. Onde obter API de Métricas de Tickets do Zendesk (/api/v2/ticket_metrics.json), campo satisfaction_rating.score. Exemplos bomruimoferecidonão oferecido
	Categoria da causa raiz RootCauseCategory	A categoria de alto nível da causa raiz subjacente do incidente.
Descrição Este atributo é usado para classificar o motivo fundamental pelo qual um incidente ocorreu. Normalmente, ele é registrado no final do ciclo de vida do incidente, muitas vezes como parte de uma análise pós-incidente ou de um processo de gerenciamento de problemas, e armazenado em um campo personalizado. Esses dados são essenciais para o Dashboard 'Precisão na Identificação da Causa Raiz' e para o KPI 'Cobertura de RCA'. Analisar os incidentes por causa raiz ajuda a identificar problemas recorrentes, orientando os esforços para implementar correções permanentes e reduzir o volume de incidentes futuros. Isso muda o foco de uma atuação reativa para a prevenção proativa de problemas. Por que isso importa Permite o gerenciamento proativo de problemas ao categorizar as causas dos incidentes, ajudando a identificar tendências e prevenir novas ocorrências. Onde obter Normalmente, este é um campo personalizado de ticket. Verifique a configuração de Ticket Fields no Zendesk Admin Center. Exemplos Bug de softwareFalha de hardwareErro do usuárioIndisponibilidade da rede
	Contagem de transferências HandoffCount	O número total de vezes que um incidente foi reatribuído a outro agente ou grupo.
Descrição Essa métrica calculada quantifica o número de vezes que a responsabilidade por um incidente foi transferida. Cada alteração no campo Assignee ou AssignedGroup incrementa essa contagem para o caso. As transferências são uma fonte comum de ineficiência e atraso no gerenciamento de incidentes. Uma contagem alta pode indicar regras de roteamento pouco claras, lacunas de conhecimento nos times de suporte ou processos excessivamente complexos. Essa métrica é a base do KPI 'Média de Transferências por Incidente' e é essencial para o Dashboard 'Análise de Transferências e Retrabalho'. Por que isso importa Quantifica o atrito no processo causado por transferências, ajudando a identificar ineficiências de roteamento e lacunas de conhecimento que prolongam os tempos de resolução. Onde obter Calculada contando o número de vezes que o campo AssignedGroup ou Assignee foi alterado para um incidente. Exemplos 0135
	Duração do caso CaseDuration	O tempo total decorrido entre a criação do incidente e seu encerramento final.
Descrição Essa métrica calculada representa o tempo de ciclo de ponta a ponta de um único incidente. Ela é calculada pela diferença entre o registro de data e hora do primeiro evento (por exemplo, 'Incidente criado') e o do último evento (por exemplo, 'Incidente encerrado'). A duração do caso é um dos principais KPIs da eficiência geral do processo. Ela é amplamente usada em Dashboards para mostrar tempos médios de ciclo, identificar casos de longa duração e analisar tendências ao longo do tempo. Essa métrica fornece uma visão geral da velocidade com que o processo consegue tratar e resolver incidentes. Por que isso importa Este é um KPI essencial para medir a velocidade geral do processo e identificar os fatores que contribuem para tempos longos de resolução. Onde obter Calculada pela diferença entre o registro de data e hora do último evento e o do primeiro evento de cada Incident ID. Exemplos 25920060480086400
	É automatizado IsAutomated	Um indicador booleano que informa se uma atividade foi executada por um sistema automatizado ou por um agente humano.
Descrição Este atributo derivado ajuda a distinguir entre eventos executados por usuários humanos e aqueles realizados por automações do sistema, gatilhos ou integrações de API. Normalmente, ele é determinado verificando se o autor de um evento é um usuário de sistema conhecido. Entender o nível de automação é essencial para a análise moderna de processos. Isso ajuda a avaliar a efetividade das regras de automação, identificar tarefas manuais que poderiam ser automatizadas e medir o impacto da automação na eficiência e nos tempos de resolução. Este atributo pode ser usado para comparar os fluxos de processo de atividades automatizadas e manuais. Por que isso importa Distingue entre ações humanas e ações do sistema, o que é essencial para analisar o impacto da automação na eficiência do processo e identificar novas oportunidades de automação. Onde obter Derivado da verificação de se o autor do evento (author_id na API de Auditorias de Tickets) corresponde a um usuário conhecido do sistema ou da automação. Exemplos truefalse
	É resolvido no primeiro contato IsFirstContactResolution	Um indicador booleano que é verdadeiro quando o incidente foi resolvido pelo primeiro agente ou grupo designado, sem nenhuma transferência.
Descrição A resolução no primeiro contato (FCR) é uma métrica essencial para a eficiência do centro de suporte e a satisfação do cliente. Este atributo calculado identifica os incidentes resolvidos sem serem reatribuídos a outro agente ou time. A lógica normalmente verifica se o ticket chegou ao status 'Resolvido' enquanto ainda estava atribuído ao agente e ao grupo iniciais. No Process Mining, isso permite calcular diretamente a taxa de FCR e comparar os caminhos de processo dos incidentes resolvidos no primeiro contato com os que exigiram escalonamento, ajudando a identificar oportunidades para dar mais autonomia ao suporte de primeira linha. Por que isso importa Mede diretamente a eficiência do primeiro ponto de contato do suporte e ajuda a identificar oportunidades para antecipar a resolução no processo. Onde obter Indicador booleano calculado. Verdadeiro quando o status do ticket é 'solved' ou 'closed' e houve apenas um responsável ou grupo designado exclusivo durante todo o ciclo de vida do incidente. Exemplos truefalse
	Organização do cliente Organization	A organização ou empresa à qual pertence o solicitante do incidente.
Descrição Este atributo vincula um incidente à organização do cliente. Ele é essencial em ambientes de suporte B2B, nos quais os níveis de serviço e os processos de suporte podem variar conforme o cliente. Analisar os incidentes por organização permite que os times de suporte monitorem a saúde dos clientes, identifiquem problemas recorrentes que afetam clientes específicos e garantam o cumprimento das obrigações contratuais. É uma dimensão importante para filtrar Dashboards e relatórios e oferecer uma visão da performance centrada no cliente. Por que isso importa Permite análises específicas por cliente, ajudando a monitorar níveis de serviço, identificar tendências em contas estratégicas e gerenciar relacionamentos com clientes de forma eficaz. Onde obter API de Tickets do Zendesk, campo organization_id. Exemplos Global Tech Inc.Innovate SolutionsData Corp
	Remetente Submitter	O usuário final ou sistema que reportou originalmente o incidente.
Descrição Este atributo identifica a pessoa ou entidade que criou o ticket. Isso é diferente do solicitante, pois um agente pode criar um ticket em nome de outra pessoa. Na análise, o remetente pode ser usado para entender quem está reportando os problemas. Quando combinado com dados da organização, ele ajuda a identificar se determinados clientes ou grupos de usuários estão enfrentando um volume alto de incidentes. Isso pode orientar iniciativas de suporte proativo ou treinamentos. Por que isso importa Identifica a origem do registro do incidente, que pode ser analisada para encontrar padrões relacionados a usuários, departamentos ou sistemas automatizados específicos. Onde obter API de Tickets do Zendesk, campo submitter_id. Exemplos alice.jones@example.combob.williams@example.comMonitor do sistema
	Severidade Severity	O nível de impacto que o incidente causa no negócio.
Descrição A severidade define o impacto de um incidente no negócio e costuma ser analisada em conjunto com a prioridade para determinar a urgência geral. Normalmente, ela é configurada como um campo personalizado no Zendesk. Analisar a severidade ajuda a entender a criticidade dos incidentes tratados. Ela é uma dimensão importante para segmentar dados em Dashboards como 'Monitoramento da Conformidade com o SLA' e 'Métricas de Efetividade da Priorização'. Comparar os fluxos de processo de diferentes níveis de severidade pode revelar se os incidentes de alta severidade estão sendo tratados com a velocidade e os recursos adequados. Por que isso importa Indica o impacto de um incidente no negócio, permitindo uma análise focada nos problemas mais críticos e garantindo que sejam resolvidos com eficiência. Onde obter Normalmente, este é um campo personalizado. Verifique a configuração de Ticket Fields no Zendesk Admin Center. Exemplos 1 - Crítico2 - Alto3 - Médio4 - Baixo
	Tags Tags	Uma lista de tags aplicadas ao incidente para categorização e contexto.
Descrição As tags são rótulos flexíveis que podem ser adicionados aos tickets para fornecer contexto adicional ou ajudar na categorização e no roteamento. Elas podem ser adicionadas manualmente pelos agentes ou automaticamente por meio de gatilhos e automações. As tags são uma fonte rica de dados para a análise de Process Mining. Elas podem ser usadas para criar segmentos detalhados, como filtrar incidentes relacionados ao lançamento de um produto específico ('launch_q4') ou a uma interrupção conhecida ('outage_20231027'). Essa flexibilidade permite investigações aprofundadas que vão além dos campos padrão de tickets. Por que isso importa Oferece uma forma flexível de categorizar e filtrar incidentes, permitindo uma análise detalhada e específica do contexto, que talvez não seja possível apenas com os campos padrão. Onde obter API de Tickets do Zendesk, campo tags. Exemplos usuário_vipproblema_de_redeindisponibilidade_20231027relacionado_a_faturamento
	Tipo de ticket TicketType	A classificação do ticket, como 'Incidente', 'Problema', 'Pergunta' ou 'Tarefa'.
Descrição Este campo categoriza o ticket com base na natureza da solicitação. O processo de gerenciamento de incidentes se concentra especificamente nos tickets cujo tipo é 'Incidente', representando uma interrupção não planejada ou uma redução na qualidade de um serviço de TI. Na análise, esse atributo é usado principalmente como filtro para garantir que apenas incidentes sejam incluídos na visualização do processo. Ele também pode ser usado em análises mais amplas de ITSM para comparar os processos de tratamento de incidentes, problemas e solicitações de serviço. Por que isso importa Permite filtrar os dados para focar especificamente nos incidentes, garantindo que a análise do processo seja relevante para o ciclo de vida do gerenciamento de incidentes. Onde obter API de Tickets do Zendesk, tipo do campo. Exemplos incidenteproblemaperguntatarefa

Obrigatório Recomendado Opcional

Atividades de Gestão de Incidentes

Estas são as etapas e os marcos críticos do processo que você deve registrar no seu Event Log para realizar uma descoberta e uma análise precisas.

6 Recomendado 7 Opcional

	Atividade	Descrição
	Incidente criado	Marca o início do ciclo de vida do incidente, quando um novo ticket é criado no Zendesk. Esse evento é capturado explicitamente pelo audit log de criação de tickets do Zendesk e serve como ponto de partida para cada caso.
Por que isso importa Esta é a principal atividade inicial. Analisar o tempo entre esse evento e os demais é essencial para medir a duração total do ciclo de vida do ticket e os tempos de resposta inicial. Onde obter Este é um evento explícito capturado nos audit logs de tickets do Zendesk. Cada novo ticket gera um evento 'Create' com o respectivo timestamp. Captura Diretamente do evento de criação do ticket no audit log. Tipo de evento explicit
	Incidente encerrado	Marca o fim definitivo do ciclo de vida do incidente, quando o ticket é encerrado permanentemente. No Zendesk, isso geralmente acontece automaticamente após um período definido desde a resolução e é capturado como uma alteração final de status.
Por que isso importa Esta é a atividade final definitiva do processo. A duração total do processo é calculada de 'Incident Created' até este evento, oferecendo uma visão completa do tempo de ciclo. Onde obter Capturado no audit log do ticket por meio de um evento 'Change' em que o novo valor do campo 'status' passa a ser 'closed'. Captura Identificado por um evento 'Change' no campo 'status' para 'closed'. Tipo de evento explicit
	Incidente resolvido	Este marco importante ocorre quando um agente implementa uma solução e marca o ticket como 'solved'. É uma ação explícita, capturada como uma alteração de status no audit log do ticket.
Por que isso importa Esta é a principal atividade de resolução e um ponto crítico para medir o tempo até a resolução. O período entre este evento e 'Incident Closed' representa o tempo de confirmação do usuário ou de encerramento automático. Onde obter Capturado no audit log do ticket por meio de um evento 'Change' em que o novo valor do campo 'status' passa a ser 'solved'. Captura Identificado por um evento 'Change' no campo 'status' para 'solved'. Tipo de evento explicit
	Status alterado para aberto	Indica que um agente começou a trabalhar ativamente no incidente. Essa atividade normalmente é inferida pela alteração do campo 'status' do ticket de 'new' para 'open', sinalizando o início da investigação e do diagnóstico.
Por que isso importa Este evento marca a transição da fila para o trabalho ativo. O tempo que os tickets permanecem com status 'new' antes de passar para 'open' é uma métrica importante do tempo de resposta inicial. Onde obter Inferido a partir do audit log do ticket, identificando um evento 'Change' em que o novo valor do campo 'status' é 'open' e o valor anterior era 'new'. Captura Inferido a partir de uma alteração no campo de status de 'new' para 'open'. Tipo de evento inferred
	Ticket atribuído a um agente	Esta atividade ocorre quando um ticket é atribuído a um agente específico para atendimento. É um evento explícito registrado no histórico de auditoria do ticket e indica que uma pessoa assumiu a responsabilidade pelo caso.
Por que isso importa Esse marco é essencial para medir o tempo até a primeira atribuição e serve de base para analisar transferências, retrabalho e taxas de resolução no primeiro contato. Onde obter Capturado no audit log do ticket quando o campo 'assignee_id' é preenchido ou alterado. A primeira atribuição é um marco importante para o cálculo de KPIs. Captura Identificado por um evento 'Change' no campo 'assignee_id' do audit log do ticket. Tipo de evento explicit
	Ticket reatribuído	Ocorre quando a responsabilidade pelo ticket é transferida de um agente ou grupo para outro depois da atribuição inicial. É um evento explícito acompanhado no histórico de auditoria do ticket.
Por que isso importa As reatribuições são importantes para analisar transferências e retrabalho. Uma frequência alta de reatribuições geralmente aponta para um roteamento inicial incorreto, problemas complexos ou gargalos no processo. Onde obter Capturado no audit log do ticket pela identificação de um evento 'Change' no campo 'assignee_id' ou 'group_id' depois que ele foi preenchido pela primeira vez. Captura Identificado por um evento 'Change' posterior no campo 'assignee_id' ou 'group_id'. Tipo de evento explicit
	Meta de SLA violada	Marca o momento em que um ticket não cumpre um Acordo de Nível de Serviço definido, como o tempo da primeira resposta ou o tempo de resolução. Esse evento é calculado com base nas definições da política de SLA e nos timestamps de atualização do ticket.
Por que isso importa Este evento apoia diretamente o monitoramento da conformidade com os SLAs. Identificar quando e por que ocorrem violações é fundamental para melhorar a confiabilidade do serviço e a confiança dos clientes. Onde obter Este é um evento calculado. Ele pode ser derivado pela análise dos dados 'sla_policy_metrics' associados a um ticket, usando o timestamp 'breached_at' de cada meta de SLA. Captura Derivado do timestamp 'breached_at' nos dados de métricas de SLA do ticket. Tipo de evento calculated
	Nota interna adicionada	Esta atividade representa a colaboração interna, quando um agente adiciona uma nota privada ao ticket para outros membros do time. Ela é capturada explicitamente quando um comentário é marcado como não público.
Por que isso importa Analisar notas internas pode gerar insights sobre problemas complexos que exigem colaboração, mas um número excessivo delas pode indicar lacunas de conhecimento ou ineficiências no processo. Onde obter Capturado nos dados de comentários do ticket. Um comentário é identificado como nota interna quando seu atributo 'public' é false. Captura Evento registrado quando um novo comentário com 'public: false' é adicionado ao ticket. Tipo de evento explicit
	Prioridade definida	O nível de prioridade de um incidente, como 'Low', 'Normal', 'High' ou 'Urgent', é definido. Isso é registrado como um evento explícito de alteração e determina a urgência e o tempo de resposta necessário para o ticket.
Por que isso importa Acompanhar quando e como a prioridade é definida é essencial para o Dashboard 'Prioritization Effectiveness Metrics', garantindo que problemas críticos sejam tratados rapidamente. Onde obter Capturado a partir de um evento 'Change' no campo 'priority' do audit log do ticket. Alterações posteriores também podem ser acompanhadas para medir o KPI Priority Change Rate. Captura Identificado por um evento 'Change' no campo 'priority' do audit log do ticket. Tipo de evento explicit
	Resposta pública enviada	Representa uma comunicação enviada por um agente de suporte ao usuário final. É um evento explícito no Zendesk, capturado sempre que um comentário público é adicionado ao ticket.
Por que isso importa Acompanhar as respostas públicas é importante para entender a frequência das comunicações e pode ser uma parte essencial da linha do tempo ao analisar atrasos na confirmação do usuário. Onde obter Capturado nos dados de comentários do ticket. Um comentário é identificado como público quando seu atributo 'public' é true. Captura Evento registrado quando um novo comentário com 'public: true' é adicionado ao ticket. Tipo de evento explicit
	Satisfação do usuário avaliada	Representa o momento em que o usuário final fornece uma avaliação de satisfação sobre o suporte recebido. É um evento explícito capturado no Zendesk depois que um ticket é resolvido.
Por que isso importa Analisar as avaliações de satisfação fornece feedback importante sobre a performance dos agentes e a eficácia do processo, conectando as métricas do processo aos resultados para os clientes. Onde obter Capturado nos dados de avaliações de satisfação associados ao ticket. Normalmente, eles incluem uma pontuação ('good' ou 'bad') e um comentário opcional. Captura Evento registrado quando uma avaliação de satisfação é enviada para o ticket. Tipo de evento explicit
	Status alterado para pendente	Indica que o processo está pausado enquanto aguarda uma resposta do solicitante. Esse evento é inferido pela alteração do campo 'status' do ticket para 'pending'.
Por que isso importa Esta atividade é essencial para calcular o tempo de espera pela confirmação do usuário. Períodos longos nesse estado podem aumentar significativamente o tempo total de resolução e destacar atrasos na comunicação. Onde obter Inferido a partir do audit log do ticket, identificando um evento 'Change' em que o novo valor do campo 'status' é 'pending'. Captura Inferido a partir de uma alteração no campo de status para 'pending'. Tipo de evento inferred
	Ticket atribuído a um grupo	Representa o roteamento ou a triagem inicial de um incidente para um grupo de suporte específico. Normalmente, este é o primeiro passo para atribuir a responsabilidade e fica registrado como um evento explícito de alteração no histórico de auditoria do ticket.
Por que isso importa Acompanhar as atribuições de grupo ajuda a analisar a eficiência da triagem inicial e a identificar atrasos antes que um ticket seja encaminhado ao time correto. Onde obter Capturado no audit log do ticket sempre que o campo 'group_id' é preenchido ou alterado. A primeira ocorrência dessa alteração após a criação representa a atribuição inicial. Captura Identificado por um evento 'Change' no campo 'group_id' do audit log do ticket. Tipo de evento explicit

Recomendado Opcional

Guias de extração

Como obter seus dados do Zendesk Support

Etapas

Acesse o Zendesk Explore: faça login na sua instância do Zendesk Support com uma conta de usuário que tenha permissão para criar e gerenciar relatórios no Zendesk Explore.
Crie um novo relatório: acesse o módulo Explore. Clique no ícone 'Reports' na barra de navegação à esquerda e depois no botão 'New report'.
Selecione o conjunto de dados: na janela 'Choose a dataset', selecione o conjunto Support: Ticket updates [default]. Esse conjunto contém o histórico de auditoria de cada alteração em um ticket, essencial para criar um Event Log.
Adicione os atributos iniciais (colunas): no criador de relatórios, acesse a seção 'Rows'. Clique em 'Add' e selecione os seguintes atributos. Eles formarão as colunas do seu Event Log: Ticket ID, Update - Timestamp, Ticket status, Assignee name, Ticket group, Ticket priority, Ticket channel, Changes - Field name, Changes - Previous value, Changes - New value, Comment public.
Crie atributos calculados: esta é a etapa mais importante. Acesse o menu 'Calculations' (ícone do béquer) e selecione 'Standard calculated attribute'. Crie os três atributos definidos na seção 'Query' abaixo: ActivityName, SourceSystem e LastDataUpdate. Você precisará copiar exatamente as fórmulas fornecidas.
Ajuste as colunas do relatório: adicione os novos atributos calculados (ActivityName, SourceSystem, LastDataUpdate) à seção 'Rows'. Agora você pode remover os campos brutos usados para criar ActivityName (Changes - Field name, Changes - Previous value, Changes - New value, Comment public) para deixar a visualização mais limpa.
Adicione filtros ao relatório: acesse a seção 'Filters' e clique em 'Add'. Adicione um filtro para Update - Date e selecione um intervalo adequado, como os últimos 3 meses. Adicione outro filtro ao atributo calculado ActivityName e exclua valores nulos para remover atualizações de tickets que não correspondam a uma atividade desejada.
Execute e revise o relatório: o Zendesk Explore atualizará o relatório automaticamente conforme você adicionar atributos e filtros. Revise a tabela de dados para confirmar que as linhas e colunas aparecem como esperado. O relatório deve mostrar uma linha por evento.
Exporte os dados para CSV: quando o relatório estiver finalizado, clique no botão 'Export' no canto superior direito e selecione 'CSV'. O Zendesk vai gerar e baixar o arquivo CSV.
Prepare o upload: abra o arquivo CSV exportado. Renomeie os cabeçalhos das colunas para corresponder aos nomes de atributos exigidos pela sua ferramenta de Process Mining, como renomear 'Ticket ID' para TicketId e 'Update - Timestamp' para EventTimestamp. Garanta que o formato das datas dos timestamps seja compatível com a ISO 8601. O arquivo estará pronto para upload.

Configuração

Conjunto de dados do Zendesk: o relatório deve ser criado com base no conjunto Support: Ticket updates [default]. Esse é o único conjunto padrão que fornece o histórico de auditoria detalhado necessário para reconstruir o processo evento por evento.
Filtro de intervalo de datas: é essencial aplicar um filtro de data para limitar o volume de dados. Use o atributo Update - Date como filtro principal. Para uma análise inicial, normalmente recomenda-se um período de 3 a 6 meses.
Filtro de atividade: depois de criar o atributo calculado ActivityName, você deve filtrar o relatório para excluir as linhas em que esse valor seja nulo. Isso remove alterações irrelevantes nos tickets, como atualizações do sistema e alterações de tags, do seu Event Log.
Atributos calculados: a lógica dessa extração depende bastante de um atributo calculado padrão para converter alterações brutas nos campos dos tickets em nomes de atividades compreensíveis. A precisão da fórmula é fundamental.
Pré-requisitos: o usuário que executa o relatório precisa ter, no mínimo, a função 'Viewer' no Zendesk Explore. Para criar e salvar o relatório, são necessárias permissões de 'Editor' ou 'Admin'.

a Consulta de exemplo config

This extraction is configured using the Zendesk Explore UI. The core logic is contained within a standard calculated attribute. 

**1. Dataset Selection:**
* `Support: Ticket updates [default]`

**2. Report Columns (Add to 'Rows' panel):**
* `Ticket ID`
* `ActivityName` (Calculated Attribute)
* `EventTimestamp` (Use the `Update - Timestamp` attribute)
* `SourceSystem` (Calculated Attribute)
* `LastDataUpdate` (Calculated Attribute)
* `Ticket status`
* `Assignee name`
* `Ticket group`
* `Ticket priority`
* `Ticket channel`
* `SLA metric status`
* `EventEndTime` (Use the `Update - Timestamp` attribute again)

**3. Standard Calculated Attribute Formulas:**

**Attribute Name:** `ActivityName`
**Formula:**
```
IF ([Changes - Field name] = "status" AND [Changes - Previous value] = NULL AND [Changes - New value] = "new") THEN "Incident Created"
ELIF ([Changes - Field name] = "status" AND [Changes - New value] = "open") THEN "Status Changed to Open"
ELIF ([Changes - Field name] = "status" AND [Changes - New value] = "pending") THEN "Status Changed to Pending"
ELIF ([Changes - Field name] = "status" AND [Changes - New value] = "solved") THEN "Incident Resolved"
ELIF ([Changes - Field name] = "status" AND [Changes - New value] = "closed") THEN "Incident Closed"
ELIF ([Changes - Field name] = "group_id") THEN "Ticket Assigned to Group"
ELIF ([Changes - Field name] = "assignee_id") THEN "Ticket Assigned to Agent"
ELIF ([Changes - Field name] = "priority") THEN "Priority Set"
ELIF ([Changes - Field name] = "satisfaction_score") THEN "User Satisfaction Rated"
ELIF ([Changes - Field name] = "SLA metric breach") THEN "SLA Target Breached"
ELIF ([Comment public] = TRUE) THEN "Public Reply Sent"
ELIF ([Comment public] = FALSE) THEN "Internal Note Added"
ELSE NULL
ENDIF
```

**Attribute Name:** `SourceSystem`
**Formula:**
```
"Zendesk Support"
```

**Attribute Name:** `LastDataUpdate`
**Formula:**
```
NOW()
```

Etapas

Pré-requisitos: confirme que o Python 3.6 ou superior está instalado no seu sistema, junto com as bibliotecas requests e pandas. Você pode instalá-las usando pip: pip install requests pandas.
Gere um token da API do Zendesk: faça login na sua instância do Zendesk Support como administrador. Acesse Admin Center > Apps and integrations > APIs > Zendesk APIs. Na seção "API Tokens", adicione um novo token de API ativo e salve a string gerada em um local seguro.
Configure o script Python: crie um novo arquivo Python, como extract_zendesk_logs.py, e copie o script fornecido para ele. Atualize as variáveis de espaço reservado no início do script: ZENDESK_SUBDOMAIN, ZENDESK_EMAIL e ZENDESK_API_TOKEN com suas credenciais específicas. Defina START_TIMESTAMP para indicar o início do período de extração desejado, usando um timestamp Unix epoch.
Entenda os endpoints da API: o script usa principalmente dois endpoints da API do Zendesk. O endpoint incremental/tickets/cursor.json é usado para buscar com eficiência todos os tickets atualizados desde START_TIMESTAMP. Para cada ticket, o script chama o endpoint tickets/{ticket_id}/audits.json para obter o histórico detalhado de cada alteração e evento.
Execute o script: execute o script no terminal usando o comando: python extract_zendesk_logs.py. O script começará a buscar dados na API do Zendesk.
Acompanhe o progresso do script: o script exibirá no console o número de tickets processados, permitindo acompanhar o andamento. Dependendo do intervalo de datas e do volume de tickets, isso pode levar bastante tempo.
Recuperação de dados e paginação: o script gerencia a paginação da API automaticamente. Ele começa com o URL inicial de exportação de tickets e segue o after_url fornecido em cada resposta da API até recuperar todos os tickets do período.
Transformação dos eventos: para cada ticket, o script percorre o histórico de auditoria. Ele analisa cada evento de auditoria, mapeando os tipos internos de evento do Zendesk, como Create, Change e Comment, para as atividades de negócio necessárias, como Incident Created, Status Changed to Open e Public Reply Sent.
Tratamento dos dados de SLA: o script inclui uma função dedicada, get_sla_breach_events, para buscar métricas de SLA de cada ticket resolvido. Isso é necessário porque violações de SLA não são eventos padrão no Event Log de auditoria. Essa função faz uma chamada adicional à API para obter os detalhes da aplicação da política de SLA.
Gere o Event Log: depois que todos os tickets forem processados, o script compila os eventos extraídos em um DataFrame do pandas e salva o Event Log final como um arquivo CSV chamado zendesk_incident_event_log.csv no mesmo diretório em que o script foi executado.
Prepare o upload: revise o arquivo CSV gerado para confirmar se está correto. Agora o arquivo está no formato necessário para ser carregado diretamente no ProcessMind para análise.

Configuração

Credenciais da API do Zendesk: você deve fornecer o subdomínio do Zendesk, o endereço de e-mail associado a uma conta de administrador ou agente e um token de API válido. Armazene essas credenciais com segurança e não as deixe fixas em scripts versionados usados em produção.
Timestamp inicial (START_TIMESTAMP): esse valor inteiro determina o ponto de início da extração de dados. Ele deve ser um timestamp Unix epoch. Recomenda-se começar de 3 a 6 meses atrás para reunir um volume significativo de dados sem sobrecarregar o sistema. Você pode usar um conversor online para obter o timestamp correto de uma data específica.
Limitação de taxa da API: o script faz várias chamadas à API. O Zendesk aplica limites de taxa que variam conforme o plano. Embora o script funcione com volumes moderados de dados, em instâncias muito grandes talvez seja necessário adicionar chamadas a time.sleep() dentro dos loops para evitar atingir o limite e receber um erro 429.
Bibliotecas Python necessárias: o script depende da biblioteca requests para fazer chamadas à API e da biblioteca pandas para manipulação de dados e exportação para CSV. Confirme que elas estão instaladas no seu ambiente Python.
Permissões do usuário: a conta de usuário associada ao token da API deve ter permissões suficientes para ler dados de tickets, incluindo auditorias e métricas dos tickets.

a Consulta de exemplo python

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

class=class="hl-string">"hl-comment"># --- CONFIGURATION --- 
class=class="hl-string">"hl-comment"># Replace with your Zendesk details
ZENDESK_SUBDOMAIN = class="hl-string">"[your_subdomain]"
ZENDESK_EMAIL = class="hl-string">"[your_login_email@example.com]"
ZENDESK_API_TOKEN = class="hl-string">"[your_zendesk_api_token]"

class=class="hl-string">"hl-comment"># Set the start time for the incremental export (Unix epoch timestamp)
class=class="hl-string">"hl-comment"># Example: 1672531200 is for January 1, 2023 00:00:00 UTC
class=class="hl-string">"hl-comment"># It's recommended to extract the last 3-6 months of data.
START_TIMESTAMP = 1672531200 

class=class="hl-string">"hl-comment"># --- SCRIPT --- 
BASE_URL = fclass="hl-string">"https://{ZENDESK_SUBDOMAIN}.zendesk.com/api/v2"
AUTH = (fclass="hl-string">"{ZENDESK_EMAIL}/token", ZENDESK_API_TOKEN)
SOURCE_SYSTEM = class="hl-string">"Zendesk Support"
LAST_DATA_UPDATE = datetime.utcnow().isoformat() + class="hl-string">'Z'

def get_sla_breach_events(ticket_id, session):
    class="hl-string">"""Fetches SLA metrics for a ticket and creates breach events."""
    sla_events = []
    try:
        metrics_url = fclass="hl-string">"{BASE_URL}/tickets/{ticket_id}/metrics.json"
        response = session.get(metrics_url)
        response.raise_for_status()
        metrics = response.json().get(class="hl-string">'ticket_metric', {})
        
        if metrics and metrics.get(class="hl-string">'sla_policy'):
            for sla in metrics.get(class="hl-string">'sla_policy').get(class="hl-string">'policy_metrics', []):
                if sla.get(class="hl-string">'breach_at'):
                    breach_timestamp = sla[class="hl-string">'breach_at']
                    sla_events.append({
                        class="hl-string">'TicketId': ticket_id,
                        class="hl-string">'ActivityName': class="hl-string">'SLA Target Breached',
                        class="hl-string">'EventTimestamp': breach_timestamp,
                        class="hl-string">'SourceSystem': SOURCE_SYSTEM,
                        class="hl-string">'LastDataUpdate': LAST_DATA_UPDATE,
                        class="hl-string">'TicketStatus': class="hl-string">'breached',
                        class="hl-string">'Assignee': metrics.get(class="hl-string">'assignee_updated_at'), 
                        class="hl-string">'AssignedGroup': metrics.get(class="hl-string">'group_stations'),
                        class="hl-string">'TicketPriority': None, class=class="hl-string">"hl-comment"># Not directly available in metrics
                        class="hl-string">'Channel': None, class=class="hl-string">"hl-comment"># Not directly available in metrics
                        class="hl-string">'SlaStatus': fclass="hl-string">"{sla.get('metric')} Breached",
                        class="hl-string">'EventEndTime': breach_timestamp
                    })
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Could not fetch SLA metrics for ticket {ticket_id}: {e}")
    return sla_events

def process_ticket(ticket, session):
    class="hl-string">"""Processes a single ticket's audits to extract all relevant events."""
    all_events = []
    ticket_id = ticket[class="hl-string">'id']
    ticket_created_at = ticket[class="hl-string">'created_at']
    
    class=class="hl-string">"hl-comment"># 1. Incident Created event
    all_events.append({
        class="hl-string">'TicketId': ticket_id,
        class="hl-string">'ActivityName': class="hl-string">'Incident Created',
        class="hl-string">'EventTimestamp': ticket_created_at,
        class="hl-string">'SourceSystem': SOURCE_SYSTEM,
        class="hl-string">'LastDataUpdate': LAST_DATA_UPDATE,
        class="hl-string">'TicketStatus': class="hl-string">'new',
        class="hl-string">'Assignee': ticket.get(class="hl-string">'assignee_id'),
        class="hl-string">'AssignedGroup': ticket.get(class="hl-string">'group_id'),
        class="hl-string">'TicketPriority': ticket.get(class="hl-string">'priority'),
        class="hl-string">'Channel': ticket.get(class="hl-string">'via', {}).get(class="hl-string">'channel'),
        class="hl-string">'SlaStatus': None,
        class="hl-string">'EventEndTime': ticket_created_at
    })
    
    class=class="hl-string">"hl-comment"># Process audits for other events
    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', [])
        
        is_first_group_assignment = True
        is_first_agent_assignment = True

        for audit in audits:
            event_timestamp = audit[class="hl-string">'created_at']
            for event in audit.get(class="hl-string">'events', []):
                activity = {}
                event_type = event.get(class="hl-string">'type')

                if event_type == class="hl-string">'Change':
                    field_name = event.get(class="hl-string">'field_name')
                    value = event.get(class="hl-string">'value')
                    
                    if field_name == class="hl-string">'group_id' and value is not None:
                        activity_name = class="hl-string">'Ticket Assigned to Group' if is_first_group_assignment else class="hl-string">'Ticket Reassigned'
                        is_first_group_assignment = False
                        activity = {class="hl-string">'ActivityName': activity_name, class="hl-string">'AssignedGroup': value}

                    elif field_name == class="hl-string">'assignee_id' and value is not None:
                        activity_name = class="hl-string">'Ticket Assigned to Agent' if is_first_agent_assignment else class="hl-string">'Ticket Reassigned'
                        is_first_agent_assignment = False
                        activity = {class="hl-string">'ActivityName': activity_name, class="hl-string">'Assignee': value}
                        
                    elif field_name == class="hl-string">'priority':
                        activity = {class="hl-string">'ActivityName': class="hl-string">'Priority Set', class="hl-string">'TicketPriority': value}
                        
                    elif field_name == class="hl-string">'status':
                        if value == class="hl-string">'open': activity = {class="hl-string">'ActivityName': class="hl-string">'Status Changed to Open', class="hl-string">'TicketStatus': class="hl-string">'open'}
                        elif value == class="hl-string">'pending': activity = {class="hl-string">'ActivityName': class="hl-string">'Status Changed to Pending', class="hl-string">'TicketStatus': class="hl-string">'pending'}
                        elif value == class="hl-string">'solved': activity = {class="hl-string">'ActivityName': class="hl-string">'Incident Resolved', class="hl-string">'TicketStatus': class="hl-string">'solved'}
                        elif value == class="hl-string">'closed': activity = {class="hl-string">'ActivityName': class="hl-string">'Incident Closed', class="hl-string">'TicketStatus': class="hl-string">'closed'}
                        
                elif event_type == class="hl-string">'Comment':
                    is_public = event.get(class="hl-string">'public', False)
                    activity_name = class="hl-string">'Public Reply Sent' if is_public else class="hl-string">'Internal Note Added'
                    activity = {class="hl-string">'ActivityName': activity_name}

                elif event_type == class="hl-string">'SatisfactionRating':
                    activity = {class="hl-string">'ActivityName': class="hl-string">'User Satisfaction Rated'}

                if activity:
                    base_event = {
                        class="hl-string">'TicketId': ticket_id,
                        class="hl-string">'EventTimestamp': event_timestamp,
                        class="hl-string">'SourceSystem': SOURCE_SYSTEM,
                        class="hl-string">'LastDataUpdate': LAST_DATA_UPDATE,
                        class="hl-string">'TicketStatus': ticket.get(class="hl-string">'status'),
                        class="hl-string">'Assignee': ticket.get(class="hl-string">'assignee_id'),
                        class="hl-string">'AssignedGroup': ticket.get(class="hl-string">'group_id'),
                        class="hl-string">'TicketPriority': ticket.get(class="hl-string">'priority'),
                        class="hl-string">'Channel': ticket.get(class="hl-string">'via', {}).get(class="hl-string">'channel'),
                        class="hl-string">'SlaStatus': None,
                        class="hl-string">'EventEndTime': event_timestamp
                    }
                    base_event.update(activity)
                    all_events.append(base_event)
    
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Could not process audits for ticket {ticket_id}: {e}")

    class=class="hl-string">"hl-comment"># Get SLA Breach events if ticket is solved
    if ticket.get(class="hl-string">'status') in [class="hl-string">'solved', class="hl-string">'closed']:
        all_events.extend(get_sla_breach_events(ticket_id, session))

    return all_events

def main():
    class="hl-string">"""Main function to fetch tickets and generate the event log."""
    all_ticket_events = []
    url = fclass="hl-string">"{BASE_URL}/incremental/tickets/cursor.json?start_time={START_TIMESTAMP}"
    
    with requests.Session() as session:
        session.auth = AUTH
        
        ticket_count = 0
        while url:
            try:
                response = session.get(url)
                response.raise_for_status()
                data = response.json()
                tickets = data.get(class="hl-string">'tickets', [])
                
                for ticket in tickets:
                    ticket_count += 1
                    all_ticket_events.extend(process_ticket(ticket, session))
                    if ticket_count % 100 == 0:
                        print(fclass="hl-string">"Processed {ticket_count} tickets...")

                if data.get(class="hl-string">'end_of_stream', True):
                    print(class="hl-string">"Reached the end of the ticket stream.")
                    break
                
                url = data.get(class="hl-string">'after_url')
                class=class="hl-string">"hl-comment"># Respect rate limits
                time.sleep(1) 

            except requests.exceptions.RequestException as e:
                print(fclass="hl-string">"An API error occurred: {e}")
                if hasattr(e, class="hl-string">'response') and e.response.status_code == 429:
                    retry_after = int(e.response.headers.get(class="hl-string">'Retry-After', 60))
                    print(fclass="hl-string">"Rate limit exceeded. Retrying after {retry_after} seconds...")
                    time.sleep(retry_after)
                else:
                    break

    if not all_ticket_events:
        print(class="hl-string">"No events were extracted. Check configuration and API access.")
        return

    print(fclass="hl-string">"\nTotal events extracted: {len(all_ticket_events)}")
    df = pd.DataFrame(all_ticket_events)
    
    class=class="hl-string">"hl-comment"># Reorder columns for clarity
    cols = [
        class="hl-string">'TicketId', class="hl-string">'ActivityName', class="hl-string">'EventTimestamp', class="hl-string">'EventEndTime', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate',
        class="hl-string">'TicketStatus', class="hl-string">'Assignee', class="hl-string">'AssignedGroup', class="hl-string">'TicketPriority', class="hl-string">'Channel', class="hl-string">'SlaStatus'
    ]
    df = df[cols]
    
    class=class="hl-string">"hl-comment"># Save to CSV
    output_file = class="hl-string">'zendesk_incident_event_log.csv'
    df.to_csv(output_file, index=False)
    print(fclass="hl-string">"Event log successfully saved to {output_file}")

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

Etapas

Crie um cliente da API do Zendesk com permissão para ler tickets, auditorias de tickets, usuários, grupos, avaliações de satisfação e exportações incrementais. Use um token de API ou uma credencial OAuth configurada para sua instância do Zendesk Support. Armazene o subdomínio, a credencial e o watermark da extração como valores de configuração seguros.
Use a API de exportação incremental de tickets do Zendesk para recuperar os tickets atualizados depois do último watermark processado com sucesso. O script abaixo usa o padrão de endpoint documentado, https://[Your Zendesk subdomain].zendesk.com/api/v2/incremental/tickets/cursor.json, e segue a paginação por cursor até a API informar que o conjunto de resultados foi concluído.
Para cada ticket retornado, solicite o histórico de auditoria pelo endpoint de auditorias do ticket. Os registros de auditoria são necessários porque o ProcessMind lê o Event Log como ele está e não infere atividades a partir do estado final do ticket. Preserve o timestamp da auditoria, o responsável pela ação, o identificador do ticket e os eventos de auditoria.
Converta os eventos de auditoria em linhas de eventos explícitas. Extraia a criação do ticket, a atribuição a um grupo, a atribuição a um agente, alterações de prioridade, alterações de status para aberto, respostas públicas, notas internas, reatribuições, alterações de status para pendente, status resolvido e status fechado. Extraia as avaliações de satisfação como linhas separadas quando a avaliação estiver disponível. Calcule violações de SLA somente quando a meta de SLA necessária e os timestamps dos eventos estiverem disponíveis, documentando os dados usados no cálculo.
Mantenha o timestamp da última atualização processada com sucesso ou o cursor correspondente. Não avance o watermark até que todas as páginas, auditorias dos tickets e registros opcionais de satisfação tenham sido gravados com sucesso. Na primeira execução, use um horário inicial limitado, como [Start date in ISO 8601 format], normalmente cobrindo de três a seis meses.
Preencha as colunas obrigatórias TicketId, ActivityName, EventTimestamp, SourceSystem e LastDataUpdate. Preencha as colunas recomendadas TicketStatus, Assignee, AssignedGroup, TicketPriority, Channel, SlaStatus e EventEndTime sempre que os dados de origem permitirem. Use valores vazios somente quando o Zendesk não fornecer o atributo para o evento.
Elimine duplicidades usando TicketId, ActivityName, EventTimestamp e um identificador de evento de origem estável, quando disponível. Preserve várias ocorrências legítimas da mesma atividade, como várias respostas públicas, notas internas, atribuições ou alterações de status.
Grave as linhas resultantes em CSV ou em outro formato de Event Log compatível com o ProcessMind. Garanta que os timestamps estejam no padrão ISO 8601 com um deslocamento UTC explícito, que TicketId tenha um tipo consistente, que os valores de ActivityName correspondam exatamente aos nomes de atividades documentados e que LastDataUpdate seja igual em todas as linhas do mesmo lote de extração.
Faça o upload do Event Log para o ProcessMind e configure Incident ID como identificador do caso, Activity como coluna de atividade e Event Timestamp como coluna de horário do evento. Valide se todas as atividades obrigatórias estão representadas por linhas explícitas, em vez de serem derivadas durante a visualização.

Configuração

Método da API: API de exportação incremental de tickets do Zendesk com paginação por cursor. Use o endpoint de auditoria dos tickets para a extração em nível de evento e o endpoint de satisfação quando as avaliações de satisfação estiverem habilitadas e acessíveis.
Configuração obrigatória: subdomínio do Zendesk, autenticação da API, data inicial, watermark da extração, tempo limite das solicitações, política de novas tentativas e local de saída. Substitua [Your Zendesk subdomain], [Your API email] e [Your API token] por valores seguros de implantação.
Intervalo de datas: para uma carga inicial, use de três a seis meses, a menos que o histórico necessário seja maior. Para cargas recorrentes, solicite registros posteriores ao último watermark processado com sucesso e inclua uma pequena janela de sobreposição para proteger contra atualizações recebidas com atraso; depois, elimine as duplicidades.
Filtros: aplique filtros de empresa, marca, grupo, organização, formulário de ticket, canal ou campos personalizados somente quando forem explicitamente exigidos pelo escopo do processo. O Zendesk Support não usa filtros no estilo SAP, como Company Code ou Document Type, a menos que esses conceitos estejam representados por campos configurados no Zendesk.
Semântica dos eventos: trate os eventos de auditoria como fonte oficial para alterações explícitas. Não crie um evento de alteração de status apenas porque o status atual do ticket tem um valor. Um evento de status deve ser emitido a partir de um evento de auditoria ou de outro evento de origem documentado.
Configuração de SLA: SLA Target Breached exige acesso à política de SLA aplicável, à duração da meta, ao calendário de horário comercial e aos timestamps necessários para avaliar a meta. Se o Zendesk disponibilizar um evento ou uma métrica de violação, use essa fonte. Caso contrário, calcule a violação somente com dados de política documentados e mantenha a base do cálculo.
Configuração de satisfação: User Satisfaction Rated exige que as avaliações de satisfação estejam habilitadas e que o registro da avaliação esteja acessível pela API. Um ticket resolvido sem avaliação não deve receber um evento de avaliação sintético.
Performance: use paginação por cursor, concorrência controlada para solicitações de auditoria dos tickets, reutilização de conexões, backoff exponencial para limites de taxa e checkpoints após lotes processados com sucesso. Evite solicitar novamente todas as auditorias dos tickets em cada execução.
Completude: as exportações incrementais podem incluir tickets atualizados depois do horário solicitado, mas a recuperação das auditorias e as atualizações recebidas com atraso devem ser tratadas separadamente. Use uma janela de sobreposição e chaves estáveis para eliminar duplicidades.
Pré-requisitos: acesso à API, permissão para ler tickets e auditorias, acesso a usuários e grupos para resolver nomes, acesso aos dados de satisfação quando necessário e acesso aos dados de SLA quando o cálculo de violações for necessário. A disponibilidade de tipos específicos de eventos de auditoria pode variar conforme a configuração e a assinatura do Zendesk.

a Consulta de exemplo python

import csv
import json
import os
import time
from datetime import datetime, timezone, timedelta
from typing import Any, Dict, Iterable, List, Optional, Tuple

import requests

ZENDESK_SUBDOMAIN = os.getenv(class="hl-string">"ZENDESK_SUBDOMAIN", class="hl-string">"[Your Zendesk subdomain]")
API_EMAIL = os.getenv(class="hl-string">"ZENDESK_API_EMAIL", class="hl-string">"[Your API email]")
API_TOKEN = os.getenv(class="hl-string">"ZENDESK_API_TOKEN", class="hl-string">"[Your API token]")
START_DATE = os.getenv(class="hl-string">"START_DATE", class="hl-string">"[Start date in ISO 8601 format]")
OUTPUT_FILE = os.getenv(class="hl-string">"OUTPUT_FILE", class="hl-string">"incident_event_log.csv")
SOURCE_SYSTEM = class="hl-string">"Zendesk Support"
LAST_DATA_UPDATE = datetime.now(timezone.utc).isoformat()

if class="hl-string">"[" in ZENDESK_SUBDOMAIN or class="hl-string">"[" in API_EMAIL or class="hl-string">"[" in API_TOKEN or class="hl-string">"[" in START_DATE:
    raise ValueError(class="hl-string">"Set ZENDESK_SUBDOMAIN, ZENDESK_API_EMAIL, ZENDESK_API_TOKEN, and START_DATE before running")

BASE_URL = fclass="hl-string">"https://{ZENDESK_SUBDOMAIN}.zendesk.com/api/v2"
SESSION = requests.Session()
SESSION.auth = (fclass="hl-string">"{API_EMAIL}/token", API_TOKEN)
SESSION.headers.update({class="hl-string">"Accept": class="hl-string">"application/json"})

FIELDS = [
    class="hl-string">"TicketId", class="hl-string">"ActivityName", class="hl-string">"EventTimestamp", class="hl-string">"SourceSystem", class="hl-string">"LastDataUpdate",
    class="hl-string">"TicketStatus", class="hl-string">"Assignee", class="hl-string">"AssignedGroup", class="hl-string">"TicketPriority", class="hl-string">"Channel",
    class="hl-string">"SlaStatus", class="hl-string">"EventEndTime"
]


def parse_time(value: Optional[str]) -> Optional[datetime]:
    if not value:
        return None
    return datetime.fromisoformat(value.replace(class="hl-string">"Z", class="hl-string">"+00:00"))


def iso(value: Any) -> str:
    if isinstance(value, datetime):
        return value.astimezone(timezone.utc).isoformat()
    if value is None:
        return class="hl-string">""
    return str(value)


def get_json(url: str, params: Optional[Dict[str, Any]] = None) -> Dict[str, Any]:
    for attempt in range(6):
        response = SESSION.get(url, params=params, timeout=60)
        if response.status_code == 429:
            retry_after = int(response.headers.get(class="hl-string">"Retry-After", class="hl-string">"5"))
            time.sleep(max(retry_after, 2 ** attempt))
            continue
        response.raise_for_status()
        return response.json()
    raise RuntimeError(fclass="hl-string">"Request failed after retries: {url}")


def incremental_tickets(start_time: str) -> Iterable[Dict[str, Any]]:
    url = fclass="hl-string">"{BASE_URL}/incremental/tickets/cursor.json"
    params: Optional[Dict[str, Any]] = {class="hl-string">"start_time": int(parse_time(start_time).timestamp())}
    while url:
        payload = get_json(url, params)
        for ticket in payload.get(class="hl-string">"tickets", []):
            yield ticket
        if payload.get(class="hl-string">"end_of_stream"):
            break
        url = payload.get(class="hl-string">"after_url")
        params = None


def ticket_audits(ticket_id: int) -> Iterable[Dict[str, Any]]:
    url = fclass="hl-string">"{BASE_URL}/tickets/{ticket_id}/audits.json"
    while url:
        payload = get_json(url)
        for audit in payload.get(class="hl-string">"audits", []):
            yield audit
        url = payload.get(class="hl-string">"next_page")


def satisfaction_for_ticket(ticket_id: int) -> Iterable[Dict[str, Any]]:
    url = fclass="hl-string">"{BASE_URL}/tickets/{ticket_id}/satisfaction_ratings.json"
    try:
        payload = get_json(url)
    except requests.HTTPError as error:
        if error.response is not None and error.response.status_code in (403, 404):
            return
        raise
    for rating in payload.get(class="hl-string">"satisfaction_ratings", []):
        yield rating


def user_name(user_id: Any, cache: Dict[str, str]) -> str:
    if not user_id:
        return class="hl-string">""
    key = str(user_id)
    if key not in cache:
        payload = get_json(fclass="hl-string">"{BASE_URL}/users/{user_id}.json")
        user = payload.get(class="hl-string">"user", {})
        cache[key] = user.get(class="hl-string">"name") or user.get(class="hl-string">"email") or key
    return cache[key]


def group_name(group_id: Any, cache: Dict[str, str]) -> str:
    if not group_id:
        return class="hl-string">""
    key = str(group_id)
    if key not in cache:
        payload = get_json(fclass="hl-string">"{BASE_URL}/groups/{group_id}.json")
        cache[key] = payload.get(class="hl-string">"group", {}).get(class="hl-string">"name") or key
    return cache[key]


def ticket_context(ticket: Dict[str, Any], users: Dict[str, str], groups: Dict[str, str]) -> Dict[str, str]:
    assignee = user_name(ticket.get(class="hl-string">"assignee_id"), users)
    group = group_name(ticket.get(class="hl-string">"group_id"), groups)
    return {
        class="hl-string">"TicketStatus": str(ticket.get(class="hl-string">"status") or class="hl-string">""),
        class="hl-string">"Assignee": assignee,
        class="hl-string">"AssignedGroup": group,
        class="hl-string">"TicketPriority": str(ticket.get(class="hl-string">"priority") or class="hl-string">""),
        class="hl-string">"Channel": str((ticket.get(class="hl-string">"via") or {}).get(class="hl-string">"channel") or class="hl-string">""),
        class="hl-string">"SlaStatus": class="hl-string">"",
    }


def make_row(ticket_id: Any, activity: str, event_time: Any, context: Dict[str, str], end_time: Any = class="hl-string">"") -> Dict[str, str]:
    row = {
        class="hl-string">"TicketId": str(ticket_id),
        class="hl-string">"ActivityName": activity,
        class="hl-string">"EventTimestamp": iso(event_time),
        class="hl-string">"SourceSystem": SOURCE_SYSTEM,
        class="hl-string">"LastDataUpdate": LAST_DATA_UPDATE,
        class="hl-string">"TicketStatus": context.get(class="hl-string">"TicketStatus", class="hl-string">""),
        class="hl-string">"Assignee": context.get(class="hl-string">"Assignee", class="hl-string">""),
        class="hl-string">"AssignedGroup": context.get(class="hl-string">"AssignedGroup", class="hl-string">""),
        class="hl-string">"TicketPriority": context.get(class="hl-string">"TicketPriority", class="hl-string">""),
        class="hl-string">"Channel": context.get(class="hl-string">"Channel", class="hl-string">""),
        class="hl-string">"SlaStatus": context.get(class="hl-string">"SlaStatus", class="hl-string">""),
        class="hl-string">"EventEndTime": iso(end_time),
    }
    return row


def audit_value(audit_event: Dict[str, Any], field: str) -> Any:
    for change in audit_event.get(class="hl-string">"changes", []):
        if change.get(class="hl-string">"field") == field:
            return change
    return None


def append_audit_rows(ticket: Dict[str, Any], audit: Dict[str, Any], rows: List[Dict[str, str]], users: Dict[str, str], groups: Dict[str, str]) -> None:
    ticket_id = ticket.get(class="hl-string">"id")
    event_time = audit.get(class="hl-string">"created_at")
    context = ticket_context(ticket, users, groups)
    author = user_name(audit.get(class="hl-string">"author_id"), users)
    for change in audit.get(class="hl-string">"events", []):
        event_type = change.get(class="hl-string">"type")
        field = change.get(class="hl-string">"field")
        value = change.get(class="hl-string">"value")
        previous = change.get(class="hl-string">"previous_value")
        if event_type == class="hl-string">"Create" or field == class="hl-string">"created_at":
            rows.append(make_row(ticket_id, class="hl-string">"Incident Created", event_time, context))
        if field == class="hl-string">"group_id" and value is not None:
            context[class="hl-string">"AssignedGroup"] = group_name(value, groups)
            if previous not in (None, class="hl-string">"", value):
                rows.append(make_row(ticket_id, class="hl-string">"Ticket Reassigned", event_time, context))
            else:
                rows.append(make_row(ticket_id, class="hl-string">"Ticket Assigned to Group", event_time, context))
        if field == class="hl-string">"assignee_id" and value is not None:
            context[class="hl-string">"Assignee"] = user_name(value, users)
            if previous not in (None, class="hl-string">"", value):
                rows.append(make_row(ticket_id, class="hl-string">"Ticket Reassigned", event_time, context))
            else:
                rows.append(make_row(ticket_id, class="hl-string">"Ticket Assigned to Agent", event_time, context))
        if field == class="hl-string">"priority" and value is not None:
            context[class="hl-string">"TicketPriority"] = str(value)
            rows.append(make_row(ticket_id, class="hl-string">"Priority Set", event_time, context))
        if field == class="hl-string">"status":
            context[class="hl-string">"TicketStatus"] = str(value or class="hl-string">"")
            if value == class="hl-string">"open":
                rows.append(make_row(ticket_id, class="hl-string">"Status Changed to Open", event_time, context))
            if value == class="hl-string">"pending":
                rows.append(make_row(ticket_id, class="hl-string">"Status Changed to Pending", event_time, context))
            if value == class="hl-string">"solved":
                rows.append(make_row(ticket_id, class="hl-string">"Incident Resolved", event_time, context))
            if value == class="hl-string">"closed":
                rows.append(make_row(ticket_id, class="hl-string">"Incident Closed", event_time, context))
        if event_type == class="hl-string">"Comment":
            if bool(change.get(class="hl-string">"public")):
                rows.append(make_row(ticket_id, class="hl-string">"Public Reply Sent", event_time, context))
            else:
                rows.append(make_row(ticket_id, class="hl-string">"Internal Note Added", event_time, context))


def append_satisfaction_rows(ticket: Dict[str, Any], rows: List[Dict[str, str]], users: Dict[str, str], groups: Dict[str, str]) -> None:
    context = ticket_context(ticket, users, groups)
    for rating in satisfaction_for_ticket(ticket.get(class="hl-string">"id")):
        rated_at = rating.get(class="hl-string">"created_at") or rating.get(class="hl-string">"updated_at")
        if rated_at:
            rows.append(make_row(ticket.get(class="hl-string">"id"), class="hl-string">"User Satisfaction Rated", rated_at, context))


def append_sla_breach_rows(ticket: Dict[str, Any], rows: List[Dict[str, str]], users: Dict[str, str], groups: Dict[str, str]) -> None:
    context = ticket_context(ticket, users, groups)
    sla_breach_time = ticket.get(class="hl-string">"sla_breach_at")
    if sla_breach_time:
        context[class="hl-string">"SlaStatus"] = class="hl-string">"Breached"
        rows.append(make_row(ticket.get(class="hl-string">"id"), class="hl-string">"SLA Target Breached", sla_breach_time, context))


def extract() -> List[Dict[str, str]]:
    rows: List[Dict[str, str]] = []
    users: Dict[str, str] = {}
    groups: Dict[str, str] = {}
    seen = set()
    for ticket in incremental_tickets(START_DATE):
        for audit in ticket_audits(ticket.get(class="hl-string">"id")):
            append_audit_rows(ticket, audit, rows, users, groups)
        append_satisfaction_rows(ticket, rows, users, groups)
        append_sla_breach_rows(ticket, rows, users, groups)
    unique_rows: List[Dict[str, str]] = []
    for row in rows:
        key = (row[class="hl-string">"TicketId"], row[class="hl-string">"ActivityName"], row[class="hl-string">"EventTimestamp"], row[class="hl-string">"Assignee"], row[class="hl-string">"AssignedGroup"])
        if key not in seen:
            seen.add(key)
            unique_rows.append(row)
    unique_rows.sort(key=lambda item: (item[class="hl-string">"TicketId"], item[class="hl-string">"EventTimestamp"], item[class="hl-string">"ActivityName"]))
    return unique_rows


if __name__ == class="hl-string">"__main__":
    event_rows = extract()
    with open(OUTPUT_FILE, class="hl-string">"w", newline=class="hl-string">"", encoding=class="hl-string">"utf-8") as output:
        writer = csv.DictWriter(output, fieldnames=FIELDS)
        writer.writeheader()
        writer.writerows(event_rows)
    print(json.dumps({class="hl-string">"output_file": OUTPUT_FILE, class="hl-string">"rows": len(event_rows), class="hl-string">"last_data_update": LAST_DATA_UPDATE}))

Etapas

Selecione uma ferramenta comercial de ETL ou integração de dados que ofereça um conector verificado para o Zendesk Support, seja compatível com o histórico de auditoria e a extração de comentários dos tickets e consiga gravar dados no seu data warehouse ou sistema de arquivos de destino. Confirme se o conector oferece suporte à extração incremental, paginação, tratamento de limites de taxa e preservação dos timestamps de origem.
Crie a conexão com o Zendesk na ferramenta selecionada. Informe o subdomínio do Zendesk, o método de autenticação, as credenciais ou o token e todas as configurações de conexão necessárias usando a interface de configuração da ferramenta. Conceda acesso a tickets, auditorias de tickets, comentários, usuários, grupos, avaliações de satisfação e dados de SLA quando esses objetos estiverem disponíveis no seu plano do Zendesk e no conector.
Configure a janela de extração. Use um período móvel de 3 a 6 meses para a carga inicial e, depois, configure cargas incrementais com base no timestamp de atualização ou de auditoria compatível com o conector. Armazene o watermark da última extração bem-sucedida fora do Event Log para que as execuções seguintes não dupliquem nem deixem de incluir eventos.
Extraia os dados em nível de ticket necessários para o contexto do caso, incluindo o identificador do ticket, o status atual ou em nível de evento, o responsável, o grupo, a prioridade, o canal de atendimento, o status do SLA e os timestamps de atualização relevantes. Extraia os registros de auditoria dos tickets, pois alterações de atribuição, prioridade, status e outros campos devem ser representadas como linhas de eventos explícitas.
Extraia os comentários dos tickets e diferencie comentários públicos de notas internas usando o indicador de visibilidade pública ou privada do conector. Extraia os timestamps dos comentários, os identificadores dos tickets, os identificadores dos autores e qualquer horário de término ou timestamp de conclusão disponível. Crie linhas Public Reply Sent para comentários públicos e Internal Note Added para comentários privados.
Extraia os registros de avaliações de satisfação e de violações de SLA quando o conector os disponibilizar. Se o conector não expuser eventos de violação de SLA diretamente, configure a ferramenta ETL para calcular as violações com base na meta de SLA, na política, no horário comercial e nos timestamps dos eventos disponíveis. Não crie uma linha de violação a menos que os dados de origem ou um cálculo configurado comprovem que a meta foi violada.
Reestruture os registros de origem extraídos em um Event Log normalizado. Crie uma linha para cada ocorrência explícita de atividade. Mapeie a criação do ticket para Incident Created, alterações de atribuição a grupos para Ticket Assigned to Group ou Ticket Reassigned, alterações de atribuição a agentes para Ticket Assigned to Agent ou Ticket Reassigned, alterações de prioridade para Priority Set, transições de status para a atividade de status correspondente, comentários para Public Reply Sent ou Internal Note Added, status resolvido para Incident Resolved, registros de satisfação para User Satisfaction Rated e status fechado para Incident Closed.
Aplique as regras de classificação de eventos em uma ordem determinística. Use os valores anterior e novo do histórico de auditoria quando estiverem disponíveis. Classifique a primeira atribuição a um grupo como Ticket Assigned to Group, a primeira atribuição a um agente como Ticket Assigned to Agent e as alterações posteriores de responsável como Ticket Reassigned. Emita uma linha para cada alteração qualificada, não apenas para o estado mais recente do ticket.
Preencha as colunas obrigatórias TicketId, ActivityName, EventTimestamp, SourceSystem e LastDataUpdate. Preencha as colunas recomendadas TicketStatus, Assignee, AssignedGroup, TicketPriority, Channel, SlaStatus e EventEndTime a partir do contexto do evento ou do registro de origem válido mais próximo. Preserve os timestamps de origem em um fuso horário consistente, de preferência UTC, mantendo a precisão original compatível com o conector.
Valide a saída transformada verificando se cada TicketId tem uma linha Incident Created, se os timestamps dos eventos estão dentro da janela de extração quando aplicável, se todos os 13 nomes de atividades obrigatórios estão representados quando houver dados de origem e se as chaves de eventos duplicadas são tratadas de acordo com o identificador de auditoria de origem ou com uma chave composta documentada.
Grave o Event Log na tabela ou no arquivo de destino em um formato tabular compatível com o ProcessMind, como CSV ou o formato do conector de data warehouse compatível. Use uma única linha de cabeçalho, nomes de colunas estáveis, codificação UTF-8, timestamps ISO 8601 e nenhum JSON aninhado nas colunas finais de eventos. Faça o upload ou conecte o Event Log resultante ao ProcessMind sem depender de atividades inferidas, pois o ProcessMind lê as linhas extraídas como estão.

Configuração

Conector e licença: use uma ferramenta comercial de ETL ou integração de dados com um conector do Zendesk Support que exponha tickets, auditorias de tickets, comentários, usuários, grupos, avaliações de satisfação e informações de SLA, conforme o suporte oferecido pelo plano do Zendesk e pela versão do conector.
Autenticação e autorização: configure o subdomínio do Zendesk e um método de autenticação aprovado. Conceda somente as permissões necessárias para extrair tickets, auditorias, comentários, usuários, grupos, dados de satisfação e dados de SLA. Confirme que a conta de integração consegue ler registros históricos.
Intervalo de datas: comece com 3 a 6 meses para validação e carga inicial. Amplie o intervalo somente depois de verificar as contagens de linhas, a paginação e o comportamento dos limites de taxa. Use um watermark incremental nas execuções agendadas.
Filtros obrigatórios: aplique somente filtros específicos da empresa confirmados na configuração de origem, como subdomínio selecionado do Zendesk, marca, organização, grupo ou escopo de tickets. Não aplique filtros Company Code ou Document Type a menos que esses campos existam no modelo de dados configurado do Zendesk.
Histórico de auditoria: habilite a extração dos eventos de auditoria dos tickets e mantenha o identificador da auditoria de origem, quando disponível, para evitar eventos duplicados durante cargas incrementais.
Comentários: extraia comentários públicos e privados. Use o indicador de visibilidade da origem para classificar Public Reply Sent e Internal Note Added. Não infira a visibilidade com base no texto do comentário.
Classificação de atribuições: compare os valores anterior e novo do grupo ou do responsável. Classifique a primeira atribuição qualificada separadamente das alterações posteriores e emita Ticket Reassigned para mudanças subsequentes de responsável.
Classificação de status: emita linhas somente para transições de status explícitas. Mapeie os valores new, open, pending, solved e closed de acordo com o modelo de status configurado no Zendesk. Se forem usados status personalizados, documente o mapeamento antes da carga.
Tratamento de SLA: dê preferência aos eventos de violação de SLA da origem. Se não estiverem disponíveis, configure um cálculo documentado usando a meta de SLA, a política, o horário comercial e os timestamps dos eventos disponíveis. Registre a base do cálculo nos metadados do ETL, sem inventar campos de origem.
Tratamento de timestamps: normalize EventTimestamp e EventEndTime para UTC ou outro fuso horário documentado. Preserve o timestamp de origem e evite substituí-lo pelo horário da extração.
LastDataUpdate: defina LastDataUpdate como o timestamp da atualização ETL concluída com sucesso, de forma consistente em todas as linhas dessa carga.
Performance: use paginação, extração incremental, particionamento por atualização do ticket ou timestamp de auditoria, paralelismo controlado, tratamento de novas tentativas e backoff para limites de taxa. Evite extrair repetidamente todo o histórico dos tickets em cada execução agendada.
Esquema de destino: configure uma tabela ou um arquivo de eventos plano com as colunas obrigatórias TicketId, ActivityName, EventTimestamp, SourceSystem e LastDataUpdate, além dos atributos recomendados quando disponíveis.
Comportamento do ProcessMind: não dependa do ProcessMind para derivar alterações de status, atribuições, respostas, notas, violações de SLA ou marcos do ciclo de vida. Cada atividade já deve existir como uma linha de evento antes do upload.

a Consulta de exemplo config

-- Configure this transformation in the selected ETL tool using its Zendesk connector.
-- Replace bracketed connection, credential, date, and company-specific values in the tool configuration.
-- The connector source objects and field mappings must be selected from the tool's verified Zendesk schema.

WITH
source_tickets AS (
    SELECT
        ticket_id,
        created_at,
        status,
        assignee,
        assigned_group,
        priority,
        channel,
        sla_status,
        updated_at
    FROM [Your Zendesk tickets source]
    WHERE updated_at >= [Start date parameter]
      AND updated_at < [End date parameter]
),
source_audits AS (
    SELECT
        ticket_id,
        audit_id,
        event_timestamp,
        event_type,
        previous_value,
        new_value,
        status,
        assignee,
        assigned_group,
        priority,
        channel,
        sla_status,
        event_end_time
    FROM [Your Zendesk ticket audits source]
    WHERE event_timestamp >= [Start date parameter]
      AND event_timestamp < [End date parameter]
),
source_comments AS (
    SELECT
        ticket_id,
        comment_id,
        event_timestamp,
        is_public,
        status,
        assignee,
        assigned_group,
        priority,
        channel,
        sla_status,
        event_end_time
    FROM [Your Zendesk ticket comments source]
    WHERE event_timestamp >= [Start date parameter]
      AND event_timestamp < [End date parameter]
),
source_sla_breaches AS (
    SELECT
        ticket_id,
        breach_timestamp,
        status,
        assignee,
        assigned_group,
        priority,
        channel,
        sla_status,
        event_end_time
    FROM [Your Zendesk SLA breach source]
    WHERE breach_timestamp >= [Start date parameter]
      AND breach_timestamp < [End date parameter]
),
source_satisfaction AS (
    SELECT
        ticket_id,
        rating_timestamp,
        status,
        assignee,
        assigned_group,
        priority,
        channel,
        sla_status,
        event_end_time
    FROM [Your Zendesk satisfaction rating source]
    WHERE rating_timestamp >= [Start date parameter]
      AND rating_timestamp < [End date parameter]
),
classified_audits AS (
    SELECT
        a.*,
        ROW_NUMBER() OVER (
            PARTITION BY a.ticket_id, a.event_type
            ORDER BY a.event_timestamp, a.audit_id
        ) AS event_sequence
    FROM source_audits a
),
event_log AS (
    SELECT
        CAST(t.ticket_id AS VARCHAR(255)) AS TicketId,
        'Incident Created' AS ActivityName,
        t.created_at AS EventTimestamp,
        'Zendesk Support' AS SourceSystem,
        [ETL refresh timestamp] AS LastDataUpdate,
        t.status AS TicketStatus,
        t.assignee AS Assignee,
        t.assigned_group AS AssignedGroup,
        t.priority AS TicketPriority,
        t.channel AS Channel,
        t.sla_status AS SlaStatus,
        CAST(NULL AS TIMESTAMP) AS EventEndTime
    FROM source_tickets t

    UNION ALL

    SELECT
        CAST(a.ticket_id AS VARCHAR(255)),
        'Ticket Assigned to Group',
        a.event_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        a.status,
        a.assignee,
        a.assigned_group,
        a.priority,
        a.channel,
        a.sla_status,
        a.event_end_time
    FROM classified_audits a
    WHERE a.event_type = 'group_assignment'
      AND a.event_sequence = 1
      AND a.new_value IS NOT NULL

    UNION ALL

    SELECT
        CAST(a.ticket_id AS VARCHAR(255)),
        'Ticket Assigned to Agent',
        a.event_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        a.status,
        a.assignee,
        a.assigned_group,
        a.priority,
        a.channel,
        a.sla_status,
        a.event_end_time
    FROM classified_audits a
    WHERE a.event_type = 'assignee_assignment'
      AND a.event_sequence = 1
      AND a.new_value IS NOT NULL

    UNION ALL

    SELECT
        CAST(a.ticket_id AS VARCHAR(255)),
        'Priority Set',
        a.event_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        a.status,
        a.assignee,
        a.assigned_group,
        a.new_value,
        a.channel,
        a.sla_status,
        a.event_end_time
    FROM classified_audits a
    WHERE a.event_type = 'priority_change'
      AND a.new_value IS NOT NULL

    UNION ALL

    SELECT
        CAST(a.ticket_id AS VARCHAR(255)),
        'Status Changed to Open',
        a.event_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        a.new_value,
        a.assignee,
        a.assigned_group,
        a.priority,
        a.channel,
        a.sla_status,
        a.event_end_time
    FROM classified_audits a
    WHERE a.event_type = 'status_change'
      AND a.previous_value = 'new'
      AND a.new_value = 'open'

    UNION ALL

    SELECT
        CAST(c.ticket_id AS VARCHAR(255)),
        'Public Reply Sent',
        c.event_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        c.status,
        c.assignee,
        c.assigned_group,
        c.priority,
        c.channel,
        c.sla_status,
        c.event_end_time
    FROM source_comments c
    WHERE c.is_public = TRUE

    UNION ALL

    SELECT
        CAST(c.ticket_id AS VARCHAR(255)),
        'Internal Note Added',
        c.event_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        c.status,
        c.assignee,
        c.assigned_group,
        c.priority,
        c.channel,
        c.sla_status,
        c.event_end_time
    FROM source_comments c
    WHERE c.is_public = FALSE

    UNION ALL

    SELECT
        CAST(a.ticket_id AS VARCHAR(255)),
        'Ticket Reassigned',
        a.event_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        a.status,
        a.assignee,
        a.assigned_group,
        a.priority,
        a.channel,
        a.sla_status,
        a.event_end_time
    FROM classified_audits a
    WHERE a.event_type IN ('group_assignment', 'assignee_assignment')
      AND a.event_sequence > 1
      AND COALESCE(a.previous_value, '') <> COALESCE(a.new_value, '')

    UNION ALL

    SELECT
        CAST(a.ticket_id AS VARCHAR(255)),
        'Status Changed to Pending',
        a.event_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        a.new_value,
        a.assignee,
        a.assigned_group,
        a.priority,
        a.channel,
        a.sla_status,
        a.event_end_time
    FROM classified_audits a
    WHERE a.event_type = 'status_change'
      AND a.new_value = 'pending'

    UNION ALL

    SELECT
        CAST(s.ticket_id AS VARCHAR(255)),
        'SLA Target Breached',
        s.breach_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        s.status,
        s.assignee,
        s.assigned_group,
        s.priority,
        s.channel,
        s.sla_status,
        s.event_end_time
    FROM source_sla_breaches s
    WHERE s.breach_timestamp IS NOT NULL

    UNION ALL

    SELECT
        CAST(a.ticket_id AS VARCHAR(255)),
        'Incident Resolved',
        a.event_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        a.new_value,
        a.assignee,
        a.assigned_group,
        a.priority,
        a.channel,
        a.sla_status,
        a.event_end_time
    FROM classified_audits a
    WHERE a.event_type = 'status_change'
      AND a.new_value = 'solved'

    UNION ALL

    SELECT
        CAST(s.ticket_id AS VARCHAR(255)),
        'User Satisfaction Rated',
        s.rating_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        s.status,
        s.assignee,
        s.assigned_group,
        s.priority,
        s.channel,
        s.sla_status,
        s.event_end_time
    FROM source_satisfaction s
    WHERE s.rating_timestamp IS NOT NULL

    UNION ALL

    SELECT
        CAST(a.ticket_id AS VARCHAR(255)),
        'Incident Closed',
        a.event_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        a.new_value,
        a.assignee,
        a.assigned_group,
        a.priority,
        a.channel,
        a.sla_status,
        a.event_end_time
    FROM classified_audits a
    WHERE a.event_type = 'status_change'
      AND a.new_value = 'closed'
)
SELECT
    TicketId,
    ActivityName,
    EventTimestamp,
    SourceSystem,
    LastDataUpdate,
    TicketStatus,
    Assignee,
    AssignedGroup,
    TicketPriority,
    Channel,
    SlaStatus,
    EventEndTime
FROM event_log
WHERE TicketId IS NOT NULL
  AND ActivityName IS NOT NULL
  AND EventTimestamp IS NOT NULL
ORDER BY TicketId, EventTimestamp, ActivityName;

Pronto para começar?

Use este Template para simplificar a preparação dos seus dados e obter insights valiosos sobre a performance do gerenciamento de incidentes. Comece a otimizar seu processo hoje.

Voltar ao guia de melhoria Baixar Template

Otimize o gerenciamento de incidentes e resolva mais rápido hoje

Reduza o MTTR em 35%, elimine incidentes recorrentes e aumente a satisfação.

Começar o teste grátis

Não é necessário cartão de crédito. Comece a melhorar em poucos minutos.

Seu Template de dados para gerenciamento de incidentes

Seu Template de dados para gerenciamento de incidentes

Atributos de Gestão de Incidentes

Atividades de Gestão de Incidentes

Guias de extração

Exportação do relatório da interface do Zendesk Explore para arquivo CSV

Etapas

Configuração

a Consulta de exemplo config

Script Python usando a API REST do Zendesk Support

Etapas

Configuração

a Consulta de exemplo python

API de exportação incremental do Zendesk para sincronização em massa de dados

Etapas

Configuração

a Consulta de exemplo python

Ferramenta ETL de terceiros com conector da API do Zendesk

Etapas

Configuração

a Consulta de exemplo config

Pronto para começar?

Otimize o gerenciamento de incidentes e resolva mais rápido hoje

Seu Template de dados para gerenciamento de incidentes

Seu Template de dados para gerenciamento de incidentes

Atributos de Gestão de Incidentes

Atividades de Gestão de Incidentes

Guias de extração

Exportação do relatório da interface do Zendesk Explore para arquivo CSV

Etapas

Configuração

a Consulta de exemplo config

Script Python usando a API REST do Zendesk Support

Etapas

Configuração

a Consulta de exemplo python

API de exportação incremental do Zendesk para sincronização em massa de dados

Etapas

Configuração

a Consulta de exemplo python

Ferramenta ETL de terceiros com conector da API do Zendesk

Etapas

Configuração

a Consulta de exemplo config

Pronto para começar?

Otimize o gerenciamento de incidentes e resolva mais rápido hoje

Valorizamos sua privacidade