> Melhoria contínua de processos > Gerenciamento de solicitações de serviço > Zendesk Support > Template de dados

Seu Template de dados para gerenciamento de solicitações de serviço

Zendesk Support

Atributos do gerenciamento de solicitações de serviço (21) Atividades do gerenciamento de solicitações de serviço (13) Guias de extração (3)

Seu Template de dados para gerenciamento de solicitações de serviço

Este Template oferece um guia completo para extrair os dados necessários para analisar seu processo de gerenciamento de solicitações de serviço no Zendesk Support. Ele apresenta os atributos de dados essenciais a serem coletados, as principais atividades a serem acompanhadas e orientações práticas para extrair essas informações diretamente do seu sistema. Use este recurso para criar um Event Log robusto para suas iniciativas de Process Mining.

Atributos recomendados para uma análise completa
Principais atividades de solicitações de serviço a serem acompanhadas
Orientações para extrair dados do Zendesk Support

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

Baixar Template

Atributos do gerenciamento de solicitações de serviço

Estes são os campos de dados recomendados para incluir no seu Event Log e obter uma análise completa do gerenciamento de solicitações de serviço no Zendesk Support.

5 Obrigatório 7 Recomendado 9 Opcional

	Nome	Descrição
	Atividade ActivityName	O nome da atividade de negócio ou do evento ocorrido para uma solicitação de serviço.
Descrição A Atividade representa uma etapa ou um evento distinto no ciclo de vida da solicitação de serviço, como 'Solicitação de serviço criada', 'Solicitação atribuída a um agente' ou 'Solicitação de serviço resolvida'. Essas atividades são derivadas das mudanças registradas no log de auditoria do ticket do Zendesk, que acompanha alterações em campos como status, responsável e prioridade, além da adição de comentários. Analisar atividades é o núcleo do Process Mining. Isso permite visualizar o mapa do processo, identificar gargalos entre etapas e analisar ciclos de retrabalho. Ao entender a sequência e a frequência das atividades, as organizações podem identificar ineficiências e oportunidades de melhoria de processos. Por que isso importa Este atributo define as etapas do processo, permitindo visualizar mapas de processo e analisar o fluxo, as variações e a conformidade do processo. Onde obter Conceitualmente, isso é derivado dos eventos registrados na API de Auditorias de Tickets do Zendesk. Por exemplo, uma mudança no campo 'status' de 'new' para 'open' pode ser mapeada para uma atividade como 'Solicitação triada'. Exemplos Solicitação de serviço criadaAgente reatribuídoSolicitação de serviço resolvida
	Hora de início EventTimestamp	A data e a hora exatas em que a atividade ocorreu.
Descrição O registro de data e hora do evento, ou Hora de início, registra o momento exato em que uma atividade ocorreu. Por exemplo, ele captura quando um agente foi atribuído, quando uma resposta pública foi enviada ou quando o status do ticket mudou para 'Resolved'. Esses dados temporais vêm do log de auditoria de cada ticket do Zendesk. Esse atributo é fundamental para qualquer análise baseada em tempo. Ele é usado para ordenar eventos cronologicamente, calcular a duração entre atividades, medir tempos de espera e analisar o tempo de ciclo geral do caso. É essencial para identificar gargalos e avaliar a performance em relação a metas baseadas em tempo, como SLAs. Por que isso importa Esse registro de data e hora ordena os eventos cronologicamente e é essencial para todas as análises de duração, performance e gargalos. Onde obter API de Auditorias de Tickets do Zendesk, campo 'created_at' de cada evento de auditoria. Exemplos 2023-10-26T10:00:00Z2023-10-26T10:15:30Z2023-10-27T14:20:10Z
	ID da Solicitação de Serviço ServiceRequestId	O identificador exclusivo de cada ticket de solicitação de serviço no Zendesk.
Descrição O ID da Solicitação de Serviço, geralmente chamado de Ticket ID no Zendesk, funciona como a chave primária de cada caso. Ele conecta todas as atividades, comentários e mudanças de status relacionados, desde o momento em que uma solicitação é criada até seu encerramento. Isso permite rastrear de ponta a ponta o ciclo de vida de uma única solicitação. Na análise de Process Mining, esse atributo é fundamental. Ele define o caso, permitindo reconstruir os fluxos do processo, identificar variantes e calcular métricas no nível do caso, como o tempo de ciclo. Cada evento do conjunto de dados deve estar associado a um ID da Solicitação de Serviço para que seu contexto no processo geral seja compreendido. Por que isso importa Este é o identificador essencial do caso, conectando todos os eventos da jornada de uma solicitação de serviço e permitindo analisar o processo de ponta a ponta. Onde obter API de Tickets do Zendesk, campo 'id'. Exemplos 102451024610247
	Sistema de origem SourceSystem	Indica o sistema do qual os dados foram extraídos.
Descrição Este atributo especifica a origem dos dados das solicitações de serviço. Nesta visão do processo, o valor será sempre 'Zendesk Support', identificando-o como o sistema de registro de todas as atividades de gestão de serviços. Em ambientes com vários sistemas integrados, esse campo é fundamental para a linhagem dos dados e a solução de problemas. Ele garante que as análises estejam corretamente delimitadas ao sistema pretendido e ajuda a diferenciar dados combinados de várias fontes. Por que isso importa Identifica o sistema de origem dos dados, garantindo a linhagem dos dados e evitando confusão quando dados de vários sistemas são combinados. Onde obter Este é um valor estático ('Zendesk Support') adicionado durante a extração e a transformação dos dados. Exemplos Zendesk Support
	Última atualização dos dados LastDataUpdate	O registro de data e hora que indica a última vez em que os dados foram atualizados a partir do sistema de origem.
Descrição Este atributo registra a data e a hora da extração mais recente de dados do Zendesk Support. Ele fornece contexto sobre a atualidade dos dados analisados, garantindo que os usuários saibam quão atual está a visão do processo. Para monitoramento contínuo e criação de Dashboards, essas informações são essenciais. Elas permitem que analistas e usuários de negócio entendam se estão consultando dados quase em tempo real ou uma fotografia de um período anterior, o que afeta a validade das conclusões. Por que isso importa Fornece um contexto essencial sobre a atualidade dos dados, permitindo que os usuários saibam quão atualizada está a análise. Onde obter Este é um campo de metadados gerado e registrado no conjunto de dados no momento da extração. Exemplos 2023-10-27T08:00:00Z
	Canal da solicitação RequestChannel	O canal pelo qual a solicitação de serviço foi enviada, por exemplo, e-mail, formulário web ou telefone.
Descrição Esse atributo identifica a origem do envio da solicitação de serviço. O Zendesk registra como um ticket foi criado, seja por e-mail, portal web, integração via API, chat ou outros canais. Isso fornece contexto sobre o método de interação do cliente. O canal da solicitação é uma dimensão poderosa para análise. Ele dá suporte ao Dashboard 'Eficiência por canal de solicitação', permitindo comparar tempos de resolução, índices de satisfação e taxas de retrabalho entre diferentes canais. Assim, as empresas podem otimizar seus canais de suporte e orientar os usuários para os mais eficientes. Por que isso importa Ajuda a analisar a eficiência e os resultados de diferentes canais de suporte ao cliente, permitindo melhorias direcionadas. Onde obter Zendesk Tickets API, objeto 'via' e sua propriedade 'channel'. Exemplos webe-mailAPIchat
	Nome do agente AgentName	O nome do agente atribuído à solicitação de serviço no momento do evento.
Descrição Este atributo identifica o agente de suporte responsável por tratar a solicitação de serviço. O agente atribuído pode mudar várias vezes durante o ciclo de vida do ticket, e este campo registra quem era o responsável em cada etapa. O Nome do agente é fundamental para a análise de performance. Ele permite filtrar e segmentar os dados para avaliar a distribuição da carga de trabalho, os tempos de resolução por agente e a frequência das reatribuições. Isso ajuda a criar o Dashboard de Performance de Agentes e Times e a entender as contribuições individuais para a eficiência geral do processo. Por que isso importa Este atributo é essencial para analisar a performance dos agentes, a distribuição da carga de trabalho e o impacto das reatribuições nos tempos de resolução. Onde obter API de Usuários do Zendesk, fazendo a junção com 'assignee_id' da resposta da API de Tickets. Exemplos Jane DoeJohn SmithEmily Jones
	Prioridade da solicitação RequestPriority	O nível de prioridade atribuído à solicitação de serviço, como Baixa, Normal, Alta ou Urgente.
Descrição A prioridade da solicitação é uma classificação que indica a urgência de uma solicitação de serviço. Esse nível geralmente define os prazos-alvo de resolução e as políticas de SLA aplicadas ao ticket. A prioridade pode ser definida inicialmente pelo sistema ou pelo usuário e pode ser alterada por um agente durante o ciclo de vida do ticket. Esse atributo é essencial para a segmentação e a análise de causa raiz. Ele ajuda a analisar se os tickets de alta prioridade são resolvidos mais rapidamente do que os de baixa prioridade e é um fator importante nos Dashboards 'Tendências de escalonamento de solicitações de serviço' e 'Aderência ao SLA'. Por que isso importa Permite segmentar as solicitações por urgência, algo essencial para analisar a conformidade com o SLA e garantir que problemas críticos sejam tratados rapidamente. Onde obter Zendesk Tickets API, campo 'priority'. Exemplos BaixaNormalAltaUrgente
	Status da solicitação RequestStatus	O status da solicitação de serviço no momento do evento, por exemplo, Nova, Aberta ou Pendente.
Descrição O status da solicitação representa o estado do ticket em um determinado momento. O Zendesk tem vários status padrão, como Nova, Aberta, Pendente, Em espera, Resolvida e Fechada, que indicam o avanço da solicitação ao longo do seu ciclo de vida. As alterações nesse campo são os principais gatilhos para criar atividades no Event Log. Analisar o tempo gasto em diferentes status é uma parte central da análise de gargalos. Isso ajuda a identificar onde os tickets estão ficando parados, por exemplo, passando tempo demais nos estados 'Pendente' ou 'Em espera'. Entender as transições de status também é essencial para descobrir loops de retrabalho. Por que isso importa Acompanhar o status é fundamental para entender o progresso da solicitação e identificar quanto tempo é gasto em estados de espera ou ativos. Onde obter Zendesk Tickets API, campo 'status'. Exemplos NovoAbertoPendenteResolvidoFechado
	Tags do ticket TicketTags	Uma lista de tags aplicadas à solicitação de serviço para categorização e roteamento.
Descrição As tags são rótulos flexíveis que podem ser adicionados manualmente aos tickets pelos agentes ou automaticamente por meio de regras de negócio. Elas servem para adicionar contexto ou categorias específicas a um ticket que talvez não sejam contempladas por campos padrão, como Tipo ou Prioridade. As tags são um atributo extremamente versátil para a análise de Process Mining. Elas podem ser usadas para filtrar cenários muito específicos, acompanhar Workflows personalizados ou identificar causas raiz. Por exemplo, uma tag 'VIP' pode ser usada para analisar o processo de clientes estratégicos, enquanto uma tag 'product_bug' pode ajudar a acompanhar o ciclo de vida de relatos de defeitos. Por que isso importa Oferece uma forma flexível de segmentar e detalhar os dados, permitindo uma análise aprofundada de subprocessos específicos ou atributos de tickets que não são registrados em outros campos. Onde obter Zendesk Tickets API, campo 'tags'. Trata-se de uma matriz de strings. Exemplos consulta_vendasproblema_faturamentosolicitacao_recursocliente_vip
	Time atribuído AssignedTeam	O time ou grupo de suporte atribuído à solicitação de serviço.
Descrição Este atributo indica qual time ou grupo da organização de suporte é responsável pela solicitação de serviço. No Zendesk, eles são chamados de 'Groups'. Os tickets geralmente são atribuídos primeiro a um grupo e depois assumidos por um agente individual. Analisar por Time atribuído é essencial para entender a performance e a carga de trabalho no nível do time. Isso ajuda a responder quais times tratam quais tipos de solicitação, quais são seus tempos médios de resolução e suas taxas de aderência aos SLAs. Essa é uma dimensão principal do Dashboard de Performance de Agentes e Times. Por que isso importa Permite analisar a performance da equipe, equilibrar a carga de trabalho e avaliar a eficiência do roteamento entre diferentes grupos de suporte. Onde obter Zendesk Groups API, fazendo a junção de 'group_id' da resposta da Tickets API. Exemplos Suporte de nível 1Suporte técnicoFaturamento
	Tipo de serviço ServiceType	A categoria ou o tipo da solicitação de serviço, por exemplo, Incidente, Dúvida, Problema ou Tarefa.
Descrição O tipo de serviço categoriza a natureza da solicitação de serviço. O Zendesk usa um campo 'type' para diferenciar os tipos de interação de suporte. Essa classificação inicial ajuda a encaminhar o ticket para a equipe correta e aplicar os processos adequados. Esse atributo é essencial para filtragem e comparação. Ele permite que os analistas examinem os fluxos de processo de diferentes tipos de solicitação, que geralmente têm caminhos de resolução e SLAs muito distintos. É uma dimensão importante para o Dashboard de performance de agentes e equipes, ajudando a identificar quem tem melhor desempenho no tratamento de tipos específicos de solicitação. Por que isso importa Categoriza as solicitações para permitir a análise separada de diferentes processos, como incidentes e dúvidas, que seguem caminhos próprios. Onde obter Zendesk Tickets API, campo 'type'. Exemplos perguntaincidenteproblematarefa
	Contagem de reatribuições do agente AgentReassignmentCount	O número total de vezes que uma solicitação foi reatribuída de um agente para outro.
Descrição Esse atributo é um contador que aumenta cada vez que o campo 'assignee_id' de um ticket é alterado. Um número alto de reatribuições para um único ticket pode indicar vários problemas de processo, como roteamento inicial incorreto, falta de conhecimento do agente ou solicitações complexas demais para serem tratadas por uma única pessoa. Essa é uma métrica importante para medir a eficiência do processo e dá suporte direto ao KPI 'Taxa de reatribuição de agentes'. Analisar casos com muitas reatribuições pode revelar oportunidades para melhorar as regras de roteamento, o treinamento dos agentes ou os recursos da base de conhecimento, garantindo que os tickets cheguem mais rapidamente à pessoa certa. Por que isso importa Ajuda a quantificar as transferências internas e identificar atritos no processo, já que taxas altas de reatribuição geralmente causam atrasos e ineficiência. Onde obter Calculado contando o número de alterações em 'assignee_id' na Zendesk Ticket Audits API para cada ticket. Exemplos 013
	É resolução no primeiro contato IsFirstContactResolution	Um indicador que mostra se a solicitação foi resolvida pelo primeiro agente atribuído, sem reatribuições ou respostas do solicitante.
Descrição A resolução no primeiro contato (FCR) é uma métrica essencial que indica que o problema do cliente foi resolvido em uma única interação. Esse atributo calculado é um indicador booleano verdadeiro quando um ticket é resolvido pelo primeiro agente ao qual foi atribuído, sem reatribuições e com apenas uma resposta do agente. Esse atributo dá suporte direto ao KPI 'Taxa de resolução no primeiro contato'. Analisar as características dos casos com FCR pode servir como referência para a excelência operacional. Por outro lado, analisar os casos que não atingem FCR pode revelar oportunidades para melhorar o treinamento dos agentes, os artigos da base de conhecimento ou a triagem inicial. Por que isso importa Mede a capacidade de resolver problemas de forma eficiente em uma única interação, um fator que impulsiona tanto a satisfação do cliente quanto a eficiência operacional. Onde obter Esse é um atributo calculado complexo. É necessário analisar o Event Log de um ticket para verificar as reatribuições de agentes e o número de respostas públicas dos agentes. Exemplos truefalse
	É retrabalho IsRework	Um indicador que é verdadeiro quando a solicitação de serviço é reaberta depois de ser resolvida.
Descrição Esse indicador booleano identifica casos que passaram por retrabalho. Uma solicitação de serviço geralmente é considerada retrabalho quando seu status muda de 'Resolvida' de volta para um estado aberto, indicando que a resolução inicial não foi suficiente e que o cliente precisou entrar em contato novamente sobre o mesmo problema. Esse atributo é essencial para calcular o KPI 'Taxa de retrabalho de solicitações de serviço' e para o Dashboard 'Análise de atividades de retrabalho e reabertura'. Ao sinalizar os casos de retrabalho, os analistas podem isolar esses fluxos de processo ineficientes, descobrir as causas raiz das reaberturas e trabalhar para melhorar a resolução no primeiro contato. Por que isso importa Identifica falhas de processo em que a resolução não foi definitiva, destacando problemas de qualidade e eficiência que afetam diretamente a satisfação do cliente. Onde obter Calculado analisando a sequência de status de um ticket na Zendesk Ticket Audits API. Uma transição de 'solved' para 'open' indica retrabalho. Exemplos truefalse
	Hora de término EndTime	A data e a hora exatas em que a atividade foi concluída.
Descrição A Hora de término marca a conclusão de uma atividade. Para muitos eventos no Zendesk, a duração é instantânea, portanto a Hora de término é igual à Hora de início. No entanto, para atividades baseadas em estado, como 'Solicitação colocada em espera', a Hora de término corresponde ao momento em que o ticket sai da espera. Esse atributo é essencial para calcular a duração de atividades específicas, o que é fundamental para a análise de gargalos. Comparando a Hora de início e a Hora de término de uma atividade, é possível medir diretamente seu tempo de processamento e identificar quais etapas consomem mais tempo. Por que isso importa Permite calcular a duração de atividades individuais, algo fundamental para identificar gargalos no processo e medir a eficiência em cada etapa. Onde obter Geralmente é igual ao StartTime para eventos discretos. Para durações de status, corresponde ao registro de data e hora do próximo evento que altera o status. Exemplos 2023-10-26T10:00:00Z2023-10-26T10:15:30Z2023-10-27T14:20:10Z
	Índice de satisfação SatisfactionRating	A pontuação de satisfação fornecida pelo solicitante depois que o ticket foi resolvido.
Descrição Esse atributo registra o feedback do cliente sobre sua experiência com o suporte, geralmente coletado por meio de uma pesquisa depois que o ticket é marcado como resolvido. As classificações comuns incluem 'Bom' ou 'Ruim', às vezes acompanhadas de um comentário. O índice de satisfação é uma métrica de resultado essencial. Correlacionar padrões de processo com pontuações de satisfação pode revelar quais comportamentos do processo levam a clientes satisfeitos ou insatisfeitos. Por exemplo, a análise pode mostrar que altas taxas de reatribuição ou tempos de resolução longos estão fortemente correlacionados com índices de satisfação negativos. Por que isso importa Estabelece uma relação direta entre a execução do processo e os resultados para o cliente, ajudando a identificar quais comportamentos do processo impulsionam a satisfação do cliente. Onde obter Zendesk Tickets API, campo 'satisfaction_rating.score' ou 'satisfaction_rating.reason'. Exemplos BomRuimOferecido
	Nome da política de SLA SlaPolicyName	O nome da política de Acordo de Nível de Serviço (SLA) aplicada à solicitação.
Descrição Esse atributo identifica a política de SLA específica que define os tempos-alvo de resposta e resolução da solicitação de serviço. Uma política geralmente é determinada por fatores como a prioridade e o tipo da solicitação ou o nível de assinatura do cliente. Conhecer a política de SLA aplicada é essencial para o Dashboard 'Análise de aderência e violações de SLA'. Isso fornece o contexto necessário para avaliar a performance, já que políticas diferentes têm metas diferentes. Assim, é possível avaliar de forma justa e precisa se um ticket cumpriu seus objetivos específicos de nível de serviço. Por que isso importa Fornece o contexto para a análise de SLA ao identificar o conjunto de metas usado para medir uma solicitação, permitindo relatórios precisos de conformidade. Onde obter Zendesk Ticket Metrics API. Os dados de SLA geralmente estão associados às métricas do ticket. Exemplos Urgente - resposta em 1 horaPadrão - resolução em 24 horasSLA de cliente premium
	Nome do solicitante RequestorName	O nome do usuário final ou cliente que enviou a solicitação de serviço.
Descrição Esse atributo identifica a pessoa que iniciou a solicitação de serviço. Vincular a solicitação a um cliente específico oferece uma visão do processo de suporte centrada no usuário. Na análise de processos, o solicitante pode ser usado para analisar padrões de clientes específicos ou segmentos de clientes. Por exemplo, você pode investigar se determinados clientes enfrentam tempos de resolução mais longos ou têm taxas de retrabalho mais altas, o que pode indicar problemas com o produto ou serviço que estão usando. Por que isso importa Conecta o processo ao cliente, permitindo analisar problemas específicos de cada cliente, solicitações repetidas e níveis de satisfação. Onde obter Zendesk Users API, fazendo a junção de 'requester_id' da resposta da Tickets API. Exemplos Alice JohnsonBob WilliamsCharlie Brown
	O SLA foi violado IsSlaBreached	Um indicador que mostra se a solicitação de serviço violou alguma de suas metas de SLA.
Descrição Esse atributo é um indicador booleano ou categórico que mostra o resultado do SLA de um ticket. Ele pode indicar estados como 'Cumprido', 'Violado' ou 'Ativo'. Isso é determinado comparando os tempos reais de resposta ou resolução com as metas definidas na política de SLA aplicada. Esse é um atributo essencial para o Dashboard 'Análise de aderência e violações de SLA'. Ele permite contar e visualizar facilmente tickets em conformidade e fora de conformidade. A análise pode então se concentrar nas características dos tickets que violaram o SLA para identificar causas raiz, como tempos de espera longos ou reatribuições excessivas. Por que isso importa Mede diretamente a performance em relação aos compromissos de nível de serviço, um indicador importante da qualidade do serviço e da satisfação do cliente. Onde obter Derivado da Zendesk Ticket Metrics API, que fornece informações sobre o status do SLA de cada ticket. Exemplos CumpridoVioladoAtivo
	Organização do solicitante RequestorOrganization	A organização ou empresa à qual o solicitante pertence.
Descrição Esse atributo vincula a solicitação de serviço a uma organização específica do cliente. Isso é especialmente relevante em cenários de suporte B2B, nos quais os acordos de nível de serviço e os contratos de suporte geralmente são definidos no nível da organização. Analisar os dados por organização permite ter uma visão da performance do suporte no nível da empresa. Isso pode ajudar a identificar organizações que estão criando um grande volume de tickets, enfrentando problemas recorrentes ou apresentando baixos índices de satisfação. Essas informações são valiosas para a gestão de contas e para identificar tendências mais amplas sobre a saúde dos clientes. Por que isso importa Permite analisar serviços B2B agrupando as solicitações por empresa, algo essencial para gerenciar relacionamentos com clientes e SLAs no nível organizacional. Onde obter Zendesk Organizations API, fazendo a junção de 'organization_id' da resposta da Tickets API. Exemplos Acme CorporationGlobal Tech Inc.Innovate Solutions

Obrigatório Recomendado Opcional

Atividades do gerenciamento de solicitações de serviço

Estas são as principais etapas e os marcos do processo que você deve registrar no seu Event Log para descobrir com precisão o processo das suas solicitações de serviço.

7 Recomendado 6 Opcional

	Atividade	Descrição
	Meta de SLA violada	Essa atividade marca o momento em que uma solicitação de serviço não cumpre uma meta de SLA definida, como o tempo de primeira resposta ou o tempo de resolução. O Zendesk registra isso como um evento explícito quando uma meta não é cumprida.
Por que isso importa Este é um evento crítico para o monitoramento da conformidade e uma entrada importante para o KPI de Taxa de Aderência ao SLA. Ele identifica falhas no cumprimento dos compromissos de serviço. Onde obter Capturado do evento 'SLABreach' nos eventos do ticket ou no log de auditoria do Zendesk. O evento especifica qual métrica de SLA foi violada. Captura Identificado por meio do evento explícito 'SLABreach' nos dados do ticket. Tipo de evento explicit
	Resposta pública enviada	Essa atividade marca qualquer comunicação enviada por um agente ao solicitante. Ela é capturada como um evento 'Comment' explícito nos dados do ticket do Zendesk, quando o atributo 'public' é true.
Por que isso importa Esses eventos são fundamentais para analisar a frequência das comunicações, medir os tempos de resposta dos agentes e identificar o número de interações necessárias para a resolução. Onde obter É um evento 'Comment' explícito nos dados do ticket. Os detalhes do evento incluem o atributo 'public: true', diferenciando-o das notas internas. Captura Capturado a partir de eventos 'Comment' do ticket em que a flag 'public' está definida como true. Tipo de evento explicit
	Solicitação atribuída a um agente	Essa atividade ocorre quando uma solicitação de serviço é atribuída a um agente específico pela primeira vez. Ela é inferida a partir de um evento 'Change' no log de auditoria do ticket, no qual o campo 'assignee_id' é preenchido a partir de um valor nulo ou de um ID de grupo.
Por que isso importa Isso marca o início do trabalho ativo de um agente e é fundamental para medir os tempos de resposta inicial, o atraso até a primeira atribuição e a distribuição da carga de trabalho dos agentes. Onde obter Inferido a partir do primeiro evento 'Change' no campo 'assignee_id' do log de auditoria do ticket, quando um ID de usuário específico é definido. Captura Inferido a partir do primeiro evento de mudança que define o campo 'assignee_id' para um agente. Tipo de evento inferred
	Solicitação de serviço criada	Marca o início do ciclo de vida da solicitação de serviço, quando uma nova solicitação é enviada por um solicitante por qualquer canal. Isso é registrado como um evento 'Create' no log de auditoria do ticket do Zendesk, fornecendo um horário de início definitivo para o processo.
Por que isso importa Essa atividade funciona como o principal evento de início de cada solicitação de serviço, sendo essencial para calcular os tempos de ciclo de ponta a ponta e analisar os volumes de entrada das solicitações. Onde obter É registrado como um tipo de evento 'Create' no log de auditoria do ticket do Zendesk. O registro de data e hora desse evento corresponde ao momento de criação do ticket da solicitação de serviço. Captura Capturado diretamente do evento 'Create' no log de auditoria do ticket. Tipo de evento explicit
	Solicitação de serviço encerrada	Representa o encerramento final e permanente da solicitação de serviço. Um ticket passa automaticamente para o estado 'closed' após permanecer 'solved' por um período definido e não pode mais ser reaberto.
Por que isso importa Essa atividade marca o fim definitivo do processo de solicitação de serviço. Ela fornece o ponto final para calcular a duração completa do caso. Onde obter Inferido a partir de um evento 'Change' no campo 'status' do log de auditoria do ticket, quando o novo valor é 'closed'. Captura Inferido a partir de um evento 'Change' no log de auditoria em que o status se torna 'closed'. Tipo de evento inferred
	Solicitação de serviço reaberta	Ocorre quando um solicitante responde a uma solicitação que está no estado 'solved', alterando automaticamente seu status de volta para 'open'. Isso indica que a resolução proposta não foi suficiente.
Por que isso importa Essa atividade é o principal indicador de retrabalho. Analisar sua frequência ajuda a medir a qualidade da resolução e identificar as causas da insatisfação do cliente. Onde obter Inferido a partir de um evento 'Change' no campo 'status' do log de auditoria do ticket, quando o valor anterior era 'solved' e o novo valor é 'open'. Captura Inferido a partir de uma mudança de status de 'solved' para 'open'. Tipo de evento inferred
	Solicitação de serviço resolvida	Essa atividade marca o momento em que um agente fornece uma solução e altera o status do ticket para 'solved'. A solicitação é considerada concluída do ponto de vista do agente, mas ainda pode ser reaberta pelo solicitante.
Por que isso importa Este é um marco importante que representa o fim do trabalho ativo do agente. O tempo até alcançar esse estado é uma medida principal da eficiência da resolução. Onde obter Inferido a partir de um evento 'Change' no campo 'status' do log de auditoria do ticket, quando o novo valor é 'solved'. Captura Inferido a partir de um evento 'Change' no log de auditoria em que o status se torna 'solved'. Tipo de evento inferred
	Agente reatribuído	Representa a transferência da responsabilidade por uma solicitação de serviço de um agente para outro. Isso é inferido a partir de qualquer evento 'Change' posterior no campo 'assignee_id' após a atribuição inicial.
Por que isso importa Acompanhar reatribuições é fundamental para calcular o KPI de Taxa de Reatribuição de Agentes, que ajuda a identificar ineficiências no processo, roteamento incorreto ou lacunas de conhecimento. Onde obter Inferido a partir de eventos 'Change' no campo 'assignee_id' do log de auditoria do ticket, excluindo o primeiro evento de atribuição do ticket. Captura Inferido a partir do segundo evento 'Change' e dos eventos subsequentes no campo 'assignee_id'. Tipo de evento inferred
	Meta de SLA aplicada	Representa o momento em que uma política de Acordo de Nível de Serviço (SLA) é aplicada ao ticket da solicitação de serviço. Esse evento é registrado explicitamente quando as propriedades do ticket correspondem às condições de uma política de SLA ativa.
Por que isso importa Acompanhar quando um SLA é aplicado é fundamental para monitorar a conformidade, analisar possíveis violações e entender o prazo de serviço esperado para diferentes tipos de solicitação. Onde obter Capturado do evento 'SLAPolicyApplied' nos eventos do ticket ou no log de auditoria do Zendesk. Esse evento especifica qual política foi correspondida. Captura Identificado por meio do evento explícito 'SLAPolicyApplied' nos dados do ticket. Tipo de evento explicit
	Nota interna adicionada	Uma nota ou comentário interno foi adicionado à solicitação de serviço por um agente e fica visível apenas para outros agentes. Isso é registrado como um evento 'Comment' em que o atributo 'public' é false.
Por que isso importa Acompanhar notas internas oferece insight sobre a colaboração entre agentes ou times, que pode ser uma fonte de atrasos ou a chave para resolver problemas com eficiência. Onde obter É um evento 'Comment' explícito nos dados do ticket. Os detalhes do evento incluem o atributo 'public: false', indicando que se trata de uma nota interna. Captura Capturado a partir de eventos 'Comment' do ticket em que a flag 'public' está definida como false. Tipo de evento explicit
	Prioridade alterada	Indica que o nível de prioridade da solicitação de serviço, como 'Low', 'Normal', 'High' ou 'Urgent', foi atualizado. Isso é capturado como um evento 'Change' no campo 'priority' do log de auditoria do ticket.
Por que isso importa Analisar mudanças de prioridade ajuda a identificar solicitações que se tornam mais urgentes ao longo do tempo e a avaliar se a priorização está sendo gerenciada de forma eficaz. Onde obter Registrado como um evento 'Change' no campo 'priority' do log de auditoria do ticket do Zendesk, mostrando os valores anterior e novo. Captura Inferido a partir de eventos 'Change' no campo 'priority' do log de auditoria. Tipo de evento inferred
	Solicitação colocada em espera	Essa atividade ocorre quando o status da solicitação de serviço muda para 'on-hold', normalmente indicando que o agente está aguardando informações do solicitante ou de terceiros. Ela é inferida a partir de um evento de mudança de status.
Por que isso importa Isso ajuda a isolar e medir os tempos de espera que estão fora do controle direto do time de suporte, oferecendo uma visão mais precisa do tempo de atendimento dos agentes. Onde obter Inferido a partir de um evento 'Change' no campo 'status' do log de auditoria do ticket, quando o novo valor é 'on-hold'. Captura Inferido a partir de um evento 'Change' no log de auditoria em que o status se torna 'on-hold'. Tipo de evento inferred
	Solicitação escalada	Representa o escalonamento formal de uma solicitação de serviço para um nível de suporte superior, outro time ou a gestão. Normalmente, isso é inferido a partir de uma mudança no grupo atribuído ao ticket ou de uma alteração em um campo personalizado usado para acompanhar escalonamentos.
Por que isso importa Monitorar escalonamentos ajuda a identificar solicitações complexas, necessidades de treinamento para agentes da linha de frente e problemas sistêmicos que exigem intervenção em um nível superior. Onde obter Este não é um evento padrão. Ele precisa ser inferido a partir de um evento 'Change' no campo 'group_id' para um grupo de escalonamento ou de uma alteração em um campo personalizado do ticket usado para acompanhar escalonamentos. Captura Inferido a partir de uma mudança em 'group_id' ou em um campo personalizado de 'escalation'. Tipo de evento inferred

Recomendado Opcional

Guias de extração

Como obter seus dados do Zendesk Support

Etapas

Acesse o Zendesk Explore e crie o relatório principal: Navegue até o ícone de produtos do Zendesk na barra superior direita e selecione Explore. No Explore, clique no ícone Queries à esquerda e depois em New query. Selecione o conjunto de dados Support: Ticket updates como fonte.
Configure métricas e atributos para eventos de tickets: No criador de consultas, adicione uma métrica como COUNT(Tickets) para visualizar os dados. Depois, acesse a seção Rows e adicione os seguintes atributos: Ticket ID, Update - Timestamp, Updater name, Update - Field name, Update - Previous value, Update - New value, Assignee name, Nome do grupo, Ticket priority, Ticket status, Submission channel, Ticket type e Ticket tags.
Crie um atributo calculado para ActivityName: Para transformar atualizações brutas em atividades relevantes, crie um atributo calculado padrão. Acesse o menu Calculations (ícone de calculadora), selecione Standard calculated attribute e dê a ele o nome ActivityName. Cole na caixa de fórmula a lógica fornecida na seção Query. Essa fórmula mapeia diferentes eventos de atualização de tickets para os nomes de atividade necessários.
Refine e filtre o relatório principal: Adicione o atributo ActivityName à seção Rows. Crie um filtro nesse atributo para excluir valores (null) ou valores indesejados gerados pelo sistema, limpando o conjunto de dados. Adicione também um filtro para Ticket created - Date, limitando a consulta a um período gerenciável, como os últimos 6 meses.
Crie o segundo relatório para eventos de SLA: Crie outra consulta, desta vez selecionando o conjunto de dados Support: SLAs. Isso é necessário porque os eventos de SLA não estão disponíveis no conjunto de dados Ticket updates.
Configure o relatório de SLA: Na consulta de SLA, adicione COUNT(SLA tickets) a Metrics. Na seção Rows, adicione Ticket ID, SLA policy, SLA target, SLA updated - Timestamp, SLA status e Updater name. A atividade será inferida a partir de SLA status na etapa de transformação.
Exporte os dois conjuntos de dados: Execute as duas consultas na interface do Explore. Depois que as tabelas forem geradas, clique no botão Export e escolha CSV como formato. Você terá dois arquivos CSV separados.
Mescle e transforme os dados: Combine os dois arquivos CSV usando uma ferramenta de planilhas, como o Microsoft Excel, ou uma linguagem de script, como Python. O objetivo é criar um único registro de eventos. No arquivo de SLA, você precisará criar a coluna ActivityName. Se SLA status for Ativo, a atividade será SLA Target Applied. Se SLA status for Breached, a atividade será SLA Target Breached. Use SLA updated - Timestamp como EventTimestamp.
Padronize os cabeçalhos das colunas: No arquivo final mesclado, renomeie as colunas para corresponder ao formato exigido pelo Process Mining. Por exemplo, renomeie Ticket ID para ServiceRequestId, Update - Timestamp para EventTimestamp e Updater name para AgentName.
Adicione colunas estáticas e finalize: Adicione duas novas colunas ao arquivo CSV final. Preencha SourceSystem com o valor 'Zendesk'. Preencha LastDataUpdate com o timestamp de quando a exportação foi realizada. O arquivo está pronto para ser carregado.

Configuração

Plano do Zendesk: É necessário ter um plano do Zendesk Support que inclua o Zendesk Explore Professional ou Enterprise para criar consultas e atributos personalizados.
Permissões: Você precisa ser um Agent com permissão para criar e editar consultas no Explore. Normalmente, isso significa ser Administrator ou um agente com uma função personalizada.
Seleção do conjunto de dados: Este método exige a criação de dois relatórios separados com base em dois conjuntos de dados diferentes: Support: Ticket updates para eventos gerais e Support: SLAs para eventos específicos de SLA.
Filtro de período: É fundamental aplicar um filtro de período, por exemplo em Ticket created - Date, para manter o volume de dados administrável. Recomenda-se um período de 3 a 6 meses para a análise inicial.
Atributos calculados: A lógica para derivar os nomes das atividades é tratada por um atributo calculado personalizado e complexo no Explore. Verifique se a fórmula foi criada corretamente para evitar erros na saída.
Volume de dados: A interface do Zendesk Explore e a funcionalidade de exportação podem ficar lentas ou atingir o tempo limite com conjuntos de dados muito grandes. Para extrações que abrangem mais de um ano de dados ou milhões de tickets, considere dividir a exportação em períodos menores.

a Consulta de exemplo config

This method uses the Zendesk Explore UI, where queries are built visually. The following describes the configuration for the two required reports.

**Report 1: Ticket Events Configuration**
* **Dataset**: `Support: Ticket updates`
* **Metrics**: `COUNT(Tickets)`
* **Rows**:
  * `Ticket ID`
  * `ActivityName` (This is the custom calculated attribute defined below)
  * `Update - Timestamp`
  * `Updater name`
  * `Assignee name`
  * `Group name`
  * `Ticket priority`
  * `Ticket status`
  * `Submission channel`
  * `Ticket type`
  * `Ticket tags`
* **Standard Calculated Attribute (`ActivityName`) Formula**:
```
IF [Update - Field name] = "assignee_id" AND ([Update - Previous value] = "" OR [Update - Previous value] = NULL) THEN
    "Request Assigned to Agent"
ELIF [Update - Field name] = "assignee_id" AND [Update - Previous value] != "" AND [Update - Previous value] != NULL THEN
    "Agent Reassigned"
ELIF [Update - Field name] = "group_id" THEN
    "Request Escalated"
ELIF [Update - Field name] = "priority" AND [Update - New value] != [Update - Previous value] THEN
    "Priority Changed"
ELIF [Update - Field name] = "status" AND [Update - New value] = "hold" THEN
    "Request Placed On-Hold"
ELIF [Update - Field name] = "status" AND [Update - New value] = "solved" THEN
    "Service Request Resolved"
ELIF [Update - Field name] = "status" AND [Update - New value] = "closed" THEN
    "Service Request Closed"
ELIF [Update - Field name] = "status" AND [Update - New value] = "open" AND [Update - Previous value] = "solved" THEN
    "Service Request Reopened"
ELIF [Update - Field name] = "requester_id" AND [Update - Previous value] = NULL THEN
    "Service Request Created"
ELSE
    NULL
ENDIF
```
* **Note on Comment Activities**: Capturing `Public Reply Sent` and `Internal Note Added` from the `Ticket updates` dataset is not reliably possible as the public vs. internal distinction is often missing. For these events, creating a third report on the `Support: Comments` dataset and merging it is the recommended, though more complex, approach.

**Report 2: SLA Events Configuration**
* **Dataset**: `Support: SLAs`
* **Metrics**: `COUNT(SLA tickets)`
* **Rows**:
  * `Ticket ID`
  * `SLA updated - Timestamp`
  * `SLA status`
  * `Updater name`
  * `Assignee name`
  * `Group name`
  * `Ticket priority`
* **Note**: The `ActivityName` for this report (`SLA Target Applied`, `SLA Target Breached`) must be generated after export based on the value in the `SLA status` column.

Etapas

Pré-requisitos: Verifique se o Python 3.6 ou uma versão mais recente está instalado no seu sistema. Você também precisará de acesso administrativo à sua instância do Zendesk Support para gerar um token de API.
Instale as bibliotecas Python: Abra o terminal ou o prompt de comando e instale as bibliotecas Python necessárias usando pip. A biblioteca requests é usada para fazer chamadas de API, e pandas é usada para manipular dados e exportá-los para um arquivo CSV.
```
pip install requests pandas
```
Gere um token de API do Zendesk: Faça login no Zendesk como administrador. Acesse Admin Center > Apps and integrations > APIs > Zendesk API. Na seção Token Access, habilite o acesso caso ele ainda não esteja habilitado e clique em "Add API token". Informe uma descrição, por exemplo "ProcessMind Extraction", e copie o token gerado. Esse token não será exibido novamente.
Configure o script Python: Abra o script Python fornecido em um editor de texto. Preencha as variáveis de configuração no início do arquivo: ZENDESK_SUBDOMAIN, o nome do domínio do Zendesk da sua empresa; ZENDESK_EMAIL, o endereço de e-mail do usuário administrador associado ao token; e ZENDESK_API_TOKEN. Defina também START_TIME_STR para indicar o início do período de extração de dados, normalmente de 3 a 6 meses atrás.
Entenda a lógica do script: Primeiro, o script busca uma lista de tickets atualizados dentro do período especificado usando a Incremental Tickets API, que é eficiente. Depois, busca o histórico completo de auditoria, os comentários e as métricas de SLA de cada ticket. Em seguida, processa esses eventos em ordem cronológica para criar um histórico detalhado.
Mapeie eventos do Zendesk para atividades: O script contém uma lógica para transformar eventos brutos do Zendesk nas atividades de negócio necessárias. Por exemplo, um evento 'Change' no campo 'status' é mapeado para atividades como 'Service Request Resolved' ou 'Request Placed On-Hold'. Os eventos de comentário são verificados para determinar se correspondem a 'Public Reply Sent' ou 'Internal Note Added'.
Execute o script de extração: Execute o script no terminal usando python your_script_name.py. O script exibirá atualizações de progresso enquanto busca dados na API do Zendesk. Dependendo do volume de dados e dos limites de requisições da API, esse processo pode levar algum tempo.
Revise o arquivo de saída: Quando o script for concluído, ele gerará um arquivo CSV chamado zendesk_event_log.csv no mesmo diretório. Esse arquivo contém o registro de eventos extraído, com todas as atividades e atributos especificados.
Prepare o upload: Abra o arquivo CSV para verificar se ele está formatado corretamente. Os cabeçalhos das colunas devem corresponder aos atributos necessários: ServiceRequestId, ActivityName, EventTimestamp, SourceSystem, LastDataUpdate e outros. O arquivo está pronto para upload no ProcessMind.

Configuração

Acesso à API do Zendesk: O script exige um token de API ativo associado a um administrador ou a um agente com permissões suficientes. O e-mail do usuário configurado no script deve ser o mesmo que criou o token de API.
Parâmetros do script: Antes de executar o script, você precisa configurar estas variáveis principais: ZENDESK_SUBDOMAIN, ZENDESK_EMAIL, ZENDESK_API_TOKEN e START_TIME_STR. START_TIME_STR deve estar no formato 'YYYY-MM-DD'.
Período: Recomendamos começar com uma extração dos últimos 3 a 6 meses de dados (START_TIME_STR). Isso fornece um conjunto de dados representativo para análise sem aumentar excessivamente o tempo de execução nem atingir os limites da API com muita frequência. Um período maior aumentará significativamente o tempo de extração.
API de exportações incrementais: O script usa o endpoint Incremental Exports (/api/v2/incremental/tickets/cursor.json) para buscar com eficiência apenas os tickets atualizados desde a última execução ou desde um horário inicial especificado. Esse método é muito mais eficiente do que verificar todos os tickets.
Limitação de requisições: O Zendesk aplica limites de requisições à API. O script inclui um tratamento básico para pausar quando um limite é atingido, mas, em instâncias muito grandes, a extração pode levar bastante tempo. O ideal é executar o script fora dos horários de pico.
Lógica de escalação: A atividade 'Request Escalated' é inferida a partir de uma alteração no campo group_id. Se a sua organização usa outro mecanismo, como um campo personalizado do ticket, será necessário modificar a lógica do script para identificar corretamente as escalações.

a Consulta de exemplo python

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

class=class="hl-string">"hl-comment"># --- Configuration ---
class=class="hl-string">"hl-comment"># Replace with your Zendesk subdomain, admin email, and API token
ZENDESK_SUBDOMAIN = class="hl-string">'[Your Subdomain]'
ZENDESK_EMAIL = class="hl-string">'[Your Zendesk Admin Email]'
ZENDESK_API_TOKEN = class="hl-string">'[Your Zendesk API Token]'

class=class="hl-string">"hl-comment"># Set the start date for the data extraction (YYYY-MM-DD)
START_TIME_STR = class="hl-string">'2023-01-01'

class=class="hl-string">"hl-comment"># --- End of Configuration ---

class=class="hl-string">"hl-comment"># Set up constants and session
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.now(timezone.utc).isoformat()

session = requests.Session()
session.auth = AUTH

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

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

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

def handle_rate_limit(response):
    if response.status_code == 429:
        retry_after = int(response.headers.get(class="hl-string">'Retry-After', 60))
        print(fclass="hl-string">'Rate limit reached. Waiting for {retry_after} seconds...')
        time.sleep(retry_after)
        return True
    response.raise_for_status()
    return False

def fetch_paginated_data(url):
    while url:
        try:
            response = session.get(url)
            if handle_rate_limit(response):
                continue
            data = response.json()
            yield data
            url = data.get(class="hl-string">'next_page')
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">'Error fetching data from {url}: {e}')
            break

def process_ticket(ticket, event_log):
    ticket_id = ticket[class="hl-string">'id']
    print(fclass="hl-string">'Processing Ticket ID: {ticket_id}')

    class=class="hl-string">"hl-comment"># --- 1. Fetch Ticket Audits ---
    audits_url = fclass="hl-string">'{BASE_URL}/tickets/{ticket_id}/audits.json'
    all_events = [] class=class="hl-string">"hl-comment"># A temporary list to hold all events for sorting

    for audit_page in fetch_paginated_data(audits_url):
        for audit in audit_page.get(class="hl-string">'audits', []):
            author_id = audit.get(class="hl-string">'author_id')
            timestamp = audit[class="hl-string">'created_at']

            class=class="hl-string">"hl-comment"># Store ticket state at the time of the audit
            ticket_state = {}
            for event in audit.get(class="hl-string">'events', []):
                if event.get(class="hl-string">'field_name') in [class="hl-string">'assignee_id', class="hl-string">'group_id', class="hl-string">'priority', class="hl-string">'status', class="hl-string">'channel', class="hl-string">'type', class="hl-string">'tags']:
                    ticket_state[event[class="hl-string">'field_name']] = event.get(class="hl-string">'value')

            for event in audit.get(class="hl-string">'events', []):
                event[class="hl-string">'timestamp'] = timestamp
                event[class="hl-string">'author_id'] = author_id
                event[class="hl-string">'ticket_state'] = ticket_state
                all_events.append(event)

    class=class="hl-string">"hl-comment"># --- 2. Fetch Comments (which are not fully detailed in audits) ---
    comments_url = fclass="hl-string">'{BASE_URL}/tickets/{ticket_id}/comments.json'
    for comment_page in fetch_paginated_data(comments_url):
        for comment in comment_page.get(class="hl-string">'comments', []):
            comment[class="hl-string">'type'] = class="hl-string">'Comment'
            comment[class="hl-string">'timestamp'] = comment[class="hl-string">'created_at']
            class=class="hl-string">"hl-comment"># Add ticket_state placeholder, though it's less relevant for comments
            comment[class="hl-string">'ticket_state'] = {}
            all_events.append(comment)

    class=class="hl-string">"hl-comment"># --- 3. Fetch SLA Metrics ---
    metrics_url = fclass="hl-string">'{BASE_URL}/tickets/{ticket_id}/metrics.json'
    try:
        response = session.get(metrics_url)
        if not handle_rate_limit(response):
            metrics_data = response.json().get(class="hl-string">'ticket_metric', {})
            if metrics_data.get(class="hl-string">'sla_policy'):
                for sla in metrics_data[class="hl-string">'sla_policy'][class="hl-string">'policy_metrics']:
                    all_events.append({
                        class="hl-string">'type': class="hl-string">'SlaApply',
                        class="hl-string">'timestamp': metrics_data[class="hl-string">'created_at'],
                        class="hl-string">'policy_name': sla[class="hl-string">'policy'][class="hl-string">'title'],
                        class="hl-string">'ticket_state': {}
                    })
                    if sla.get(class="hl-string">'breach_at') and datetime.fromisoformat(sla[class="hl-string">'breach_at'].replace(class="hl-string">'Z', class="hl-string">'+00:00')) < datetime.now(timezone.utc):
                        all_events.append({
                            class="hl-string">'type': class="hl-string">'SlaBreach',
                            class="hl-string">'timestamp': sla[class="hl-string">'breach_at'],
                            class="hl-string">'policy_name': sla[class="hl-string">'policy'][class="hl-string">'title'],
                            class="hl-string">'metric': sla[class="hl-string">'metric'],
                            class="hl-string">'ticket_state': {}
                        })
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">'Could not fetch SLA metrics for ticket {ticket_id}: {e}')


    class=class="hl-string">"hl-comment"># --- 4. Sort all collected events by timestamp ---
    all_events.sort(key=lambda x: x[class="hl-string">'timestamp'])

    class=class="hl-string">"hl-comment"># --- 5. Process sorted events to create event log rows ---
    last_assignee = None

    for event in all_events:
        activity_name = None
        timestamp = event[class="hl-string">'timestamp']

        event_type = event.get(class="hl-string">'type')
        field_name = event.get(class="hl-string">'field_name')

        if event_type == class="hl-string">'Create':
            activity_name = class="hl-string">'Service Request Created'
            last_assignee = event.get(class="hl-string">'value') if field_name == class="hl-string">'assignee_id' else None

        elif event_type == class="hl-string">'Change':
            prev_value = event.get(class="hl-string">'previous_value')
            new_value = event.get(class="hl-string">'value')

            if field_name == class="hl-string">'status':
                if new_value == class="hl-string">'solved': activity_name = class="hl-string">'Service Request Resolved'
                elif new_value == class="hl-string">'closed': activity_name = class="hl-string">'Service Request Closed'
                elif new_value == class="hl-string">'hold': activity_name = class="hl-string">'Request Placed On-Hold'
                elif new_value == class="hl-string">'open' and prev_value == class="hl-string">'solved': activity_name = class="hl-string">'Service Request Reopened'
            elif field_name == class="hl-string">'priority': activity_name = class="hl-string">'Priority Changed'
            elif field_name == class="hl-string">'assignee_id':
                if prev_value is None and new_value is not None:
                    activity_name = class="hl-string">'Request Assigned to Agent'
                elif prev_value is not None and new_value is not None:
                    activity_name = class="hl-string">'Agent Reassigned'
                last_assignee = new_value
            elif field_name == class="hl-string">'group_id':
                if prev_value is not None and new_value is not None:
                    activity_name = class="hl-string">'Request Escalated'

        elif event_type == class="hl-string">'Comment':
            if event.get(class="hl-string">'public', False):
                activity_name = class="hl-string">'Public Reply Sent'
            else:
                activity_name = class="hl-string">'Internal Note Added'

        elif event_type == class="hl-string">'SlaApply':
            activity_name = class="hl-string">'SLA Target Applied'
        elif event_type == class="hl-string">'SlaBreach':
            activity_name = class="hl-string">'SLA Target Breached'

        if activity_name:
            class=class="hl-string">"hl-comment"># Get attribute values from the ticket object itself as a baseline
            agent_id = ticket.get(class="hl-string">'assignee_id')
            group_id = ticket.get(class="hl-string">'group_id')
            priority = ticket.get(class="hl-string">'priority')
            status = ticket.get(class="hl-string">'status')
            
            class=class="hl-string">"hl-comment"># Override with values at the time of the event if available
            state = event.get(class="hl-string">'ticket_state', {})
            agent_id = state.get(class="hl-string">'assignee_id', agent_id)
            group_id = state.get(class="hl-string">'group_id', group_id)
            priority = state.get(class="hl-string">'priority', priority)
            status = state.get(class="hl-string">'status', status)
            
            event_log.append({
                class="hl-string">'ServiceRequestId': ticket_id,
                class="hl-string">'ActivityName': activity_name,
                class="hl-string">'EventTimestamp': timestamp,
                class="hl-string">'SourceSystem': SOURCE_SYSTEM,
                class="hl-string">'LastDataUpdate': LAST_DATA_UPDATE,
                class="hl-string">'AgentName': get_user_name(agent_id),
                class="hl-string">'AssignedTeam': get_group_name(group_id),
                class="hl-string">'RequestPriority': priority,
                class="hl-string">'RequestStatus': status,
                class="hl-string">'RequestChannel': ticket.get(class="hl-string">'via', {}).get(class="hl-string">'channel'),
                class="hl-string">'ServiceType': ticket.get(class="hl-string">'type'),
                class="hl-string">'TicketTags': class="hl-string">', '.join(ticket.get(class="hl-string">'tags', [])),
            })


def main():
    print(class="hl-string">'Starting Zendesk data extraction...')
    event_log = []
    start_unix_time = int(datetime.strptime(START_TIME_STR, class="hl-string">'%Y-%m-%d').timestamp())
    
    class=class="hl-string">"hl-comment"># Use the incremental export endpoint for efficiency
    url = fclass="hl-string">'{BASE_URL}/incremental/tickets/cursor.json?start_time={start_unix_time}'

    while url:
        try:
            response = session.get(url)
            if handle_rate_limit(response):
                continue
            data = response.json()
            tickets = data.get(class="hl-string">'tickets', [])
            print(fclass="hl-string">'Fetched {len(tickets)} tickets...')
            for ticket in tickets:
                process_ticket(ticket, event_log)
            
            if not data.get(class="hl-string">'after_cursor'):
                break
            url = data[class="hl-string">'next_page']

        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">'A critical error occurred: {e}')
            break

    print(fclass="hl-string">'Extraction complete. Total events found: {len(event_log)}')
    
    if not event_log:
        print(class="hl-string">'No events were extracted. Please check your configuration and date range.')
        return

    df = pd.DataFrame(event_log)

    class=class="hl-string">"hl-comment"># Reorder columns to match requirements
    columns = [
        class="hl-string">'ServiceRequestId', class="hl-string">'ActivityName', class="hl-string">'EventTimestamp', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate',
        class="hl-string">'AgentName', class="hl-string">'AssignedTeam', class="hl-string">'RequestPriority', class="hl-string">'RequestStatus',
        class="hl-string">'RequestChannel', class="hl-string">'ServiceType', class="hl-string">'TicketTags'
    ]
    df = df[columns]
    df = df.sort_values(by=[class="hl-string">'ServiceRequestId', class="hl-string">'EventTimestamp']).reset_index(drop=True)

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

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

Etapas

No Zendesk Admin Center, solicite ou inicie a Native Full Account JSON Export usando o recurso de exportação disponível na sua assinatura e conta do Zendesk. O caminho exato do menu e os requisitos de autorização variam conforme a configuração da conta. Use a opção de exportação disponível no Admin Center e siga o processo de aprovação da sua organização.
Selecione um período que cubra a análise necessária, de preferência de três a seis meses. Se a exportação nativa não oferecer um filtro de período, baixe a exportação completa da conta e aplique o filtro durante a transformação.
Baixe e mantenha todos os arquivos JSON produzidos pela exportação. Preserve os arquivos originais, o registro de data e hora da exportação, o identificador da conta e qualquer arquivo de manifesto ou metadados. Não substitua os arquivos de origem durante o processamento.
Analise os registros de tickets, registros de auditoria de tickets, eventos de auditoria, comentários, usuários, organizações, grupos, registros relacionados a SLA e campos personalizados contidos na exportação. Como os nomes dos arquivos e as estruturas JSON podem variar conforme a versão da exportação do Zendesk, configure os caminhos de origem e os mapeamentos de propriedades JSON nos placeholders do script antes da execução.
Normalize cada evento de auditoria de ticket em uma estrutura comum contendo ServiceRequestId, registro de data e hora da auditoria, tipo de evento, nome do campo, valor anterior, novo valor, identificador do responsável pela ação, indicador público, status do ticket, responsável, grupo, prioridade, canal, tipo de serviço, tags, sistema de origem e LastDataUpdate.
Gere uma linha do registro de eventos para cada atividade qualificada. A extração deve criar explicitamente linhas para Service Request Created, SLA Target Applied, Request Assigned to Agent, Priority Changed, Agent Reassigned, Public Reply Sent, Internal Note Added, Request Placed On-Hold, Request Escalated, SLA Target Breached, Service Request Reopened, Service Request Resolved e Service Request Closed. O ProcessMind lê essas linhas como estão e não infere eventos adicionais.
Resolva os identificadores de agente, grupo, organização e solicitante usando os registros correspondentes de usuários, grupos e organizações exportados, quando disponíveis. Preencha AgentName e AssignedTeam com o estado da atribuição no momento do evento. Mantenha o identificador ou deixe o valor em branco quando não for possível resolver um nome de exibição.
Aplique regras determinísticas de eventos. Use o evento de auditoria Create do ticket para Service Request Created; eventos explícitos de auditoria de SLA para SLA Target Applied e SLA Target Breached; a primeira alteração de responsável que atender aos critérios para Request Assigned to Agent; alterações posteriores de responsável para Agent Reassigned; indicadores de comentários públicos e privados para eventos de resposta e nota; transições de status para eventos de espera, reabertura, resolução e fechamento; e alterações no grupo ou no campo de escalação configurado para Request Escalated.
Ordene as linhas resultantes por ServiceRequestId e EventTimestamp, mantendo uma sequência estável do evento de origem como critério de desempate. Não deduplique eventos apenas porque os registros de data e hora são iguais, pois vários comentários ou eventos de auditoria podem ocorrer ao mesmo tempo.
Valide se todas as colunas obrigatórias estão presentes e se cada atividade tem pelo menos uma linha qualificada quando os dados de origem contêm o evento correspondente. Exporte o resultado final como CSV UTF-8 ou em outro formato de registro de eventos compatível com o ProcessMind, com uma linha por evento e os nomes de coluna obrigatórios ServiceRequestId, ActivityName, EventTimestamp, SourceSystem e LastDataUpdate.

Configuração

Escopo da exportação: Use a Native Full Account JSON Export do Zendesk Support e mantenha todos os arquivos JSON gerados pela exportação. A exportação deve incluir dados de tickets e dados de auditoria ou eventos de tickets. Se dados de SLA, comentários, usuários, organizações, grupos ou campos personalizados forem entregues separadamente, inclua esses arquivos na entrada da transformação.
Período: Prefira de três a seis meses para a extração e validação iniciais. Se a exportação nativa abranger toda a conta e não puder ser restringida por período, filtre EventTimestamp após a análise, mantendo o arquivo completo de origem.
Regras de atividade: Configure mapeamentos explícitos para todas as 13 atividades. Não dependa do ProcessMind para derivar eventos de atribuição, escalação, SLA, status ou comentários a partir de outras linhas.
Configuração de SLA: Mapeie os nomes ou as propriedades reais dos eventos exportados usados pela conta para aplicação e violação de metas de SLA. Se a exportação não contiver eventos explícitos de SLA, não os invente. Configure os caminhos de origem correspondentes nos placeholders e documente qualquer atividade indisponível.
Configuração de escalação: Identifique o campo de grupo específico da conta ou o campo personalizado que representa uma escalação. Defina ESCALATION_FIELD_ID ou a configuração equivalente com o identificador real do campo exportado antes da execução.
Caminhos de origem: Defina os caminhos dos arquivos JSON e os mapeamentos de propriedades JSON no script. Os nomes dos arquivos e a estrutura dos dados da exportação do Zendesk podem variar conforme a versão da exportação e a configuração da conta.
Saída obrigatória: ServiceRequestId, ActivityName, EventTimestamp, SourceSystem e LastDataUpdate devem ser preenchidos em todas as linhas de eventos. As colunas recomendadas são AgentName, AssignedTeam, RequestPriority, RequestStatus, RequestChannel, ServiceType e TicketTags.
Filtros: Aplique o período de análise necessário, o escopo da conta ou da marca e quaisquer filtros específicos da empresa somente depois de confirmar a propriedade exportada correspondente. Não aplique filtros com base em nomes de campos não compatíveis ou não verificados.
Performance: Processe o JSON de forma incremental sempre que possível, evite carregar toda a exportação da conta na memória, indexe os identificadores de tickets e auditorias e grave arquivos intermediários normalizados antes de produzir o registro de eventos final. Exportações grandes podem exigir particionamento por período ou identificador de ticket.
Pré-requisitos: Acesso administrativo para solicitar ou baixar a exportação nativa da conta, autorização para acessar auditorias de tickets e dados de referência de usuários ou grupos, uma assinatura do Zendesk que ofereça suporte ao recurso de exportação, armazenamento local para a exportação completa e um ambiente capaz de analisar JSON e gravar CSV UTF-8.
Proteção de dados: Trate dados de solicitantes, agentes, organizações, comentários e tickets como potencialmente sensíveis. Armazene os arquivos de origem e transformados de acordo com os requisitos organizacionais de retenção, controle de acesso e privacidade.

a Consulta de exemplo config

import csv
import json
import os
from datetime import datetime, timezone
from pathlib import Path

SOURCE_DIRECTORY = "[Path to extracted Zendesk JSON directory]"
OUTPUT_FILE = "[Path to ProcessMind event log CSV]"
START_DATE = "[YYYY-MM-DD or blank]"
END_DATE = "[YYYY-MM-DD or blank]"
SOURCE_SYSTEM = "Zendesk Support"
LAST_DATA_UPDATE = "[ISO-8601 timestamp of source refresh]"
ESCALATION_FIELD_ID = "[Zendesk custom field identifier used for escalation, or blank]"


def load_json_files(directory):
    documents = []
    for path in Path(directory).rglob("*.json"):
        with path.open("r", encoding="utf-8") as handle:
            documents.append((path.name, json.load(handle)))
    return documents


def as_list(value):
    if isinstance(value, list):
        return value
    if isinstance(value, dict):
        for key in ("tickets", "ticket", "audits", "events", "comments", "users", "groups", "organizations", "data", "results"):
            if isinstance(value.get(key), list):
                return value[key]
    return []


def parse_timestamp(value):
    if not value:
        return None
    text = str(value).replace("Z", "+00:00")
    try:
        parsed = datetime.fromisoformat(text)
        if parsed.tzinfo is None:
            parsed = parsed.replace(tzinfo=timezone.utc)
        return parsed.astimezone(timezone.utc)
    except ValueError:
        return None


def in_range(timestamp):
    if timestamp is None:
        return False
    if START_DATE and timestamp.date().isoformat() < START_DATE:
        return False
    if END_DATE and timestamp.date().isoformat() > END_DATE:
        return False
    return True


def value(record, *keys):
    for key in keys:
        if isinstance(record, dict) and record.get(key) is not None:
            return record.get(key)
    return None


def identifier(record):
    return value(record, "id", "user_id", "group_id", "organization_id", "ticket_id")


def normalize_id(value_to_normalize):
    if value_to_normalize is None or value_to_normalize == "":
        return None
    return str(value_to_normalize)


def audit_events(audit):
    events = value(audit, "events", "audit_events")
    return events if isinstance(events, list) else []


def event_type(event):
    return str(value(event, "type", "event_type", "action") or "").lower()


def event_field(event):
    return str(value(event, "field_name", "field", "property") or "").lower()


def event_value(event, key):
    return value(event, key, key.replace("_", ""))


def status_value(ticket, event, new=True):
    if new:
        return value(event, "value", "new_value", "to") or value(ticket, "status")
    return value(event, "previous_value", "old_value", "from")


def comment_public(event):
    public_value = value(event, "public", "is_public")
    return public_value is True or str(public_value).lower() == "true"


def add_row(rows, ticket, activity, timestamp, agent_name=None, assigned_team=None, priority=None, status=None, channel=None, service_type=None, tags=None, sequence=0):
    parsed = parse_timestamp(timestamp)
    if not in_range(parsed):
        return
    rows.append({
        "ServiceRequestId": str(value(ticket, "id", "ticket_id")),
        "ActivityName": activity,
        "EventTimestamp": parsed.isoformat(),
        "SourceSystem": SOURCE_SYSTEM,
        "LastDataUpdate": LAST_DATA_UPDATE,
        "AgentName": agent_name or "",
        "AssignedTeam": assigned_team or "",
        "RequestPriority": priority or "",
        "RequestStatus": status or "",
        "RequestChannel": channel or "",
        "ServiceType": service_type or "",
        "TicketTags": ",".join(tags) if isinstance(tags, list) else (tags or ""),
        "SourceSequence": sequence
    })


def main():
    documents = load_json_files(SOURCE_DIRECTORY)
    tickets = {}
    audits_by_ticket = {}
    users = {}
    groups = {}
    organizations = {}
    standalone_comments = []
    standalone_sla_events = []

    for filename, document in documents:
        records = as_list(document)
        lower_name = filename.lower()
        for record in records:
            if not isinstance(record, dict):
                continue
            record_id = normalize_id(identifier(record))
            if any(token in lower_name for token in ("user", "agent")) and record_id:
                users[record_id] = record
            elif "group" in lower_name and record_id:
                groups[record_id] = record
            elif "organization" in lower_name and record_id:
                organizations[record_id] = record
            elif "audit" in lower_name and value(record, "ticket_id") is not None:
                audits_by_ticket.setdefault(normalize_id(value(record, "ticket_id")), []).append(record)
            elif "comment" in lower_name:
                standalone_comments.append(record)
            elif "sla" in lower_name:
                standalone_sla_events.append(record)
            elif value(record, "ticket_id") is not None and value(record, "type", "event_type") is not None:
                standalone_sla_events.append(record)
            elif value(record, "id") is not None and any(key in record for key in ("status", "priority", "assignee_id", "group_id", "tags")):
                tickets[record_id] = record

    rows = []
    for ticket_id, ticket in tickets.items():
        if not ticket_id:
            continue
        ticket_audits = audits_by_ticket.get(ticket_id, [])
        ticket_audits.sort(key=lambda item: (parse_timestamp(value(item, "created_at", "timestamp", "time")) or datetime.min.replace(tzinfo=timezone.utc), str(value(item, "id") or "")))
        current_assignee = normalize_id(value(ticket, "assignee_id"))
        current_group = normalize_id(value(ticket, "group_id"))
        assignment_seen = False
        sequence = 0
        base_priority = value(ticket, "priority")
        base_status = value(ticket, "status")
        base_channel = value(ticket, "via", "channel")
        base_service_type = value(ticket, "type", "service_type")
        base_tags = value(ticket, "tags") or []

        for audit in ticket_audits:
            audit_time = value(audit, "created_at", "timestamp", "time")
            actor_id = normalize_id(value(audit, "author_id", "actor_id", "user_id"))
            actor = users.get(actor_id, {})
            agent_name = value(actor, "name", "display_name", "email") or ""
            audit_group = groups.get(current_group, {})
            assigned_team = value(audit_group, "name", "display_name") or ""
            for event in audit_events(audit):
                sequence += 1
                kind = event_type(event)
                field = event_field(event)
                timestamp = value(event, "created_at", "timestamp", "time") or audit_time
                new_value = event_value(event, "value") or event_value(event, "new_value") or event_value(event, "to")
                old_value = event_value(event, "previous_value") or event_value(event, "old_value") or event_value(event, "from")
                event_agent = agent_name
                event_team = assigned_team
                if field in ("assignee_id", "assignee"):
                    new_assignee = normalize_id(new_value)
                    old_assignee = normalize_id(old_value)
                    if new_assignee and not assignment_seen and new_assignee != current_group:
                        assigned_agent = users.get(new_assignee, {})
                        add_row(rows, ticket, "Request Assigned to Agent", timestamp, value(assigned_agent, "name", "display_name", "email") or event_agent, event_team, base_priority, base_status, base_channel, base_service_type, base_tags, sequence)
                        assignment_seen = True
                    elif new_assignee and assignment_seen and new_assignee != old_assignee:
                        assigned_agent = users.get(new_assignee, {})
                        add_row(rows, ticket, "Agent Reassigned", timestamp, value(assigned_agent, "name", "display_name", "email") or event_agent, event_team, base_priority, base_status, base_channel, base_service_type, base_tags, sequence)
                    current_assignee = new_assignee or current_assignee
                elif field in ("priority",):
                    add_row(rows, ticket, "Priority Changed", timestamp, event_agent, event_team, new_value, base_status, base_channel, base_service_type, base_tags, sequence)
                    base_priority = new_value or base_priority
                elif field in ("group_id", "group"):
                    new_group = normalize_id(new_value)
                    new_group_record = groups.get(new_group, {})
                    new_team = value(new_group_record, "name", "display_name") or event_team
                    if new_group and new_group != current_group:
                        add_row(rows, ticket, "Request Escalated", timestamp, event_agent, new_team, base_priority, base_status, base_channel, base_service_type, base_tags, sequence)
                    current_group = new_group or current_group
                elif field in ("status", "status_category"):
                    status_text = str(new_value or "").lower()
                    old_status_text = str(old_value or "").lower()
                    if status_text == "on-hold":
                        add_row(rows, ticket, "Request Placed On-Hold", timestamp, event_agent, event_team, base_priority, status_text, base_channel, base_service_type, base_tags, sequence)
                    if status_text == "solved":
                        add_row(rows, ticket, "Service Request Resolved", timestamp, event_agent, event_team, base_priority, status_text, base_channel, base_service_type, base_tags, sequence)
                    if status_text == "closed":
                        add_row(rows, ticket, "Service Request Closed", timestamp, event_agent, event_team, base_priority, status_text, base_channel, base_service_type, base_tags, sequence)
                    if old_status_text == "solved" and status_text in ("open", "pending", "on-hold"):
                        add_row(rows, ticket, "Service Request Reopened", timestamp, event_agent, event_team, base_priority, status_text, base_channel, base_service_type, base_tags, sequence)
                    base_status = new_value or base_status
                elif kind in ("comment", "comment_created", "comment_added") or field in ("comment", "comment_body"):
                    if comment_public(event):
                        add_row(rows, ticket, "Public Reply Sent", timestamp, event_agent, event_team, base_priority, base_status, base_channel, base_service_type, base_tags, sequence)
                    else:
                        add_row(rows, ticket, "Internal Note Added", timestamp, event_agent, event_team, base_priority, base_status, base_channel, base_service_type, base_tags, sequence)
                elif "sla" in kind or "sla" in field:
                    sla_text = str(value(event, "target_status", "status", "action", "event_type", "type") or "").lower()
                    if any(token in sla_text for token in ("breach", "breached", "missed", "failed")):
                        add_row(rows, ticket, "SLA Target Breached", timestamp, event_agent, event_team, base_priority, base_status, base_channel, base_service_type, base_tags, sequence)
                    elif any(token in sla_text for token in ("applied", "active", "started", "target")):
                        add_row(rows, ticket, "SLA Target Applied", timestamp, event_agent, event_team, base_priority, base_status, base_channel, base_service_type, base_tags, sequence)
                elif ESCALATION_FIELD_ID and field == ESCALATION_FIELD_ID.lower():
                    add_row(rows, ticket, "Request Escalated", timestamp, event_agent, event_team, base_priority, base_status, base_channel, base_service_type, base_tags, sequence)

            if str(value(audit, "action", "type", "event_type") or "").lower() == "create":
                add_row(rows, ticket, "Service Request Created", audit_time, agent_name, assigned_team, base_priority, base_status, base_channel, base_service_type, base_tags, sequence)

        for record in standalone_sla_events:
            if normalize_id(value(record, "ticket_id")) != ticket_id:
                continue
            timestamp = value(record, "created_at", "timestamp", "time")
            text = str(value(record, "event_type", "type", "status", "action") or "").lower()
            if "breach" in text or "missed" in text or "failed" in text:
                add_row(rows, ticket, "SLA Target Breached", timestamp, "", "", base_priority, base_status, base_channel, base_service_type, base_tags, sequence)
            elif "sla" in text or "applied" in text or "active" in text:
                add_row(rows, ticket, "SLA Target Applied", timestamp, "", "", base_priority, base_status, base_channel, base_service_type, base_tags, sequence)

    rows.sort(key=lambda row: (row["ServiceRequestId"], row["EventTimestamp"], int(row["SourceSequence"])))
    output_columns = ["ServiceRequestId", "ActivityName", "EventTimestamp", "SourceSystem", "LastDataUpdate", "AgentName", "AssignedTeam", "RequestPriority", "RequestStatus", "RequestChannel", "ServiceType", "TicketTags"]
    with open(OUTPUT_FILE, "w", encoding="utf-8", newline="") as handle:
        writer = csv.DictWriter(handle, fieldnames=output_columns)
        writer.writeheader()
        for row in rows:
            writer.writerow({column: row.get(column, "") for column in output_columns})


if __name__ == "__main__":
    main()

Pronto para começar?

Comece hoje mesmo a otimizar seu processo de solicitações de serviço. Use este Template de dados para descobrir gargalos e aumentar a eficiência no Zendesk Support.

Voltar ao guia de melhoria Baixar Template

Otimize o gerenciamento de solicitações de serviço. Reduza os atrasos agora.

Acabe com o atendimento lento e a frustração dos usuários. Alcance 70% de automação.

Começar o teste grátis

Não é necessário cartão de crédito. Configuração rápida.

Seu Template de dados para gerenciamento de solicitações de serviço

Seu Template de dados para gerenciamento de solicitações de serviço

Atributos do gerenciamento de solicitações de serviço

Atividades do gerenciamento de solicitações de serviço

Guias de extração

Interface do Zendesk Explore para relatórios e exportação de dados

Etapas

Configuração

a Consulta de exemplo config

Extração pela API REST do Zendesk usando um script Python

Etapas

Configuração

a Consulta de exemplo python

Exportação JSON nativa completa da conta do Zendesk Support

Etapas

Configuração

a Consulta de exemplo config

Pronto para começar?

Otimize o gerenciamento de solicitações de serviço. Reduza os atrasos agora.

Seu Template de dados para gerenciamento de solicitações de serviço

Seu Template de dados para gerenciamento de solicitações de serviço

Atributos do gerenciamento de solicitações de serviço

Atividades do gerenciamento de solicitações de serviço

Guias de extração

Interface do Zendesk Explore para relatórios e exportação de dados

Etapas

Configuração

a Consulta de exemplo config

Extração pela API REST do Zendesk usando um script Python

Etapas

Configuração

a Consulta de exemplo python

Exportação JSON nativa completa da conta do Zendesk Support

Etapas

Configuração

a Consulta de exemplo config

Pronto para começar?

Otimize o gerenciamento de solicitações de serviço. Reduza os atrasos agora.

Valorizamos sua privacidade