Seu Template de Dados para Gestão de Solicitações
Seu Template de Dados para Gestão de Solicitações
- Atributos recomendados para análise abrangente
- Principais atividades de solicitação de serviço para rastrear
- Guia de extração para dados do Zendesk Support
Atributos de gestão de solicitações de serviço
| Nome | Descrição | ||
|---|---|---|---|
|
Atividade
ActivityName
|
O nome da atividade de negócio ou evento ocorrido em uma solicitação de serviço. | ||
|
Descrição
A Atividade representa uma etapa ou evento distinto no ciclo de vida da solicitação de serviço, como 'Solicitação de Serviço Criada', 'Solicitação Atribuída ao Agente' ou 'Solicitação de Serviço Resolvida'. Essas atividades são derivadas de alterações registradas no log de auditoria do ticket do Zendesk, que rastreia modificações em campos como status, responsável, prioridade e a adição de comentários. A análise das atividades é o cerne do Process Mining. Ela permite a visualização do mapa do processo, a identificação de gargalos entre as etapas e a análise de loops de retrabalho. Ao compreender a sequência e a frequência das atividades, as organizações podem identificar ineficiências e oportunidades de melhoria de processos.
Por que é importante
Este atributo define as etapas do processo, permitindo a visualização de mapas de processos e a análise do fluxo, variações e conformidade do processo.
Onde obter
Isso é derivado conceitualmente de eventos registrados na API de Auditoria de Tickets do Zendesk. Por exemplo, uma mudança no campo 'status' de 'novo' para 'aberto' pode ser mapeada para uma atividade como 'Solicitação Triada'.
Exemplos
Solicitação de Serviço CriadaAgente ReatribuídoSolicitação de Serviço Resolvida
|
|||
|
Hora de Início
EventTimestamp
|
A data e hora precisas em que a atividade ocorreu. | ||
|
Descrição
Event Timestamp, ou Hora de Início, registra o momento exato em que uma atividade ocorreu. Captura, por exemplo, quando um agente foi atribuído, uma resposta pública foi enviada ou o status mudou para 'Resolvido'. Esses dados temporais vêm do log de auditoria do ticket. Este atributo é crítico para qualquer análise temporal. É usado para ordenar eventos, calcular a duração entre atividades, medir tempos de espera e o tempo de ciclo total do caso. É fundamental para identificar gargalos e avaliar o desempenho em relação a metas como SLAs.
Por que é importante
Este timestamp ordena os eventos cronologicamente e é essencial para todas as análises de duração, desempenho e gargalos.
Onde obter
Zendesk Ticket Audits API, campo 'created_at' para cada evento de auditoria.
Exemplos
2023-10-26T10:00:00Z2023-10-26T10:15:30Z2023-10-27T14:20:10Z
|
|||
|
ID da Solicitação de Serviço
ServiceRequestId
|
O identificador exclusivo para cada ticket de solicitação de serviço no Zendesk. | ||
|
Descrição
O ID da Solicitação de Serviço, frequentemente chamado de Ticket ID no Zendesk, serve como a chave primária de cada caso. Ele vincula todas as atividades, comentários e mudanças de status, desde a criação da solicitação até o fechamento. Isso permite um rastreamento completo de ponta a ponta do ciclo de vida de uma única solicitação. Na análise de Process Mining, esse atributo é fundamental. Ele define o caso, permitindo a reconstrução dos fluxos de processo, a identificação de variantes e o cálculo de métricas de caso, como o tempo de ciclo. Cada evento no conjunto de dados deve estar associado a um ID de Solicitação de Serviço para que seu contexto no processo geral seja compreendido.
Por que é importante
Este é o identificador de caso essencial que conecta todos os eventos na jornada de uma solicitação de serviço, permitindo a análise do processo de ponta a ponta.
Onde obter
Zendesk Tickets API, campo 'id'.
Exemplos
102451024610247
|
|||
|
Sistema de Origem
SourceSystem
|
Indica de qual sistema os dados foram extraídos. | ||
|
Descrição
Este atributo especifica a origem dos dados da solicitação de serviço. Para esta visão de processo, o valor será consistentemente 'Zendesk Support', identificando-o como o sistema de registro de todas as atividades de gestão de serviços. Em ambientes com múltiplos sistemas integrados, este campo é crucial para a linhagem de dados e solução de problemas. Ele garante que as análises estejam corretamente delimitadas ao sistema pretendido e ajuda a diferenciar os dados quando mesclados de várias fontes.
Por que é importante
Identifica o sistema de origem dos dados, garantindo a linhagem e evitando confusão ao combinar dados de múltiplos sistemas.
Onde obter
Este é um valor estático ('Zendesk Support') adicionado durante a extração e transformação dos dados.
Exemplos
Zendesk Support
|
|||
|
Última Atualização de Dados
LastDataUpdate
|
O timestamp que indica a última vez que os dados foram atualizados a partir do sistema de origem. | ||
|
Descrição
Este atributo registra a data e a hora da extração de dados mais recente do Zendesk Support. Ele fornece contexto sobre a atualidade dos dados analisados, garantindo que os usuários saibam quão recente é a visão do processo. Para monitoramento contínuo e criação de dashboards, essa informação é vital. Ela permite que analistas e usuários de negócio entendam se estão vendo dados em tempo quase real ou um recorte de um período anterior, o que afeta a validade das suas conclusões.
Por que é importante
Fornece contexto crucial sobre a atualização dos dados, permitindo que os usuários saibam quão recente é a análise.
Onde obter
Este é um campo de metadados gerado e carimbado no conjunto de dados no momento da extração dos dados.
Exemplos
2023-10-27T08:00:00Z
|
|||
|
Canal de Solicitação
RequestChannel
|
O canal pelo qual a solicitação de serviço foi enviada (ex: E-mail, Formulário Web, Telefone). | ||
|
Descrição
Este atributo identifica a fonte de envio da solicitação de serviço. O Zendesk captura como um ticket foi criado, seja via e-mail, portal web, integração de API, chat ou outros canais. Isso fornece contexto sobre o método de interação do cliente. O Canal de Solicitação é uma dimensão poderosa para análise. Ele alimenta o dashboard de 'Eficiência do Canal de Solicitação', permitindo comparações de tempos de resolução, avaliações de satisfação e taxas de retrabalho entre diferentes canais. Isso ajuda as empresas a otimizarem seus canais de suporte e direcionarem os usuários para os mais eficientes.
Por que é importante
Ajuda a analisar a eficiência e os resultados de diferentes canais de suporte, permitindo melhorias direcionadas.
Onde obter
Zendesk Tickets API, objeto 'via' e sua propriedade 'channel'.
Exemplos
webe-mailapichat
|
|||
|
Equipe designada
AssignedTeam
|
A equipe ou grupo de suporte atribuído à solicitação de serviço. | ||
|
Descrição
Este atributo indica qual equipe ou grupo dentro da organização de suporte é responsável pela solicitação de serviço. No Zendesk, eles são conhecidos como 'Grupos'. Os tickets geralmente são atribuídos a um grupo antes de serem assumidos por um agente individual. Analisar pela Equipe Atribuída é essencial para entender o desempenho e a carga de trabalho a nível de equipe. Ajuda a responder quais equipes lidam com quais tipos de solicitações, seus tempos médios de resolução e suas taxas de adesão ao SLA. Esta é uma dimensão primária para o dashboard de Desempenho de Agentes e Equipes.
Por que é importante
Permite analisar o desempenho da equipe, o equilíbrio da carga de trabalho e a eficiência do roteamento entre diferentes grupos de suporte.
Onde obter
Zendesk Groups API, unindo o 'group_id' da resposta da API de Tickets.
Exemplos
Suporte Nível 1Suporte TécnicoFaturamento
|
|||
|
Nome do Agente
AgentName
|
O nome do agente atribuído à solicitação de serviço no momento do evento. | ||
|
Descrição
Este atributo identifica o agente de suporte responsável pelo tratamento da solicitação de serviço. O agente atribuído pode mudar várias vezes ao longo do ciclo de vida do ticket, e este campo captura quem foi o responsável em cada etapa. O Nome do Agente é crítico para a análise de desempenho. Ele permite filtrar e segmentar dados para avaliar a distribuição de carga de trabalho, tempos de resolução por agente e a frequência de reatribuições. Isso auxilia na construção do dashboard de Desempenho de Agentes e Equipes e na compreensão das contribuições individuais para a eficiência geral do processo.
Por que é importante
Este atributo é vital para analisar o desempenho do agente, a distribuição da carga de trabalho e o impacto das reatribuições nos tempos de resolução.
Onde obter
Zendesk Users API, unindo o 'assignee_id' da resposta da API de Tickets.
Exemplos
Jane DoeJohn SmithEmily Jones
|
|||
|
Prioridade da Solicitação
RequestPriority
|
O nível de prioridade atribuído à solicitação, como Baixa, Normal, Alta ou Urgente. | ||
|
Descrição
Prioridade da Solicitação indica a urgência. Esse nível dita os tempos de resolução e as políticas de SLA aplicadas. Pode ser definida inicialmente pelo sistema ou usuário e alterada pelo agente. Este atributo é vital para segmentação e análise de causa raiz. Ajuda a verificar se chamados prioritários são de fato resolvidos mais rápido e é essencial para os dashboards de 'Tendências de Escalação' e 'Adesão ao SLA'.
Por que é importante
Permite segmentar as solicitações por urgência, o que é fundamental para analisar a conformidade com o SLA e garantir que problemas críticos sejam tratados prontamente.
Onde obter
Zendesk Tickets API, campo 'priority'.
Exemplos
BaixoNormalAltoUrgente
|
|||
|
Status da Solicitação
RequestStatus
|
O status da solicitação de serviço no momento do evento (ex: Novo, Aberto, Pendente). | ||
|
Descrição
Status da Solicitação representa o estado do ticket. O Zendesk possui status como Novo, Aberto, Pendente, Em Espera, Resolvido e Fechado. Mudanças aqui são os principais gatilhos para atividades no event log. Analisar o tempo em cada status é a base para identificar gargalos. Ajuda a ver onde os tickets travam (ex: muito tempo em 'Pendente') e é fundamental para descobrir loops de retrabalho.
Por que é importante
Rastrear o status é fundamental para entender o progresso da solicitação e identificar quanto tempo é gasto em estados de espera ou ativos.
Onde obter
Zendesk Tickets API, campo 'status'.
Exemplos
NovoAbertoPendenteResolvidoEncerrado
|
|||
|
Tags do ticket
TicketTags
|
Uma lista de tags aplicadas à solicitação de serviço para categorização e roteamento. | ||
|
Descrição
Tags são etiquetas flexíveis que podem ser adicionadas aos tickets manualmente pelos agentes ou automaticamente por meio de regras de negócio. Elas são usadas para adicionar contextos ou categorias específicas a um ticket que podem não ser abrangidos por campos padrão, como Tipo ou Prioridade. As tags são um atributo extremamente versátil para a análise de Process Mining. Elas podem ser usadas para filtrar cenários muito específicos, rastrear workflows personalizados ou identificar causas raiz. Por exemplo, uma tag 'VIP' poderia ser usada para analisar o processo de clientes importantes, ou uma tag 'product_bug' para rastrear o ciclo de vida de relatos de defeitos.
Por que é importante
Oferece uma forma flexível de filtrar os dados, permitindo análises aprofundadas em subprocessos específicos ou atributos de ticket não capturados em outros campos.
Onde obter
Zendesk Tickets API, campo 'tags'. Este é um array de strings.
Exemplos
consulta_vendasproblema_faturamentosolicitação_funcionalidadevip_customer
|
|||
|
Tipo de Serviço
ServiceType
|
A categoria ou tipo de solicitação de serviço (ex: Incidente, Pergunta, Problema, Tarefa). | ||
|
Descrição
O Tipo de Serviço categoriza a natureza da solicitação. O Zendesk utiliza um campo 'type' para distinguir entre diferentes tipos de interações de suporte. Essa classificação inicial ajuda no roteamento do ticket para a equipe correta e na aplicação dos processos adequados. Este atributo é essencial para filtragem e comparação. Ele permite que os analistas examinem os fluxos de processo para diferentes tipos de solicitações, que muitas vezes possuem caminhos de resolução e SLAs muito distintos. É uma dimensão fundamental para o dashboard de Desempenho de Agentes e Equipes para identificar quem é mais eficiente em tipos específicos de solicitações.
Por que é importante
Categoriza as solicitações para permitir análises separadas de diferentes processos, como incidentes versus dúvidas, que seguem caminhos únicos.
Onde obter
Zendesk Tickets API, campo 'type'.
Exemplos
perguntaincidenteproblematarefa
|
|||
|
Avaliação de Satisfação
SatisfactionRating
|
A pontuação de satisfação atribuída pelo solicitante após a resolução do ticket. | ||
|
Descrição
Este atributo captura o feedback do cliente sobre sua experiência de suporte, geralmente coletado via pesquisa após o ticket ser marcado como resolvido. As avaliações comuns são 'Bom' ou 'Ruim', às vezes acompanhadas de um comentário. A Avaliação de Satisfação é uma métrica de resultado crítica. Correlacionar padrões de processos com as pontuações de satisfação pode revelar quais comportamentos do processo geram clientes felizes ou insatisfeitos. Por exemplo, a análise pode mostrar que altas taxas de reatribuição ou longos tempos de resolução estão fortemente correlacionados com avaliações de satisfação negativas.
Por que é importante
Oferece um link direto entre a execução do processo e os resultados do cliente, ajudando a identificar quais comportamentos aumentam a satisfação.
Onde obter
Zendesk Tickets API, campo 'satisfaction_rating.score' ou 'satisfaction_rating.reason'.
Exemplos
BomRuimOfertado
|
|||
|
Contagem de Reatribuição de Agente
AgentReassignmentCount
|
O número total de vezes que uma solicitação foi reatribuída de um agente para outro. | ||
|
Descrição
Este atributo é um contador que aumenta cada vez que o campo 'assignee_id' de um ticket é alterado. Um alto número de reatribuições em um único ticket pode indicar diversos problemas de processo, como roteamento inicial incorreto, falta de conhecimento do agente ou solicitações complexas demais para um único agente. Esta é uma métrica fundamental para medir a eficiência do processo e suporta diretamente o KPI de 'Taxa de Reatribuição de Agentes'. A análise de casos com altas contagens de reatribuição pode revelar oportunidades para melhorar as regras de roteamento, o treinamento de agentes ou os recursos da base de conhecimento, garantindo que os tickets cheguem à pessoa certa mais rapidamente.
Por que é importante
Ajuda a quantificar as passagens de bastão internas e identifica fricções no processo, já que altas taxas de reatribuição costumam gerar atrasos e ineficiência.
Onde obter
Calculado pela contagem do número de alterações de 'assignee_id' na API de Auditoria do Zendesk para cada ticket.
Exemplos
013
|
|||
|
É Resolução no Primeiro Contato
IsFirstContactResolution
|
Um indicador que sinaliza se a solicitação foi resolvida pelo primeiro agente atribuído, sem reatribuições ou novas respostas do solicitante. | ||
|
Descrição
Resolução no Primeiro Contato (FCR) é uma métrica crucial que indica que o problema foi resolvido em uma única interação. Este atributo é um sinalizador booleano verdadeiro se o ticket foi resolvido pelo primeiro agente atribuído, sem reatribuições e com apenas uma resposta. Este atributo alimenta o KPI de 'Taxa de Resolução no Primeiro Contato'. Analisar casos de FCR bem-sucedidos serve como modelo de excelência. Já os casos que falham no FCR revelam oportunidades para treinamento de agentes, melhoria da base de conhecimento ou triagem inicial mais eficaz.
Por que é importante
Mede a capacidade de resolver problemas com eficiência em um único contato, o que impulsiona tanto a satisfação do cliente quanto a eficiência operacional.
Onde obter
Este é um atributo calculado complexo. Ele exige a análise do log de eventos de um ticket para verificar as reatribuições de agentes e o número de respostas públicas dos mesmos.
Exemplos
verdadeirofalse
|
|||
|
É Retrabalho
IsRework
|
Um indicador que é verdadeiro se a solicitação de serviço foi reaberta após ter sido resolvida. | ||
|
Descrição
Este sinalizador booleano identifica casos que passaram por retrabalho. Uma solicitação de serviço é geralmente considerada retrabalho se o seu status mudar de 'Resolvido' de volta para um estado aberto, indicando que a resolução inicial não foi suficiente e o cliente teve que retornar ao mesmo problema. Este atributo é essencial para calcular o KPI de 'Taxa de Retrabalho de Solicitações de Serviço' e para o dashboard de 'Análise de Atividade de Retrabalho e Reabertura'. Ao sinalizar os casos de 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 é importante
Identifica falhas no processo onde a resolução não foi final, destacando problemas de qualidade e eficiência que impactam a satisfação do cliente.
Onde obter
Calculado analisando a sequência de status de um ticket na API de Auditoria do Zendesk. Uma transição de 'resolvido' para 'aberto' indica retrabalho.
Exemplos
verdadeirofalse
|
|||
|
End Time
EndTime
|
A data e o horário exatos em que a atividade foi concluída. | ||
|
Descrição
O End Time marca o término de uma atividade. Para muitos eventos no Zendesk, a duração é instantânea, logo o End Time é idêntico ao Start Time. No entanto, para atividades baseadas em estados, como 'Solicitação em Espera', o End Time será registrado quando o ticket sair desse estado. Este atributo é essencial para calcular a duração de atividades específicas, ponto crucial para a análise de gargalos. Ao comparar o Start Time e o End Time, é possível medir diretamente o tempo de processamento, ajudando a identificar quais etapas são mais demoradas.
Por que é importante
Permite o cálculo das durações de atividades individuais, o que é fundamental para identificar gargalos e medir a eficiência de cada etapa.
Onde obter
Geralmente é o mesmo que o StartTime para eventos discretos. Para durações de status, é o timestamp do próximo evento que altera o status.
Exemplos
2023-10-26T10:00:00Z2023-10-26T10:15:30Z2023-10-27T14:20:10Z
|
|||
|
Nome da política de SLA
SlaPolicyName
|
O nome da política de Acordo de Nível de Serviço (SLA) aplicada à solicitação. | ||
|
Descrição
Este atributo identifica a política de SLA específica que rege os tempos de resposta e resolução para a solicitação de serviço. Uma política é geralmente determinada por fatores como prioridade, tipo de solicitação ou nível de assinatura do cliente. Conhecer a política de SLA aplicada é essencial para o dashboard de 'Adesão ao SLA e Análise de Violação'. Isso fornece o contexto necessário para avaliar o desempenho, já que diferentes políticas possuem metas distintas. Isso permite uma avaliação justa e precisa se um ticket cumpriu seus objetivos específicos de nível de serviço.
Por que é importante
Oferece contexto para a análise de SLA ao identificar quais metas foram aplicadas a cada chamado, permitindo relatórios precisos de conformidade.
Onde obter
Zendesk Ticket Metrics API. Os dados de SLA geralmente estão associados às métricas do ticket.
Exemplos
Urgente - Resposta em 1 horaPadrão - Resolução em 24 horasSLA de Cliente Premium
|
|||
|
Nome do Solicitante
RequestorName
|
O nome do usuário final ou cliente que enviou a solicitação de serviço. | ||
|
Descrição
Este atributo identifica o indivíduo que iniciou a solicitação de serviço. Vincular a solicitação a um cliente específico oferece uma visão centrada no usuário do processo de suporte. Na análise de processos, o solicitante pode ser usado para analisar padrões de clientes ou segmentos específicos. Por exemplo, pode-se investigar se certos clientes enfrentam tempos de resolução mais longos ou possuem taxas de retrabalho mais altas, o que poderia indicar problemas com um produto ou serviço utilizado por eles.
Por que é importante
Conecta o processo ao cliente, permitindo analisar problemas específicos, solicitações repetidas e níveis de satisfação.
Onde obter
Zendesk Users API, unindo o 'requester_id' da resposta da API de Tickets.
Exemplos
Alice JohnsonBob WilliamsCharlie Brown
|
|||
|
Organização do Solicitante
RequestorOrganization
|
A organização ou empresa à qual o solicitante pertence. | ||
|
Descrição
Este atributo vincula a solicitação de serviço a uma organização de cliente específica. Isso é particularmente relevante em cenários de suporte B2B, onde acordos de nível de serviço e contratos de suporte costumam ser definidos a nível organizacional. Analisar dados por organização permite uma visão de desempenho do suporte a nível de empresa. Pode ajudar a identificar organizações que geram um alto volume de tickets, enfrentam problemas recorrentes ou possuem baixas pontuações de satisfação. Isso é valioso para a gestão de contas e para identificar tendências gerais de saúde do cliente.
Por que é importante
Permite a análise de serviços B2B ao agrupar solicitações por empresa, o que é fundamental para gerir o relacionamento com o cliente e SLAs corporativos.
Onde obter
Zendesk Organizations API, unindo o 'organization_id' da resposta da API de Tickets.
Exemplos
Acme CorporationGlobal Tech Inc.Innovate Solutions
|
|||
|
SLA violado
IsSlaBreached
|
Um indicador que mostra se a solicitação de serviço violou qualquer uma de suas metas de SLA. | ||
|
Descrição
Este atributo é um sinalizador booleano ou categórico que mostra o resultado do SLA para um ticket. Ele pode indicar estados como 'Cumprido', 'Violado' ou 'Ativo'. Isso é determinado comparando os tempos reais de resposta ou resolução com as metas definidas na política de SLA aplicada. Este é um atributo crítico para o dashboard de 'Adesão ao SLA e Análise de Violação'. Ele permite a contagem e visualização fácil de tickets conformes versus não conformes. Análises posteriores podem, então, focar nas características do processo de tickets com violação para identificar causas raiz, como longos tempos de espera ou reatribuições excessivas.
Por que é importante
Mede diretamente o desempenho em relação aos compromissos de nível de serviço, um indicador-chave da qualidade do serviço e da satisfação do cliente.
Onde obter
Derivado da API de Métricas de Ticket do Zendesk, que fornece informações sobre o status do SLA para cada ticket.
Exemplos
AtingidoVioladoAtivo
|
|||
|
Tempo de ciclo da solicitação
ServiceRequestCycleTime
|
A duração total desde a criação de uma solicitação de serviço até sua resolução final. | ||
|
Descrição
Esta métrica calculada mede o tempo de processamento de ponta a ponta de uma solicitação de serviço. Geralmente é calculada como a diferença de tempo entre as atividades 'Solicitação de Serviço Resolvida' e 'Solicitação de Serviço Criada'. Este é um dos KPIs de alto nível mais importantes para qualquer processo de suporte. Este atributo suporta diretamente o KPI de 'Tempo Médio de Ciclo da Solicitação de Serviço' e o dashboard de 'Tempo de Ciclo de Ponta a Ponta'. Analisar esta métrica em diferentes dimensões, como tipo de solicitação ou prioridade, ajuda a identificar quais fatores têm o maior impacto na eficiência geral.
Por que é importante
Este é um KPI primário para medir a eficiência geral do processo e a experiência do cliente, indicando quanto tempo leva para entregar uma resolução.
Onde obter
Calculado como a diferença entre os timestamps do primeiro e do último evento (resolução) de um caso.
Exemplos
259200s (3 dias)86400s (1 dia)3600s (1 hora)
|
|||
Atividades de gestão de solicitações de serviço
| Atividade | Descrição | ||
|---|---|---|---|
|
Meta de SLA violada
|
Esta atividade marca o momento em que uma solicitação de serviço não cumpre uma meta de SLA definida, como o tempo de primeira resposta ou o tempo de resolução. O Zendesk registra isso como um evento explícito quando uma meta é perdida. | ||
|
Por que é importante
Este é um evento crítico para o monitoramento de conformidade e é um dado fundamental para o KPI de Taxa de Adesão ao SLA. Ele aponta falhas no cumprimento dos compromissos de serviço.
Onde obter
Capturado do evento 'SLABreach' nos eventos ou log de auditoria do Zendesk. O evento especifica qual métrica de SLA foi violada.
Captura
Identificado através do evento explícito 'SLABreach' nos dados do ticket.
Tipo de evento
explicit
|
|||
|
Resposta Pública Enviada
|
Esta atividade marca qualquer comunicação enviada de um agente para o solicitante. Isso é capturado como um evento explícito de 'Comentário' nos dados do ticket do Zendesk onde o atributo 'public' é verdadeiro. | ||
|
Por que é importante
Estes eventos são cruciais para analisar a frequência de comunicação, medir o tempo de resposta dos agentes e identificar o número de interações necessárias para a resolução.
Onde obter
Este é um evento de 'Comentário' explícito nos dados do ticket. Os detalhes do evento incluem um atributo 'public: true', distinguindo-o de notas internas.
Captura
Capturado de eventos de 'Comentário' onde o sinalizador 'público' está definido como verdadeiro.
Tipo de evento
explicit
|
|||
|
Solicitação Atribuída ao Agente
|
Esta atividade ocorre quando uma solicitação de serviço é atribuída a um agente específico pela primeira vez. Ela é inferida de um evento de 'Alteração' no log de auditoria do ticket, onde o campo 'assignee_id' é preenchido a partir de um valor nulo ou de um ID de grupo. | ||
|
Por que é importante
Isso marca o início do trabalho ativo de um agente e é fundamental para medir os tempos de resposta inicial, o atraso na primeira atribuição e a distribuição da carga de trabalho dos agentes.
Onde obter
Inferido do primeiro evento de 'Mudança' no campo 'assignee_id' no log de auditoria onde um ID de usuário é definido.
Captura
Inferido do primeiro evento de mudança que define o campo 'assignee_id' para um agente.
Tipo de evento
inferred
|
|||
|
Solicitação de Serviço Criada
|
Marca o início do ciclo de vida quando um novo ticket é enviado por qualquer canal. Capturado como um evento de 'Criação' no log de auditoria do Zendesk, definindo o tempo de início do processo. | ||
|
Por que é importante
Esta atividade serve como o evento de início principal para cada solicitação de serviço, sendo essencial para calcular os tempos de ciclo de ponta a ponta e analisar os volumes de entrada de solicitações.
Onde obter
Isso é registrado como um tipo de evento 'Criar' no log de auditoria de tickets do Zendesk. O timestamp deste evento é o momento de criação do ticket de solicitação de serviço.
Captura
Capturado diretamente do evento 'Criar' no log de auditoria do ticket.
Tipo de evento
explicit
|
|||
|
Solicitação de Serviço Encerrada
|
Representa o fechamento definitivo da solicitação. Um ticket passa para o estado 'fechado' automaticamente após um período como 'resolvido' e não pode mais ser reaberto. | ||
|
Por que é importante
Esta atividade marca o fim definitivo do processo de solicitação de serviço. Ela fornece o ponto final para o cálculo da duração total do caso.
Onde obter
Inferido de um evento de 'Mudança' no campo 'status' do log de auditoria, quando o novo valor é 'fechado' (closed).
Captura
Inferido a partir de um evento de 'Mudança' no log de auditoria onde o status se torna 'fechado'.
Tipo de evento
inferred
|
|||
|
Solicitação de serviço reaberta
|
Ocorre quando o requerente responde a um chamado que estava 'resolvido', voltando-o automaticamente para 'aberto'. Significa que a resolução proposta não foi suficiente. | ||
|
Por que é importante
Esta atividade é o principal indicador de retrabalho. Analisar sua frequência ajuda a medir a qualidade da resolução e identificar causas de insatisfação do cliente.
Onde obter
Inferido de um evento de 'Mudança' no campo 'status' onde o valor anterior era 'resolvido' e o novo é 'aberto' (open).
Captura
Inferido a partir de uma mudança de status de 'resolvido' para 'aberto'.
Tipo de evento
inferred
|
|||
|
Solicitação de Serviço Resolvida
|
Esta atividade marca o ponto em que um agente forneceu uma solução e alterou o status do ticket para 'resolvido'. A solicitação é considerada concluída sob a perspectiva do agente, mas ainda pode ser reaberta pelo solicitante. | ||
|
Por que é importante
Este é um marco importante que sinaliza o fim do trabalho ativo do agente. O tempo para atingir este estado é uma medida primária da eficiência da resolução.
Onde obter
Inferido de um evento de 'Mudança' no campo 'status' do log de auditoria, quando o novo valor é 'resolvido' (solved).
Captura
Inferido a partir de um evento de 'Mudança' no log de auditoria onde o status se torna 'resolvido'.
Tipo de evento
inferred
|
|||
|
Agente Reatribuído
|
Representa a transferência de responsabilidade de um agente para outro. Inferido de qualquer evento de 'Mudança' no campo 'assignee_id' após a primeira atribuição. | ||
|
Por que é importante
Rastrear reatribuições é fundamental para calcular o KPI de Taxa de Reatribuição de Agentes, o que ajuda a identificar ineficiências no processo, roteamento incorreto ou lacunas de conhecimento.
Onde obter
Inferido a partir de eventos de 'Mudança' no campo 'assignee_id' no log de auditoria, excluindo a primeiríssima atribuição.
Captura
Inferido do segundo evento de 'Mudança' e subsequentes no campo 'assignee_id'.
Tipo de evento
inferred
|
|||
|
Meta de SLA aplicada
|
Representa o momento em que uma política de SLA é aplicada ao ticket. Este evento é registrado quando as propriedades do chamado batem com as condições de uma política ativa. | ||
|
Por que é importante
Rastrear quando um SLA é aplicado é crucial para monitorar a conformidade, analisar possíveis violações e entender o cronograma de serviço esperado para diferentes tipos de solicitação.
Onde obter
Capturado do evento 'SLAPolicyApplied' nos eventos ou log de auditoria do Zendesk. O evento especifica qual política foi aplicada.
Captura
Identificado através do evento explícito 'SLAPolicyApplied' nos dados do ticket.
Tipo de evento
explicit
|
|||
|
Nota Interna Adicionada
|
Uma nota ou comentário interno foi adicionado pelo agente, visível apenas para outros agentes. Isso é registrado como um evento de 'Comentário' onde o atributo 'público' é falso. | ||
|
Por que é importante
O rastreamento de notas internas oferece insights sobre a colaboração entre agentes ou equipes, que pode ser uma fonte de atraso ou a chave para uma resolução de problemas eficiente.
Onde obter
Este é um evento de 'Comentário' explícito nos dados do ticket. Os detalhes do evento incluem um atributo 'public: false', indicando que se trata de uma nota interna.
Captura
Capturado de eventos de 'Comentário' onde o sinalizador 'público' está definido como falso.
Tipo de evento
explicit
|
|||
|
Prioridade Alterada
|
Indica que a prioridade (Baixa, Normal, Alta ou Urgente) foi atualizada. Capturado como um evento de 'Mudança' no campo 'prioridade' do log de auditoria. | ||
|
Por que é importante
Analisar mudanças de prioridade ajuda a identificar solicitações que ganham urgência com o tempo e avalia se a priorização está sendo gerida com eficácia.
Onde obter
Registrado como um evento de 'Mudança' no campo 'prioridade' do log de auditoria, mostrando os valores anterior e novo.
Captura
Inferido a partir de eventos de 'Mudança' no campo 'prioridade' do log de auditoria.
Tipo de evento
inferred
|
|||
|
Solicitação em Espera
|
Esta atividade ocorre quando o status da solicitação de serviço é alterado para 'em espera', indicando geralmente que o agente aguarda informações do solicitante ou de terceiros. Isso é inferido a partir de um evento de mudança de status. | ||
|
Por que é importante
Isso ajuda a isolar e medir tempos de espera que estão fora do controle direto da equipe de suporte, fornecendo uma visão mais precisa do tempo de tratamento do agente.
Onde obter
Inferido de um evento de 'Mudança' no campo 'status' do log de auditoria, quando o novo valor é 'em espera' (on-hold).
Captura
Inferido a partir de um evento de 'Mudança' no log de auditoria onde o status se torna 'em espera'.
Tipo de evento
inferred
|
|||
|
Solicitação Escalonada
|
Representa a escalação formal para um nível superior, outra equipe ou gestão. Geralmente inferido pela mudança do grupo atribuído ou de um campo personalizado de escalação. | ||
|
Por que é importante
Monitorar escalações ajuda a identificar solicitações complexas, necessidades de treinamento para agentes de linha de frente e problemas sistêmicos que exigem intervenção superior.
Onde obter
Este não é um evento padrão. Ele deve ser inferido a partir de um evento de 'Alteração' no campo 'group_id' para um grupo de escalação ou de uma alteração em um campo de ticket personalizado usado para rastreamento de escalação.
Captura
Inferido a partir de uma mudança no 'group_id' ou em um campo personalizado de 'escalação'.
Tipo de evento
inferred
|
|||