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

Seu Template de dados para gestão de solicitações de serviço

Zendesk Support

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

Seu Template de dados para gestão de solicitações de serviço

Este Template orienta você na extração dos dados necessários para analisar o processo de gestão de solicitações de serviço no Zendesk Support. Ele apresenta os atributos essenciais a coletar, as principais atividades a acompanhar e orientações práticas para extrair essas informações diretamente do sistema. Use este material para criar um Event Log consistente para suas iniciativas de Process Mining.

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

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

Baixar Template

Atributos de gestão de solicitações de serviço

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

5 Obrigatório 7 Recomendado 9 Opcional

	Nome	Descrição
	Atividade ActivityName	Nome da atividade de negócio ou do evento ocorrido em uma solicitação de serviço.
Descrição A atividade representa uma etapa ou um evento específico 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 inclusão de comentários. Analisar as atividades é a base do Process Mining. Isso permite visualizar o mapa do processo, identificar gargalos entre etapas e analisar ciclos de retrabalho. Ao compreender a sequência e a frequência das atividades, as organizações podem identificar ineficiências e oportunidades de melhoria do processo. Por que isso importa Este atributo define as etapas do processo e permite visualizar os mapas de processo, além de analisar o fluxo, as variações e a Conformidade do processo. Onde encontrar Este dado é derivado conceitualmente dos eventos registrados na API de auditoria 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	Data e hora exatas em que a atividade ocorreu.
Descrição O timestamp do evento, ou hora de início, registra o momento exato em que uma atividade ocorreu. Por exemplo, indica 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. Este atributo é essencial para qualquer análise baseada em tempo. Ele é usado para ordenar os eventos cronologicamente, calcular a duração entre atividades, medir tempos de espera e analisar o tempo de ciclo total do caso. Também é fundamental para identificar gargalos e avaliar a performance em relação a metas baseadas em tempo, como os SLAs. Por que isso importa Este timestamp organiza os eventos cronologicamente e é essencial para analisar durações, performance e gargalos. Onde encontrar API de auditoria 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	Identificador exclusivo de cada ticket de solicitação de serviço no Zendesk.
Descrição O ID da solicitação de serviço, muitas vezes chamado de ID do ticket no Zendesk, é a chave primária de cada caso. Ele reúne todas as atividades, comentários e mudanças de status relacionados, desde a criação da solicitação até seu encerramento. Assim, é possível acompanhar todo o ciclo de vida de uma única solicitação. Na análise de Process Mining, esse atributo é fundamental. Ele define o caso e permite reconstruir os fluxos do processo, identificar variantes e calcular métricas por caso, como o tempo de ciclo. Cada evento do conjunto de dados precisa estar associado a um ID da solicitação de serviço para que seu contexto no processo possa ser compreendido. Por que isso importa Este é o identificador essencial do caso, que conecta todos os eventos da jornada de uma solicitação de serviço e permite analisar o processo de ponta a ponta. Onde encontrar API de tickets do Zendesk, campo 'id'. Exemplos 102451024610247
	Sistema de origem SourceSystem	Indica o sistema de onde os dados foram extraídos.
Descrição Este atributo especifica a origem dos dados da solicitação de serviço. Nesta visão do processo, o valor será sempre 'Zendesk Support', identificando o sistema que registra todas as atividades de gerenciamento de serviços. Em ambientes com vários sistemas integrados, este campo é essencial para rastrear a origem dos dados e solucionar problemas. Ele garante que as análises considerem o sistema correto e ajuda a diferenciar dados quando informações de várias fontes são combinadas. Por que isso importa Identifica o sistema de origem dos dados, permitindo rastrear sua procedência e evitar confusões quando informações de vários sistemas são combinadas. Onde encontrar 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	Timestamp que indica a última atualização dos dados 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 informa o nível de atualização dos dados analisados e permite saber o quanto a visão do processo está atualizada. Esse dado é essencial para o monitoramento contínuo e a criação de dashboards. Ele ajuda analistas e usuários de negócio a entender se estão consultando dados quase em tempo real ou um instantâneo de um período anterior, o que afeta a validade das conclusões. Por que isso importa Oferece contexto essencial sobre a atualização dos dados, mostrando aos usuários o quanto a análise está atualizada. Onde encontrar Este é um campo de metadados gerado e registrado no conjunto de dados durante a extração. Exemplos 2023-10-27T08:00:00Z
	Canal da solicitação RequestChannel	Canal pelo qual a solicitação de serviço foi enviada (por exemplo, e-mail, formulário web ou telefone).
Descrição Este atributo identifica o canal de 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 outro canal. Isso informa como o cliente entrou em contato. O canal da solicitação é uma dimensão importante para a análise. Ele permite comparar tempos de resolução, índices de satisfação e taxas de retrabalho entre diferentes canais no Dashboard de eficiência dos canais de solicitação. Com essas informações, as empresas podem otimizar os 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 dos diferentes canais de suporte ao cliente, permitindo melhorias direcionadas. Onde encontrar API de tickets do Zendesk, objeto 'via' e sua propriedade 'channel'. Exemplos webe-mailapichat
	Equipe atribuída AssignedTeam	Equipe ou grupo de suporte responsável pela solicitação de serviço.
Descrição Este atributo indica qual equipe ou grupo da organização de suporte é responsável pela solicitação de serviço. No Zendesk, esses grupos são chamados de 'Groups'. Os tickets costumam ser atribuídos primeiro a um grupo e, depois, a um agente específico. Analisar os dados por equipe atribuída é essencial para entender a performance e a carga de trabalho de cada equipe. Isso ajuda a identificar quais equipes atendem a cada tipo de solicitação, seus tempos médios de resolução e suas taxas de cumprimento de SLA. É uma dimensão importante do Dashboard de performance de agentes e equipes. Por que isso importa Permite analisar a performance das equipes, equilibrar a carga de trabalho e avaliar a eficiência do encaminhamento entre diferentes grupos de suporte. Onde encontrar API de grupos do Zendesk, combinando o 'group_id' da resposta da API de tickets. Exemplos Suporte de nível 1Suporte técnicoFaturamento
	Nome do agente AgentName	Nome do agente responsável pela solicitação de serviço no momento do evento.
Descrição Este atributo identifica o agente de suporte responsável por atender à 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 responsável em cada etapa. O nome do agente é essencial para analisar a 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 de reatribuições. Isso ajuda a criar o Dashboard de performance de agentes e equipes e a entender a contribuição de cada pessoa 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 encontrar API de usuários do Zendesk, combinando o 'assignee_id' da resposta da API de tickets. Exemplos Jane DoeJohn SmithEmily Jones
	Prioridade da solicitação RequestPriority	Nível de prioridade atribuído à solicitação de serviço, como baixa, normal, alta ou urgente.
Descrição A prioridade da solicitação classifica o nível de urgência de uma solicitação de serviço. Esse nível costuma determinar os tempos de resolução esperados e as políticas de SLA aplicadas ao ticket. A prioridade pode ser definida inicialmente pelo sistema ou pelo usuário e alterada por um agente durante o ciclo de vida do ticket. Este atributo é essencial para segmentar os dados e fazer análises de causa raiz. Ele ajuda a avaliar se os tickets de alta prioridade são resolvidos mais rapidamente do que os de baixa prioridade e é uma dimensão importante dos dashboards 'Tendências de escalonamento de solicitações de serviço' e 'Cumprimento de SLA'. Por que isso importa Permite segmentar as solicitações por urgência, o que é essencial para analisar o cumprimento dos SLAs e garantir que os problemas críticos sejam tratados rapidamente. Onde encontrar API de tickets do Zendesk, campo 'priority'. Exemplos BaixaNormalAltaUrgente
	Status da solicitação RequestStatus	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 a situação do ticket em um determinado momento. O Zendesk tem vários status padrão, como New, Open, Pending, On-hold, Solved e Closed, que indicam o avanço da solicitação ao longo do ciclo de vida. As mudanças neste campo são os principais gatilhos para criar atividades no Event Log. Analisar o tempo gasto em cada status é uma parte central da análise de gargalos. Isso ajuda a identificar onde os tickets ficam parados, por exemplo, quando passam tempo demais como 'Pending' ou 'On-hold'. Entender as transições de status também é essencial para identificar ciclos de retrabalho. Por que isso importa Acompanhar o status é fundamental para entender o andamento da solicitação e identificar quanto tempo ela passa em espera ou em atendimento ativo. Onde encontrar API de tickets do Zendesk, campo 'status'. Exemplos NovaAbertaPendenteResolvidaEncerrada
	Tags do ticket TicketTags	Lista de tags aplicadas à solicitação de serviço para categorização e encaminhamento.
Descrição Tags são rótulos flexíveis que os agentes podem adicionar manualmente aos tickets ou que podem ser aplicados automaticamente por regras de negócio. Elas acrescentam contexto ou categorias específicas que talvez não estejam contempladas em campos padrão, como tipo ou prioridade. Tags são um atributo muito versátil para análises de Process Mining. Elas podem ser usadas para filtrar cenários específicos, acompanhar fluxos de trabalho personalizados ou identificar causas raiz. Por exemplo, a tag 'VIP' pode ajudar a analisar o processo para clientes importantes, enquanto a tag 'product_bug' pode ser usada para acompanhar o ciclo de vida de relatos de defeitos. Por que isso importa Oferece uma forma flexível de segmentar os dados e analisar em profundidade subprocessos específicos ou atributos do ticket que não aparecem em outros campos. Onde encontrar API de tickets do Zendesk, campo 'tags'. Trata-se de uma matriz de strings. Exemplos consulta_comercialproblema_de_faturamentosolicitação_de_recursocliente_vip
	Tipo de serviço ServiceType	Categoria ou tipo da solicitação de serviço (por exemplo, incidente, dúvida, problema ou tarefa).
Descrição O tipo de serviço classifica a natureza da solicitaçã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. Este atributo é essencial para filtrar e comparar dados. Ele permite que analistas examinem os fluxos de processo de diferentes tipos de solicitação, que muitas vezes seguem caminhos de resolução e SLAs bem distintos. É uma dimensão importante do Dashboard de performance de agentes e equipes, pois mostra quem atende melhor cada tipo de solicitação. Por que isso importa Classifica as solicitações para permitir a análise separada de diferentes processos, como incidentes e dúvidas, que seguem caminhos distintos. Onde encontrar API de tickets do Zendesk, campo 'type'. Exemplos dúvidaincidenteproblematarefa
	É retrabalho IsRework	Indicador verdadeiro quando a solicitação de serviço é reaberta depois de ser resolvida.
Descrição Este indicador booleano identifica os casos que passaram por retrabalho. Em geral, uma solicitação de serviço é considerada retrabalho quando seu status muda de 'Resolvido' para um estado aberto. Isso indica 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 de taxa de retrabalho em solicitações de serviço e para o Dashboard de análise de retrabalho e reabertura. Ao identificar os casos com retrabalho, os analistas podem isolar esses fluxos ineficientes, descobrir as causas raiz das reaberturas e trabalhar para melhorar a resolução no primeiro contato. Por que isso importa Identifica falhas no 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 encontrar Calculado pela análise da sequência de status de um chamado na API de auditoria de chamados do Zendesk. Uma transição de 'resolvido' para 'aberto' indica retrabalho. Exemplos truefalse
	Hora de término EndTime	Data e 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, então a hora de término é igual à hora de início. Já em atividades baseadas em status, como 'Solicitação colocada em espera', a hora de término corresponde ao momento em que o ticket sai da espera. Este atributo é essencial para calcular a duração de atividades específicas, um dado importante para a análise de gargalos. Comparar a hora de início e a hora de término de uma atividade permite medir diretamente seu tempo de processamento e identificar quais etapas consomem mais tempo. Por que isso importa Permite calcular a duração de cada atividade, o que é essencial para identificar gargalos no processo e medir a eficiência de cada etapa. Onde encontrar Em geral, é igual a StartTime para eventos discretos. Para durações de status, corresponde ao timestamp 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	Pontuação de satisfação informada pelo solicitante após a resolução do ticket.
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 o ticket ser marcado como resolvido. As avaliações mais comuns são 'Bom' ou 'Ruim', às vezes acompanhadas de um comentário. O índice de satisfação é uma métrica importante de resultado. Relacionar padrões do processo às pontuações de satisfação pode revelar quais comportamentos levam a clientes satisfeitos ou insatisfeitos. Por exemplo, a análise pode mostrar uma forte correlação entre muitas reatribuições ou tempos longos de resolução e avaliações negativas de satisfação. Por que isso importa Relaciona diretamente a execução do processo aos resultados para o cliente e ajuda a identificar quais comportamentos do processo influenciam a satisfação. Onde encontrar API de tickets do Zendesk, campo 'satisfaction_rating.score' ou 'satisfaction_rating.reason'. Exemplos BomRuimOferecida
	Nome da política de SLA SlaPolicyName	Nome da política de acordo de nível de serviço (SLA) aplicada à solicitação.
Descrição Este atributo identifica a política de SLA específica que define os prazos de resposta e resolução do chamado. A política costuma ser 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 de Análise de cumprimento e violações de SLA. Ela fornece o contexto necessário para avaliar a performance, já que cada política pode ter metas diferentes. Assim, é possível avaliar de forma justa e precisa se um chamado atingiu os objetivos de nível de serviço definidos para ele. 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 gerar relatórios precisos de conformidade. Onde encontrar API de métricas de chamados do Zendesk. Os dados de SLA costumam estar associados às métricas do chamado. Exemplos Urgente: resposta em 1 horaPadrão: resolução em 24 horasSLA para clientes premium
	Nome do solicitante RequestorName	Nome do usuário final ou cliente que enviou a solicitação de serviço.
Descrição Este atributo identifica a pessoa que iniciou a solicitação de serviço. Associar 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 identificar padrões de clientes específicos ou segmentos de clientes. Por exemplo, é possível investigar se determinados clientes têm tempos de resolução mais longos ou mais retrabalho, o que pode indicar problemas com um produto ou serviço que utilizam. Por que isso importa Relaciona o processo ao cliente e permite analisar problemas específicos, solicitações recorrentes e níveis de satisfação. Onde encontrar API de usuários do Zendesk, combinando o 'requester_id' da resposta da API de tickets. Exemplos Alice JohnsonBob WilliamsCharlie Brown
	Número de reatribuições de agente AgentReassignmentCount	Número total de vezes que uma solicitação foi transferida de um agente para outro.
Descrição Este atributo é um contador que aumenta sempre que o campo 'assignee_id' de um chamado muda. Um número elevado de reatribuições em um único chamado pode indicar diferentes problemas no processo, como encaminhamento 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 contribui diretamente para o KPI de taxa de reatribuição de agentes. A análise de casos com muitas reatribuições pode revelar oportunidades para melhorar as regras de encaminhamento, o treinamento dos agentes ou os recursos da base de conhecimento, ajudando os chamados a chegar mais rápido à pessoa certa. Por que isso importa Ajuda a quantificar as transferências internas e identificar atritos no processo, já que taxas elevadas de reatribuição costumam causar atrasos e ineficiência. Onde encontrar Calculado pela contagem das mudanças no campo 'assignee_id' para cada chamado na API de auditoria de chamados do Zendesk. Exemplos 013
	Organização do solicitante RequestorOrganization	Organização ou empresa à qual o solicitante pertence.
Descrição Este atributo relaciona a solicitação de serviço a uma organização cliente específica. Isso é especialmente relevante no suporte B2B, em que os acordos de nível de serviço e os contratos de suporte costumam ser definidos para cada organização. Analisar os dados por organização oferece uma visão da performance do suporte em cada empresa. Isso pode ajudar a identificar organizações que geram muitos tickets, enfrentam problemas recorrentes ou apresentam baixos índices de satisfação. Essas informações são úteis 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 o serviço B2B agrupando as solicitações por empresa, algo essencial para gerenciar o relacionamento com clientes e os SLAs no nível organizacional. Onde encontrar API de organizações do Zendesk, combinando o 'organization_id' da resposta da API de tickets. Exemplos Acme CorporationGlobal Tech Inc.Innovate Solutions
	Resolvido no primeiro contato IsFirstContactResolution	Indicador que informa se a solicitação foi resolvida pelo primeiro agente designado, sem reatribuições nem respostas do solicitante.
Descrição A resolução no primeiro contato (FCR) é uma métrica essencial que indica se o problema do cliente foi resolvido em uma única interação. Este atributo calculado é um indicador booleano que assume o valor verdadeiro quando um chamado é resolvido pelo primeiro agente a quem foi atribuído, sem reatribuições e com apenas uma resposta do agente. Esse atributo contribui diretamente para o KPI de taxa de resolução no primeiro contato. A análise das características dos casos com FCR pode servir de referência para a excelência do processo. Por outro lado, analisar os casos sem FCR pode revelar oportunidades para aprimorar o treinamento dos agentes, os artigos da base de conhecimento ou a triagem inicial. Por que isso importa Mede a capacidade de resolver problemas com eficiência em uma única interação, o que contribui muito para a satisfação do cliente e a eficiência operacional. Onde encontrar Este é um atributo calculado complexo. É necessário analisar o Event Log de um chamado para verificar se houve reatribuições de agentes e quantas respostas públicas foram enviadas por eles. Exemplos truefalse
	SLA violado IsSlaBreached	Indicador que informa se a solicitação de serviço ultrapassou alguma meta de SLA.
Descrição Este atributo é um indicador booleano ou categórico que mostra o resultado do SLA de um chamado. Ele pode indicar estados como 'Cumprido', 'Violado' ou 'Ativo'. O resultado é determinado pela comparação dos tempos reais de resposta ou resolução com as metas definidas na política de SLA aplicada. Esse é um atributo essencial para o Dashboard de Análise de cumprimento e violações de SLA. Ele facilita a contagem e a visualização dos chamados em conformidade e fora de conformidade. A análise pode então se concentrar nas características do processo dos chamados que violaram o SLA para identificar as causas raiz, como longos tempos de espera 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 encontrar Obtido pela API de métricas de chamados do Zendesk, que fornece informações sobre o status do SLA de cada chamado. Exemplos CumpridoVioladoAtivo

Obrigatório Recomendado Opcional

Atividades de gestão de solicitações de serviço

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

7 Recomendado 6 Opcional

	Atividade	Descrição
	Meta de SLA não cumprida	Esta atividade marca o momento em que uma solicitação de serviço não cumpre uma meta de SLA definida, como o tempo até a primeira resposta ou o tempo de resolução. O Zendesk registra um evento explícito quando uma meta não é atingida.
Por que isso importa Este é um evento crítico para monitorar a Conformidade e um dado importante para o KPI de taxa de cumprimento de SLA. Ele identifica falhas no cumprimento dos compromissos de serviço. Onde encontrar Capturado a partir do evento 'SLABreach' nos eventos do ticket ou no log de auditoria do Zendesk. O evento especifica qual métrica de SLA não foi cumprida. Coleta Identificado pelo evento explícito 'SLABreach' nos dados do ticket. Tipo de evento explicit
	Resposta pública enviada	Esta atividade registra qualquer comunicação enviada por um agente ao solicitante. Ela é capturada como um evento explícito 'Comment' nos dados do ticket do Zendesk, quando o atributo 'public' é true.
Por que isso importa Esses eventos são essenciais para analisar a frequência das comunicações, medir os tempos de resposta dos agentes e identificar quantas interações são necessárias para resolver uma solicitação. Onde encontrar Este é um evento explícito 'Comment' nos dados do ticket. Os detalhes do evento incluem o atributo 'public: true', que o diferencia das notas internas. Coleta 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, quando o campo “assignee_id” é preenchido após estar vazio ou conter um ID de grupo.
Por que isso importa Esse evento marca o início do trabalho ativo de um agente e é essencial para medir o tempo de resposta inicial, o atraso até a primeira atribuição e a distribuição da carga de trabalho dos agentes. Onde encontrar Inferido a partir do primeiro evento “Change” no campo “assignee_id” do log de auditoria do ticket que define o ID de um usuário específico. Coleta Inferido a partir do primeiro evento de alteração que define o campo “assignee_id” com o ID de 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 qualquer canal. Esse evento é registrado como “Create” no log de auditoria do ticket do Zendesk e define o horário de início do processo.
Por que isso importa Essa atividade é o principal evento de início de cada solicitação de serviço. Por isso, é essencial para calcular os tempos de ciclo de ponta a ponta e analisar o volume de solicitações recebidas. Onde encontrar O evento é registrado como “Create” no log de auditoria do ticket do Zendesk. O registro de data e hora desse evento corresponde ao momento em que o ticket da solicitação de serviço foi criado. Coleta Capturado diretamente do evento “Create” no log de auditoria do ticket. Tipo de evento explicit
	Solicitação de serviço encerrada	Representa o encerramento definitivo da solicitação de serviço. O ticket passa automaticamente para o status 'closed' após permanecer como 'solved' por um período definido e não pode mais ser reaberto.
Por que isso importa Esta atividade marca o fim definitivo do processo de solicitação de serviço. Ela fornece o ponto final para calcular a duração total do caso. Onde encontrar Inferido a partir de um evento 'Change' no campo 'status' do log de auditoria do ticket, quando o novo valor é 'closed'. Coleta Inferido a partir de um evento 'Change' no log de auditoria em que o status muda para 'closed'. Tipo de evento inferred
	Solicitação de serviço reaberta	Ocorre quando o solicitante responde a uma solicitação com status 'solved', alterando automaticamente o status para 'open'. Isso indica que a solução proposta não foi suficiente.
Por que isso importa Esta atividade é o principal indicador de retrabalho. Analisar sua frequência ajuda a medir a qualidade das resoluções e identificar as causas da insatisfação dos clientes. Onde encontrar 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'. Coleta Inferido a partir de uma mudança de status de 'solved' para 'open'. Tipo de evento inferred
	Solicitação de serviço resolvida	Esta atividade marca o momento em que um agente apresenta uma solução e altera o status do ticket para 'solved'. Do ponto de vista do agente, a solicitação está concluída, mas o solicitante ainda pode reabri-la.
Por que isso importa Este é um marco importante, que indica o fim do trabalho ativo do agente. O tempo até chegar a esse status é uma das principais medidas da eficiência da resolução. Onde encontrar Inferido a partir de um evento 'Change' no campo 'status' do log de auditoria do ticket, quando o novo valor é 'solved'. Coleta Inferido a partir de um evento 'Change' no log de auditoria em que o status muda para '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. É inferida a partir de qualquer evento 'Change' posterior no campo 'assignee_id', após a atribuição inicial.
Por que isso importa Acompanhar as reatribuições é essencial para calcular o KPI de taxa de reatribuição de agentes, que ajuda a identificar ineficiências no processo, encaminhamentos incorretos ou lacunas de conhecimento. Onde encontrar Inferido a partir de eventos 'Change' no campo 'assignee_id' do log de auditoria do ticket, excluindo o primeiro evento de atribuição. Coleta Inferido a partir do segundo evento 'Change' em diante 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. O 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 é essencial para monitorar a conformidade, analisar possíveis descumprimentos e entender o prazo de atendimento esperado para cada tipo de solicitação. Onde encontrar Capturado do evento “SLAPolicyApplied” nos eventos do ticket ou no log de auditoria do Zendesk. Esse evento especifica qual política foi aplicada. Coleta Identificado pelo evento explícito “SLAPolicyApplied” nos dados do ticket. Tipo de evento explicit
	Nota interna adicionada	Um agente adicionou uma nota ou comentário interno à solicitação de serviço, visível apenas para outros agentes. O registro é feito como um evento 'Comment' em que o atributo 'public' é false.
Por que isso importa Acompanhar as notas internas oferece insights sobre a colaboração entre agentes ou equipes, que pode causar atrasos ou ser essencial para resolver problemas com eficiência. Onde encontrar Este é um evento explícito 'Comment' nos dados do ticket. Os detalhes do evento incluem o atributo 'public: false', indicando que se trata de uma nota interna. Coleta 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 “Baixa”, “Normal”, “Alta” ou “Urgente”, foi atualizado. O evento é registrado como “Change” no campo “priority” do log de auditoria do ticket.
Por que isso importa Analisar as mudanças de prioridade ajuda a identificar solicitações que se tornam mais urgentes com o tempo e a avaliar se a priorização está sendo feita de forma eficaz. Onde encontrar Registrado como um evento 'Change' no campo 'priority' do log de auditoria do ticket do Zendesk, com os valores anterior e novo. Coleta Inferido a partir de eventos 'Change' no campo 'priority' do log de auditoria. Tipo de evento inferred
	Solicitação colocada em espera	Esta atividade ocorre quando o status da solicitação de serviço muda para 'on-hold', geralmente porque 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 identificar e medir os tempos de espera que estão fora do controle direto da equipe de suporte, oferecendo uma visão mais precisa do tempo de atendimento dos agentes. Onde encontrar Inferido a partir de um evento 'Change' no campo 'status' do log de auditoria do ticket, quando o novo valor é 'on-hold'. Coleta Inferido a partir de um evento 'Change' no log de auditoria em que o status muda para 'on-hold'. Tipo de evento inferred
	Solicitação escalada	Representa o encaminhamento formal de uma solicitação de serviço para um nível de suporte superior, outra equipe ou a gerência. Geralmente, é inferido a partir de uma mudança no grupo atribuído ao ticket ou em um campo personalizado usado para registrar escalonamentos.
Por que isso importa Monitorar os escalonamentos ajuda a identificar solicitações complexas, necessidades de treinamento dos agentes de linha de frente e problemas sistêmicos que exigem intervenção de níveis superiores. Onde encontrar 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 mudança em um campo personalizado do ticket usado para acompanhar escalonamentos. Coleta Inferido a partir de uma mudança em 'group_id' ou em um campo personalizado '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: Acesse o ícone de produtos do Zendesk na barra superior direita e selecione Explore. No Explore, clique no ícone Consultas à esquerda e depois em Nova consulta. Selecione o conjunto de dados Support: Ticket updates como fonte.
Configure métricas e atributos para os eventos dos chamados: No criador de consultas, adicione uma métrica como COUNT(Tickets) para visualizar os dados. Em seguida, acesse a seção Linhas e adicione estes atributos: Ticket ID, Update - Timestamp, Updater name, Update - Field name, Update - Previous value, Update - New value, Assignee name, Group name, 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 Cálculos (ícone da calculadora), selecione Atributo calculado padrão e dê a ele o nome ActivityName. Cole na caixa de fórmula a lógica fornecida na seção Consulta. Essa fórmula associa diferentes eventos de atualização de chamados aos nomes de atividade necessários.
Ajuste e filtre o relatório principal: Adicione o novo atributo ActivityName à seção Linhas. Crie um filtro para esse atributo e exclua valores (null) ou valores indesejados gerados pelo sistema para limpar o conjunto de dados. Adicione também um filtro para Ticket created - Date e limite a consulta a um período viável, como os últimos 6 meses.
Crie o segundo relatório para eventos de SLA: Crie outra consulta e, desta vez, selecione o conjunto de dados Support: SLAs. Essa etapa é necessária porque o conjunto de dados Ticket updates não inclui eventos de SLA.
Configure o relatório de SLA: Na consulta de SLA, adicione COUNT(SLA tickets) a Métricas. Na seção Linhas, 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. Quando as tabelas forem geradas, clique no botão Exportar e escolha CSV como formato. Você terá dois arquivos CSV separados.
Combine e transforme os dados: Combine os dois arquivos CSV com uma ferramenta de planilha, como o Microsoft Excel, ou uma linguagem de script, como Python. O objetivo é criar um único Event Log. No arquivo de SLA, será necessário criar a coluna ActivityName. Se SLA status for Active, 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 combinado, 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 colunas ao arquivo CSV final. Preencha SourceSystem com o valor 'Zendesk'. Preencha LastDataUpdate com a data e hora da exportação. O arquivo estará 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 agente com permissão para criar e editar consultas no Explore. Normalmente, esse perfil é de administrador ou de um agente com uma função personalizada.
Seleção de conjuntos de dados: Este método exige a criação de dois relatórios separados com conjuntos de dados diferentes: Support: Ticket updates para eventos gerais e Support: SLAs para eventos específicos de SLA.
Filtro por período: É essencial aplicar um filtro por período, por exemplo, em Ticket created - Date, para manter o volume de dados viável. Para a análise inicial, recomendamos um período de 3 a 6 meses.
Atributos calculados: Os nomes das atividades são derivados por meio de um atributo calculado personalizado e complexo no Explore. Confira se a fórmula foi criada corretamente para evitar erros nos resultados.
Volume de dados: A interface e a função de exportação do Zendesk Explore podem ficar lentas ou atingir o tempo limite com conjuntos de dados muito grandes. Para extrações com mais de um ano de dados ou milhões de chamados, considere dividir a exportação em períodos menores.

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 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 com o pip. A biblioteca requests é usada para fazer chamadas à API, e pandas é usada para manipular os dados e exportá-los para um arquivo CSV.
```
pip install requests pandas
```
Gere um token de API do Zendesk: Entre no Zendesk como administrador. Acesse Admin Center > Apps and integrations > APIs > Zendesk API. Na seção Token Access, habilite o acesso se ainda não estiver habilitado e clique em "Add API token". Informe uma descrição, por exemplo, "ProcessMind Extraction", e copie o token gerado. Ele 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 domínio 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 dos dados, geralmente de 3 a 6 meses atrás.
Entenda a lógica do script: Primeiro, o script busca uma lista de chamados atualizados no período especificado usando a API Incremental Tickets, que é eficiente. Em seguida, busca o histórico completo de auditoria, os comentários e as métricas de SLA de cada chamado. Por fim, processa os eventos em ordem cronológica para criar um histórico detalhado.
Associe eventos do Zendesk a atividades: O script contém a lógica para transformar eventos brutos do Zendesk nas atividades de negócio necessárias. Por exemplo, um evento 'Change' no campo 'status' é associado a 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: No terminal, execute python your_script_name.py. O script exibirá o andamento enquanto busca dados na API do Zendesk. Esse processo pode levar algum tempo, dependendo do volume de dados e dos limites de chamadas da API.
Confira o arquivo de saída: Quando o script terminar, ele criará um arquivo CSV chamado zendesk_event_log.csv no mesmo diretório. O arquivo contém o Event Log extraído, com todas as atividades e os atributos especificados.
Prepare o arquivo para carregamento: Abra o arquivo CSV e confira se a formatação está correta. Os cabeçalhos das colunas devem corresponder aos atributos necessários, como ServiceRequestId, ActivityName, EventTimestamp, SourceSystem, LastDataUpdate e outros. O arquivo estará pronto para ser carregado no ProcessMind.

Configuração

Acesso à API do Zendesk: O script precisa de um token de API ativo associado a um administrador ou agente com permissões suficientes. O e-mail do usuário configurado no script deve ser o mesmo usado para criar o token de API.
Parâmetros do script: Antes de executar o script, configure estas variáveis principais: ZENDESK_SUBDOMAIN, ZENDESK_EMAIL, ZENDESK_API_TOKEN e START_TIME_STR. O valor de START_TIME_STR deve seguir o formato 'YYYY-MM-DD'.
Período: Recomendamos começar extraindo os dados dos últimos 3 a 6 meses (START_TIME_STR). Esse período fornece um conjunto de dados representativo para análise sem prolongar demais a execução ou 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 de exportações incrementais (/api/v2/incremental/tickets/cursor.json) para buscar com eficiência apenas os chamados atualizados desde a última execução ou desde uma data de início especificada. Esse método é muito mais eficiente do que percorrer todos os chamados.
Limites de chamadas: O Zendesk impõe limites de chamadas à API. O script inclui um mecanismo básico para pausar quando um limite é atingido, mas a extração de instâncias muito grandes pode levar bastante tempo. O ideal é executar o script fora dos horários de pico.
Lógica de escalonamento: A atividade 'Request Escalated' é inferida a partir de uma mudança no campo group_id. Se sua organização usa outro mecanismo, como um campo personalizado do chamado, será necessário alterar a lógica do script para identificar corretamente os escalonamentos.

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 exportação JSON nativa da conta completa usando o recurso de exportação disponível na sua assinatura e conta do Zendesk. O caminho exato nos menus 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 permitir filtrar por data, baixe a exportação completa da conta e aplique o filtro de data durante a transformação.
Baixe e mantenha todos os arquivos JSON gerados pela exportação. Preserve os arquivos originais, a 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 chamados, auditorias de chamados, 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 espaços reservados do script antes de executá-lo.
Normalize cada evento de auditoria de chamado em uma estrutura comum com ServiceRequestId, data e hora da auditoria, tipo de evento, nome do campo, valor anterior, novo valor, identificador do autor, indicador de conteúdo público, status do chamado, responsável, grupo, prioridade, canal, tipo de serviço, tags, sistema de origem e LastDataUpdate.
Gere uma linha no Event Log para cada atividade válida. 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.
Quando houver dados disponíveis, associe os identificadores de agentes, grupos, organizações e solicitantes aos registros correspondentes de usuários, grupos e organizações exportados. Preencha AgentName e AssignedTeam com base no estado da atribuição no momento do evento. Mantenha o identificador ou deixe o valor em branco quando não for possível identificar o nome de exibição.
Aplique regras determinísticas aos eventos. Use o evento Create da auditoria do chamado para Service Request Created; eventos explícitos de auditoria de SLA para SLA Target Applied e SLA Target Breached; a primeira mudança válida de responsável para Request Assigned to Agent; mudanças posteriores de responsável para Agent Reassigned; indicadores de comentários públicos e privados para eventos de resposta e anotação; transições de status para eventos de espera, reabertura, resolução e fechamento; e mudanças no grupo ou no campo de escalonamento configurado para Request Escalated.
Ordene as linhas resultantes por ServiceRequestId e EventTimestamp, usando a sequência estável dos eventos de origem como critério de desempate. Não elimine eventos apenas porque têm a mesma data e hora, pois vários comentários ou eventos de auditoria podem ocorrer simultaneamente.
Valide se todas as colunas obrigatórias estão presentes e se cada atividade tem pelo menos uma linha válida quando os dados de origem contêm o evento correspondente. Exporte o resultado final como CSV UTF-8 ou em outro formato de Event Log 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 exportação JSON nativa da conta completa do Zendesk Support e mantenha todos os arquivos JSON gerados. A exportação deve incluir os dados dos chamados e os dados de auditoria ou eventos dos chamados. Se os dados de SLA, comentários, usuários, organizações, grupos ou campos personalizados forem fornecidos separadamente, inclua esses arquivos na entrada da transformação.
Período: Para a extração e validação iniciais, prefira um período de três a seis meses. Se a exportação nativa abranger toda a conta e não permitir limitar o período, aplique o filtro em EventTimestamp após a análise dos arquivos, 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, escalonamento, SLA, status ou comentários a partir de outras linhas.
Configuração de SLA: Mapeie os nomes ou as propriedades reais dos eventos exportados que a conta usa para registrar a aplicação e a 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 espaços reservados e documente as atividades indisponíveis.
Configuração de escalonamento: Identifique o campo de grupo específico da conta ou o campo personalizado que representa o escalonamento. Antes de executar o script, defina ESCALATION_FIELD_ID ou a configuração equivalente com o identificador real do campo exportado.
Caminhos de origem: Defina os caminhos dos arquivos JSON e os mapeamentos de propriedades JSON no script. Os nomes dos arquivos exportados pelo Zendesk e a estrutura dos dados podem variar conforme a versão da exportação e a configuração da conta.
Saída obrigatória: Preencha ServiceRequestId, ActivityName, EventTimestamp, SourceSystem e LastDataUpdate 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 os 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 confirmados ou sem suporte.
Performance: Sempre que possível, processe os arquivos JSON de forma incremental, evite carregar a exportação inteira da conta na memória, indexe os identificadores de chamados e auditorias e grave arquivos intermediários normalizados antes de criar o Event Log final. Exportações grandes podem exigir divisão por data ou identificador do chamado.
Pré-requisitos: Acesso administrativo para solicitar ou baixar a exportação nativa da conta, autorização para acessar auditorias de chamados e dados de referência de usuários ou grupos, uma assinatura do Zendesk que ofereça o recurso de exportação, armazenamento local para a exportação completa e um ambiente capaz de analisar JSON e gravar arquivos CSV UTF-8.
Proteção de dados: Considere potencialmente confidenciais os dados de solicitantes, agentes, organizações, comentários e chamados. Armazene os arquivos de origem e os transformados de acordo com os requisitos de retenção, controle de acesso e privacidade da organização.

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 a otimizar seu processo de solicitação de serviço. Use este Template de dados para identificar gargalos e aumentar a eficiência no Zendesk Support.

Voltar ao guia de melhoria

Baixar Template

Otimize a gestão de solicitações de serviço. Reduza os atrasos agora.

Acabe com a demora no atendimento 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 gestão de solicitações de serviço

Seu Template de dados para gestão de solicitações de serviço

Atributos de gestão de solicitações de serviço

Atividades de gestão 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

Consulta de exemplo config

Extração da API REST do Zendesk com script Python

Etapas

Configuração

Consulta de exemplo python

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

Etapas

Configuração

Consulta de exemplo config

Pronto para começar?

Otimize a gestão de solicitações de serviço. Reduza os atrasos agora.