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

Seu Template de dados para gestão de incidentes

Zendesk Support

Atributos da gestão de incidentes(23) Atividades da gestão de incidentes(13) Guias de extração(4)

Seu Template de dados para gestão de incidentes

Este Template organiza os dados essenciais para analisar com eficiência seu processo de gestão de incidentes. Ele apresenta os principais atributos a coletar, as atividades importantes a acompanhar e orientações práticas para extrair esses dados do Zendesk Support. Use-o para começar seu projeto de Process Mining com um conjunto de dados completo e confiável.

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

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

Baixar Template

Atributos da gestão de incidentes

Estes são os campos de dados recomendados para incluir no Event Log e analisar seu processo de gestão de incidentes em detalhes.

5 Obrigatório 7 Recomendado 11 Opcional

	Nome	Descrição
	Data e hora do evento EventTimestamp	Data e hora exatas em que a atividade ocorreu.
Descrição Esta data e hora registra o momento exato em que um evento ocorreu no ciclo de vida do incidente, como a inclusão de um comentário ou a alteração do status. Ela define a ordem cronológica de todas as atividades 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 períodos de espera, medir a duração total dos casos e analisar a performance do processo em diferentes períodos. Datas e horas precisas são essenciais para criar um mapa animado do processo, que mostra o fluxo dos casos ao longo do tempo, e para montar Dashboards de performance que acompanham KPIs como o tempo médio de resolução. Por que isso importa As datas e horas dão contexto cronológico a todas as atividades, permitindo calcular durações, identificar gargalos e analisar a performance do processo ao longo do tempo. Onde encontrar API de auditoria 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
	ID do incidente TicketId	Identificador exclusivo, gerado pelo sistema, para cada ticket de incidente.
Descrição O ID do incidente é a chave primária que identifica cada caso de incidente no Zendesk Support. Ele funciona como CaseId no Process Mining, vinculando todas as atividades, alterações de status e comunicações relacionadas desde a criação até o encerramento do incidente. Na análise, esse ID é essencial para reconstruir a jornada completa de cada incidente. Ele permite reunir os dados de eventos e acompanhar métricas como o tempo total de resolução, o número de transferências e o cumprimento dos acordos de nível de serviço em cada caso. Ao agrupar os eventos por esse ID, analistas podem visualizar os fluxos do processo, identificar caminhos comuns e detectar desvios do procedimento padrão. Por que isso importa Este identificador essencial conecta todos os eventos a um único incidente, permitindo acompanhar todo o ciclo de vida e analisar a performance do processo com precisão. Onde encontrar API de tickets do Zendesk (/api/v2/tickets/{id}), campo id. Exemplos 19428230113521941055
	Atividade ActivityName	Nome da atividade de negócio ou do evento ocorrido em um determinado momento do ciclo de vida do incidente.
Descrição Este atributo descreve uma etapa ou ação específica do processo de gerenciamento de incidentes, como 'Incidente criado', 'Ticket atribuído a um agente' ou 'Incidente resolvido'. Essas atividades são derivadas dos dados do registro de eventos ou do histórico de auditoria do Zendesk, onde as alterações do sistema ficam registradas. No Process Mining, a sequência dessas atividades forma o mapa do processo, que serve de base para toda a análise. Ao analisar o fluxo de atividades, as organizações podem descobrir os caminhos reais dos incidentes, identificar gargalos entre etapas, medir ciclos de retrabalho, como a reabertura de 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 e é a base da análise de Process Mining para identificar ineficiências, desvios e oportunidades de melhoria. Onde encontrar Derivado dos eventos da API de auditoria de tickets do Zendesk. Por exemplo, um evento Change no campo de status pode ser mapeado como 'Status alterado'. Exemplos Incidente criadoTicket atribuído a um agenteStatus alterado para pendenteIncidente resolvidoIncidente encerrado
	Sistema de origem SourceSystem	Sistema do qual os dados dos incidentes foram extraídos.
Descrição Este atributo identifica a origem dos dados do processo. Nesta visualização, o valor seria fixo, por exemplo, 'Zendesk Support', indicando que todos os eventos e atributos vieram 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 gerenciamento de incidentes no Zendesk com o de outra ferramenta de ITSM. Por que isso importa Identifica a origem dos dados, informação essencial para a governança de dados e para análises que combinam dados de vários sistemas de origem. Onde encontrar Valor fixo definido durante a transformação dos dados para identificar sua origem. Exemplos Zendesk SupportZendesk
	Última atualização dos dados LastDataUpdate	Data e hora que indicam 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 ciclo de atualização. Essa informação é importante para a governança de dados e para quem usa a análise de Process Mining. Ela indica o quanto os dados estão atualizados e ajuda analistas a entender se estão consultando as informações mais recentes disponíveis. Isso é especialmente importante para acompanhar a performance operacional e tomar decisões no momento certo com base na análise. Por que isso importa Oferece contexto importante sobre a atualização dos dados, ajudando os usuários a entender até que ponto a análise está atualizada e quando os dados foram obtidos pela última vez. Onde encontrar Data e hora geradas pelo processo de ETL ou pelo pipeline de dados ao concluir a atualização dos dados. Exemplos 2023-10-27T08:00:00Z2023-10-28T08:00:00Z
	Agente responsável Assignee	O agente de suporte atualmente responsável por tratar o incidente.
Descrição Este atributo identifica o agente responsável pelo incidente em determinado momento. As mudanças de responsável são eventos importantes, pois indicam a transferência do trabalho de uma pessoa para outra. Analisar o agente responsável ajuda a entender a distribuição da carga de trabalho, a performance individual e os padrões de colaboração. Acompanhar as mudanças nesse campo é essencial para calcular o KPI "Média de transferências por incidente" e identificar casos que passam frequentemente de uma pessoa para outra, o que pode indicar lacunas de conhecimento ou encaminhamento ineficiente. Por que isso importa Identifica o agente responsável e permite analisar a carga de trabalho e acompanhar as transferências, algo essencial para encontrar ineficiências no processo. Onde encontrar Zendesk Tickets API, campo assignee_id. As mudanças são registradas na Ticket Audits API. Exemplos John SmithJane DoeAutomação da Central de serviços
	Canal de registro Channel	O canal pelo qual o incidente foi registrado inicialmente, como "E-mail", "Web" ou "API".
Descrição Este atributo registra o método usado pelo usuário final ou pelo sistema para criar o chamado do incidente. Entender o canal é importante para analisar a origem dos incidentes e adaptar o processo de suporte. A análise por canal pode revelar padrões diferentes. Por exemplo, incidentes registrados por telefone podem ter um tempo de resolução menor do que os recebidos por e-mail. Essas informações dão suporte ao Dashboard "Volume de incidentes processados" 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 para cada canal e uma melhor alocação de recursos. Onde encontrar Zendesk Tickets API, campo via.channel. Exemplos webe-mailapitelefone
	Grupo responsável AssignedGroup	A equipe ou o grupo de suporte atualmente responsável pelo incidente.
Descrição Este atributo indica qual equipe é responsável pelo incidente. Muitas vezes, os incidentes passam por diferentes níveis de suporte ou grupos especializados, por exemplo, do "Suporte L1" para a "Equipe de redes". Essa dimensão é essencial para analisar as transferências entre equipes e identificar gargalos. Ao acompanhar o fluxo de incidentes entre grupos, analistas podem medir as dependências entre equipes, calcular o tempo em fila de cada grupo e otimizar as regras de encaminhamento. O atributo também dá suporte direto ao Dashboard "Análise de transferências e retrabalho". Por que isso importa Acompanha a equipe responsável, algo essencial para analisar transferências entre equipes, identificar gargalos específicos de cada equipe e medir o tempo em fila. Onde encontrar Zendesk Tickets API, campo group_id. As mudanças são registradas na Ticket Audits API. Exemplos Suporte L1Equipe de redes L2Infraestrutura L3Faturamento
	Hora de término do evento EventEndTime	A data e hora que indicam 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, muitas vezes, a hora de término de uma atividade é inferida a partir da hora de início da atividade seguinte no mesmo caso. Para a última atividade de um caso, a hora de término pode ser igual à hora de início. Este atributo é essencial para calcular a duração de cada atividade (ProcessingTime) e o tempo de espera entre atividades. Essas informações são a base da análise de gargalos, pois permitem ver não só quanto tempo uma etapa leva, mas também quanto tempo o caso ficou parado antes de ela começar. Por que isso importa Permite calcular a duração das atividades e os tempos de espera, algo fundamental para analisar gargalos em detalhes e identificar atrasos no processo. Onde encontrar Calculado com base na hora de início do evento seguinte no mesmo caso. A hora de término do último evento pode ser igual à hora de início ou à hora 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 "Baixa", "Normal", "Alta" ou "Urgente".
Descrição A prioridade de um incidente determina a urgência necessária para responder e resolvê-lo. É um fator importante para priorizar o trabalho e alocar recursos na equipe de suporte. Na análise de processos, a prioridade é usada para segmentar os incidentes e comparar seus fluxos e sua performance. Por exemplo, analistas podem verificar se incidentes "Urgentes" são realmente resolvidos mais rápido do que os de prioridade "Baixa". A prioridade também é usada para monitorar a Conformidade com o SLA, já que os SLAs costumam ser definidos de acordo com os níveis de prioridade. O KPI "Taxa de mudanças de prioridade" depende do acompanhamento das alterações nesse campo. Por que isso importa Este atributo é essencial para segmentar análises, avaliar a eficácia da priorização e monitorar a Conformidade com o SLA em diferentes níveis de urgência. Onde encontrar Zendesk Tickets API, campo priority. As mudanças são registradas na Ticket Audits API. Exemplos baixanormalaltaurgente
	Status do SLA SlaStatus	O status atual do Acordo de Nível de Serviço (SLA) do incidente.
Descrição Este atributo indica se o incidente está no prazo para cumprir as metas definidas no SLA, se já ultrapassou o prazo 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 atributo é essencial para o Dashboard "Monitoramento da Conformidade com o SLA". Ele mede diretamente a performance em relação aos compromissos de serviço. Ao analisar quando e por que os SLAs são descumpridos, as organizações podem identificar pontos fracos no processo e melhorar a confiabilidade do serviço. O atributo também dá suporte direto ao KPI "Taxa de cumprimento do SLA de incidentes". Por que isso importa Mede diretamente a performance em relação aos compromissos de serviço e permite analisar violações de SLA e monitorar os casos de forma proativa para melhorar a Conformidade. Onde encontrar Zendesk Ticket Metrics API (/api/v2/ticket_metrics.json), derivado de campos como sla_policy, breached_at etc. Exemplos AtivoPausadoDescumpridoCumprido
	Status do ticket TicketStatus	Status do ticket de incidente no momento do evento, como 'Aberto', 'Pendente' ou 'Resolvido'.
Descrição Este atributo mostra o estado do ticket de incidente em diferentes momentos do ciclo de vida. Os status padrão do Zendesk incluem novo, aberto, pendente, em espera, resolvido e encerrado. Acompanhar as alterações deste 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 'Pendente', que muitas vezes indica espera por uma resposta do cliente. O status também é essencial para definir a conclusão do caso e calcular os tempos de resolução. Por que isso importa Acompanhar as mudanças de status é essencial para entender o andamento do processo, identificar tempos de espera e definir os pontos de início e fim do ciclo de vida do incidente. Onde encontrar Zendesk Tickets API, campo status. As mudanças são registradas na Ticket Audits API. Exemplos novoabertopendenteresolvidofechado
	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 registra o feedback do cliente sobre a experiência com o suporte, geralmente coletado por meio de uma pesquisa após a resolução do chamado. No Zendesk, as avaliações mais comuns são "Bom" ou "Ruim". Embora não meça diretamente a eficiência do processo, a avaliação de satisfação é um indicador importante do resultado. Em Process Mining, ela pode ser comparada 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 mais baixas? Por que isso importa Fornece um indicador importante de resultado que pode ser comparado com as características do processo para entender como a performance afeta a satisfação dos usuários. Onde encontrar Zendesk Ticket Metrics API (/api/v2/ticket_metrics.json), campo satisfaction_rating.score. Exemplos bomruimoferecidonão oferecido
	Categoria da causa raiz RootCauseCategory	A categoria geral da causa raiz do incidente.
Descrição Este atributo classifica o motivo fundamental da ocorrência de um incidente. Normalmente, ele é registrado perto do fim do ciclo de vida do incidente, muitas vezes como parte de uma análise pós-incidente ou do 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 da análise de causa raiz". Analisar os incidentes por causa raiz ajuda a identificar problemas recorrentes e orienta a implementação de correções permanentes para reduzir o volume de incidentes futuros. Assim, o foco deixa de ser apenas reagir aos problemas e passa a incluir a prevenção. Por que isso importa Ajuda a gerenciar problemas de forma proativa, classificando as causas dos incidentes para identificar tendências e evitar novas ocorrências. Onde encontrar Normalmente, este é um campo personalizado do chamado. Consulte a configuração de Ticket Fields no Zendesk Admin Center. Exemplos Falha de softwareFalha de hardwareErro do usuárioIndisponibilidade da rede
	Duração do caso CaseDuration	O tempo total entre a criação do incidente e seu encerramento definitivo.
Descrição Esta métrica calculada representa o tempo de ciclo completo de um único incidente. Ela é calculada pela diferença entre a data e hora do primeiro evento (por exemplo, "Incidente criado") e a do último evento (por exemplo, "Incidente encerrado"). A duração do caso é um dos principais KPIs para medir a eficiência geral do processo. Ela é usada com frequência em Dashboards para mostrar tempos médios de ciclo, identificar casos de longa duração e analisar tendências ao longo do tempo. É uma medida geral da rapidez com que o processo trata e resolve incidentes. Por que isso importa Este é um KPI essencial para medir a velocidade geral do processo e identificar fatores que contribuem para tempos de resolução longos. Onde encontrar Calculado pela diferença entre a data e hora do último evento e a do primeiro evento de cada ID de incidente. Exemplos 25920060480086400
	É automatizado IsAutomated	Um indicador booleano que mostra se uma atividade foi realizada por um sistema automatizado ou por um agente humano.
Descrição Este atributo derivado diferencia os eventos executados por usuários dos realizados por automações do sistema, gatilhos ou integrações de API. Normalmente, ele é determinado verificando se o autor do evento é um usuário do sistema conhecido. Entender o nível de automação é essencial para analisar processos atualmente. Isso 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 e nos tempos de resolução. O atributo também permite comparar os fluxos de atividades automatizadas e manuais. Por que isso importa Diferencia as ações humanas das ações do sistema, algo essencial para analisar o impacto da automação na eficiência do processo e identificar novas oportunidades de automação. Onde encontrar Derivado da verificação de se o autor do evento (author_id na Ticket Audits API) corresponde a um usuário conhecido do sistema ou de automação. Exemplos truefalse
	Gravidade Severity	O impacto do incidente para o negócio.
Descrição A gravidade define o impacto de um incidente para o negócio e, muitas vezes, é considerada junto com a prioridade para determinar a urgência geral. Normalmente, ela é configurada como um campo personalizado no Zendesk. Analisar a gravidade ajuda a entender a criticidade dos incidentes tratados. É uma dimensão importante para segmentar dados em Dashboards como "Monitoramento da Conformidade com o SLA" e "Métricas de eficácia da priorização". Comparar os fluxos de processo de diferentes níveis de gravidade pode revelar se os incidentes mais graves estão recebendo a velocidade e os recursos adequados. Por que isso importa Indica o impacto do incidente para o negócio e permite concentrar a análise nos problemas mais críticos, garantindo que sejam resolvidos com eficiência. Onde encontrar Normalmente, este é um campo personalizado. Consulte a configuração de Ticket Fields no Zendesk Admin Center. 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 outro agente ou grupo.
Descrição Esta métrica calculada quantifica quantas vezes a responsabilidade por um incidente foi transferida. Cada mudança no campo Assignee ou AssignedGroup aumenta essa contagem para o caso. As transferências são uma fonte comum de ineficiência e atrasos no gerenciamento de incidentes. Um número elevado de transferências pode indicar regras de encaminhamento pouco claras, lacunas de conhecimento nas equipes de suporte ou processos complexos demais. Esta 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 os atritos no processo causados pelas transferências e ajuda a identificar ineficiências no encaminhamento e lacunas de conhecimento que prolongam os tempos de resolução. Onde encontrar Calculado contando quantas vezes o campo AssignedGroup ou Assignee mudou para um incidente. Exemplos 0135
	Organização do cliente Organization	A organização ou empresa à qual pertence quem solicitou o atendimento do incidente.
Descrição Este atributo associa um incidente à organização do cliente. É essencial em ambientes de suporte B2B, nos quais os níveis de serviço e os processos de suporte podem variar de um cliente para outro. Analisar incidentes por organização permite que as equipes de suporte acompanhem a situação dos clientes, identifiquem problemas recorrentes que afetam contas específicas e verifiquem se as obrigações contratuais estão sendo cumpridas. É uma dimensão importante para filtrar Dashboards e relatórios e analisar a performance pela perspectiva do cliente. Por que isso importa Permite analisar cada cliente, acompanhar níveis de serviço, identificar tendências em contas importantes e gerenciar o relacionamento com os clientes de forma eficaz. Onde encontrar Zendesk Tickets API, campo organization_id. Exemplos Global Tech Inc.Innovate SolutionsData Corp
	Resolvido no primeiro contato IsFirstContactResolution	Um indicador booleano que é verdadeiro quando o incidente é resolvido pelo primeiro agente ou grupo responsável, sem transferências.
Descrição A resolução no primeiro contato (FCR) é uma métrica essencial para a eficiência da central de suporte e a satisfação do cliente. Este atributo calculado identifica os incidentes resolvidos sem serem reatribuídos a outro agente ou equipe. A lógica normalmente verifica se o chamado chegou ao status "Resolvido" enquanto ainda estava atribuído ao agente e ao grupo iniciais. Em Process Mining, isso permite calcular diretamente a taxa de FCR e comparar os caminhos dos incidentes resolvidos no primeiro contato com os que precisaram ser escalados. Essa análise ajuda a identificar oportunidades para dar mais autonomia à equipe de suporte de primeiro nível. Por que isso importa Mede diretamente a eficiência do primeiro contato com o suporte e ajuda a identificar oportunidades para resolver os incidentes mais cedo no processo. Onde encontrar Indicador booleano calculado. É verdadeiro quando o status do chamado é "solved" ou "closed" e houve apenas um agente ou grupo responsável durante todo o ciclo de vida do incidente. Exemplos truefalse
	Solicitante do registro Submitter	O usuário final ou sistema que registrou o incidente originalmente.
Descrição Este atributo identifica a pessoa ou entidade que criou o chamado. Ela não é necessariamente quem fez a solicitação, pois um agente pode criar um chamado em nome de outra pessoa. Na análise, o responsável pelo registro ajuda a entender quem está relatando problemas. Combinado com dados da organização, esse atributo pode revelar se determinados clientes ou grupos de usuários estão enfrentando muitos incidentes. Essas informações podem orientar iniciativas de suporte proativo ou treinamento. Por que isso importa Identifica a origem do relato do incidente e permite analisar padrões relacionados a usuários, departamentos ou sistemas automatizados específicos. Onde encontrar Zendesk Tickets API, campo submitter_id. Exemplos alice.jones@example.combob.williams@example.comMonitor do sistema
	Tags Tags	Uma lista de tags aplicadas ao incidente para classificá-lo e fornecer contexto.
Descrição As tags são rótulos flexíveis que podem ser adicionados aos chamados para fornecer contexto ou ajudar na classificação e no encaminhamento. Os agentes podem adicioná-las manualmente, ou elas podem ser aplicadas automaticamente por gatilhos e automações. As tags são uma fonte valiosa 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 investigar os dados em profundidade, indo além dos campos padrão dos chamados. Por que isso importa Oferece uma forma flexível de classificar e filtrar incidentes, permitindo análises detalhadas e específicas por contexto que talvez não sejam possíveis apenas com os campos padrão. Onde encontrar Zendesk Tickets API, campo tags. Exemplos vip_usernetwork_issueoutage_20231027billing_related
	Tipo de chamado TicketType	A classificação do chamado, como "Incidente", "Problema", "Dúvida" ou "Tarefa".
Descrição Este campo classifica o chamado de acordo com a natureza da solicitação. O processo de gerenciamento de incidentes se concentra especificamente nos chamados do tipo "Incidente", que representam uma interrupção não planejada ou uma redução na qualidade de um serviço de TI. Na análise, este atributo é usado principalmente como filtro para incluir apenas incidentes na visualização do processo. 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 analisar especificamente os incidentes e manter a análise alinhada ao ciclo de vida do gerenciamento de incidentes. Onde encontrar Zendesk Tickets API, campo type. Exemplos incidenteproblemadúvidatarefa

Obrigatório Recomendado Opcional

Atividades da gestão de incidentes

Estas são as etapas e os marcos importantes do processo que você deve registrar no Event Log para descobrir e analisar o fluxo com precisão.

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 é registrado explicitamente no log de auditoria de criação de tickets do Zendesk e serve como ponto de partida de cada caso.
Por que isso importa Esta é a principal atividade de início. Analisar o tempo entre este evento e os demais é essencial para medir a duração total do ciclo de vida do ticket e o tempo de resposta inicial. Onde encontrar Este evento é registrado explicitamente nos logs de auditoria de tickets do Zendesk. Cada novo ticket gera um evento 'Create' com a data e hora correspondente. Coleta Diretamente do evento de criação do ticket no log de auditoria. Tipo de evento explicit
	Incidente encerrado	Marca o fim do ciclo de vida do incidente, quando o ticket é encerrado permanentemente. No Zendesk, isso costuma acontecer automaticamente após um período definido desde a resolução e fica registrado como uma alteração final de status.
Por que isso importa Esta é a atividade que encerra definitivamente o processo. A duração total é calculada do evento 'Incidente criado' até este evento, oferecendo uma visão completa do tempo de ciclo. Onde encontrar Registrado no log de auditoria do ticket por um evento 'Change' em que o novo valor do campo 'status' passa a ser 'closed'. Coleta Identificado por um evento 'Change' que altera o 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, registrada como alteração de status no log de auditoria do ticket.
Por que isso importa Esta é a principal atividade de resolução e um ponto essencial para medir o tempo até a resolução. O intervalo entre este evento e 'Incidente encerrado' corresponde ao período de confirmação do usuário ou de encerramento automático. Onde encontrar Registrado no log de auditoria do ticket por um evento 'Change' em que o novo valor do campo 'status' passa a ser 'solved'. Coleta Identificado por um evento 'Change' que altera o campo 'status' para 'solved'. Tipo de evento explicit
	Status alterado para aberto	Indica que um agente começou a trabalhar ativamente no incidente. Em geral, essa atividade é identificada quando o campo 'status' do ticket muda de 'new' para 'open', marcando o início da investigação e do diagnóstico.
Por que isso importa Este evento marca a passagem 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 encontrar Identificado no log de auditoria do ticket por um evento 'Change' em que o novo valor do campo 'status' é 'open' e o valor anterior era 'new'. Coleta Identificado pela alteração do 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. O evento é registrado explicitamente no histórico de auditoria do ticket e indica que uma pessoa assumiu a responsabilidade pelo caso.
Por que isso importa Este marco é essencial para medir o tempo até a primeira atribuição e serve de base para analisar transferências, retrabalho e índices de resolução no primeiro contato. Onde encontrar Registrado no log de auditoria do ticket quando o campo 'assignee_id' é preenchido ou alterado. A primeira atribuição é um marco importante para o cálculo de KPIs. Coleta Identificado por um evento 'Change' no campo 'assignee_id' do log de auditoria do ticket. Tipo de evento explicit
	Ticket reatribuído	Ocorre quando a responsabilidade pelo ticket é transferida de um agente ou grupo para outro após a atribuição inicial. É um evento explícito registrado 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 costuma indicar encaminhamento inicial incorreto, problemas complexos ou gargalos no processo. Onde encontrar Identificado no log de auditoria do ticket por um evento 'Change' no campo 'assignee_id' ou 'group_id', após o primeiro preenchimento do campo. Coleta Identificado por um evento 'Change' posterior no campo 'assignee_id' ou 'group_id'. Tipo de evento explicit
	Meta de SLA descumprida	Marca o momento em que um ticket deixa de cumprir um Acordo de Nível de Serviço definido, como o prazo da primeira resposta ou da resolução. Esse evento é calculado com base nas políticas de SLA e nas datas e horas de atualização do ticket.
Por que isso importa Este evento ajuda a monitorar a Conformidade com os SLAs. Identificar quando e por que ocorrem descumprimentos é fundamental para melhorar a confiabilidade do serviço e a confiança dos clientes. Onde encontrar Este evento é calculado. Ele pode ser derivado da análise dos dados 'sla_policy_metrics' associados ao ticket, usando a data e hora 'breached_at' de cada meta de SLA. Coleta Derivado da data e hora '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: um agente adiciona uma nota privada ao ticket para que outros membros da equipe possam consultá-la. O registro é explícito quando um comentário é marcado como não público.
Por que isso importa Analisar as notas internas pode revelar problemas complexos que exigem colaboração. Um número excessivo de notas, porém, pode indicar lacunas de conhecimento ou ineficiências no processo. Onde encontrar Obtido dos dados de comentários do ticket. Um comentário é considerado uma nota interna quando o atributo 'public' está definido como false. Coleta Evento registrado quando um novo comentário com 'public: false' é adicionado ao ticket. Tipo de evento explicit
	Prioridade definida	O nível de prioridade do incidente, como baixo, normal, alto ou urgente, é definido. Essa ação fica registrada 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 de métricas de eficácia da priorização, garantindo que os problemas críticos sejam tratados rapidamente. Onde encontrar Registrado como um evento 'Change' no campo 'priority' do log de auditoria do ticket. Também é possível acompanhar alterações posteriores para medir o KPI de taxa de mudança de prioridade. Coleta Identificado por um evento 'Change' no campo 'priority' do log de auditoria do ticket. Tipo de evento explicit
	Resposta pública enviada	Representa uma mensagem enviada por um agente de suporte ao usuário final. É um evento explícito no Zendesk, registrado sempre que um comentário público é adicionado ao ticket.
Por que isso importa Acompanhar as respostas públicas ajuda a entender a frequência das comunicações e pode ser importante para analisar atrasos na confirmação do usuário. Onde encontrar Obtido dos dados de comentários do ticket. Um comentário é considerado público quando o atributo 'public' está definido como true. Coleta 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 avalia o suporte recebido. É um evento explícito, registrado no Zendesk depois que o ticket é resolvido.
Por que isso importa Analisar as avaliações de satisfação oferece feedback importante sobre a performance dos agentes e a eficácia do processo, relacionando as métricas do processo aos resultados para os clientes. Onde encontrar Obtido dos dados de avaliação de satisfação associados ao ticket. Normalmente, inclui uma nota ('good' ou 'bad') e um comentário opcional. Coleta 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 é identificado quando o campo 'status' do ticket muda 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 status podem aumentar significativamente o tempo total de resolução e revelar atrasos na comunicação. Onde encontrar Identificado no log de auditoria do ticket por um evento 'Change' em que o novo valor do campo 'status' é 'pending'. Coleta Identificado pela alteração do campo de status para 'pending'. Tipo de evento inferred
	Ticket atribuído a um grupo	Representa o encaminhamento ou a triagem inicial do incidente para um grupo de suporte específico. Geralmente, é a primeira etapa da atribuição de responsabilidade e fica registrada como um evento explícito de alteração no histórico de auditoria do ticket.
Por que isso importa Acompanhar as atribuições a grupos ajuda a avaliar a eficiência da triagem inicial e a identificar atrasos antes de o ticket chegar à equipe correta. Onde encontrar Registrado no log de auditoria do ticket sempre que o campo 'group_id' é definido ou alterado. A primeira ocorrência dessa alteração após a criação corresponde à atribuição inicial. Coleta Identificado por um evento 'Change' no campo 'group_id' do log de auditoria do ticket. Tipo de evento explicit

Recomendado Opcional

Guias de extração

Como obter seus dados do Zendesk Support

Etapas

Acesse o Zendesk Explore: Entre 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 'Relatórios' na barra de navegação à esquerda e, em seguida, clique no botão 'Novo relatório'.
Selecione o conjunto de dados: Na janela 'Escolher um conjunto de dados', selecione o conjunto de dados Support: Ticket updates [default]. Ele contém o histórico de auditoria de cada alteração nos chamados, essencial para criar um Event Log.
Adicione os atributos iniciais (colunas): No criador de relatórios, acesse a seção 'Linhas'. Clique em 'Adicionar' e selecione os seguintes atributos, que formarão as colunas do 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 'Cálculos' (ícone de béquer) e selecione 'Atributo calculado padrão'. Crie os três atributos definidos na seção 'Consulta' abaixo: ActivityName, SourceSystem e LastDataUpdate. Copie as fórmulas fornecidas exatamente.
Ajuste as colunas do relatório: Adicione os atributos calculados que você acabou de criar (ActivityName, SourceSystem, LastDataUpdate) à seção 'Linhas'. Agora, você pode remover os campos brutos usados para criar ActivityName (Changes - Field name, Changes - Previous value, Changes - New value, Comment public) e deixar a visualização mais organizada.
Adicione filtros ao relatório: Acesse a seção 'Filtros' e clique em 'Adicionar'. Adicione um filtro para Update - Date e selecione um período adequado, como os últimos 3 meses. Adicione outro filtro ao atributo calculado ActivityName e exclua os valores nulos para remover atualizações de chamados que não correspondam a uma atividade desejada.
Gere e revise o relatório: O Zendesk Explore atualiza o relatório automaticamente conforme você adiciona atributos e filtros. Revise a tabela de dados para confirmar que as linhas e colunas estão como esperado. O relatório deve mostrar uma linha por evento.
Exporte os dados para CSV: Quando o relatório estiver pronto, clique no botão 'Exportar' no canto superior direito e selecione 'CSV'. O Zendesk vai gerar e baixar o arquivo CSV.
Prepare os dados para carregamento: Abra o arquivo CSV exportado. Renomeie os cabeçalhos das colunas para corresponder aos nomes de atributos exigidos pela sua ferramenta de Process Mining, por exemplo, renomeie 'Ticket ID' para TicketId e 'Update - Timestamp' para EventTimestamp. Use o formato ISO 8601 nas datas e horas. O arquivo estará pronto para ser carregado.

Configuração

Conjunto de dados do Zendesk: O relatório deve usar o conjunto de dados Support: Ticket updates [default]. Este é o único conjunto de dados padrão que fornece o histórico detalhado de auditoria necessário para reconstruir o processo evento por evento.
Filtro por período: É 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, recomenda-se usar dados de um período de 3 a 6 meses.
Filtro de atividade: Depois de criar o atributo calculado ActivityName, filtre o relatório para excluir as linhas em que esse valor seja nulo. Assim, você remove alterações irrelevantes nos chamados, como atualizações do sistema e mudanças em tags, do Event Log.
Atributos calculados: A extração depende bastante de um atributo calculado padrão que converte alterações brutas nos campos dos chamados em nomes de atividades fáceis de entender. A fórmula precisa ser exata.
Pré-requisitos: Quem executar o relatório precisa ter pelo menos o perfil 'Viewer' no Zendesk Explore. Para criar e salvar o relatório, é necessário ter permissão de 'Editor' ou 'Admin'.

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: Instale o Python 3.6 ou superior no sistema, além das bibliotecas requests e pandas. Para instalá-las com pip, execute: pip install requests pandas.
Gere um token da API do Zendesk: Entre 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 o token gerado em um local seguro.
Configure o script Python: Crie um arquivo Python, por exemplo, extract_zendesk_logs.py, e copie o script fornecido para ele. Atualize as variáveis de espaço reservado no início do script com suas credenciais: ZENDESK_SUBDOMAIN, ZENDESK_EMAIL e ZENDESK_API_TOKEN. Defina START_TIMESTAMP para indicar o início do período de extração desejado, usando um timestamp Unix.
Entenda os endpoints da API: O script usa principalmente dois endpoints da API do Zendesk. O endpoint incremental/tickets/cursor.json busca com eficiência todos os chamados atualizados desde START_TIMESTAMP. Para cada chamado, o script acessa o endpoint tickets/{ticket_id}/audits.json para obter o histórico detalhado de cada alteração e evento.
Execute o script: No terminal, execute o comando: python extract_zendesk_logs.py. O script começará a buscar dados na API do Zendesk.
Acompanhe o andamento do script: O script exibirá no console a quantidade de chamados processados para você acompanhar o andamento. Dependendo do período e do volume de chamados, a execução pode levar bastante tempo.
Recuperação e paginação de dados: O script gerencia a paginação da API automaticamente. Ele começa pelo URL inicial de exportação de chamados e segue o after_url fornecido em cada resposta da API até recuperar todos os chamados do período.
Transformação de eventos: Para cada chamado, o script percorre o histórico de auditoria. Ele analisa cada evento e converte os tipos internos do Zendesk, como Create, Change e Comment, nas atividades de negócio necessárias, como Incidente criado, Status alterado para aberto e Resposta pública enviada.
Tratamento dos dados de SLA: O script inclui uma função específica, get_sla_breach_events, para buscar métricas de SLA de cada chamado resolvido. Isso é necessário porque as violações de SLA não são eventos padrão no registro de auditoria. A função faz uma chamada adicional à API para obter detalhes sobre a aplicação das políticas de SLA.
Gere o Event Log: Depois de processar todos os chamados, o script reúne os eventos 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 os dados para carregamento: Confira se o arquivo CSV gerado está correto. Ele já está no formato necessário para ser carregado diretamente no ProcessMind para análise.

Configuração

Credenciais da API do Zendesk: Informe 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 inclua diretamente em scripts com controle de versão usados em produção.
Timestamp inicial (START_TIMESTAMP): Esse valor inteiro define o início da extração de dados e deve ser um timestamp Unix. Recomenda-se começar de 3 a 6 meses atrás para reunir dados suficientes sem sobrecarregar o sistema. Use um conversor online para obter o timestamp correto de uma data específica.
Limite de requisições da API: O script faz várias chamadas à API. Os limites de requisições do Zendesk variam conforme o plano. Para volumes moderados, o script funciona como esperado. 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 usa a biblioteca requests para fazer chamadas à API e a biblioteca pandas para manipular dados e exportar arquivos CSV. Instale ambas no ambiente Python.
Permissões do usuário: A conta associada ao token da API precisa ter permissão suficiente para ler os dados dos chamados, incluindo auditorias e métricas dos chamados.

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 chamados, auditorias de chamados, 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 marcador de extração como valores de configuração seguros.
Use a API de exportação incremental de chamados do Zendesk para recuperar os chamados atualizados após o último marcador concluído 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 percorre a paginação por cursor até a API informar que o conjunto de resultados está completo.
Para cada chamado retornado, solicite o histórico de auditoria pelo endpoint de auditoria de chamados. Os registros de auditoria são necessários porque o ProcessMind lê o Event Log como está e não deduz atividades a partir do estado final do chamado. Preserve a data e hora da auditoria, o responsável, o identificador do chamado e os eventos de auditoria.
Converta os eventos de auditoria em linhas explícitas de eventos. Extraia a criação do chamado, a atribuição a um grupo, a atribuição a um agente, as mudanças de prioridade, as mudanças de status para aberto, as respostas públicas, as notas internas, as reatribuições, as mudanças de status para pendente, o status resolvido e o status fechado. Quando houver uma avaliação de satisfação, extraia-a como uma linha separada. Calcule violações de SLA somente quando houver a meta de SLA e as datas e horas dos eventos necessárias, e documente os dados usados no cálculo.
Mantenha a data e hora da última atualização processada com sucesso ou o cursor correspondente. Não avance o marcador até que todas as páginas, auditorias de chamados e avaliações de satisfação opcionais tenham sido gravadas com sucesso. Na primeira execução, use um horário inicial limitado, como [Start date in ISO 8601 format], normalmente abrangendo 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.
Remova duplicatas usando TicketId, ActivityName, EventTimestamp e um identificador estável do evento de origem, quando disponível. Preserve ocorrências legítimas repetidas da mesma atividade, como várias respostas públicas, notas internas, atribuições ou mudanças de status.
Grave as linhas resultantes em CSV ou em outro formato de Event Log compatível com o ProcessMind. Use datas e horas no formato ISO 8601 com deslocamento UTC explícito, mantenha um tipo consistente para TicketId, use valores de ActivityName que correspondam exatamente aos nomes de atividades documentados e defina LastDataUpdate com o mesmo valor em todas as linhas do lote de extração.
Carregue o Event Log no ProcessMind e configure Incident ID como identificador do caso, Activity como coluna de atividade e Event Timestamp como coluna de data e hora do evento. Confirme que cada atividade obrigatória está representada por linhas explícitas, em vez de ser derivada durante a visualização.

Configuração

Método da API: use a API de exportação incremental de chamados do Zendesk com paginação por cursor. Para extrair eventos individuais, use o endpoint de auditoria de chamados. Use o endpoint de avaliações de satisfação quando elas estiverem habilitadas e acessíveis.
Configuração obrigatória: subdomínio do Zendesk, autenticação da API, data inicial, marcador de extração, tempo limite das requisiçõ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.
Período: para a carga inicial, use de três a seis meses, a menos que seja necessário um histórico maior. Nas cargas recorrentes, solicite os registros posteriores ao último marcador concluído com sucesso e inclua um pequeno período de sobreposição para contemplar atualizações recebidas com atraso. Depois, remova as duplicatas.
Filtros: aplique filtros por empresa, marca, grupo, organização, formulário de chamado, canal ou campo personalizado somente quando forem exigidos explicitamente pelo escopo do processo. O Zendesk Support não usa filtros de Company Code ou Document Type no estilo SAP, a menos que esses conceitos estejam representados em campos configurados no Zendesk.
Semântica dos eventos: considere os eventos de auditoria como fonte oficial das alterações explícitas. Não crie um evento de mudança de status apenas porque o chamado está com determinado status no momento. O evento de status deve vir de um evento de auditoria ou de outra fonte documentada.
Configuração do SLA: para identificar uma violação da meta de SLA, é necessário ter acesso à política de SLA aplicável, à duração da meta, ao calendário de horário comercial e às datas e horas necessárias 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 documentados da política e registre os critérios usados no cálculo.
Configuração de satisfação: a atividade 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. Não crie uma avaliação fictícia para um chamado resolvido sem avaliação.
Performance: use paginação por cursor, concorrência limitada para as requisições de auditoria dos chamados, reutilização de conexões, espera exponencial entre novas tentativas quando houver limite de requisições e pontos de controle após lotes concluídos com sucesso. Evite solicitar repetidamente todas as auditorias dos chamados em cada execução.
Integridade dos dados: as exportações incrementais podem incluir chamados atualizados após o horário solicitado, mas a recuperação das auditorias e o tratamento de atualizações atrasadas precisam ser feitos separadamente. Use um período de sobreposição e chaves estáveis para remover duplicatas.
Pré-requisitos: acesso à API, permissão para ler chamados e auditorias, acesso a usuários e grupos para identificar 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 o plano do Zendesk.

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

Escolha uma ferramenta comercial de ETL ou integração de dados que ofereça um conector verificado do Zendesk Support, aceite a extração do histórico de auditoria e dos comentários dos chamados e grave os dados no data warehouse ou sistema de arquivos de destino. Confirme se o conector oferece extração incremental, paginação, tratamento de limites de requisições e preservação das datas e horas de origem.
Crie a conexão com o Zendesk na ferramenta escolhida. Informe o subdomínio do Zendesk, o método de autenticação, as credenciais ou o token e as configurações de conexão necessárias na interface da ferramenta. Conceda acesso a chamados, auditorias de chamados, 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 o período de extração. Para a carga inicial, use um período móvel de 3 a 6 meses. Depois, configure cargas incrementais com base na data e hora de atualização ou de auditoria aceita pelo conector. Armazene o marcador da última extração concluída com sucesso fora do Event Log para evitar duplicar ou omitir eventos nas execuções seguintes.
Extraia os dados dos chamados necessários para dar contexto aos casos, incluindo o identificador do chamado, o status atual ou do evento, o responsável, o grupo, a prioridade, o canal de registro, o status do SLA e as datas e horas relevantes de atualização. Extraia os registros de auditoria dos chamados, pois as mudanças de atribuição, prioridade, status e outros campos precisam ser representadas como linhas explícitas de eventos.
Extraia os comentários dos chamados e diferencie comentários públicos de notas internas usando o indicador de visibilidade pública ou privada do conector. Extraia as datas e horas dos comentários, os identificadores dos chamados e dos autores e qualquer hora de término ou data e hora de conclusão disponível. Crie linhas Public Reply Sent para comentários públicos e Internal Note Added para notas privadas.
Extraia os registros de avaliação de satisfação e de violação de SLA quando o conector os disponibilizar. Se o conector não expuser diretamente os eventos de violação de SLA, configure a ferramenta ETL para calculá-los com base na meta e na política de SLA disponíveis, no horário comercial e nas datas e horas dos eventos do chamado. Não crie uma linha de violação, a menos que os dados de origem ou o cálculo configurado confirmem que a meta foi descumprida.
Reestruture os registros extraídos em um Event Log normalizado. Crie uma linha para cada ocorrência explícita de atividade. Mapeie a criação do chamado para Incident Created; mudanças na atribuição de grupo para Ticket Assigned to Group ou Ticket Reassigned; mudanças na atribuição de agente para Ticket Assigned to Agent ou Ticket Reassigned; mudanças 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; avaliações 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 anteriores e novos do histórico de auditoria, quando 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 mudanças posteriores de responsável como Ticket Reassigned. Gere uma linha para cada mudança que atenda aos critérios, não apenas para o estado mais recente do chamado.
Preencha as colunas obrigatórias TicketId, ActivityName, EventTimestamp, SourceSystem e LastDataUpdate. Preencha as colunas recomendadas TicketStatus, Assignee, AssignedGroup, TicketPriority, Channel, SlaStatus e EventEndTime com base no contexto do evento ou no registro de origem válido mais próximo. Mantenha as datas e horas de origem em um fuso horário consistente, de preferência UTC, e preserve a precisão original aceita pelo conector.
Valide os dados transformados. Confira se cada TicketId tem uma linha Incident Created, se as datas e horas dos eventos estão dentro do período de extração quando aplicável, se 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 conforme o identificador de auditoria de origem ou uma chave composta documentada.
Grave o Event Log na tabela do data warehouse ou no arquivo de destino em formato tabular compatível com o ProcessMind, como CSV ou o formato aceito pelo conector do data warehouse. Use uma linha de cabeçalho, nomes de colunas estáveis, codificação UTF-8, datas e horas ISO 8601 e nenhuma estrutura JSON aninhada nas colunas finais de eventos. Carregue 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 disponibilize chamados, auditorias de chamados, comentários, usuários, grupos, avaliações de satisfação e informações de SLA, conforme o plano do Zendesk e a 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 chamados, 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.
Período: Comece com 3 a 6 meses para validar e fazer a carga inicial. Amplie o período somente depois de verificar a quantidade de linhas, a paginação e o comportamento dos limites de requisições. Use um marcador incremental nas execuções programadas.
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 dos chamados. Não aplique filtros de 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 chamados e mantenha o identificador de auditoria de origem, quando disponível, para evitar eventos duplicados nas 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 deduza a visibilidade pelo texto do comentário.
Classificação de atribuições: Compare os valores anteriores e novos do grupo ou do responsável. Classifique separadamente a primeira atribuição que atender aos critérios e gere Ticket Reassigned para mudanças posteriores de responsável.
Classificação de status: Gere linhas somente para transições explícitas de status. Mapeie os valores new, open, pending, solved e closed conforme o modelo de status configurado no Zendesk. Se houver status personalizados, documente o mapeamento antes da carga.
Tratamento do SLA: Prefira os eventos de violação de SLA da fonte. Se não estiverem disponíveis, configure um cálculo documentado com a meta e a política de SLA disponíveis, o horário comercial e as datas e horas dos eventos. Registre os critérios do cálculo nos metadados do ETL, sem inventar campos de origem.
Tratamento de datas e horas: Normalize EventTimestamp e EventEndTime para UTC ou outro fuso horário documentado. Preserve a data e hora de origem e não as substitua pela data e hora da extração.
LastDataUpdate: Defina LastDataUpdate como a data e hora da atualização ETL concluída com sucesso e use o mesmo valor em todas as linhas dessa carga.
Performance: Use paginação, extração incremental, particionamento por data e hora de atualização ou de auditoria do chamado, paralelismo controlado, novas tentativas e espera progressiva quando houver limite de requisições. Evite extrair repetidamente todo o histórico dos chamados em cada execução programada.
Esquema de destino: Configure uma tabela ou um arquivo de eventos sem estruturas aninhadas, com as colunas obrigatórias TicketId, ActivityName, EventTimestamp, SourceSystem e LastDataUpdate, além dos atributos recomendados disponíveis.
Comportamento do ProcessMind: Não dependa do ProcessMind para deduzir mudanças de status, atribuições, respostas, notas, violações de SLA ou marcos do ciclo de vida. Cada atividade precisa existir como uma linha de evento antes do carregamento.

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 agilizar a preparação dos dados e obter insights relevantes sobre a performance da gestão de incidentes. Comece a otimizar seu processo hoje.

Voltar ao guia de melhoria

Baixar Template

Otimize a gestão de incidentes e resolva mais rápido

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

Começar o teste grátis

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

Seu Template de dados para gestão de incidentes

Seu Template de dados para gestão de incidentes

Atributos da gestão de incidentes

Atividades da gestão de incidentes

Guias de extração

Exportação de relatórios do Zendesk Explore para arquivo CSV

Etapas

Configuração

Consulta de exemplo config

Script Python usando a API REST do Zendesk Support

Etapas

Configuração

Consulta de exemplo python

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

Etapas

Configuração

Consulta de exemplo python

Ferramenta ETL de terceiros com conector da API do Zendesk

Etapas

Configuração

Consulta de exemplo config

Pronto para começar?

Otimize a gestão de incidentes e resolva mais rápido