> Melhoria Contínua de Processos > Serviço ao Cliente > Zendesk Support > Modelo de Dados

Seu Template de Dados de Atendimento ao Cliente

Zendesk Support

Atributos de Atendimento ao Cliente (19) Atividades de Atendimento ao Cliente (14) Guias de Extração (4)

Seu Template de Dados de Atendimento ao Cliente

Este template ajuda você a reunir os dados certos para analisar seu processo de atendimento. Ele detalha atributos de dados essenciais para coleta, as principais atividades a serem rastreadas e fornece orientações práticas sobre como extrair essas informações. Com este guia, você pode construir um event log robusto para descobrir insights e melhorar suas operações de serviço.

Atributos recomendados para coletar
Principais atividades para monitorar no seu atendimento
Guia de extração para Zendesk Support

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

Baixar Modelo

Atributos de Atendimento ao Cliente

Estes são os campos de dados recomendados para incluir em seu event log para uma análise abrangente do atendimento ao cliente.

5 Obrigatório 7 Recomendado 7 Opcional

	Nome	Descrição
	Hora de Início StartTime	O timestamp que indica quando uma atividade ou evento começou.
Descrição O Tempo de Início, ou timestamp do evento, registra a data e hora exata em que uma atividade específica ocorreu. Por exemplo, ele captura quando um comentário do cliente foi adicionado, quando um agente foi atribuído ou quando o status do ticket mudou para "Resolvido". Este timestamp é fundamental para o Process Mining, pois estabelece a ordem cronológica dos eventos. Ele é usado para calcular durações entre atividades, medir tempos de ciclo, analisar a performance em relação aos SLAs e entender a dinâmica temporal do processo de atendimento. Por que é importante Este timestamp é essencial para ordenar os eventos, calcular durações e analisar a linha do tempo do processo de solicitação de serviço. Onde obter API de Auditoria de Tickets do Zendesk, campo `created_at` para cada evento no log de auditoria. Exemplos 2023-04-15T10:00:00Z2023-04-15T10:05:14Z2023-04-16T14:30:00Z
	Solicitação de Serviço ServiceRequest	O identificador exclusivo de cada solicitação de atendimento, também conhecido como ticket ou caso.
Descrição A Solicitação de Serviço é o identificador principal do caso que vincula todas as atividades relacionadas a uma única consulta ou problema do cliente, desde sua criação até a resolução final. Cada interação, atualização ou ação interna está ligada a este ID exclusivo. No Process Mining, analisar eventos agrupados pela Solicitação de Serviço permite uma visão completa de ponta a ponta da jornada do cliente. É a base para calcular métricas fundamentais como o tempo total de resolução, identificar desvios de processo e entender o ciclo de vida de cada problema do cliente. Por que é importante Este é o Case ID essencial que conecta todas as etapas do processo, permitindo a reconstrução e análise de cada jornada individual de atendimento ao cliente. Onde obter API de Tickets do Zendesk, campo `id`. Exemplos 102451287415332
	Nome da Atividade ActivityName	O nome do evento ou tarefa específica que ocorreu no ciclo de vida da solicitação de serviço.
Descrição O Nome da Atividade descreve uma única etapa ou marco no processo de atendimento, como "Solicitação de serviço criada", "Solicitação atribuída ao agente" ou "Solicitação de serviço resolvida". Esses eventos possuem timestamps e formam a sequência de ações para cada solicitação. Este atributo é fundamental para visualizar o fluxo do processo, descobrir variantes e analisar a frequência e a ordem dos eventos. Ele permite que os analistas entendam quais ações estão sendo executadas e identifiquem caminhos comuns, gargalos e desvios do procedimento padrão. Por que é importante Este atributo define as etapas do processo, permitindo a visualização do mapa do processo e a análise de fluxos e variações. Onde obter Derivado dos logs de auditoria ou fluxos de eventos do Zendesk que registram alterações e ações. Exemplos Solicitação de Serviço CriadaSolicitação atribuída ao agentePrimeira Resposta Pùblica do Agente EnviadaSolicitação de serviço resolvida
	Sistema de Origem SourceSystem	O sistema de registro de onde os dados foram extraídos.
Descrição Este atributo especifica o sistema de origem dos dados da solicitação, que neste caso é o Zendesk Support. Ele auxilia na governança e linhagem de dados, especialmente ao combinar informações de múltiplos sistemas. Na análise, ele garante que os dados sejam atribuídos corretamente à sua fonte, o que é importante para manter a integridade dos dados e entender o contexto do processo, particularmente em ambientes com diversos sistemas. Por que é importante Identifica a origem dos dados, o que é fundamental para a governança e para distinguir processos em ambientes integrados. Onde obter Este é um valor estático adicionado durante o processo de extração para identificar a origem dos dados. Exemplos Zendesk Support
	Última Atualização de Dados LastDataUpdate	O timestamp da atualização ou extração de dados mais recentes do sistema de origem.
Descrição Este atributo indica a última vez que o conjunto de dados foi atualizado a partir do Zendesk Support. Ele fornece o contexto sobre a atualidade dos dados analisados. Saber o horário da última atualização é crucial para que analistas e usuários de negócios entendam se estão visualizando as informações mais recentes do processo. Isso ajuda a gerenciar expectativas sobre a recência dos dados e é vital para fins de relatório e monitoramento. Por que é importante Traz clareza sobre a atualização dos dados, garantindo que os usuários entendam o quão recente é a análise do processo. Onde obter Este é um campo de metadados gerado e armazenado durante o processo de extração, registrando o timestamp da tarefa de extração. Exemplos 2023-10-27T02:00:00Z
	Agente atribuído AssignedAgent	O nome ou ID do agente de atendimento atribuído para lidar com a solicitação de serviço.
Descrição Este atributo identifica o agente específico responsável por uma atividade ou pela solicitação em um determinado momento. Ele pode mudar ao longo do ciclo de vida se a solicitação for reatribuída. Analisar por Agente Atribuído é fundamental para entender a carga de trabalho, a performance e a eficiência dos agentes. Ele alimenta o dashboard "Agent Workload and Efficiency", permitindo comparações de tempos de atendimento e volumes de casos entre diferentes agentes, ajudando a identificar oportunidades de treinamento e garantir cargas de trabalho equilibradas. Por que é importante Rastreia qual agente executou uma ação, permitindo a análise da performance individual, distribuição da carga de trabalho e alocação de recursos. Onde obter API de Tickets do Zendesk, campo `assignee_id`. Detalhes do usuário podem ser obtidos na API de Usuários. Exemplos John SmithJane DoeSupportBot
	Canal de Comunicação CommunicationChannel	O canal pelo qual a solicitação de serviço foi enviada ou a comunicação ocorreu.
Descrição Este atributo identifica o método de comunicação utilizado, como e-mail, formulário web, chat ou telefone. Ele reflete como os clientes interagem com o service desk. Entender o uso dos canais é importante para o planejamento de recursos e a melhoria da experiência do cliente. O dashboard "Communication Channel Usage Overview" analisa esses dados para ver quais canais são mais populares e se certos canais estão associados a tempos de resolução mais longos ou caminhos de processo diferentes. Pode ajudar a decidir onde investir em melhorias de serviço ou automação. Por que é importante Mostra como clientes e agentes interagem, permitindo a análise da eficiência dos canais e seu impacto no processo e na experiência do cliente. Onde obter API de Tickets do Zendesk, campo `via.channel`. Exemplos webe-mailapichat
	Meta de tempo de resolução do SLA SlaTargetResolutionTime	O tempo previsto dentro do qual se espera que uma solicitação de serviço seja resolvida, com base em sua política de SLA.
Descrição Este atributo define a meta de Acordo de Nível de Serviço (SLA) para a resolução de um ticket. Essa meta costuma ser dinâmica e depende de fatores como prioridade, tipo de solicitação ou o plano de serviço do cliente. Este é um atributo fundamental para o dashboard "SLA Compliance Performance". Ele serve como referência para medir o tempo real de resolução. Analisar a performance em relação a essa meta ajuda a quantificar a qualidade da entrega do serviço e garante que as obrigações contratuais com os clientes sejam cumpridas. Por que é importante Define a promessa de serviço ao cliente, servindo como referéncia para medir a pontualidade e a conformidade de SLA. Onde obter Derivado das políticas de SLA aplicadas a um ticket. Disponível através da API de Métricas de Tickets do Zendesk. Exemplos 144002880086400
	Prioridade Priority	O nível de prioridade atribuído à solicitação de serviço, como "Baixa", "Normal", "Alta" ou "Urgente".
Descrição A Prioridade indica a urgência de uma solicitação de serviço e costuma influenciar sua posição na fila e o prazo de resolução. Ela ajuda os agentes a focarem primeiro nos problemas mais críticos. Este atributo é essencial para análises de performance e de SLA. O dashboard "Service Request Resolution Time Analysis" usa a prioridade para segmentar dados, revelando se as solicitações de alta prioridade estão sendo atendidas mais rápido do que as de menor prioridade e se os recursos estão alocados de forma eficaz conforme as necessidades do negócio. Por que é importante Indica a urgéncia de uma solicitação, o que é vital para analisar a conformidade do SLA e garantir que casos críticos sejam atendidos logo. Onde obter API de Tickets do Zendesk, campo `priority`. Exemplos BaixoNormalAltoUrgente
	SLA violado IsSlaBreached	Um sinalizador booleano que indica se o tempo de resolução da solicitação de serviço excedeu sua meta de SLA.
Descrição Este atributo calculado é um marcador simples de verdadeiro ou falso que mostra se uma solicitação de serviço deixou de cumprir seu Acordo de Nível de Serviço definido para o tempo de resolução. Ele é derivado da comparação da duração real da resolução com a meta de SLA planejada. Este marcador simplifica a análise de conformidade de SLA. É o ponto de dados central para o dashboard "SLA Compliance Performance" e o KPI "SLA Compliance Rate", permitindo uma rápida agregação e visualização de quantas solicitações estão cumprindo as metas de serviço versus as que não estão. Por que é importante Oferece um resultado binário claro sobre a performance do SLA em cada caso, simplificando o monitoramento da conformidade e a geração de relatórios. Onde obter Calculado durante a transformação de dados ao comparar o tempo total de resolução com o SlaTargetResolutionTime. Exemplos verdadeirofalse
	Tempo de resolução ServiceRequestResolutionTime	O tempo total decorrido desde o momento em que uma solicitação de serviço foi criada até sua resolução final.
Descrição Esta métrica mede a duração de ponta a ponta de uma solicitação de serviço. Ela é calculada como a diferença entre o timestamp da atividade "Solicitação de serviço resolvida" e a atividade "Solicitação de serviço criada". Este é um dos KPIs mais importantes para qualquer processo de atendimento. É a métrica principal para o dashboard "Service Request Resolution Time Analysis" e o KPI "Average Service Request Resolution Time". Analisar essa duração ajuda a identificar atrasos sistêmicos e medir a eficiência geral do processo de suporte. Por que é importante Mede a duração ponta a ponta do caso, um KPI crítico para avaliar a eficiência e a experiência do cliente. Onde obter Calculado subtraindo o timestamp de criação do timestamp de resolução final para cada solicitação. Exemplos 720086400172800
	Tipo de solicitação de serviço ServiceRequestType	A classificação da solicitação de serviço, como "Pergunta", "Incidente", "Problema" ou "Tarefa".
Descrição Este atributo categoriza a solicitação de serviço com base em sua natureza. Esta classificação costuma ser definida quando a solicitação é criada ou triada, ajudando a determinar o workflow e a prioridade adequados. Na análise, a segmentação por Tipo de Solicitação de Serviço é fundamental. Ela permite comparar tempos de resolução, taxas de escalonamento e fluxos de processo para diferentes tipos de problemas, como mostrado nos dashboards "Service Request Resolution Time Analysis" e "Internal Escalation Rate & Causes". Isso ajuda a identificar se certos tipos de solicitações são mais problemáticos ou ineficientes de lidar. Por que é importante Categoriza as solicitações para permitir a comparação de desempenho e análise entre diferentes tipos de problemas. Onde obter API de Tickets do Zendesk, campo `type`. Exemplos PerguntaIncidenteProblemaTarefa
	Avaliação de Satisfação SatisfactionRating	O score de satisfação fornecido pelo cliente após a resolução da solicitação.
Descrição Este atributo captura o feedback do cliente sobre sua experiência de atendimento, geralmente coletado por meio de uma pesquisa após a resolução do ticket. As avaliações comuns incluem "Bom", "Ruim" ou uma nota numérica. Esta é uma medida direta do sentimento do cliente e é uma métrica de resultado fundamental. É usada para calcular o KPI "Customer Sentiment Score". Analisar as avaliações de satisfação em conjunto com os dados do processo, como o tempo de resolução ou o número de interações do agente, pode revelar quais comportamentos do processo levam a melhores resultados para o cliente. Por que é importante Mede diretamente o feedback do cliente sobre o serviço, vinculando o desempenho do processo aos resultados percebidos. Onde obter API de Tickets do Zendesk, campo `satisfaction_rating.score`. Exemplos bomruimoferecido
	Categoria de Serviço do Produto ProductServiceCategory	O produto, serviço ou recurso específico sobre o qual trata a solicitação do cliente.
Descrição Este atributo fornece um contexto detalhado ao categorizar a solicitação de serviço com base em uma área de produto ou serviço. Geralmente é definido manualmente por um agente ou automaticamente com base no conteúdo da solicitação. Esta categorização é vital para os dashboards "Request Categorization Accuracy" e "Investigation Cycle Time Breakdown". Permite uma análise aprofundada sobre quais produtos geram mais solicitações de suporte, quais são os mais complexos de resolver e se a categorização inicial está alinhada com a solução final, ajudando a melhorar o roteamento e o treinamento dos agentes. Por que é importante Vincula as solicitações a áreas de negócio ou produtos específicos, permitindo uma análise focada nos pontos problemáticos. Onde obter Geralmente é um campo de ticket personalizado no Zendesk. O nome exato do campo depende da configuração específica do Zendesk. Exemplos Mobile AppGestão de AssinaturasIntegração via APIHardware
	Código de resolução ResolutionCode	Um código ou categoria que indica o motivo da resolução final ou do fechamento da solicitação.
Descrição O Código de Resolução fornece informações estruturadas sobre o desfecho de uma solicitação. Exemplos incluem "Resolvido pelo Agente", "Duplicado", "Nenhuma ação necessária" ou "Problema conhecido". Ele oferece mais contexto do que um simples status "Fechado". Este atributo é valioso para a análise de causa raiz. No dashboard "Reopened Service Request Trends", analisar as taxas de reabertura por código de resolução pode revelar se certos tipos de soluções são menos eficazes, levando os clientes a precisarem de novo suporte. Por que é importante Oferece insights sobre o desfecho de uma solicitação de serviço, o que é crucial para a análise de causa raiz e para entender por que as solicitações estão sendo reabertas. Onde obter Geralmente é um campo de ticket personalizado no Zendesk. O nome exato do campo depende da configuração específica do Zendesk. Exemplos Resolução no Primeiro ContatoEscalonado para Nível 2Aguardando ClienteBug de Produto
	Contagem de Pedidos de Informação InformationRequestCount	O número total de vezes que informações foram solicitadas ao cliente para uma única solicitação de serviço.
Descrição Esta métrica calculada conta as ocorrências da atividade "Informações solicitadas ao cliente" para cada solicitação de serviço. Uma contagem alta sugere que os agentes não estão coletando todas as informações necessárias antecipadamente. Este atributo é utilizado no dashboard "Repeated Information Request Analysis". Monitorar essa contagem ajuda a identificar ineficiências de processo e áreas para treinamento de agentes. Reduzir o número de vezes que as informações são solicitadas pode encurtar significativamente os tempos de resolução e melhorar a experiência do cliente. Por que é importante Quantifica a troca de mensagens com o cliente, destacando ineficiências que prolongam o tempo de resolução e prejudicam a experiência do usuário. Onde obter Calculado pela contagem de eventos onde o ActivityName é "Informação Solicitada ao Cliente" para cada solicitação. Exemplos 013
	End Time EndTime	O timestamp que indica quando uma atividade ou evento foi concluído.
Descrição O Tempo de Término representa o horário de conclusão de uma atividade. Em muitas estruturas de event log, o Tempo de Início da próxima atividade pode servir como o Tempo de Término da atual. Para atividades baseadas em estado, como "Agente investiga o problema", ele marca quando esse estado foi concluído. Este atributo é essencial para calcular a duração precisa das atividades, componente central da análise de performance. Ele ajuda a identificar quais etapas consomem mais tempo e fornece a base para análises detalhadas de gargalos e cálculos de eficiência de recursos. Por que é importante Permite o cálculo da duração das atividades, essencial para identificar gargalos e medir a performance. Onde obter Isso costuma ser derivado utilizando o StartTime do evento subsequente na sequência de uma determinada Solicitação de Serviço. Exemplos 2023-04-15T10:05:14Z2023-04-15T11:20:30Z2023-04-16T15:00:00Z
	Grupo de Agentes AgentGroup	O grupo ou equipe de suporte ao qual a solicitação de serviço está atribuída.
Descrição Este atributo representa a equipe de agentes responsável pela solicitação de serviço. As solicitações costumam ser roteadas para grupos específicos com base em habilidades, área de produto ou idioma. Analisar por Grupo de Agentes ajuda a entender a performance no nível da equipe, a distribuição da carga de trabalho e os padrões de escalonamento entre times. Oferece uma visão de nível superior à análise individual e ajuda a identificar problemas sistêmicos em departamentos ou funções específicas. Por que é importante Rastreia a responsabilidade da equipe, permitindo a análise da performance do grupo, transferências entre times e alocação de recursos em diferentes níveis ou especialidades de suporte. Onde obter API de Tickets do Zendesk, campo `group_id`. Detalhes do grupo podem ser obtidos na API de Grupos. Exemplos Suporte Nível 1Suporte TécnicoFaturamento
	Reaberto IsReopened	Um sinalizador booleano que indica se uma solicitação de serviço foi reaberta após ser marcada como resolvida.
Descrição Este atributo é um marcador que se torna verdadeiro se uma solicitação de serviço retornar ao estado aberto após ter sido definida anteriormente como resolvida ou fechada. Ele sinaliza que a resolução inicial não foi suficiente. Este marcador é crucial para rastrear retrabalho e falhas na resolução no primeiro contato. Ele alimenta diretamente o dashboard "Reopened Service Request Trends" e o KPI "Service Request Reopen Rate", facilitando a contagem e análise dos casos que exigem atenção adicional, o que muitas vezes indica problemas subjacentes mais profundos. Por que é importante Identifica retrabalhos e falhas, ajudando a medir a qualidade e a eficácia das soluções oferecidas. Onde obter Calculado durante a transformação de dados, verificando se o status de um ticket mudou de "resolvido" ou "fechado" de volta para "aberto". Exemplos verdadeirofalse

Obrigatório Recomendado Opcional

Atividades de Atendimento ao Cliente

Estas são as principais etapas e marcos do processo a serem capturados em seu event log para uma descoberta precisa do processo de atendimento.

6 Recomendado 8 Opcional

	Atividade	Descrição
	Informação Solicitada ao Cliente	Ocorre quando um agente precisa de mais dados do cliente e muda o status para "pendente". Isso indica que o processo está aguardando uma resposta externa.
Por que é importante Esta atividade destaca as dependências em relação ao cliente e pausa os cronômetros internos de SLA. Ocorrências frequentes ou repetidas em um único ticket podem indicar falha na coleta inicial de informações e levar a tempos de resolução mais longos. Onde obter Este é um evento de mudança de status explícito registrado na API de Auditoria de Tickets do Zendesk. Ele é capturado quando o campo "status" muda para "pendente". Captura Identifica eventos de "Alteração" nas auditorias onde o status foi definido como "pendente". Tipo de evento explicit
	Solicitação atribuída ao agente	Este evento significa que a solicitação de serviço foi atribuída a um agente específico para tratamento. Isso pode ocorrer automaticamente com base em regras de roteamento ou manualmente por um líder de equipe ou agente.
Por que é importante A atribuição é um marco crítico para a responsabilidade e gestão de carga de trabalho. Analisar o tempo de atribuição e os padrões de redistribuição revela gargalos na triagem. Onde obter Este é um evento de "Mudança" explícito na API de Auditoria de Tickets do Zendesk, registrado sempre que o campo "assignee_id" é preenchido ou alterado. Captura Monitore as alterações no campo "assignee_id" no log de Auditoria de Tickets. Tipo de evento explicit
	Solicitação de Serviço Criada	Esta atividade marca o início do processo de atendimento, quando um novo ticket é gerado no Zendesk por qualquer canal, como e-mail, formulário web ou chat. Esse evento é registrado explicitamente pelo sistema com um ID de ticket exclusivo e um timestamp no momento da criação.
Por que é importante Como principal evento de início, é essencial para calcular a duração total do caso e analisar o volume de solicitações. Serve como base para medir KPIs como o tempo de primeira resposta e o tempo total de resolução. Onde obter Este é um evento explícito capturado na API de Auditoria de Tickets do Zendesk. Ele corresponde ao evento de "Criação" de um ticket, fornecendo o timestamp inicial. Captura Capturado a partir do evento de criação do ticket no log de Auditorias de Tickets. Tipo de evento explicit
	Solicitação de serviço fechada	Esta é a atividade final, que marca o fechamento permanente da solicitação. Isso costuma ocorrer automaticamente após um período definido desde que o ticket foi marcado como "resolvido", sem novas respostas do cliente.
Por que é importante Como o evento final definitivo, ele encerra o ciclo de vida do ticket. O período entre "resolvido" e "fechado" representa a janela para possíveis reaberturas, e o fechamento confirma que a resolução foi aceita. Onde obter Esta é uma mudança de status explícita registrada na API de Auditoria de Tickets do Zendesk quando o campo "status" é definido como "fechado". Captura Identifica eventos de "Alteração" nas auditorias onde o status foi definido como "fechado". Tipo de evento explicit
	Solicitação de serviço reaberta	Esta atividade ocorre se um cliente responde a um ticket que está com o status "resolvido". O Zendesk altera automaticamente o status de volta para "aberto", indicando que o problema não foi totalmente resolvido.
Por que é importante As reaberturas são um indicador crítico de falha na Resolução no Primeiro Contato (FCR) e de baixa qualidade na solução. Analisar a frequência e os motivos dos tickets reabertos ajuda a identificar áreas para melhorar o treinamento dos agentes e os procedimentos de resolução. Onde obter Esta é uma mudança de status explícita na API de Auditoria de Tickets, capturada quando o status passa de "resolvido" de volta para "aberto". Captura Rastreie eventos de "Mudança" de status de "resolvido" para "aberto". Tipo de evento explicit
	Solicitação de serviço resolvida	Um agente marca a solicitação como "resolvida" após fornecer uma solução. Este é um estado temporário, já que o ticket pode ser reaberto por uma resposta do cliente antes de ser fechado definitivamente.
Por que é importante Este é o marco principal para medir o tempo de resolução e a eficiência do agente. Ele sinaliza o ponto onde o agente acredita que o trabalho está concluído, fornecendo uma base para analisar retrabalho se o ticket for reaberto. Onde obter Esta é uma mudança de status explícita registrada na API de Auditoria de Tickets do Zendesk quando o campo "status" é definido como "resolvido". Captura Identifica eventos de "Alteração" nas auditorias onde o status foi definido como "resolvido". Tipo de evento explicit
	Avaliação de satisfação recebida	Este evento ocorre quando o cliente envia sua resposta à pesquisa de satisfação, fornecendo uma avaliação como "Bom" ou "Ruim". A avaliação e qualquer comentário associado são registrados no ticket.
Por que é importante O feedback direto do cliente é inestimável para medir a qualidade e o sentimento. Analisar essas notas no contexto do fluxo ajuda a relacionar atividades ou agentes específicos aos resultados. Onde obter Capturado como um evento de "Alteração" na API de Auditorias de Tickets quando o campo "satisfaction_rating" é preenchido. Captura Filtre os logs de auditoria para alterações no campo "satisfaction_rating". Tipo de evento explicit
	Cliente respondeu	Este evento é acionado quando um cliente responde a um ticket, geralmente um que estava em estado "pendente". O Zendesk faz a transição automática do status do ticket de "pendente" para "aberto", sinalizando que o agente pode retomar o trabalho.
Por que é importante Esta atividade marca o fim de um tempo de espera e serve como gatilho para a continuação do processo. Analisar o tempo que os clientes levam para responder pode fornecer insights sobre a clareza das solicitações dos agentes. Onde obter Este evento corresponde a um novo comentário público do usuário final, o que aciona uma mudança explícita de status de "pendente" para "aberto" na API de Auditoria de Tickets. Captura Rastreie eventos de "Mudança" de status de "pendente" para "aberto" ou identifique novos comentários públicos de um usuário final. Tipo de evento explicit
	Escalação Interna Ativada	Representa a transferência de uma solicitação de serviço para uma equipe interna diferente ou um nível de suporte superior. Isso geralmente é identificado quando o grupo atribuído ao ticket é alterado.
Por que é importante Rastrear os escalonamentos é fundamental para identificar pontos fracos no processo, lacunas de conhecimento no suporte de linha de frente e tipos de solicitações complexas. Altas taxas de escalonamento podem indicar a necessidade de melhor treinamento ou documentação de processos. Onde obter Inferido a partir de um evento de "Alteração" na API de Auditorias onde o campo "group_id" é modificado, sinalizando um handoff entre equipes. Captura Monitore alterações no campo "group_id" no log de auditoria dos tickets. Tipo de evento inferred
	Ocorreu violação de SLA	Esta atividade marca o momento em que uma solicitação de serviço deixa de cumprir um Acordo de Nível de Serviço pré-definido, como o tempo de primeira resposta ou o tempo de resolução. Este evento é calculado com base nos timestamps das atividades do ticket comparados com as políticas de SLA.
Por que é importante As violações de SLA impactam diretamente a satisfação do cliente e a conformidade contratual. Analisar quando e por que elas ocorrem é fundamental para identificar atrasos sistêmicos, falta de recursos ou metas de performance irreais. Onde obter Isso pode ser obtido na API de Métricas de Ticket do Zendesk, que armazena os timestamps de violação de SLA ("breached_at"). Alternativamente, pode ser calculado comparando os timestamps dos eventos do ticket com as regras de SLA definidas. Captura Use o timestamp "breached_at" da API de Métricas de Ticket ou calcule comparando o tempo de resolução com o tempo da política de SLA. Tipo de evento calculated
	Pesquisa de satisfação enviada	Representa o momento em que uma pesquisa de satisfação do cliente (CSAT) é enviada automaticamente. Isso costuma ocorrer pouco tempo depois de o ticket ser marcado como resolvido.
Por que é importante Esta atividade inicia o ciclo de feedback do cliente. Entender quando e se as pesquisas são enviadas é importante para contextualizar os scores de satisfação e medir a eficácia do programa de feedback. Onde obter Isso pode ser inferido a partir de um log de automação ou por uma tag específica adicionada ao ticket. A seção "satisfaction_rating" na API de Auditoria de Tickets (Ticket Audits) também registra quando a pesquisa foi oferecida. Captura Busque por tags como "csat_sent" ou use o timestamp de quando a avaliação foi oferecida. Tipo de evento inferred
	Primeira Resposta Pùblica do Agente Enviada	Esta atividade marca a primeira vez que um agente envia um comentário público ao cliente, em vez de um reconhecimento automático. Este evento é um indicador crucial do engajamento inicial do agente com o problema do cliente.
Por que é importante Este é um marco fundamental para medir o SLA de "Tempo de Primeira Resposta", um indicador crítico da responsividade do serviço. Ele separa a comunicação automatizada do início da investigação e suporte ativos liderados por humanos. Onde obter Identificado ao encontrar o primeiro comentário pùblico no fluxo onde o autor é um agente humano (não um robô). Captura Analise os comentários dos tickets, filtrando pelos comentários públicos dos agentes e selecionando aquele com o timestamp mais antigo. Tipo de evento inferred
	Reconhecimento Inicial Enviado	Representa a primeira resposta automática enviada ao cliente, confirmando que sua solicitação foi recebida. Isso geralmente é gerenciado por um gatilho do Zendesk que envia uma notificação por e-mail com um template logo após a criação do ticket.
Por que é importante Rastrear esta atividade é crucial para medir a responsividade inicial e gerenciar as expectativas do cliente. O tempo entre a criação da solicitação e este reconhecimento é uma métrica chave para a satisfação do cliente. Onde obter Inferido pelo primeiro comentário pùblico se o autor for um robô ou se ocorrer segundos após a criação. Identificado analisando o fluxo de comentários do ticket. Captura Identifica o primeiro comentário pùblico criado por uma automação logo após a criação do ticket. Tipo de evento inferred
	Solicitação categorizada e priorizada	Esta atividade ocorre quando um agente ou uma automação define ou atualiza campos do ticket, como tipo, categoria e prioridade. Esta etapa é registrada como um evento de mudança no histórico do ticket.
Por que é importante A categorização e priorização adequadas são vitais para um roteamento e alocação de recursos eficientes. Analisar esta atividade ajuda a determinar a precisão da triagem inicial e seu impacto nos tempos de resolução. Onde obter Capturado na API de Auditorias de Tickets do Zendesk como eventos de "Alteração". Pode ser identificado buscando a primeira atualização em campos como "prioridade", "tipo" ou campos customizados de categorização. Captura Filtre os logs de auditoria para o primeiro evento de "Alteração" nos campos de categorização após a criação. Tipo de evento explicit

Recomendado Opcional

Guias de Extração

Como obter seus dados do Zendesk Support

Etapas

Navegue até o Zendesk Explore: Faça login no seu Zendesk e abra o produto Explore clicando no ícone do seletor de produtos na barra superior.
Crie uma Nova Consulta: No Explore, clique no ícone de Consultas (Queries) na barra lateral esquerda e, em seguida, no botão "Nova consulta" (New query) no canto superior direito.
Selecione o Conjunto de Dados: Na janela "Escolha um conjunto de dados", selecione Support: Tickets. Este conjunto contém os principais atributos dos tickets e os timestamps dos eventos.
Adicione Métricas: No construtor de consultas, vá ao painel "Métricas" e clique em "Adicionar". Selecione COUNT(Tickets). Isso ajuda a validar o volume de dados.
Adicione Atributos às Linhas: Vá ao painel "Linhas" (Rows) e clique em "Adicionar". Insira os seguintes atributos, que formarão as colunas base da sua exportação:
- Ticket ID (Seu Identificador de Caso, ServiceRequest)
- Assignee name (AssignedAgent)
- Ticket type (ServiceRequestType)
- Ticket priority (Priority)
- Ticket channel (CommunicationChannel)
- SLA resolution time (SlaTargetResolutionTime)
- SLA breach status (IsSlaBreached)
- Full resolution time (min) (ServiceRequestResolutionTime)
Adicione Timestamps de Atividade às Linhas: Adicione os seguintes timestamps ao painel "Linhas". Cada um representa uma atividade potencial. Alguns exigem a criação de atributos calculados personalizados.
- Ticket created - Timestamp: Para Solicitação de Serviço Criada e Reconhecimento Inicial Enviado.
- Ticket assigned - Timestamp: Para Solicitação Atribuída ao Agente.
- First reply time - Timestamp: Para Primeira Resposta Pùblica do Agente Enviada.
- Ticket solved - Timestamp: Para Solicitação Resolvida e Pesquisa de Satisfação Enviada.
- Ticket reopened - Timestamp: Para Solicitação Reaberta.
- Satisfaction rating received - Timestamp: Para Avaliação de Satisfação Recebida.
- Ticket closed - Timestamp: Para Solicitação de Serviço Fechada.
Crie Atributos Calculados para Outras Atividades: Algumas atividades dependem de alterações de campos específicos. Vá ao menu de Cálculos (ícone de calculadora) e selecione "Atributo calculado padrão". Crie um para cada atividade abaixo (ajuste os nomes dos campos conforme sua instância):
- Nome: Timestamp - Categorizado e Priorizado. Fórmula: IF ([Changes - Field name] = "priority" OR [Changes - Field name] = "type") THEN [Update - Timestamp] ENDIF. Defina o agregador como MIN.
- Nome: Timestamp - Informação Solicitada. Fórmula: IF ([Changes - Field name] = "status" AND [Changes - New value] = "pending") THEN [Update - Timestamp] ENDIF. Defina como MIN.
- Nome: Timestamp - Cliente Respondeu. Fórmula: IF ([Changes - Field name] = "status" AND [Changes - Previous value] = "pending" AND [Changes - New value] = "open") THEN [Update - Timestamp] ENDIF. Defina como MIN.
- Nome: Timestamp - Escalonado. Fórmula: IF ([Changes - Field name] = "group") THEN [Update - Timestamp] ENDIF. Defina como MIN.
- Nome: Timestamp - Quebra de SLA. Fórmula: IF ([SLA breach status]=TRUE) THEN [SLA update - Timestamp] ENDIF. Defina como MIN.
Filtre os Dados: No painel "Filtros", adicione um filtro para Ticket created - Date e selecione um intervalo (ex: ùltimos 3 a 6 meses).
Execute e Exporte o Relatório: Clique em "Salvar" e, quando os dados aparecerem, clique em "Exportar" (Export) e escolha CSV ou Excel.
Transforme para Formato de Log de Eventos: O arquivo exportado estará em formato "largo". Você deve transformá-lo em formato "longo" para Process Mining usando ferramentas como o Power Query do Excel (função Unpivot), Python ou similares.
- Para cada linha (ticket), crie novas linhas para cada coluna de timestamp preenchida.
- A tabela final deve conter colunas como ServiceRequest, ActivityName, StartTime, além dos outros atributos que serão duplicados para cada atividade daquela solicitação.

Configuração

Conjunto de Dados (Dataset): O conjunto principal a ser utilizado é o Support: Tickets. Ele permite acessar a maioria das propriedades dos tickets e os principais timestamps em uma ùnica consulta.
Permissões: Você precisa de, no mínimo, uma função de Editor ou Administrador no Zendesk Explore para criar e salvar consultas.
Intervalo de Datas: É fundamental definir um filtro de intervalo de datas em Ticket created - Date. Recomendamos um período de 3 a 6 meses para equilibrar a profundidade dos insights com o desempenho do sistema. Exportar milhões de tickets pode ser lento ou resultar em falhas.
Filtros de Consulta: Considere adicionar filtros para propriedades específicas, como Ticket brand, Ticket form ou Ticket group, para focar a análise em um serviço ou equipe em particular.
Atributos Calculados: Este método depende muito da criação de atributos calculados padrão para capturar timestamps de eventos que não são atributos nativos, como alterações de status ou escalações. Certifique-se de ter as permissões necessárias para criar esses atributos.

a Consulta de Exemplo config

This extraction is configured through the Zendesk Explore graphical user interface. There is no single script to execute. The configuration below outlines the components to add in the query builder.

**Dataset**: `Support: Tickets`

**Metrics**:
1.  `COUNT(Tickets)`

**Rows (Attributes)**:
1.  `Ticket ID`
2.  `Assignee name`
3.  `Ticket type`
4.  `Ticket priority`
5.  `Ticket channel`
6.  `SLA resolution time`
7.  `SLA breach status`
8.  `Full resolution time (min)`
9.  `MIN(Ticket created - Timestamp)`
10. `MIN(Ticket assigned - Timestamp)`
11. `MIN(First reply time - Timestamp)`
12. `MIN(Ticket solved - Timestamp)`
13. `MIN(Ticket reopened - Timestamp)`
14. `MIN(Satisfaction rating received - Timestamp)`
15. `MIN(Ticket closed - Timestamp)`
16. `MIN(Timestamp - Categorized and Prioritized)` (Custom calculated attribute)
17. `MIN(Timestamp - Info Requested)` (Custom calculated attribute)
18. `MIN(Timestamp - Customer Responded)` (Custom calculated attribute)
19. `MIN(Timestamp - Escalated)` (Custom calculated attribute)
20. `MIN(Timestamp - SLA Breach)` (Custom calculated attribute)

**Filters**:
1.  `Ticket created - Date`: Select a date range (e.g., last 180 days)

**Standard Calculated Attribute Formulas**:
*   `Timestamp - Categorized and Prioritized`: `IF ([Changes - Field name] = "priority" OR [Changes - Field name] = "type") THEN [Update - Timestamp] ENDIF`
*   `Timestamp - Info Requested`: `IF ([Changes - Field name] = "status" AND [Changes - New value] = "pending") THEN [Update - Timestamp] ENDIF`
*   `Timestamp - Customer Responded`: `IF ([Changes - Field name] = "status" AND [Changes - Previous value] = "pending" AND [Changes - New value] = "open") THEN [Update - Timestamp] ENDIF`
*   `Timestamp - Escalated`: `IF ([Changes - Field name] = "group") THEN [Update - Timestamp] ENDIF`
*   `Timestamp - SLA Breach`: `IF ([SLA breach status]=TRUE) THEN [SLA update - Timestamp] ENDIF`

Etapas

Prepare o Acesso à API do Zendesk: Faça login como administrador. Vá até a Central de Administração > Apps e integrações > APIs > API do Zendesk. Na aba Configurações, ative o "Acesso por token". Clique em "Adicionar token de API" para criar um novo. Copie o token gerado e guarde-o em local seguro.
Configure o Ambiente Python: Verifique se o Python 3.6+ está instalado. Instale a biblioteca requests via linha de comando usando: pip install requests.
Configure o Script Python: Salve o script fornecido como extract_zendesk_log.py. Abra-o em um editor de texto e preencha as variáveis no topo: ZENDESK_SUBDOMAIN, ZENDESK_EMAIL e API_TOKEN com seus dados.
Defina o Período de Extração: Localize a variável START_TIMESTAMP no script. Este valor define a data inicial da extração (em formato Unix epoch). Para uma análise inicial, recomendamos os ùltimos 3 a 6 meses.
Execute o Script: No terminal, navegue até a pasta do arquivo e execute: python extract_zendesk_log.py.
Acompanhe a Execução: O script exibirá o progresso e a quantidade de tickets processados. O tempo total dependerá do volume de dados e dos limites de taxa da API do Zendesk. O script já trata automaticamente as pausas por rate limit.
Obtenha o Log de Eventos: Ao finalizar, o arquivo zendesk_event_log.csv será criado na mesma pasta, contendo o log estruturado para análise.
Prepare o Upload: Abra o arquivo para conferir se as colunas obrigatórias estão corretas: ServiceRequest, ActivityName, StartTime, SourceSystem e LastDataUpdate. Agora, o arquivo está pronto para ser carregado na ferramenta de Process Mining.

Configuração

Credenciais de API: O script exige um subdomínio válido do Zendesk, o e-mail de um agente ou administrador e um token de API ativo. O usuário vinculado às credenciais deve ter permissão para ler tickets, auditorias de tickets, usuários e métricas de tickets.
Intervalo de Datas: A data de início da extração é controlada pela variável START_TIMESTAMP no script, que deve ser um timestamp Unix epoch. Recomendamos começar com um período curto, como 3 meses, para validar a saída e o desempenho do script antes de tentar uma coleta maior de dados históricos.
API de Exportação Incremental: Esta solução utiliza a API de Exportação Incremental do Zendesk. Este é o método mais eficiente e indicado para buscar um grande volume de tickets, pois foi projetado para exportação de dados em massa e evita problemas comuns de paginação.
Desempenho e Limites de Taxa (Rate Limiting): O Zendesk impõe limites de taxa de API que variam conforme o plano de assinatura. O script possui uma lógica integrada para pausar a execução quando um limite é atingido, com base no cabeçalho Retry-After retornado pela API. Em instâncias muito grandes, a extração pode levar várias horas.
Pré-requisitos: Este método de extração requer um ambiente Python 3.6+ funcional e a biblioteca externa requests. O acesso de administrador à instância de destino do Zendesk é necessário para gerar o token de API obrigatório.

a Consulta de Exemplo python

import requests
import json
import time
import datetime
import csv

class=class="hl-string">"hl-comment"># --- Configuration ---
class=class="hl-string">"hl-comment"># Replace with your Zendesk details
ZENDESK_SUBDOMAIN = class="hl-string">'[your_zendesk_subdomain]'
ZENDESK_EMAIL = class="hl-string">'[your_zendesk_login_email]'
API_TOKEN = class="hl-string">'[your_zendesk_api_token]'

class=class="hl-string">"hl-comment"># Set the start time for the export (Unix epoch timestamp)
class=class="hl-string">"hl-comment"># Example: 1672531200 is Jan 1, 2023 00:00:00 GMT
START_TIMESTAMP = 1672531200

class=class="hl-string">"hl-comment"># --- Script --- 

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

CSV_FILENAME = class="hl-string">'zendesk_event_log.csv'
CSV_HEADERS = [
    class="hl-string">'ServiceRequest', class="hl-string">'ActivityName', class="hl-string">'StartTime', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate',
    class="hl-string">'AssignedAgent', class="hl-string">'ServiceRequestType', class="hl-string">'Priority', class="hl-string">'CommunicationChannel',
    class="hl-string">'SlaTargetResolutionTime', class="hl-string">'IsSlaBreached', class="hl-string">'ServiceRequestResolutionTime'
]

def get_user_name(user_id, users_cache, session):
    if user_id in users_cache:
        return users_cache[user_id]
    if user_id is None:
        return None
    try:
        response = session.get(fclass="hl-string">'{BASE_URL}/users/{user_id}.json')
        response.raise_for_status()
        user_name = response.json().get(class="hl-string">'user', {}).get(class="hl-string">'name')
        users_cache[user_id] = user_name
        return user_name
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">'Warning: Could not fetch user {user_id}. Error: {e}')
        users_cache[user_id] = str(user_id)
        return str(user_id)

def format_duration(seconds):
    if seconds is None:
        return None
    return str(datetime.timedelta(seconds=seconds))

def main():
    session = requests.Session()
    session.auth = AUTH
    users_cache = {}
    event_log = []

    class=class="hl-string">"hl-comment"># Fetch tickets using the incremental export API
    url = fclass="hl-string">'{BASE_URL}/incremental/tickets/cursor.json?start_time={START_TIMESTAMP}'
    ticket_count = 0

    while url:
        print(fclass="hl-string">'Fetching tickets from: {url}')
        try:
            response = session.get(url)

            if response.status_code == 429:
                retry_after = int(response.headers.get(class="hl-string">'Retry-After', 60))
                print(fclass="hl-string">'Rate limit hit. Retrying after {retry_after} seconds.')
                time.sleep(retry_after)
                continue

            response.raise_for_status()
            data = response.json()
            tickets = data.get(class="hl-string">'tickets', [])

            for ticket in tickets:
                ticket_count += 1
                ticket_id = ticket[class="hl-string">'id']
                print(fclass="hl-string">'Processing ticket {ticket_id} ({ticket_count} total)...')

                class=class="hl-string">"hl-comment"># Fetch ticket metrics for SLA and resolution time
                metrics_response = session.get(fclass="hl-string">'{BASE_URL}/tickets/{ticket_id}/metrics.json')
                ticket_metrics = metrics_response.json().get(class="hl-string">'ticket_metric', {}) if metrics_response.ok else {}

                resolution_time_seconds = ticket_metrics.get(class="hl-string">'full_resolution_time_in_minutes', {}).get(class="hl-string">'business')
                if resolution_time_seconds:
                    resolution_time_seconds *= 60

                class=class="hl-string">"hl-comment"># Fetch ticket audits for events
                audits_url = fclass="hl-string">'{BASE_URL}/tickets/{ticket_id}/audits.json'
                audits_response = session.get(audits_url)
                audits = audits_response.json().get(class="hl-string">'audits', []) if audits_response.ok else []

                first_agent_reply_sent = False

                for audit in audits:
                    audit_created_at = audit[class="hl-string">'created_at']
                    base_event = {
                        class="hl-string">'ServiceRequest': ticket_id,
                        class="hl-string">'StartTime': audit_created_at,
                        class="hl-string">'SourceSystem': SOURCE_SYSTEM,
                        class="hl-string">'LastDataUpdate': LAST_DATA_UPDATE,
                        class="hl-string">'AssignedAgent': get_user_name(ticket.get(class="hl-string">'assignee_id'), users_cache, session),
                        class="hl-string">'ServiceRequestType': ticket.get(class="hl-string">'type'),
                        class="hl-string">'Priority': ticket.get(class="hl-string">'priority'),
                        class="hl-string">'CommunicationChannel': ticket.get(class="hl-string">'via', {}).get(class="hl-string">'channel'),
                        class="hl-string">'SlaTargetResolutionTime': None, class=class="hl-string">"hl-comment"># Requires parsing SLA policies, complex
                        class="hl-string">'IsSlaBreached': ticket_metrics.get(class="hl-string">'sla_breach_at') is not None,
                        class="hl-string">'ServiceRequestResolutionTime': format_duration(resolution_time_seconds)
                    }

                    for event in audit.get(class="hl-string">'events', []):
                        event_type = event.get(class="hl-string">'type')
                        class=class="hl-string">"hl-comment"># Service Request Created
                        if event_type == class="hl-string">'Create' and event.get(class="hl-string">'field_name') == class="hl-string">'id':
                            new_event = base_event.copy()
                            new_event[class="hl-string">'ActivityName'] = class="hl-string">'Service Request Created'
                            event_log.append(new_event)

                        class=class="hl-string">"hl-comment"># Initial Acknowledgment Sent (Proxy by Notification event)
                        if event_type == class="hl-string">'Notification':
                            new_event = base_event.copy()
                            new_event[class="hl-string">'ActivityName'] = class="hl-string">'Initial Acknowledgment Sent'
                            event_log.append(new_event)

                        class=class="hl-string">"hl-comment"># Request Categorized And Prioritized, Assigned, Status Changes
                        if event_type == class="hl-string">'Change':
                            field = event.get(class="hl-string">'field_name')
                            if field in [class="hl-string">'type', class="hl-string">'priority', class="hl-string">'custom_field_[your_category_field_id]']:
                                new_event = base_event.copy()
                                new_event[class="hl-string">'ActivityName'] = class="hl-string">'Request Categorized And Prioritized'
                                event_log.append(new_event)
                            
                            if field == class="hl-string">'assignee_id':
                                new_event = base_event.copy()
                                new_event[class="hl-string">'ActivityName'] = class="hl-string">'Request Assigned To Agent'
                                new_event[class="hl-string">'AssignedAgent'] = get_user_name(event.get(class="hl-string">'value'), users_cache, session)
                                event_log.append(new_event)

                            if field == class="hl-string">'group_id':
                                new_event = base_event.copy()
                                new_event[class="hl-string">'ActivityName'] = class="hl-string">'Internal Escalation Triggered'
                                event_log.append(new_event)

                            if field == class="hl-string">'status':
                                new_status = event.get(class="hl-string">'value')
                                if new_status == class="hl-string">'pending':
                                    new_event = base_event.copy()
                                    new_event[class="hl-string">'ActivityName'] = class="hl-string">'Information Requested From Customer'
                                    event_log.append(new_event)
                                elif new_status == class="hl-string">'solved':
                                    new_event = base_event.copy()
                                    new_event[class="hl-string">'ActivityName'] = class="hl-string">'Service Request Resolved'
                                    event_log.append(new_event)
                                    class=class="hl-string">"hl-comment"># Satisfaction Survey Sent (Proxy: occurs after solve)
                                    solve_time = datetime.datetime.fromisoformat(audit_created_at.replace(class="hl-string">'Z', class="hl-string">'+00:00'))
                                    survey_time = solve_time + datetime.timedelta(hours=1)
                                    survey_event = new_event.copy()
                                    survey_event[class="hl-string">'ActivityName'] = class="hl-string">'Satisfaction Survey Sent'
                                    survey_event[class="hl-string">'StartTime'] = survey_time.isoformat().replace(class="hl-string">'+00:00', class="hl-string">'Z')
                                    event_log.append(survey_event)
                                elif new_status == class="hl-string">'closed':
                                    new_event = base_event.copy()
                                    new_event[class="hl-string">'ActivityName'] = class="hl-string">'Service Request Closed'
                                    event_log.append(new_event)
                                elif new_status == class="hl-string">'open' and event.get(class="hl-string">'previous_value') in [class="hl-string">'solved', class="hl-string">'pending']:
                                    activity = class="hl-string">'Service Request Reopened' if event.get(class="hl-string">'previous_value') == class="hl-string">'solved' else class="hl-string">'Customer Responded'
                                    new_event = base_event.copy()
                                    new_event[class="hl-string">'ActivityName'] = activity
                                    event_log.append(new_event)
                            
                            if field == class="hl-string">'satisfaction_score':
                                new_event = base_event.copy()
                                new_event[class="hl-string">'ActivityName'] = class="hl-string">'Satisfaction Rating Received'
                                event_log.append(new_event)

                        class=class="hl-string">"hl-comment"># First Agent Public Reply Sent & Customer Responded
                        if event_type == class="hl-string">'Comment':
                            author_id = event.get(class="hl-string">'author_id')
                            author_details_response = session.get(fclass="hl-string">'{BASE_URL}/users/{author_id}.json')
                            author_role = author_details_response.json().get(class="hl-string">'user',{}).get(class="hl-string">'role', class="hl-string">'end-user') if author_details_response.ok else class="hl-string">'end-user'

                            if author_role in [class="hl-string">'agent', class="hl-string">'admin'] and event.get(class="hl-string">'public') and not first_agent_reply_sent:
                                new_event = base_event.copy()
                                new_event[class="hl-string">'ActivityName'] = class="hl-string">'First Agent Public Reply Sent'
                                event_log.append(new_event)
                                first_agent_reply_sent = True

                class=class="hl-string">"hl-comment"># SLA Breach Occurred
                if ticket_metrics.get(class="hl-string">'sla_breach_at'):
                    sla_breach_time = ticket_metrics.get(class="hl-string">'sla_breach_at')
                    new_event = base_event.copy()
                    new_event[class="hl-string">'ActivityName'] = class="hl-string">'SLA Breach Occurred'
                    new_event[class="hl-string">'StartTime'] = sla_breach_time
                    event_log.append(new_event)

            url = data.get(class="hl-string">'after_url')
            if not data.get(class="hl-string">'end_of_stream', False):
                time.sleep(1) class=class="hl-string">"hl-comment"># Be a good API citizen
            else:
                url = None

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

    class=class="hl-string">"hl-comment"># Write to CSV
    print(fclass="hl-string">'Writing {len(event_log)} events to {CSV_FILENAME}...')
    with open(CSV_FILENAME, class="hl-string">'w', newline=class="hl-string">'', encoding=class="hl-string">'utf-8') as csvfile:
        writer = csv.DictWriter(csvfile, fieldnames=CSV_HEADERS)
        writer.writeheader()
        class=class="hl-string">"hl-comment"># Sort events by ticket and then by time for chronological order
        sorted_log = sorted(event_log, key=lambda x: (x[class="hl-string">'ServiceRequest'], x[class="hl-string">'StartTime']))
        for row in sorted_log:
            writer.writerow(row)
    print(class="hl-string">'Extraction complete.')

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

Etapas

Prepare o Acesso à API do Zendesk: Faça login como administrador. Vá até a Central de Administração > Apps e integrações > APIs > API do Zendesk. Na aba Configurações, ative o "Acesso por token". Clique em "Adicionar token de API" para criar um novo. Copie o token gerado e guarde-o em local seguro.
Configure o Ambiente Python: Verifique se o Python 3.6+ está instalado. Instale a biblioteca requests via linha de comando usando: pip install requests.
Configure o Script Python: Salve o script fornecido como extract_zendesk_log.py. Abra-o em um editor de texto e preencha as variáveis no topo: ZENDESK_SUBDOMAIN, ZENDESK_EMAIL e API_TOKEN com seus dados.
Defina o Período de Extração: Localize a variável START_TIMESTAMP no script. Este valor define a data inicial da extração (em formato Unix epoch). Para uma análise inicial, recomendamos os ùltimos 3 a 6 meses.
Execute o Script: No terminal, navegue até a pasta do arquivo e execute: python extract_zendesk_log.py.
Acompanhe a Execução: O script exibirá o progresso e a quantidade de tickets processados. O tempo total dependerá do volume de dados e dos limites de taxa da API do Zendesk. O script já trata automaticamente as pausas por rate limit.
Obtenha o Log de Eventos: Ao finalizar, o arquivo zendesk_event_log.csv será criado na mesma pasta, contendo o log estruturado para análise.
Prepare o Upload: Abra o arquivo para conferir se as colunas obrigatórias estão corretas: ServiceRequest, ActivityName, StartTime, SourceSystem e LastDataUpdate. Agora, o arquivo está pronto para ser carregado na ferramenta de Process Mining.

Configuração

Credenciais de API: O script exige um subdomínio válido do Zendesk, o e-mail de um agente ou administrador e um token de API ativo. O usuário vinculado às credenciais deve ter permissão para ler tickets, auditorias de tickets, usuários e métricas de tickets.
Intervalo de Datas: A data de início da extração é controlada pela variável START_TIMESTAMP no script, que deve ser um timestamp Unix epoch. Recomendamos começar com um período curto, como 3 meses, para validar a saída e o desempenho do script antes de tentar uma coleta maior de dados históricos.
API de Exportação Incremental: Esta solução utiliza a API de Exportação Incremental do Zendesk. Este é o método mais eficiente e indicado para buscar um grande volume de tickets, pois foi projetado para exportação de dados em massa e evita problemas comuns de paginação.
Desempenho e Limites de Taxa (Rate Limiting): O Zendesk impõe limites de taxa de API que variam conforme o plano de assinatura. O script possui uma lógica integrada para pausar a execução quando um limite é atingido, com base no cabeçalho Retry-After retornado pela API. Em instâncias muito grandes, a extração pode levar várias horas.
Pré-requisitos: Este método de extração requer um ambiente Python 3.6+ funcional e a biblioteca externa requests. O acesso de administrador à instância de destino do Zendesk é necessário para gerar o token de API obrigatório.

a Consulta de Exemplo python

import requests
import json
import time
import datetime
import csv

class=class="hl-string">"hl-comment"># --- Configuration ---
class=class="hl-string">"hl-comment"># Replace with your Zendesk details
ZENDESK_SUBDOMAIN = class="hl-string">'[your_zendesk_subdomain]'
ZENDESK_EMAIL = class="hl-string">'[your_zendesk_login_email]'
API_TOKEN = class="hl-string">'[your_zendesk_api_token]'

class=class="hl-string">"hl-comment"># Set the start time for the export (Unix epoch timestamp)
class=class="hl-string">"hl-comment"># Example: 1672531200 is Jan 1, 2023 00:00:00 GMT
START_TIMESTAMP = 1672531200

class=class="hl-string">"hl-comment"># --- Script --- 

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

CSV_FILENAME = class="hl-string">'zendesk_event_log.csv'
CSV_HEADERS = [
    class="hl-string">'ServiceRequest', class="hl-string">'ActivityName', class="hl-string">'StartTime', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate',
    class="hl-string">'AssignedAgent', class="hl-string">'ServiceRequestType', class="hl-string">'Priority', class="hl-string">'CommunicationChannel',
    class="hl-string">'SlaTargetResolutionTime', class="hl-string">'IsSlaBreached', class="hl-string">'ServiceRequestResolutionTime'
]

def get_user_name(user_id, users_cache, session):
    if user_id in users_cache:
        return users_cache[user_id]
    if user_id is None:
        return None
    try:
        response = session.get(fclass="hl-string">'{BASE_URL}/users/{user_id}.json')
        response.raise_for_status()
        user_name = response.json().get(class="hl-string">'user', {}).get(class="hl-string">'name')
        users_cache[user_id] = user_name
        return user_name
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">'Warning: Could not fetch user {user_id}. Error: {e}')
        users_cache[user_id] = str(user_id)
        return str(user_id)

def format_duration(seconds):
    if seconds is None:
        return None
    return str(datetime.timedelta(seconds=seconds))

def main():
    session = requests.Session()
    session.auth = AUTH
    users_cache = {}
    event_log = []

    class=class="hl-string">"hl-comment"># Fetch tickets using the incremental export API
    url = fclass="hl-string">'{BASE_URL}/incremental/tickets/cursor.json?start_time={START_TIMESTAMP}'
    ticket_count = 0

    while url:
        print(fclass="hl-string">'Fetching tickets from: {url}')
        try:
            response = session.get(url)

            if response.status_code == 429:
                retry_after = int(response.headers.get(class="hl-string">'Retry-After', 60))
                print(fclass="hl-string">'Rate limit hit. Retrying after {retry_after} seconds.')
                time.sleep(retry_after)
                continue

            response.raise_for_status()
            data = response.json()
            tickets = data.get(class="hl-string">'tickets', [])

            for ticket in tickets:
                ticket_count += 1
                ticket_id = ticket[class="hl-string">'id']
                print(fclass="hl-string">'Processing ticket {ticket_id} ({ticket_count} total)...')

                class=class="hl-string">"hl-comment"># Fetch ticket metrics for SLA and resolution time
                metrics_response = session.get(fclass="hl-string">'{BASE_URL}/tickets/{ticket_id}/metrics.json')
                ticket_metrics = metrics_response.json().get(class="hl-string">'ticket_metric', {}) if metrics_response.ok else {}

                resolution_time_seconds = ticket_metrics.get(class="hl-string">'full_resolution_time_in_minutes', {}).get(class="hl-string">'business')
                if resolution_time_seconds:
                    resolution_time_seconds *= 60

                class=class="hl-string">"hl-comment"># Fetch ticket audits for events
                audits_url = fclass="hl-string">'{BASE_URL}/tickets/{ticket_id}/audits.json'
                audits_response = session.get(audits_url)
                audits = audits_response.json().get(class="hl-string">'audits', []) if audits_response.ok else []

                first_agent_reply_sent = False

                for audit in audits:
                    audit_created_at = audit[class="hl-string">'created_at']
                    base_event = {
                        class="hl-string">'ServiceRequest': ticket_id,
                        class="hl-string">'StartTime': audit_created_at,
                        class="hl-string">'SourceSystem': SOURCE_SYSTEM,
                        class="hl-string">'LastDataUpdate': LAST_DATA_UPDATE,
                        class="hl-string">'AssignedAgent': get_user_name(ticket.get(class="hl-string">'assignee_id'), users_cache, session),
                        class="hl-string">'ServiceRequestType': ticket.get(class="hl-string">'type'),
                        class="hl-string">'Priority': ticket.get(class="hl-string">'priority'),
                        class="hl-string">'CommunicationChannel': ticket.get(class="hl-string">'via', {}).get(class="hl-string">'channel'),
                        class="hl-string">'SlaTargetResolutionTime': None, class=class="hl-string">"hl-comment"># Requires parsing SLA policies, complex
                        class="hl-string">'IsSlaBreached': ticket_metrics.get(class="hl-string">'sla_breach_at') is not None,
                        class="hl-string">'ServiceRequestResolutionTime': format_duration(resolution_time_seconds)
                    }

                    for event in audit.get(class="hl-string">'events', []):
                        event_type = event.get(class="hl-string">'type')
                        class=class="hl-string">"hl-comment"># Service Request Created
                        if event_type == class="hl-string">'Create' and event.get(class="hl-string">'field_name') == class="hl-string">'id':
                            new_event = base_event.copy()
                            new_event[class="hl-string">'ActivityName'] = class="hl-string">'Service Request Created'
                            event_log.append(new_event)

                        class=class="hl-string">"hl-comment"># Initial Acknowledgment Sent (Proxy by Notification event)
                        if event_type == class="hl-string">'Notification':
                            new_event = base_event.copy()
                            new_event[class="hl-string">'ActivityName'] = class="hl-string">'Initial Acknowledgment Sent'
                            event_log.append(new_event)

                        class=class="hl-string">"hl-comment"># Request Categorized And Prioritized, Assigned, Status Changes
                        if event_type == class="hl-string">'Change':
                            field = event.get(class="hl-string">'field_name')
                            if field in [class="hl-string">'type', class="hl-string">'priority', class="hl-string">'custom_field_[your_category_field_id]']:
                                new_event = base_event.copy()
                                new_event[class="hl-string">'ActivityName'] = class="hl-string">'Request Categorized And Prioritized'
                                event_log.append(new_event)
                            
                            if field == class="hl-string">'assignee_id':
                                new_event = base_event.copy()
                                new_event[class="hl-string">'ActivityName'] = class="hl-string">'Request Assigned To Agent'
                                new_event[class="hl-string">'AssignedAgent'] = get_user_name(event.get(class="hl-string">'value'), users_cache, session)
                                event_log.append(new_event)

                            if field == class="hl-string">'group_id':
                                new_event = base_event.copy()
                                new_event[class="hl-string">'ActivityName'] = class="hl-string">'Internal Escalation Triggered'
                                event_log.append(new_event)

                            if field == class="hl-string">'status':
                                new_status = event.get(class="hl-string">'value')
                                if new_status == class="hl-string">'pending':
                                    new_event = base_event.copy()
                                    new_event[class="hl-string">'ActivityName'] = class="hl-string">'Information Requested From Customer'
                                    event_log.append(new_event)
                                elif new_status == class="hl-string">'solved':
                                    new_event = base_event.copy()
                                    new_event[class="hl-string">'ActivityName'] = class="hl-string">'Service Request Resolved'
                                    event_log.append(new_event)
                                    class=class="hl-string">"hl-comment"># Satisfaction Survey Sent (Proxy: occurs after solve)
                                    solve_time = datetime.datetime.fromisoformat(audit_created_at.replace(class="hl-string">'Z', class="hl-string">'+00:00'))
                                    survey_time = solve_time + datetime.timedelta(hours=1)
                                    survey_event = new_event.copy()
                                    survey_event[class="hl-string">'ActivityName'] = class="hl-string">'Satisfaction Survey Sent'
                                    survey_event[class="hl-string">'StartTime'] = survey_time.isoformat().replace(class="hl-string">'+00:00', class="hl-string">'Z')
                                    event_log.append(survey_event)
                                elif new_status == class="hl-string">'closed':
                                    new_event = base_event.copy()
                                    new_event[class="hl-string">'ActivityName'] = class="hl-string">'Service Request Closed'
                                    event_log.append(new_event)
                                elif new_status == class="hl-string">'open' and event.get(class="hl-string">'previous_value') in [class="hl-string">'solved', class="hl-string">'pending']:
                                    activity = class="hl-string">'Service Request Reopened' if event.get(class="hl-string">'previous_value') == class="hl-string">'solved' else class="hl-string">'Customer Responded'
                                    new_event = base_event.copy()
                                    new_event[class="hl-string">'ActivityName'] = activity
                                    event_log.append(new_event)
                            
                            if field == class="hl-string">'satisfaction_score':
                                new_event = base_event.copy()
                                new_event[class="hl-string">'ActivityName'] = class="hl-string">'Satisfaction Rating Received'
                                event_log.append(new_event)

                        class=class="hl-string">"hl-comment"># First Agent Public Reply Sent & Customer Responded
                        if event_type == class="hl-string">'Comment':
                            author_id = event.get(class="hl-string">'author_id')
                            author_details_response = session.get(fclass="hl-string">'{BASE_URL}/users/{author_id}.json')
                            author_role = author_details_response.json().get(class="hl-string">'user',{}).get(class="hl-string">'role', class="hl-string">'end-user') if author_details_response.ok else class="hl-string">'end-user'

                            if author_role in [class="hl-string">'agent', class="hl-string">'admin'] and event.get(class="hl-string">'public') and not first_agent_reply_sent:
                                new_event = base_event.copy()
                                new_event[class="hl-string">'ActivityName'] = class="hl-string">'First Agent Public Reply Sent'
                                event_log.append(new_event)
                                first_agent_reply_sent = True

                class=class="hl-string">"hl-comment"># SLA Breach Occurred
                if ticket_metrics.get(class="hl-string">'sla_breach_at'):
                    sla_breach_time = ticket_metrics.get(class="hl-string">'sla_breach_at')
                    new_event = base_event.copy()
                    new_event[class="hl-string">'ActivityName'] = class="hl-string">'SLA Breach Occurred'
                    new_event[class="hl-string">'StartTime'] = sla_breach_time
                    event_log.append(new_event)

            url = data.get(class="hl-string">'after_url')
            if not data.get(class="hl-string">'end_of_stream', False):
                time.sleep(1) class=class="hl-string">"hl-comment"># Be a good API citizen
            else:
                url = None

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

    class=class="hl-string">"hl-comment"># Write to CSV
    print(fclass="hl-string">'Writing {len(event_log)} events to {CSV_FILENAME}...')
    with open(CSV_FILENAME, class="hl-string">'w', newline=class="hl-string">'', encoding=class="hl-string">'utf-8') as csvfile:
        writer = csv.DictWriter(csvfile, fieldnames=CSV_HEADERS)
        writer.writeheader()
        class=class="hl-string">"hl-comment"># Sort events by ticket and then by time for chronological order
        sorted_log = sorted(event_log, key=lambda x: (x[class="hl-string">'ServiceRequest'], x[class="hl-string">'StartTime']))
        for row in sorted_log:
            writer.writerow(row)
    print(class="hl-string">'Extraction complete.')

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

Etapas

Navegue até o Zendesk Explore: Faça login no seu Zendesk e abra o produto Explore clicando no ícone do seletor de produtos na barra superior.
Crie uma Nova Consulta: No Explore, clique no ícone de Consultas (Queries) na barra lateral esquerda e, em seguida, no botão "Nova consulta" (New query) no canto superior direito.
Selecione o Conjunto de Dados: Na janela "Escolha um conjunto de dados", selecione Support: Tickets. Este conjunto contém os principais atributos dos tickets e os timestamps dos eventos.
Adicione Métricas: No construtor de consultas, vá ao painel "Métricas" e clique em "Adicionar". Selecione COUNT(Tickets). Isso ajuda a validar o volume de dados.
Adicione Atributos às Linhas: Vá ao painel "Linhas" (Rows) e clique em "Adicionar". Insira os seguintes atributos, que formarão as colunas base da sua exportação:
- Ticket ID (Seu Identificador de Caso, ServiceRequest)
- Assignee name (AssignedAgent)
- Ticket type (ServiceRequestType)
- Ticket priority (Priority)
- Ticket channel (CommunicationChannel)
- SLA resolution time (SlaTargetResolutionTime)
- SLA breach status (IsSlaBreached)
- Full resolution time (min) (ServiceRequestResolutionTime)
Adicione Timestamps de Atividade às Linhas: Adicione os seguintes timestamps ao painel "Linhas". Cada um representa uma atividade potencial. Alguns exigem a criação de atributos calculados personalizados.
- Ticket created - Timestamp: Para Solicitação de Serviço Criada e Reconhecimento Inicial Enviado.
- Ticket assigned - Timestamp: Para Solicitação Atribuída ao Agente.
- First reply time - Timestamp: Para Primeira Resposta Pùblica do Agente Enviada.
- Ticket solved - Timestamp: Para Solicitação Resolvida e Pesquisa de Satisfação Enviada.
- Ticket reopened - Timestamp: Para Solicitação Reaberta.
- Satisfaction rating received - Timestamp: Para Avaliação de Satisfação Recebida.
- Ticket closed - Timestamp: Para Solicitação de Serviço Fechada.
Crie Atributos Calculados para Outras Atividades: Algumas atividades dependem de alterações de campos específicos. Vá ao menu de Cálculos (ícone de calculadora) e selecione "Atributo calculado padrão". Crie um para cada atividade abaixo (ajuste os nomes dos campos conforme sua instância):
- Nome: Timestamp - Categorizado e Priorizado. Fórmula: IF ([Changes - Field name] = "priority" OR [Changes - Field name] = "type") THEN [Update - Timestamp] ENDIF. Defina o agregador como MIN.
- Nome: Timestamp - Informação Solicitada. Fórmula: IF ([Changes - Field name] = "status" AND [Changes - New value] = "pending") THEN [Update - Timestamp] ENDIF. Defina como MIN.
- Nome: Timestamp - Cliente Respondeu. Fórmula: IF ([Changes - Field name] = "status" AND [Changes - Previous value] = "pending" AND [Changes - New value] = "open") THEN [Update - Timestamp] ENDIF. Defina como MIN.
- Nome: Timestamp - Escalonado. Fórmula: IF ([Changes - Field name] = "group") THEN [Update - Timestamp] ENDIF. Defina como MIN.
- Nome: Timestamp - Quebra de SLA. Fórmula: IF ([SLA breach status]=TRUE) THEN [SLA update - Timestamp] ENDIF. Defina como MIN.
Filtre os Dados: No painel "Filtros", adicione um filtro para Ticket created - Date e selecione um intervalo (ex: ùltimos 3 a 6 meses).
Execute e Exporte o Relatório: Clique em "Salvar" e, quando os dados aparecerem, clique em "Exportar" (Export) e escolha CSV ou Excel.
Transforme para Formato de Log de Eventos: O arquivo exportado estará em formato "largo". Você deve transformá-lo em formato "longo" para Process Mining usando ferramentas como o Power Query do Excel (função Unpivot), Python ou similares.
- Para cada linha (ticket), crie novas linhas para cada coluna de timestamp preenchida.
- A tabela final deve conter colunas como ServiceRequest, ActivityName, StartTime, além dos outros atributos que serão duplicados para cada atividade daquela solicitação.

Configuração

Conjunto de Dados (Dataset): O conjunto principal a ser utilizado é o Support: Tickets. Ele permite acessar a maioria das propriedades dos tickets e os principais timestamps em uma ùnica consulta.
Permissões: Você precisa de, no mínimo, uma função de Editor ou Administrador no Zendesk Explore para criar e salvar consultas.
Intervalo de Datas: É fundamental definir um filtro de intervalo de datas em Ticket created - Date. Recomendamos um período de 3 a 6 meses para equilibrar a profundidade dos insights com o desempenho do sistema. Exportar milhões de tickets pode ser lento ou resultar em falhas.
Filtros de Consulta: Considere adicionar filtros para propriedades específicas, como Ticket brand, Ticket form ou Ticket group, para focar a análise em um serviço ou equipe em particular.
Atributos Calculados: Este método depende muito da criação de atributos calculados padrão para capturar timestamps de eventos que não são atributos nativos, como alterações de status ou escalações. Certifique-se de ter as permissões necessárias para criar esses atributos.

a Consulta de Exemplo config

This extraction is configured through the Zendesk Explore graphical user interface. There is no single script to execute. The configuration below outlines the components to add in the query builder.

**Dataset**: `Support: Tickets`

**Metrics**:
1.  `COUNT(Tickets)`

**Rows (Attributes)**:
1.  `Ticket ID`
2.  `Assignee name`
3.  `Ticket type`
4.  `Ticket priority`
5.  `Ticket channel`
6.  `SLA resolution time`
7.  `SLA breach status`
8.  `Full resolution time (min)`
9.  `MIN(Ticket created - Timestamp)`
10. `MIN(Ticket assigned - Timestamp)`
11. `MIN(First reply time - Timestamp)`
12. `MIN(Ticket solved - Timestamp)`
13. `MIN(Ticket reopened - Timestamp)`
14. `MIN(Satisfaction rating received - Timestamp)`
15. `MIN(Ticket closed - Timestamp)`
16. `MIN(Timestamp - Categorized and Prioritized)` (Custom calculated attribute)
17. `MIN(Timestamp - Info Requested)` (Custom calculated attribute)
18. `MIN(Timestamp - Customer Responded)` (Custom calculated attribute)
19. `MIN(Timestamp - Escalated)` (Custom calculated attribute)
20. `MIN(Timestamp - SLA Breach)` (Custom calculated attribute)

**Filters**:
1.  `Ticket created - Date`: Select a date range (e.g., last 180 days)

**Standard Calculated Attribute Formulas**:
*   `Timestamp - Categorized and Prioritized`: `IF ([Changes - Field name] = "priority" OR [Changes - Field name] = "type") THEN [Update - Timestamp] ENDIF`
*   `Timestamp - Info Requested`: `IF ([Changes - Field name] = "status" AND [Changes - New value] = "pending") THEN [Update - Timestamp] ENDIF`
*   `Timestamp - Customer Responded`: `IF ([Changes - Field name] = "status" AND [Changes - Previous value] = "pending" AND [Changes - New value] = "open") THEN [Update - Timestamp] ENDIF`
*   `Timestamp - Escalated`: `IF ([Changes - Field name] = "group") THEN [Update - Timestamp] ENDIF`
*   `Timestamp - SLA Breach`: `IF ([SLA breach status]=TRUE) THEN [SLA update - Timestamp] ENDIF`

Seu Template de Dados de Atendimento ao Cliente

Seu Template de Dados de Atendimento ao Cliente

Atributos de Atendimento ao Cliente

Atividades de Atendimento ao Cliente

Guias de Extração

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

Etapas

Configuração

a Consulta de Exemplo config

Script Python usando a API REST do Zendesk Support

Etapas

Configuração

a Consulta de Exemplo python

API de Exportações Incrementais do Zendesk para dados em massa

Etapas

Configuração

a Consulta de Exemplo python

Conector de ferramenta de ETL de terceiros para o Zendesk

Etapas

Configuração

a Consulta de Exemplo config

Pronto para Começar?

Elimine Gargalos no Atendimento e Aumente o CSAT

Seu Template de Dados de Atendimento ao Cliente

Seu Template de Dados de Atendimento ao Cliente

Atributos de Atendimento ao Cliente

Atividades de Atendimento ao Cliente

Guias de Extração

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

Etapas

Configuração

a Consulta de Exemplo config

Script Python usando a API REST do Zendesk Support

Etapas

Configuração

a Consulta de Exemplo python

API de Exportações Incrementais do Zendesk para dados em massa

Etapas

Configuração

a Consulta de Exemplo python

Conector de ferramenta de ETL de terceiros para o Zendesk

Etapas

Configuração

a Consulta de Exemplo config

Valorizamos sua privacidade

Pronto para Começar?

Elimine Gargalos no Atendimento e Aumente o CSAT