> Melhoria Contínua de Processos > Gerenciamento de Incidentes > Zendesk Support > Modelo de Dados

Seu template de dados para Gestão de Incidentes

Zendesk Support

Atributos de Gerenciamento de Incidentes (24) Atividades de Gerenciamento de Incidentes (13) Guias de Extração (4)

Seu template de dados para Gestão de Incidentes

Este template oferece uma visão estruturada dos dados essenciais para analisar seu processo de gestão de incidentes. Ele detalha atributos-chave para coletar, atividades críticas para rastrear e inclui guias práticos para extrair dados do Zendesk Support. Use-o para garantir que seu projeto de Process Mining comece com um conjunto de dados robusto e completo.

Atributos recomendados para coletar
Principais atividades para acompanhar no mapeamento do processo
Orientação prática para extração de dados

É novo em event logs? Saiba como criar um event log para Process Mining.

Baixar Modelo

Atributos de Gerenciamento de Incidentes

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

5 Obrigatório 7 Recomendado 12 Opcional

	Nome	Descrição
	Event Timestamp EventTimestamp	A data e hora exatas em que a atividade ocorreu.
Descrição Este carimbo registra o momento exato em que um evento ocorreu, como a inclusão de um comentário ou mudança de status. Ele define a ordem cronológica das atividades de um caso. Este atributo é fundamental para qualquer análise temporal de Process Mining. Serve para calcular tempos de ciclo entre atividades, identificar esperas, medir a duração total do caso e analisar a performance em diferentes períodos. Carimbos precisos são vitais para criar mapas de processos animados e construir Dashboards que acompanham KPIs como o tempo médio de resolução. Por que é importante Os carimbos de data/hora fornecem o contexto cronológico de todas as atividades, permitindo o cálculo de durações, a identificação de gargalos e a análise de performance do processo ao longo do tempo. Onde obter API de Auditoria de Tickets do Zendesk (/api/v2/tickets/{ticket_id}/audits), campo created_at para cada evento de auditoria. Exemplos 2023-04-15T10:00:00Z2023-04-15T10:05:12Z2023-04-16T14:30:00Z
	ID do incidente TicketId	O identificador único gerado pelo sistema para cada ticket de incidente.
Descrição O ID do Incidente é a chave primária que identifica cada caso de forma única no Zendesk Support. Ele serve como o CaseId para o Process Mining, vinculando todas as atividades, mudanças de status e comunicações desde a criação até o fechamento. Na análise, este ID é crucial para reconstruir a jornada ponta a ponta de cada incidente. Ele permite agregar dados de eventos para rastrear métricas como tempo total de resolução, número de transferências e adesão ao SLA. Ao agrupar eventos por este ID, é possível visualizar fluxos, identificar caminhos comuns e detectar desvios do procedimento padrão. Por que é importante 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
	Atividade ActivityName	O nome da atividade de negócio ou evento que ocorreu em um ponto específico do ciclo de vida do incidente.
Descrição Este atributo descreve um passo ou ação no processo, como 'Incidente Criado', 'Ticket Atribuído ao Agente' ou 'Incidente Resolvido'. Estas atividades vêm do Event Log ou do histórico de auditoria do Zendesk. No Process Mining, a sequência dessas atividades forma o mapa do processo, base de toda a análise. Ao analisar o fluxo, as empresas descobrem os caminhos reais dos incidentes, identificam gargalos, medem loops de retrabalho (ex: reabertura de tickets) e verificam a conformidade com o processo padrão definido. Por que é importante 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 Auditoria do Zendesk. Por exemplo: uma alteração no campo status mapeada como 'Status Alterado'. Exemplos Incidente criadoTicket atribuído ao agenteStatus alterado para PendenteIncidente resolvidoIncidente fechado
	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. Para esta visão, o valor seria estático, como 'Zendesk Support', indicando a fonte de todos os eventos. Em ambientes que combinam dados de múltiplos sistemas, este campo é crítico para distinguir as fontes. Garante a integridade dos dados e permite análises específicas, como comparar o processo de gestão de incidentes no Zendesk com outra ferramenta de ITSM. Por que é importante Identifica a origem dos dados, algo crucial para a governança e para análises que cruzam informações de múltiplos sistemas. Onde obter Valor estático definido durante a transformação de dados para identificar a origem dos dados. Exemplos Zendesk SupportZendesk
	Última Atualização de Dados LastDataUpdate	O carimbo de data/hora indicando quando os dados deste processo foram atualizados pela última vez.
Descrição Este atributo registra a data e hora da extração ou atualização mais recente do sistema de origem. Geralmente é um valor único aplicado a todo o conjunto de dados de um ciclo de atualização. Esta informação é vital para a governança de dados e para os usuários da análise de Process Mining. Fornece contexto sobre a atualidade dos dados, ajudando os analistas a saberem se estão vendo a informação mais recente. Isso é crucial para monitorar a performance operacional e tomar decisões ágeis com base na análise. Por que é importante Oferece um contexto crucial sobre a atualização dos dados, garantindo que os usuários entendam quão recente é a análise e quando os dados foram coletados pela última vez. Onde obter Carimbo de data/hora gerado pelo processo de pipeline de dados/ETL 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 individual atualmente atribuído para tratar o incidente.
Descrição Este atributo identifica o agente responsável pelo incidente em um dado momento. Mudanças de responsável são eventos críticos que sinalizam uma transferência de trabalho (handoff). Analisar o responsável ajuda a entender a distribuição de carga, a performance individual e os padrões de colaboração. Rastrear essas mudanças é essencial para calcular o KPI de 'Média de Transferências por Incidente' e identificar situações onde tickets circulam demais, o que pode indicar lacunas de conhecimento ou roteamento ineficiente. Por que é importante Identifica o agente responsável, permitindo analisar a carga de trabalho e rastrear transferências, essencial para localizar ineficiências. Onde obter API de Tickets do Zendesk, campo assignee_id. As mudanças são registradas na API de Auditoria de Tickets. Exemplos John SmithJane DoeAutomação de Service Desk
	Canal de registro Channel	O canal pelo qual o incidente foi inicialmente reportado, como 'E-mail', 'Web' ou 'API'.
Descrição Este atributo captura o método usado pelo usuário ou sistema para criar o ticket. Entender o canal é vital para analisar as fontes de incidentes e adaptar o suporte. Analisar incidentes por canal pode revelar padrões distintos. Por exemplo, incidentes via telefone podem ter resoluções mais rápidas que por e-mail. Esta informação alimenta o Dashboard de 'Volume de Processamento de Incidentes' e ajuda no planejamento de recursos e otimização de canais. Por que é importante Ajuda a analisar o volume e o desempenho por origem, permitindo melhorias focadas em canais específicos e na alocação de recursos. Onde obter API de Tickets do Zendesk, campo via.channel. Exemplos webe-mailapitelefone
	Event End Time EventEndTime	O timestamp que indica quando uma atividade foi concluída.
Descrição O Horário de Término do Evento marca a conclusão de uma atividade. Em dados de Event Log, o término de uma atividade costuma ser inferido como o início da próxima. Para a última atividade, o término pode ser igual ao início. Este atributo é essencial para calcular a duração de atividades individuais (Tempo de Processamento) e o tempo de espera entre elas. Essa informação é a base para a análise de gargalos, permitindo que os analistas vejam não apenas quanto tempo um passo demora, mas quanto tempo o caso ficou parado antes de começar. Por que é importante Permite calcular durações de atividades e tempos de espera, base fundamental para análise de gargalos e identificação de atrasos. Onde obter Calculado como o horário de início do evento subsequente no mesmo caso. Para o último evento, pode ser o horário de início ou o fechamento do caso. Exemplos 2023-04-15T10:05:12Z2023-04-16T14:30:00Z2023-04-16T18:00:00Z
	Grupo Atribuído AssignedGroup	A equipe ou grupo de suporte atualmente atribuído ao incidente.
Descrição Este atributo indica qual equipe é responsável pelo incidente. Incidentes costumam transitar entre níveis de suporte ou grupos especializados (ex: do 'Suporte N1' para a 'Equipe de Rede'). Esta é uma dimensão crítica para analisar transferências e identificar gargalos. Ao monitorar o fluxo entre grupos, analistas medem dependências, calculam tempos de fila para equipes específicas e otimizam regras de roteamento. Suporta diretamente o Dashboard de 'Análise de Transferências e Retrabalho'. Por que é importante Rastreia a responsabilidade da equipe, o que é essencial para analisar transferências entre times, identificar gargalos específicos e medir tempos de fila. Onde obter API de Tickets do Zendesk, campo group_id. As mudanças são registradas na API de Auditoria de Tickets. Exemplos Suporte Nível 1Equipe de Redes L2Infraestrutura L3Faturamento
	Prioridade TicketPriority	O nível de prioridade atribuído ao incidente, como 'Baixa', 'Normal', 'Alta' ou 'Urgente'.
Descrição A prioridade de um incidente determina a urgência de resposta e resolução. É um fator-chave na priorização do trabalho e alocação de recursos da equipe de suporte. Na análise de processos, a prioridade serve para segmentar incidentes e comparar fluxos e desempenho. Por exemplo, analistas podem verificar se incidentes 'Urgentes' são realmente resolvidos mais rápido que os de prioridade 'Baixa'. Também monitora a conformidade de SLA, pois os prazos variam por prioridade. O KPI 'Taxa de Mudança de Prioridade' depende do rastreamento deste campo. Por que é importante Este atributo é crucial para segmentar análises, avaliar a eficácia da priorização e monitorar a conformidade de SLA para diferentes níveis de urgência. Onde obter API de Tickets do Zendesk, campo priority. As mudanças são registradas na API de Auditoria de Tickets. Exemplos baixanormalaltaurgente
	Status do SLA SlaStatus	O status atual do Acordo de Nível de Serviço (SLA) para o incidente.
Descrição Este atributo indica se um incidente está no prazo do SLA, se já foi violado ou se os cronômetros estão pausados. O Zendesk rastreia isso automaticamente com base em suas políticas. É um atributo vital para o Dashboard de 'Monitoramento de Conformidade de SLA'. Ele mede diretamente o desempenho em relação aos compromissos de serviço. Ao analisar quando e por que os SLAs são violados, as empresas identificam fraquezas no processo e melhoram a confiabilidade, alimentando o KPI de 'Taxa de Adesão ao SLA de Incidentes'. Por que é importante Mede o desempenho em relação aos compromissos de serviço, permitindo analisar falhas de SLA e monitorar a conformidade proativamente. Onde obter API de Métricas de Tickets do Zendesk (/api/v2/ticket_metrics.json), derivado de campos como sla_policy, breached_at, etc. Exemplos AtivoPausadoVioladoAtendido
	Status do Ticket TicketStatus	O status do ticket de incidente no momento do evento, como 'Aberto', 'Pendente' ou 'Resolvido'.
Descrição Este atributo reflete o estado do ticket em diferentes momentos do seu ciclo de vida. Os status padrão do Zendesk incluem novo, aberto, pendente, em espera, resolvido e fechado. Rastrear as mudanças neste campo é a forma principal de gerar atividades para o Process Mining. Analisar o status do ticket é fundamental para entender o processo. Ajuda a identificar quanto tempo os incidentes passam em certos estados, como 'Pendente', que muitas vezes indica espera pela resposta do cliente. Também é essencial para definir a conclusão de casos e calcular tempos de resolução. Por que é importante Rastrear mudanças de status é a chave para entender o progresso do processo, identificar tempos de espera e definir os pontos de início e fim do ciclo de vida do incidente. Onde obter API de Tickets do Zendesk, campo status. As mudanças são registradas na API de Auditoria de Tickets. Exemplos novoopenpendingresolvidofechado
	Autor Submitter	O usuário final ou sistema que reportou o incidente originalmente.
Descrição Este atributo identifica quem criou o ticket. É diferente do solicitante, pois um agente pode criar um ticket em nome de outra pessoa. Na análise, o emissor ajuda a entender quem está reportando os problemas. Combinado com dados da organização, pode identificar se clientes ou grupos específicos sofrem com alto volume de incidentes, orientando iniciativas de suporte proativo ou treinamentos. Por que é importante Identifica a origem do relato do incidente, permitindo encontrar padrões ligados a usuários, departamentos ou sistemas automatizados. Onde obter API de Tickets do Zendesk, campo submitter_id. Exemplos alice.jones@example.combob.williams@example.comMonitor do Sistema
	Avaliação de Satisfação SatisfactionRating	A avaliação de satisfação fornecida pelo usuário final após a resolução do incidente.
Descrição Este atributo captura o feedback do cliente sobre a experiência de suporte, geralmente via pesquisa após o ticket ser resolvido. No Zendesk, as avaliações comuns são 'Bom' ou 'Ruim'. Embora não meça a eficiência do processo diretamente, as notas de satisfação são métricas de resultado críticas. No Process Mining, podem ser correlacionadas com variantes do processo para entender quais caminhos levam a uma satisfação maior. Por exemplo: incidentes com mais transferências recebem notas menores? Por que é importante Fornece uma métrica de resultado essencial que pode ser correlacionada com as características do processo para entender como a performance 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 classifica o motivo fundamental do incidente. Geralmente é capturado ao final do ciclo de vida, em processos de post-mortem ou gestão de problemas, em um campo personalizado. Estes dados são essenciais para o Dashboard de 'Precisão de Identificação de Causa Raiz' e o KPI de 'Cobertura de RCA'. Analisar incidentes pela causa raiz ajuda a identificar problemas recorrentes, orientando soluções definitivas e reduzindo o volume futuro de chamados. Muda o foco do combate reativo a incêndios para a prevenção proativa de problemas. Por que é importante Permite a gestão proativa de problemas ao categorizar causas, ajudando a identificar tendências e evitar novos incidentes. Onde obter Geralmente é um campo de ticket personalizado. Verifique a configuração de Campos de Ticket na Central de Administração do Zendesk. Exemplos Bug de softwareFalha de hardwareErro do usuárioInterrupção de rede
	Duração do Caso CaseDuration	O tempo total decorrido desde a criação do incidente até o seu fechamento final.
Descrição Esta métrica representa o tempo total do ciclo de um único incidente. É calculada pela diferença entre o primeiro evento (ex: 'Incidente Criado') e o último (ex: 'Incidente Fechado'). A Duração do Caso é um KPI primordial para a eficiência geral do processo. É muito usada em Dashboards para mostrar tempos médios de ciclo, identificar casos longos e analisar tendências. Oferece uma visão macro de quão rápido o processo consegue processar e resolver incidentes. Por que é importante Este é um KPI crítico para medir a velocidade geral do processo e identificar fatores que contribuem para tempos de resolução longos. Onde obter Calculado pela diferença entre o timestamp do último e do primeiro evento de cada ID de incidente. Exemplos 25920060480086400
	É Automatizado IsAutomated	Uma flag booleana que indica se a atividade foi realizada por um sistema automatizado ou por um agente humano.
Descrição Este atributo derivado ajuda a distinguir eventos feitos por humanos daqueles realizados por automações, gatilhos ou APIs. Geralmente é determinado verificando se o autor é um usuário do sistema. Entender o nível de automação é crucial para a análise de processos moderna. Ajuda a avaliar a eficácia das regras de automação, identificar tarefas manuais que poderiam ser automatizadas e medir o impacto da automação na eficiência. Este atributo permite comparar os fluxos de atividades automáticas versus manuais. Por que é importante Distingue ações humanas de sistêmicas, essencial para medir o impacto da automação e identificar novas oportunidades de automatizar tarefas. Onde obter Derivado ao verificar se o autor do evento (author_id na API) corresponde a um usuário de sistema ou automação conhecido. Exemplos verdadeirofalse
	É Resolução no Primeiro Contato IsFirstContactResolution	Uma flag booleana que é verdadeira se o incidente foi resolvido pelo primeiro agente ou grupo atribuído, sem transferências.
Descrição A Resolução no Primeiro Contato (FCR) é vital para a eficiência e satisfação. Este atributo identifica incidentes resolvidos sem reatribuição. A lógica verifica se o ticket foi 'Resolvido' ainda com o primeiro agente/grupo. No Process Mining, isso permite comparar caminhos de FCR com os de escalonamento, revelando como capacitar melhor a linha de frente. Por que é importante Mede a eficiência do primeiro contato e ajuda a identificar oportunidades de resolver problemas mais cedo no processo. Onde obter Flag booleana calculada. Verdadeira se o status for 'resolvido' ou 'fechado' e houve apenas um agente ou grupo atribuído durante todo o ciclo. Exemplos verdadeirofalse
	Gravidade Severity	O nível de impacto que o incidente tem no negócio.
Descrição A severidade define o impacto de um incidente nos negócios, muitas vezes em conjunto com a prioridade para determinar a urgência geral. Geralmente é configurada como um campo personalizado no Zendesk. Analisar a severidade ajuda a entender a criticidade dos incidentes tratados. É uma dimensão fundamental para segmentar dados em Dashboards como 'Monitoramento de Conformidade de SLA' e 'Métricas de Eficácia de Priorização'. Comparar fluxos de processos para diferentes níveis de severidade pode revelar se incidentes graves estão sendo tratados com a velocidade e os recursos adequados. Por que é importante Indica o impacto para o negócio, permitindo focar a análise nos problemas mais críticos e garantir sua resolução eficiente. Onde obter Geralmente é um campo personalizado. Verifique a configuração de Campos de Ticket na Central de Administração do Zendesk. Exemplos 1 - Crítico2 - Alto3 - Médio4 - Baixo
	Número de transferências HandoffCount	O número total de vezes que um incidente foi reatribuído a um agente ou grupo diferente.
Descrição Esta métrica calculada quantifica quantas vezes a responsabilidade por um incidente foi transferida. Cada mudança no campo de Responsável ou Grupo Atribuído incrementa essa contagem. As transferências (handoffs) são fontes comuns de ineficiência e atraso. Uma contagem alta pode indicar regras de roteamento confusas, lacunas de conhecimento ou processos complexos demais. Esta métrica baseia o KPI de 'Média de Transferências por Incidente' e é crucial para o Dashboard de 'Análise de Transferências e Retrabalho'. Por que é importante Quantifica a fricção do processo causada por transferências, ajudando a identificar ineficiências de roteamento e lacunas de conhecimento que prolongam o tempo de resolução. Onde obter Calculado contando quantas vezes os campos AssignedGroup ou Assignee foram alterados em um incidente. Exemplos 0135
	Organização do Cliente Organization	A organização ou empresa à qual o solicitante do incidente pertence.
Descrição Este atributo vincula um incidente à organização do cliente. É essencial em ambientes B2B onde os níveis de serviço e processos podem variar por cliente. Analisar incidentes por organização permite que as equipes de suporte monitorem a saúde do cliente, identifiquem problemas recorrentes que afetam contas específicas e garantam o cumprimento de obrigações contratuais. É uma dimensão-chave para filtrar Dashboards e relatórios, oferecendo uma visão de performance focada no cliente. Por que é importante Permite análises específicas por cliente, ajudando a monitorar níveis de serviço e identificar tendências em contas estratégicas. Onde obter API de Tickets do Zendesk, campo organization_id. Exemplos Global Tech Inc.Innovate SolutionsData Corp
	Tags Tags	Uma lista de tags aplicadas ao incidente para categorização e contexto.
Descrição As Tags são etiquetas flexíveis que podem ser adicionadas aos tickets para fornecer contexto extra ou ajudar na categorização e roteamento. Podem ser inseridas manualmente por agentes ou automaticamente via gatilhos. As tags são uma fonte riquíssima de dados para o Process Mining. Elas podem ser usadas para criar segmentos de análise detalhados, como filtrar incidentes relacionados ao lançamento de um produto específico ('launch_q4') ou a uma queda de sistema conhecida ('outage_20231027'). Essa flexibilidade permite investigações profundas que vão além dos campos padrão de tickets. Por que é importante Oferece uma maneira flexível de categorizar e filtrar incidentes, permitindo uma análise detalhada e específica que não seria possível apenas com os campos padrão. Onde obter API de Tickets do Zendesk, campo tags. Exemplos vip_usernetwork_issueoutage_20231027billing_related
	Tempo de Processamento ProcessingTime	A duração de uma única atividade, representando o tempo gasto trabalhando ativamente em uma tarefa.
Descrição Esta métrica mede o tempo decorrido do início ao fim de uma atividade. É a diferença entre o Horário de Término e o Horário do Evento no Event Log. O Tempo de Processamento (ou duração da atividade) ajuda a diferenciar o trabalho ativo do tempo de espera. No Dashboard de 'Visão Geral de Atividades de Gargalo', tempos médios altos podem indicar tarefas complexas e demoradas. Isso é diferente do tempo de espera, que representa atrasos entre as tarefas. Por que é importante Mede o tempo de trabalho ativo em tarefas específicas, ajudando a identificar o que consome muito tempo e pode ser simplificado ou automatizado. Onde obter Calculado como a diferença entre EventEndTime e EventTimestamp para cada atividade. Exemplos 30018003600
	Tipo de Ticket TicketType	A classificação do ticket, como 'Incidente', 'Problema', 'Pergunta' ou 'Tarefa'.
Descrição Este campo categoriza o ticket conforme a natureza da solicitação. O processo de gestão de incidentes foca especificamente em tickets do tipo 'Incidente', que representam interrupções não planejadas ou redução na qualidade de um serviço de TI. Na análise, este atributo serve principalmente como filtro para garantir que apenas incidentes apareçam na visão do processo. Também pode ser usado em análises de ITSM mais amplas para comparar o tratamento de incidentes versus problemas ou solicitações de serviço. Por que é importante Permite filtrar os dados para focar especificamente em incidentes, garantindo que a análise seja relevante para o ciclo de vida da gestão de incidentes. Onde obter API de Tickets do Zendesk, campo type. Exemplos incidenteproblemaperguntatarefa

Obrigatório Recomendado Opcional

Atividades de Gerenciamento de Incidentes

Estes são os passos e marcos críticos do processo que devem ser capturados no seu Event Log para uma descoberta e análise precisas.

6 Recomendado 7 Opcional

	Atividade	Descrição
	Incidente criado	Marca o início do ciclo de vida quando um ticket é criado. Capturado pelo log de auditoria, serve como o ponto de partida de cada caso.
Por que é importante Esta é a atividade inicial principal. Analisar o tempo deste evento para os outros é crucial para medir a duração total do ciclo de vida do ticket e os tempos de resposta iniciais. Onde obter Este é um evento explícito capturado nos logs de auditoria do Zendesk. Cada novo ticket gera um evento de 'Criação' com seu respectivo carimbo de data/hora. Captura Extraído diretamente do evento de criação do ticket no log de auditoria. Tipo de evento explicit
	Incidente fechado	Marca o encerramento definitivo quando o ticket é fechado. No Zendesk, isso costuma ser automático após um tempo da resolução e é registrado como mudança final de status.
Por que é importante Esta é a atividade final definitiva do processo. A duração total é calculada desde 'Incidente Criado' até este evento, fornecendo uma visão ponta a ponta do tempo de ciclo. Onde obter Capturado do log de auditoria via evento de alteração onde o novo valor do campo 'status' é 'closed' (fechado). Captura Identificado por uma alteração no campo 'status' para 'fechado'. Tipo de evento explicit
	Incidente resolvido	Este marco importante ocorre quando um agente implementa uma solução e marca o ticket como 'resolvido'. É uma ação explícita, capturada como mudança de status no log de auditoria.
Por que é importante Esta é a principal atividade de resolução e um ponto crítico para medir o tempo de resolução. O tempo entre este evento e o 'Incidente Fechado' representa o período de confirmação do usuário ou fechamento automático. Onde obter Capturado do log de auditoria via evento de alteração onde o novo valor do campo 'status' é 'solved' (resolvido). Captura Identificado por uma alteração no campo 'status' para 'resolvido'. Tipo de evento explicit
	Status Alterado para Aberto	Indica que o agente começou a trabalhar no incidente. Geralmente é inferido quando o status muda de 'novo' para 'aberto', marcando o início da fase de diagnóstico.
Por que é importante Este evento marca a transição da fila para o trabalho ativo. O tempo que os tickets passam no status 'novo' antes de irem para 'aberto' é uma métrica essencial para o tempo de resposta inicial. Onde obter Inferido do log de auditoria ao identificar a mudança de status de 'novo' para 'aberto'. Captura Inferido a partir da mudança de status de 'novo' para 'aberto'. Tipo de evento inferred
	Ticket atribuído ao agente	Esta atividade ocorre quando um ticket é atribuído a um agente específico. É um evento explícito registrado no histórico de auditoria e significa que um indivíduo assumiu a responsabilidade.
Por que é importante Este 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 (FCR). Onde obter Capturado do log de auditoria quando o campo 'assignee_id' é preenchido ou alterado. A primeira atribuição é um marco para o cálculo de KPIs. Captura Identificado por um evento de alteração no campo 'assignee_id' no log de auditoria. Tipo de evento explicit
	Ticket Reatribu#do	Ocorre quando a responsabilidade pelo ticket é passada para outro agente ou grupo após a primeira atribuição. Evento rastreado no histórico de auditoria.
Por que é importante Reatribuições são críticas para analisar transferências e retrabalho. Uma alta frequência de reatribuições geralmente indica erro no roteamento inicial, problemas complexos ou gargalos no processo. Onde obter Capturado do log de auditoria ao identificar mudanças nos campos 'assignee_id' ou 'group_id' após o preenchimento inicial. Captura Identificado por uma alteração posterior nos campos 'assignee_id' ou 'group_id'. Tipo de evento explicit
	Meta de SLA violada	Marca o momento em que o ticket viola um SLA (ex: tempo de resposta ou resolução). Calculado com base nas regras de SLA e timestamps de atualização.
Por que é importante Este evento apoia diretamente o monitoramento de conformidade de SLA. Identificar quando e por que as violações ocorrem é fundamental para aumentar a confiabilidade do serviço e a confiança do cliente. Onde obter Este é um evento calculado. Pode ser derivado da análise dos dados de 'sla_policy_metrics' de um ticket, usando o carimbo de data/hora 'breached_at' para 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 sinaliza colaboração interna, onde um agente adiciona uma nota privada ao ticket para outros membros da equipe. É capturada quando um comentário é marcado como não público.
Por que é importante Analisar notas internas oferece insights sobre problemas complexos, mas um excesso delas pode indicar falta de conhecimento ou ineficiências no processo. Onde obter Capturado dos comentários do ticket. Um comentário é nota interna quando o atributo 'public' é falso. Captura Evento registrado quando um novo comentário com 'public: false' é adicionado ao ticket. Tipo de evento explicit
	Prioridade definida	Define o nível de prioridade (Baixa, Normal, Alta, Urgente). É registrado como uma alteração explícita e dita a urgência e o tempo de resposta exigido para o ticket.
Por que é importante Rastrear quando e como a prioridade é definida é vital para o Dashboard de 'Métricas de Eficácia de Priorização', garantindo que problemas críticos sejam resolvidos prontamente. Onde obter Capturado de um evento de alteração no campo 'prioridade' no log de auditoria. Mudanças posteriores também são rastreadas para medir o KPI de Taxa de Alteração de Prioridade. Captura Identificado por um evento de alteração no campo 'priority' no log de auditoria. Tipo de evento explicit
	Resposta Pública Enviada	Representa uma comunicação enviada por um agente de suporte ao usuário final. Este é um evento explícito no Zendesk, capturado sempre que um comentário público é adicionado ao ticket.
Por que é importante Rastrear respostas públicas é importante para entender a frequência de comunicação e pode ser vital para analisar atrasos na confirmação do usuário. Onde obter Capturado dos comentários do ticket. Um comentário é público quando o atributo 'public' é verdadeiro. 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 nota de satisfação pelo suporte recebido. Este é um evento explícito capturado no Zendesk após a resolução de um ticket.
Por que é importante Analisar as avaliações de satisfação fornece feedback crucial sobre o desempenho dos agentes e a eficácia do processo, ligando métricas operacionais aos resultados dos clientes. Onde obter Capturado dos dados de avaliação de satisfação do ticket. Geralmente inclui uma pontuação ('bom' ou 'ruim') 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 aguardando o solicitante. Este evento é inferido quando o status do ticket muda para 'pendente'.
Por que é importante Esta atividade é crucial para calcular o Tempo de Espera de Confirmação do Usuário. Longos períodos neste estado podem inflar o tempo total de resolução e indicar falhas de comunicação. Onde obter Inferido do log de auditoria ao identificar que o status mudou para 'pendente'. Captura Inferido a partir da mudança de status para 'pendente'. Tipo de evento inferred
	Ticket Atribuído ao Grupo	Representa o roteamento inicial ou a triagem de um incidente para um grupo de suporte específico. Geralmente é o primeiro passo na atribuição de responsabilidade e é registrado como um evento de alteração no histórico de auditoria do ticket.
Por que é importante O rastreamento de atribuições de grupo ajuda a analisar a eficiência do processo de triagem inicial e identifica atrasos antes que o ticket chegue à equipe correta. Onde obter Capturado do log de auditoria sempre que o campo 'group_id' é definido ou alterado. A primeira ocorrência após a criação é a atribuição inicial. Captura Identificado por um evento de alteração no campo 'group_id' no log de auditoria. Tipo de evento explicit

Recomendado Opcional

Guias de Extração

Como obter seus dados do Zendesk Support

Etapas

Acessar o Zendesk Explore: Faça login na sua instância do Zendesk Support com uma conta que tenha permissão para criar e gerenciar relatórios no Explore.
Criar um Novo Relatório: No módulo Explore, clique no ícone 'Relatórios' e depois no botão 'Novo relatório'.
Selecionar o Dataset: Escolha o dataset Support: Ticket updates [padrão]. Ele contém a trilha de auditoria essencial para criar o Event Log.
Adicionar Atributos Iniciais (Colunas): Na seção 'Linhas', clique em 'Adicionar' e selecione: Ticket ID, Update - Timestamp, Ticket status, Assignee name, Ticket group, Ticket priority, Ticket channel, Changes - Field name, Changes - Previous value, Changes - New value e Comment public.
Criar Atributos Calculados: No menu 'Cálculos' (ícone do béquer), selecione 'Atributo calculado padrão'. Crie os três atributos definidos abaixo: ActivityName, SourceSystem e LastDataUpdate, copiando as fórmulas exatamente como fornecidas.
Refinar Colunas do Relatório: Adicione os novos atributos (ActivityName, SourceSystem, LastDataUpdate) às 'Linhas'. Remova os campos brutos usados na criação do ActivityName para limpar a visualização.
Adicionar Filtros: Em 'Filtros', adicione Update - Date para definir o período (ex: últimos 3 meses). Filtre também o ActivityName para excluir valores nulos, removendo atualizações que não são atividades relevantes.
Revisar o Relatório: O Explore atualizará a tabela automaticamente. Verifique se as linhas e colunas estão corretas; cada linha deve representar um evento.
Exportar para CSV: Com o relatório pronto, clique em 'Exportar' no canto superior direito e escolha 'CSV'.
Preparar para Upload: Abra o CSV e renomeie os cabeçalhos para os nomes exigidos pela ferramenta de Process Mining (ex: de 'Ticket ID' para TicketId). Garanta que as datas sigam o padrão ISO 8601. O arquivo está pronto.

Configuração

Dataset do Zendesk: O relatório deve ser criado com base no dataset Support: Ticket updates [padrão]. Este é o único conjunto de dados padrão que oferece a trilha de auditoria detalhada necessária para reconstruir o processo evento por evento.
Filtro de Período: É fundamental aplicar um filtro de data para limitar o volume de dados. Use o atributo Update - Date como filtro principal. Recomendamos um intervalo de 3 a 6 meses para uma análise inicial.
Filtro de Atividade: Após criar o atributo calculado ActivityName, você deve filtrar o relatório para excluir linhas onde este valor seja nulo. Isso remove alterações irrelevantes (como atualizações de sistema ou mudanças de tags) do seu Event Log.
Atributos Calculados: A lógica desta extração depende de um atributo calculado padrão para traduzir mudanças brutas nos campos de ticket em nomes de atividades legíveis. A precisão na fórmula é essencial.
Pré-requisitos: O usuário que executa o relatório precisa de, no mínimo, a função de 'Visualizador' no Zendesk Explore. Para criar e salvar o relatório, são necessárias permissões de 'Editor' ou 'Administrador'.

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: Tenha o Python 3.6+ instalado com as bibliotecas requests e pandas (instale via: pip install requests pandas).
Gerar Token de API do Zendesk: No Admin Center do Zendesk, vá em Apps e integrações > APIs > APIs do Zendesk. Em "Tokens de API", crie um novo token e salve-o com segurança.
Configurar o Script: Crie um arquivo .py e cole o script fornecido. Atualize as variáveis ZENDESK_SUBDOMAIN, ZENDESK_EMAIL e ZENDESK_API_TOKEN. Defina o START_TIMESTAMP (Unix epoch) para o início do período de extração.
Endpoints da API: O script usa o endpoint incremental/tickets/cursor.json para listar tickets atualizados e o tickets/{ticket_id}/audits.json para obter o histórico detalhado de cada um.
Executar o Script: No terminal, use: python extract_zendesk_logs.py. A extração de dados começará.
Monitorar o Progresso: O console mostrará o número de tickets processados. O tempo total depende do volume de dados.
Paginação e Coleta: O script gerencia a paginação automaticamente, seguindo a after_url de cada resposta da API até coletar todos os tickets do período.
Transformação de Eventos: O script percorre o histórico de auditoria e mapeia eventos internos do Zendesk (Criação, Alteração, Comentário) para atividades de negócio (Incidente Criado, Status Alterado, Resposta Enviada).
Dados de SLA: Como violações de SLA não são eventos padrão do log de auditoria, a função get_sla_breach_events faz chamadas extras para buscar métricas de tickets resolvidos.
Gerar Event Log: Ao finalizar, o script organiza tudo em um DataFrame do pandas e salva o arquivo zendesk_incident_event_log.csv na mesma pasta.
Preparar Upload: Verifique se o CSV está correto. Ele já está no formato ideal para ser carregado no ProcessMind.

Configuração

Credenciais da API do Zendesk: Você deve fornecer seu 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 inclua diretamente em scripts controlados por versão.
Timestamp de Início (START_TIMESTAMP): Este valor inteiro determina o ponto de partida para a extração de dados. Deve ser um timestamp Unix epoch. Recomendamos um período de 3 a 6 meses no passado para coletar uma quantidade significativa de dados sem sobrecarregar o sistema. Use um conversor online para obter o timestamp correto de uma data específica.
Limite de Taxa da API (Rate Limiting): O script faz várias chamadas de API. O Zendesk impõe limites de taxa que variam conforme o plano. Para volumes muito grandes de dados, pode ser necessário adicionar pausas (time.sleep()) nos loops para evitar o erro 429 (limite excedido).
Bibliotecas Python Necessárias: O script depende da biblioteca requests para chamadas de API e da biblioteca pandas para manipulação de dados e exportação de CSV. Certifique-se de que elas estejam instaladas no seu ambiente Python.
Permissões de 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.

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

Pré-requisitos: Tenha o Python 3.6+ instalado com as bibliotecas requests e pandas (instale via: pip install requests pandas).
Gerar Token de API do Zendesk: No Admin Center do Zendesk, vá em Apps e integrações > APIs > APIs do Zendesk. Em "Tokens de API", crie um novo token e salve-o com segurança.
Configurar o Script: Crie um arquivo .py e cole o script fornecido. Atualize as variáveis ZENDESK_SUBDOMAIN, ZENDESK_EMAIL e ZENDESK_API_TOKEN. Defina o START_TIMESTAMP (Unix epoch) para o início do período de extração.
Endpoints da API: O script usa o endpoint incremental/tickets/cursor.json para listar tickets atualizados e o tickets/{ticket_id}/audits.json para obter o histórico detalhado de cada um.
Executar o Script: No terminal, use: python extract_zendesk_logs.py. A extração de dados começará.
Monitorar o Progresso: O console mostrará o número de tickets processados. O tempo total depende do volume de dados.
Paginação e Coleta: O script gerencia a paginação automaticamente, seguindo a after_url de cada resposta da API até coletar todos os tickets do período.
Transformação de Eventos: O script percorre o histórico de auditoria e mapeia eventos internos do Zendesk (Criação, Alteração, Comentário) para atividades de negócio (Incidente Criado, Status Alterado, Resposta Enviada).
Dados de SLA: Como violações de SLA não são eventos padrão do log de auditoria, a função get_sla_breach_events faz chamadas extras para buscar métricas de tickets resolvidos.
Gerar Event Log: Ao finalizar, o script organiza tudo em um DataFrame do pandas e salva o arquivo zendesk_incident_event_log.csv na mesma pasta.
Preparar Upload: Verifique se o CSV está correto. Ele já está no formato ideal para ser carregado no ProcessMind.

Configuração

Credenciais da API do Zendesk: Você deve fornecer seu 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 inclua diretamente em scripts controlados por versão.
Timestamp de Início (START_TIMESTAMP): Este valor inteiro determina o ponto de partida para a extração de dados. Deve ser um timestamp Unix epoch. Recomendamos um período de 3 a 6 meses no passado para coletar uma quantidade significativa de dados sem sobrecarregar o sistema. Use um conversor online para obter o timestamp correto de uma data específica.
Limite de Taxa da API (Rate Limiting): O script faz várias chamadas de API. O Zendesk impõe limites de taxa que variam conforme o plano. Para volumes muito grandes de dados, pode ser necessário adicionar pausas (time.sleep()) nos loops para evitar o erro 429 (limite excedido).
Bibliotecas Python Necessárias: O script depende da biblioteca requests para chamadas de API e da biblioteca pandas para manipulação de dados e exportação de CSV. Certifique-se de que elas estejam instaladas no seu ambiente Python.
Permissões de 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.

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

Acessar o Zendesk Explore: Faça login na sua instância do Zendesk Support com uma conta que tenha permissão para criar e gerenciar relatórios no Explore.
Criar um Novo Relatório: No módulo Explore, clique no ícone 'Relatórios' e depois no botão 'Novo relatório'.
Selecionar o Dataset: Escolha o dataset Support: Ticket updates [padrão]. Ele contém a trilha de auditoria essencial para criar o Event Log.
Adicionar Atributos Iniciais (Colunas): Na seção 'Linhas', clique em 'Adicionar' e selecione: Ticket ID, Update - Timestamp, Ticket status, Assignee name, Ticket group, Ticket priority, Ticket channel, Changes - Field name, Changes - Previous value, Changes - New value e Comment public.
Criar Atributos Calculados: No menu 'Cálculos' (ícone do béquer), selecione 'Atributo calculado padrão'. Crie os três atributos definidos abaixo: ActivityName, SourceSystem e LastDataUpdate, copiando as fórmulas exatamente como fornecidas.
Refinar Colunas do Relatório: Adicione os novos atributos (ActivityName, SourceSystem, LastDataUpdate) às 'Linhas'. Remova os campos brutos usados na criação do ActivityName para limpar a visualização.
Adicionar Filtros: Em 'Filtros', adicione Update - Date para definir o período (ex: últimos 3 meses). Filtre também o ActivityName para excluir valores nulos, removendo atualizações que não são atividades relevantes.
Revisar o Relatório: O Explore atualizará a tabela automaticamente. Verifique se as linhas e colunas estão corretas; cada linha deve representar um evento.
Exportar para CSV: Com o relatório pronto, clique em 'Exportar' no canto superior direito e escolha 'CSV'.
Preparar para Upload: Abra o CSV e renomeie os cabeçalhos para os nomes exigidos pela ferramenta de Process Mining (ex: de 'Ticket ID' para TicketId). Garanta que as datas sigam o padrão ISO 8601. O arquivo está pronto.

Configuração

Dataset do Zendesk: O relatório deve ser criado com base no dataset Support: Ticket updates [padrão]. Este é o único conjunto de dados padrão que oferece a trilha de auditoria detalhada necessária para reconstruir o processo evento por evento.
Filtro de Período: É fundamental aplicar um filtro de data para limitar o volume de dados. Use o atributo Update - Date como filtro principal. Recomendamos um intervalo de 3 a 6 meses para uma análise inicial.
Filtro de Atividade: Após criar o atributo calculado ActivityName, você deve filtrar o relatório para excluir linhas onde este valor seja nulo. Isso remove alterações irrelevantes (como atualizações de sistema ou mudanças de tags) do seu Event Log.
Atributos Calculados: A lógica desta extração depende de um atributo calculado padrão para traduzir mudanças brutas nos campos de ticket em nomes de atividades legíveis. A precisão na fórmula é essencial.
Pré-requisitos: O usuário que executa o relatório precisa de, no mínimo, a função de 'Visualizador' no Zendesk Explore. Para criar e salvar o relatório, são necessárias permissões de 'Editor' ou 'Administrador'.

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()
```

Seu template de dados para Gestão de Incidentes

Seu template de dados para Gestão de Incidentes

Atributos de Gerenciamento de Incidentes

Atividades de Gerenciamento de Incidentes

Guias de Extração

Exportação de Relatório da UI 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 de Dados em Lote

Etapas

Configuração

a Consulta de Exemplo python

Ferramenta de ETL de terceiros com conector de API do Zendesk

Etapas

Configuração

a Consulta de Exemplo config

Pronto para Começar?

Otimize a Gestão de Incidentes e Resolva Mais Rápido Hoje

Seu template de dados para Gestão de Incidentes

Seu template de dados para Gestão de Incidentes

Atributos de Gerenciamento de Incidentes

Atividades de Gerenciamento de Incidentes

Guias de Extração

Exportação de Relatório da UI 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 de Dados em Lote

Etapas

Configuração

a Consulta de Exemplo python

Ferramenta de ETL de terceiros com conector de API do Zendesk

Etapas

Configuração

a Consulta de Exemplo config

Valorizamos sua privacidade

Pronto para Começar?

Otimize a Gestão de Incidentes e Resolva Mais Rápido Hoje