> Melhoria Contínua de Processos > Gerenciamento de Incidentes > Freshservice > Modelo de Dados

Template de dados: Gestão de Incidentes

Freshservice

Atributos de Gerenciamento de Incidentes (20) Atividades de Gerenciamento de Incidentes (14) Guias de Extração (3)

Seu Template de dados de Gerenciamento de Incidentes

Este template foi pensado para ajudar você a preparar seus dados para uma análise eficaz de gestão de incidentes. Ele detalha os atributos essenciais a coletar, as atividades críticas a acompanhar e traz orientações práticas para extrair essas informações do seu sistema de origem. Use este recurso para agilizar a preparação dos dados.

Atributos recomendados para coletar
Atividades-chave a monitorizar
Orientação para Extração

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

Baixar Modelo

Atributos de Gerenciamento de Incidentes

Estes são os campos de dados recomendados para inclusão no seu Event Log, permitindo uma análise completa do processo de gestão de incidentes.

5 Obrigatório 7 Recomendado 8 Opcional

	Nome	Descrição
	ID do incidente IncidentId	O identificador único de cada registro de incidente, usado como chave primária para rastrear todo o ciclo de vida do incidente.
Descrição O Incident ID é a base da análise de gerenciamento de incidentes. Ele funciona como o Case ID, conectando todas as atividades, timestamps e mudanças de atributos em uma jornada única e coerente. Em Process Mining, cada entrada do Event Log está associada a um Incident ID, permitindo reconstruir o fluxo ponta a ponta de cada incidente. Isso é essencial para calcular tempos de ciclo, analisar variantes de processo e identificar gargalos específicos de cada caso. Sem um identificador único, seria impossível diferenciar incidentes e analisar seus caminhos do registro à resolução. Por que é importante Identifica de forma única cada incidente, permitindo o acompanhamento e a análise de ponta a ponta do seu ciclo de vida, da criação ao fechamento. Onde obter Identificador principal de um ticket, disponível na Freshservice Tickets API como o campo 'id' no objeto de ticket. Exemplos INC-10234INC-10235INC-10236
	Event Timestamp EventTimestamp	A data e hora exatas em que a atividade ou evento ocorreu.
Descrição O Event Timestamp, ou Start Time, marca o momento exato em que uma atividade ocorreu. Cada atividade no ciclo de vida do incidente, da criação ao fechamento, tem um timestamp associado. Esse atributo é crítico para todas as análises de Process Mining baseadas em tempo. Ele é usado para ordenar eventos cronologicamente, calcular a duração entre atividades, medir o tempo total de ciclo do caso e analisar tempos de espera. É a base para construir dashboards que acompanham a performance de SLA, atrasos em repasses e tempos totais de resolução. Por que é importante Fornece a ordem cronológica dos eventos, essencial para calcular durações, analisar tempos de ciclo e entender o desempenho do processo. Onde obter Derivado de vários campos de timestamp no Freshservice, como 'created_at', 'updated_at' e timestamps dentro da conversa do ticket ou nos audit logs. Exemplos 2023-10-26T10:00:00Z2023-10-26T10:05:14Z2023-10-27T14:30:00Z
	Nome da Atividade ActivityName	O nome da atividade de negócio específica ou evento que ocorreu em um ponto do ciclo de vida do incidente.
Descrição O nome da atividade descreve uma etapa ou evento específico no processo de gerenciamento de incidentes, como 'Incident Assigned to Group', 'Status Changed to Pending' ou 'Incident Resolved'. Essas atividades são derivadas das mudanças nos dados do incidente ao longo do tempo. Esse atributo é fundamental para Process Mining, pois define os nós no mapa de processo descoberto. Ao analisar a sequência e a frequência dessas atividades, as organizações conseguem visualizar o processo real de resolução de incidentes, identificar caminhos comuns, detectar desvios do procedimento padrão e apontar ciclos de retrabalho, como reatribuições frequentes. Por que é importante Define as etapas no mapa do processo, permitindo visualizar e analisar o fluxo de resolução de incidentes, gargalos e desvios. Onde obter Este atributo não é um campo direto no Freshservice; ele é derivado de mudanças nas propriedades do ticket, como status, prioridade, atribuição de agente/grupo e inclusão de notas. Exemplos Incidente relatadoIncidente atribuído ao grupoNota de resolução adicionadaIncidente resolvido
	Sistema de Origem SourceSystem	O sistema do qual os dados foram extraídos, normalmente 'Freshservice'.
Descrição Este atributo identifica a origem dos dados. Embora neste contexto ele seja sempre 'Freshservice', é um campo fundamental em ambientes onde dados de múltiplos sistemas podem ser combinados para uma visão completa do processo. Incluir o atributo Sistema de Origem é uma boa prática de governança e rastreabilidade de dados. Ele garante clareza sobre a origem dos dados, algo importante para validação, depuração e futuras expansões do projeto de Process Mining para outros sistemas de gestão de serviços ou operações. Por que é importante Garante rastreabilidade e governança ao identificar claramente a origem dos dados de gestão de incidentes. Onde obter Normalmente é um valor estático adicionado durante a transformação de dados (ETL) para rotular o conjunto de dados. Exemplos FreshserviceFreshservice-EUFreshservice-PROD
	Última Atualização de Dados LastDataUpdate	O timestamp que indica a última atualização ou extração dos dados do processo.
Descrição Este atributo fornece um timestamp de quando todo o conjunto de dados foi atualizado pela última vez a partir do sistema de origem. É um metadado que se aplica ao conjunto como um todo, mas costuma ser incluído também no nível de evento por consistência. Nas análises, essa informação é vital para entender a atualidade dos dados e a janela de tempo coberta pelos dashboards e KPIs. Ela dá confiança aos usuários sobre a recência dos insights e ajuda a ajustar expectativas sobre se os incidentes mais recentes estão ou não incluídos na análise. Por que é importante Informa os usuários sobre quão recentes são os dados, garantindo que entendam o período coberto pela análise. Onde obter Timestamp de metadados gerado durante o processo de extração de dados (ETL). Exemplos 2023-11-01T02:00:00Z2023-11-02T02:00:00Z
	Agente atribuído AssignedAgent	O nome ou ID do agente de suporte atualmente atribuído para resolver o incidente.
Descrição O Agente Responsável identifica o colaborador do service desk encarregado do incidente em um determinado momento. Mudanças nesse atributo representam uma transferência de responsabilidade entre agentes. Esse atributo é essencial para a análise de performance, permitindo dashboards que acompanham a carga de trabalho por agente, o tempo médio de resolução por agente e as taxas de resolução no primeiro contato. Também é usado para analisar repasses entre agentes, que podem ser fonte de atrasos e ineficiências. Ao acompanhar as atribuições, os gestores conseguem identificar necessidades de treinamento e reconhecer membros de alta performance. Por que é importante Permite analisar o desempenho dos agentes, a distribuição de carga de trabalho e o impacto dos repasses entre agentes nos tempos de resolução. Onde obter Disponível na API de Tickets do Freshservice como o campo 'responder_id'. Esse ID pode ser associado à Agents API para obter o nome do agente. Exemplos John DoeJane SmithSupportBot
	Categoria do incidente IncidentCategory	A categoria usada para classificar o incidente, como Hardware, Software ou Rede.
Descrição A Categoria do incidente oferece uma forma de classificar incidentes pelo tipo de problema relatado. Essa classificação hierárquica ajuda a encaminhar o incidente para a equipe correta e é vital para análise de tendências. Esse atributo é usado no dashboard 'Incident Categorization Accuracy' para analisar se a categorização incorreta inicial leva a tempos de resolução mais longos devido a reatribuições. Ao agrupar incidentes por categoria, as organizações conseguem identificar problemas recorrentes, entender onde se concentra o esforço de suporte e direcionar iniciativas de melhoria. Por que é importante Permite analisar tendências de incidentes e ajuda a identificar se a categorização incorreta está causando atrasos na resolução. Onde obter Campo padrão, porém personalizável, no Freshservice. Está disponível na Tickets API como 'category', com os campos relacionados 'sub_category' e 'item_category'. Exemplos HardwareSoftwareProblema de RedeAcesso à conta
	Grupo atribuído AssignedGroup	O grupo ou equipe de suporte atualmente atribuído ao incidente.
Descrição O Grupo Responsável indica qual equipe, como 'Level 1 Support', 'Network Team' ou 'Database Admins', está encarregada do incidente. Mudanças nesse atributo indicam uma escalada ou transferência entre diferentes equipes funcionais. Analisar o Grupo Responsável é fundamental para entender atrasos em repasses e transferências. O Process Mining pode visualizar o fluxo de incidentes entre grupos, destacando caminhos de escalonamento comuns e medindo o tempo de espera até cada grupo agir. Isso ajuda a identificar gargalos organizacionais e oportunidades para agilizar a colaboração entre equipes. Por que é importante Rastreia qual equipe é responsável, o que é crucial para analisar repasses, escalonamentos e atrasos entre equipes. Onde obter Disponível na API de Tickets do Freshservice como o campo 'group_id'. Esse ID pode ser associado à Groups API para obter o nome do grupo. Exemplos Service DeskOperações de RedeSuporte de Infraestrutura
	Prioridade do incidente IncidentPriority	O nível de prioridade do incidente, que determina a urgência da resposta e da resolução.
Descrição A Prioridade do incidente é um campo-chave que define a velocidade e o foco necessários para tratá-lo. Normalmente é definida em uma escala como Baixa, Média, Alta e Urgente, e costuma direcionar metas de SLA. Em Process Mining, a prioridade é uma dimensão essencial para filtragem e análise. Ela permite comparar os processos de resolução de incidentes de alta versus baixa prioridade, garantindo que questões críticas sejam tratadas com eficiência. Dashboards geralmente segmentam métricas como tempo de ciclo e aderência a SLA por prioridade para fornecer insights acionáveis aos gestores de suporte. Por que é importante Ajuda a priorizar a análise nos incidentes mais críticos e é essencial para avaliar o cumprimento do SLA e a alocação de recursos. Onde obter Disponível na API de Tickets do Freshservice como o campo 'priority'. Os valores são numéricos (por exemplo, 1 para Baixa, 4 para Urgente). Exemplos BaixoMédioAltoUrgente
	Severidade do incidente IncidentSeverity	O nível de severidade do incidente, indicando seu impacto no negócio.
Descrição A Severidade do incidente mede o impacto que um incidente tem no negócio, geralmente categorizada como Baixa, Média, Alta ou Crítica. Embora relacionada à prioridade, a severidade foca no impacto, enquanto a prioridade foca na urgência. A combinação de severidade e impacto costuma determinar a prioridade final. Analisar por severidade ajuda a entender quão bem a organização lida com incidentes de grande consequência para o negócio. Ela é usada em dashboards para segmentar tempos de resolução e desempenho de SLA, garantindo que as questões mais impactantes recebam o nível adequado de atenção e recursos ao longo de todo o seu ciclo de vida. Por que é importante Mede o impacto no negócio de um incidente, permitindo análises focadas em mitigar os problemas mais prejudiciais. Onde obter Campo padrão no Freshservice, disponível pela Tickets API como 'impact'. Os valores são numéricos. Exemplos BaixoMédioAlto
	Status do incidente IncidentStatus	O status atual do incidente no seu ciclo de vida, como Aberto, Pendente, Resolvido ou Fechado.
Descrição O Status do Incidente indica o estado atual do incidente. Mudanças de status são eventos-chave que formam a base do mapa de processo descoberto, como a transição de 'In Progress' para 'Pending' ou de 'Resolved' para 'Closed'. Esse atributo é fundamental para entender a jornada do incidente. Analisar o tempo gasto em cada status ajuda a identificar gargalos, como incidentes que ficam tempo demais em 'Pending' aguardando resposta do usuário. Também é crucial para definir os pontos de início e término no cálculo do tempo de ciclo. Por que é importante Acompanha o progresso do incidente ao longo do ciclo de vida e ajuda a identificar etapas em que atrasos são comuns. Onde obter Disponível na API de Tickets do Freshservice como o campo 'status'. Os valores são numéricos. Exemplos AbertoEm ProgressoPendenteResolvidoEncerrado
	Tempo-alvo do SLA de resolução ResolutionSlaTargetTime	O timestamp que indica o prazo em que o incidente deve ser resolvido, conforme a política de SLA.
Descrição Este atributo armazena a data e hora específicas que servem como prazo para resolver um incidente. Esse prazo é determinado pela política de Service Level Agreement (SLA) aplicada ao ticket, geralmente com base em fatores como prioridade. Esse prazo é essencial para calcular o KPI 'Taxa de Aderência ao SLA' e alimentar o 'Dashboard de Performance de SLA'. Ao comparar o timestamp real de resolução com esse prazo, identificamos se o incidente foi resolvido no prazo ou se houve violação do SLA. Isso é fundamental para medir a conformidade com os níveis de serviço. Por que é importante Fornece o prazo para resolução, necessário para calcular o cumprimento do SLA e identificar incidentes em risco. Onde obter Disponível na API de Tickets do Freshservice como os campos 'fr_due_by' (primeira resposta) e 'due_by' (resolução). Exemplos 2023-10-26T14:00:00Z2023-10-27T09:00:00Z2023-11-05T17:00:00Z
	Canal de abertura ReportingChannel	O método ou canal pelo qual o incidente foi reportado, como e-mail, portal ou telefone.
Descrição O Canal de Abertura, também chamado de origem, indica como o incidente entrou no sistema de suporte. Os canais mais comuns são e-mail, portal de autoatendimento, telefone e chat. Analisar esse atributo ajuda a medir a eficiência de cada canal. O Dashboard 'Eficiência por Canal de Abertura' compara o volume de incidentes e o tempo médio de resolução por canal para mostrar quais são mais eficazes e quais precisam de melhorias no processo. Por exemplo, incidentes enviados pelo portal tendem a ser resolvidos mais rápido quando já vêm com informações mais estruturadas. Por que é importante Ajuda a identificar os canais de abertura mais eficientes e revela oportunidades para melhorar o processo de recebimento de incidentes. Onde obter Disponível na API de Tickets do Freshservice como o campo 'source'. Os valores são numéricos. Exemplos EmailPortalTelefoneChat
	Causa raiz RootCause	O motivo principal (causa raiz) identificado para o incidente após a investigação.
Descrição O atributo Causa Raiz registra o problema fundamental que levou ao incidente. Normalmente, essa informação é preenchida pelos agentes de suporte durante ou após a resolução, como parte do processo de Análise de Causa Raiz (RCA). Esse atributo é essencial para o Dashboard 'Incidentes Recorrentes e Causas Raiz' e para o KPI 'Taxa de Conclusão da Análise de Causa Raiz'. Ao identificar as causas mais comuns, a organização sai do modo reativo e passa a uma gestão proativa de problemas, implementando soluções permanentes que evitam novos incidentes e reduzem recorrências. Por que é importante Viabiliza uma gestão proativa de problemas, ajudando a identificar e eliminar as causas raiz de incidentes recorrentes. Onde obter Muitas vezes é um campo personalizado no Freshservice, pois a funcionalidade padrão pode ser limitada. Verifique em 'Ticket Fields' se existe um campo chamado 'Root Cause' ou similar. Exemplos Bug de softwareErro de Configuração de RedeProblema de treinamento do usuárioFalha de hardware
	Departamento do solicitante RequestersDepartment	O departamento ao qual pertence o usuário que registrou o incidente.
Descrição Este atributo identifica o departamento do solicitante, como 'Vendas', 'Financeiro' ou 'TI'. Normalmente, essa informação vem do perfil do usuário no Freshservice. Analisar os incidentes pelo departamento do solicitante pode revelar se algumas áreas de negócio são afetadas de forma desproporcional ou se há problemas específicos de um departamento. Isso traz contexto para entender o impacto no negócio e ajuda a priorizar correções que afetam áreas críticas. Por que é importante Traz contexto de negócios, permitindo analisar tendências de incidentes e impactos em departamentos específicos. Onde obter Essa informação está vinculada ao solicitante do ticket. Pode ser obtida no endpoint da API 'Requesters' usando o 'requester_id' do ticket e, em seguida, acessando o 'department_id' e o nome. Exemplos VendasMarketingFinançasRecursos Humanos
	Número de transferências HandoffCount	O número de vezes que um incidente foi transferido entre agentes ou grupos diferentes.
Descrição Handoff Count é uma métrica calculada que quantifica o número de reatribuições que um incidente sofre ao longo do seu ciclo de vida. Cada alteração nos atributos 'AssignedAgent' ou 'AssignedGroup' incrementa essa contagem. Um handoff count alto geralmente indica ineficiência do processo, roteamento inicial incorreto ou falta de conhecimento do agente. Essa métrica sustenta diretamente o KPI 'Incident Handoff Count' e o Dashboard 'Handoff And Transfer Delay Analysis', ajudando a identificar incidentes ou caminhos do processo com transferências excessivas que geram atrasos. Por que é importante Quantifica retrabalho e reatribuições, ajudando a identificar ineficiências causadas por roteamento incorreto ou lacunas de conhecimento. Onde obter Métrica calculada obtida contando o número de valores distintos ou de mudanças nos campos 'AssignedAgent' ou 'AssignedGroup' ao longo do ciclo de vida de um incidente. Exemplos 0125
	Reaberto IsReopened	Indicador calculado que indica que um incidente foi reaberto após ter sido resolvido ou encerrado.
Descrição Este atributo booleano é um indicador calculado que identifica incidentes reabertos. É marcado como true quando um incidente, após chegar aos estados 'Resolved' ou 'Closed', tem o status alterado novamente para aberto ou em andamento. Esse indicador é fundamental para calcular o KPI 'Taxa de Reabertura de Incidentes' e para o Dashboard 'Incidentes Recorrentes'. Uma taxa alta de reabertura pode sinalizar problemas na qualidade da resolução inicial, análise de causa raiz incompleta ou fechamento prematuro. Analisar esses casos ajuda a elevar a qualidade e a durabilidade das correções. Por que é importante Identifica falhas no processo de resolução, destacando incidentes em que a correção inicial foi ineficaz e gerou retrabalho. Onde obter Campo calculado a partir da sequência de atividades no Event Log. Fica verdadeiro quando ocorre uma atividade como 'Incident Reopened' ou quando, para o mesmo Incident ID, uma atividade em estado aberto ocorre após uma em estado fechado. Exemplos verdadeirofalse
	SLA Violado IsSlaBreached	Indicador calculado que indica que o incidente não foi resolvido dentro do prazo-alvo definido no SLA.
Descrição Este atributo booleano é uma métrica calculada que indica se o tempo de resolução de um incidente excedeu o prazo de SLA. Ele é calculado comparando o timestamp real de resolução com o 'ResolutionSlaTargetTime'. Esse indicador alimenta diretamente o KPI 'Taxa de Aderência ao SLA' e o 'Dashboard de Performance de SLA'. Ele simplifica a análise ao fornecer um resultado binário e claro para o desempenho de SLA de cada incidente, permitindo agregações e análise de tendências. Ajuda a identificar rapidamente o volume e a porcentagem de incidentes que não cumpriram os compromissos de serviço. Por que é importante Mede diretamente o cumprimento do SLA para cada incidente, facilitando o cálculo das taxas gerais de conformidade e a identificação de áreas problemáticas. Onde obter Campo calculado, gerado durante a transformação de dados ao comparar o timestamp de 'Incident Resolved' com o campo 'ResolutionSlaTargetTime'. Exemplos verdadeirofalse
	Tempo de ciclo de resolução ResolutionCycleTime	O tempo total decorrido entre a abertura do incidente e sua resolução.
Descrição Tempo de ciclo de resolução é um indicador-chave de desempenho calculado para cada incidente. Ele mede a duração total do processo de gerenciamento de incidentes sob a ótica do usuário, da abertura inicial à confirmação da resolução. Essa métrica calculada é a base do dashboard 'Incident Resolution Cycle Time'. Ela é usada para medir a eficiência geral do processo e costuma ser analisada por dimensões como prioridade, categoria e agente. Identificar incidentes com tempos de ciclo elevados ajuda a apontar atrasos sistêmicos e ineficiências. Por que é importante É uma medida principal de desempenho do processo, indicando diretamente quanto tempo leva para resolver incidentes de ponta a ponta. Onde obter Métrica calculada: é a diferença entre o timestamp da atividade 'Incident Resolved' e o da atividade 'Incident Reported'. Exemplos 259200000864000003600000
	Workaround fornecido WorkaroundProvided	Indicador que mostra se uma solução de contorno temporária (workaround) foi oferecida ao usuário antes da resolução final.
Descrição Este atributo booleano indica se uma solução temporária (solução de contorno) foi aplicada para mitigar o impacto do incidente enquanto a solução definitiva era desenvolvida. Isso geralmente é controlado por meio de uma checkbox ou de um status específico. Em Process Mining, esse atributo alimenta o Dashboard 'Métricas de Eficácia de Soluções de Contorno'. Ele permite comparar os tempos de resolução de incidentes com e sem soluções de contorno, ajudando a avaliar se essas medidas realmente reduzem a interrupção do negócio e aceleram a resolução do ponto de vista do usuário. Por que é importante Ajuda a medir a eficácia de soluções temporárias (workarounds) na redução do impacto do incidente e na aceleração da percepção de resolução. Onde obter Geralmente é um campo booleano (checkbox) personalizado. É preciso verificar sua existência na configuração 'Ticket Fields' do Freshservice. Exemplos verdadeirofalse

Obrigatório Recomendado Opcional

Atividades de Gerenciamento de Incidentes

Estas são as principais etapas do processo e marcos a serem capturados no seu log de eventos para uma descoberta precisa de processos e identificação de gargalos.

7 Recomendado 7 Opcional

	Atividade	Descrição
	Incidente atribuído ao grupo	Representa a atribuição inicial de um incidente a um grupo de suporte. Pode ser feita automaticamente por regras de roteamento ou manualmente por um despachante. Essa atividade é capturada acompanhando o primeiro preenchimento do campo 'Group' no log de auditoria do incidente.
Por que é importante Acompanhar as atribuições é essencial para medir o tempo de primeira resposta e identificar gargalos no processo de roteamento. Isso ajuda a avaliar a eficiência do encaminhamento dos incidentes para a equipe correta. Onde obter Inferido a partir do primeiro registro no log de atividades do incidente que preenche ou altera o campo 'Group'. Captura Identifique o primeiro timestamp em que o campo 'Group' é preenchido para um incidente. Tipo de evento inferred
	Incidente encerrado	Representa o encerramento final e formal do registro do incidente. Normalmente acontece automaticamente após um período no estado 'Resolved', ou pode ser feito manualmente por um agente. Esse evento marca o fim do ciclo de vida do incidente.
Por que é importante Esta atividade é o ponto final do processo. O tempo total até esse evento representa todo o ciclo de vida do incidente, incluindo eventuais períodos de confirmação pelo usuário. Onde obter Inferido pelo log de atividades do incidente ao identificar quando o campo 'Status' é atualizado para 'Closed'. Captura Use o timestamp da entrada no activity log referente à mudança de status para 'Closed'. Tipo de evento inferred
	Incidente priorizado	Ocorre quando a prioridade do incidente é definida ou atualizada. O nível de prioridade determina a urgência e as metas de SLA para a resolução. Isso é capturado ao monitorar alterações no campo 'Priority' no histórico do incidente.
Por que é importante Priorização incorreta ou atrasada pode levar a violações de SLA e à alocação ineficiente de recursos. Analisar essa atividade ajuda a garantir que incidentes críticos recebam atenção imediata. Onde obter Inferido pelo log de atividades do incidente, que rastreia todas as atualizações do campo 'Priority'. Captura Use os timestamps do audit log em que o valor do campo 'Priority' foi definido ou alterado. Tipo de evento inferred
	Incidente relatado	Marca a criação de um novo registro de incidente no Freshservice. Este é o ponto de partida do ciclo de vida do incidente, normalmente acionado por um usuário final via portal, e-mail ou por um agente da central de serviços abrindo um chamado em seu nome. Esse evento é registrado explicitamente com um carimbo de data e hora de criação.
Por que é importante Esta atividade é o evento inicial do processo. Analisar o tempo entre esse evento e a resolução é essencial para medir os tempos de ciclo e a aderência ao SLA. Onde obter Capturado a partir do timestamp de criação do incidente. O Freshservice registra isso explicitamente para cada novo ticket. Captura Use o timestamp 'Created at' do registro principal do incidente. Tipo de evento explicit
	Incidente resolvido	Marca o momento em que o agente aplicou uma correção e considera o incidente resolvido. Isso é capturado quando o status do incidente é alterado para 'Resolved'. No Freshservice, esse é um marco importante que interrompe a contagem do SLA.
Por que é importante Marco crítico para medir o Time to Resolution (TTR). O período entre 'Resolved' e 'Closed' é importante para analisar atrasos de confirmação do usuário e políticas de fechamento automático. Onde obter Inferido pelo log de atividades do incidente ao identificar quando o campo 'Status' é atualizado para 'Resolved'. Captura Use o timestamp da entrada no activity log referente à mudança de status para 'Resolved'. Tipo de evento inferred
	Nota de resolução adicionada	Ocorre quando um agente documenta a solução do incidente adicionando uma nota de resolução. É uma ação distinta no Freshservice, antes de mudar o status para 'Resolved'. Essa ação e seu conteúdo são registrados explicitamente.
Por que é importante Marca a identificação de uma solução. O tempo entre esse momento e o status 'Incident Resolved' pode indicar revisões internas ou sobrecarga de documentação. Onde obter Capturado no timestamp em que uma nota de resolução é adicionada ao incidente, o que fica registrado no histórico de conversas. Captura Identifique o timestamp da entrada 'Resolution Note' no log de conversas do incidente. Tipo de evento explicit
	Status alterado para Em andamento	Esta atividade marca o início oficial da investigação e do trabalho no incidente. Ela é registrada quando um agente altera o status do incidente para 'In Progress'. Essa mudança de status fica registrada no histórico de atividades do ticket.
Por que é importante Esse marco ajuda a diferenciar o tempo de espera do tempo de trabalho ativo. Analisar por quanto tempo um incidente fica 'In Progress' é essencial para entender o esforço de resolução. Onde obter Inferido pelo log de atividades do incidente ao identificar quando o campo 'Status' é atualizado para 'In Progress'. Captura No log de atividades, filtre a mudança de status para 'In Progress' e use seu timestamp. Tipo de evento inferred
	Agente atribuído ao incidente	Esta atividade indica quando um agente específico é atribuído para tratar o incidente. Ela sinaliza a responsabilidade individual pelo ticket. A atribuição fica registrada no histórico de atividades do ticket, mostrando qual agente foi atribuído e quando.
Por que é importante Isso permite analisar a carga de trabalho dos agentes, a performance e o tempo que leva para um incidente ser assumido por um agente após a atribuição ao grupo. É crucial para dashboards de performance dos agentes. Onde obter Rastreado pelas mudanças no campo 'Agent' no activity log ou no audit trail do incidente. Captura Identifique os timestamps correspondentes às mudanças no campo 'Agent'. Tipo de evento inferred
	Incidente reaberto	Ocorre quando um incidente que estava marcado como 'Resolved' volta a ficar aberto, geralmente porque o usuário discordou da resolução. Isso é inferido por uma mudança de status de 'Resolved' de volta para um estado como 'Open' ou 'In Progress'.
Por que é importante Uma taxa alta de reabertura indica problemas na qualidade da resolução ou correções incompletas. É uma métrica-chave para analisar retrabalho e o desempenho dos agentes. Onde obter Inferido pelo log de atividades do incidente ao detectar mudança de status de 'Resolved' para um status ativo. Captura No log de atividades, filtre a mudança de 'Status' de 'Resolved' para 'Open' ou 'In Progress'. Tipo de evento inferred
	Incidente reatribuído	Indica que o incidente foi transferido de um agente ou grupo para outro. Isso sinaliza um repasse no processo de resolução. Este evento é inferido ao detectar alterações subsequentes nos campos 'Agent' ou 'Group' após a atribuição inicial.
Por que é importante Reatribuições frequentes, ou handoffs, costumam indicar ineficiências de processo, lacunas de conhecimento ou roteamento inicial incorreto. Analisar esses eventos ajuda a identificar e reduzir atrasos. Onde obter Inferido pelo log de atividades do incidente ao rastrear qualquer alteração nos campos 'Agent' ou 'Group' após a primeira atribuição. Captura Detecte mudanças nos campos 'Agent' ou 'Group' no histórico de auditoria do ticket. Tipo de evento inferred
	Meta do SLA violada	Este é um evento calculado que ocorre quando o tempo decorrido de um incidente excede o prazo definido pelo SLA para resposta ou resolução. O Freshservice controla o status de SLA internamente e esse evento pode ser derivado comparando timestamps com os prazos definidos nas políticas de SLA.
Por que é importante Mede diretamente a conformidade com os compromissos de nível de serviço. Identificar quando e por que ocorrem violações é essencial para o SLA Performance Dashboard e para a melhoria contínua. Onde obter Calculado comparando o timestamp de resolução ou de resposta com o prazo-alvo do SLA. O Freshservice frequentemente marca tickets como 'SLA Violated'. Captura Calcule comparando o timestamp de 'Resolved at' com o de 'Due by', ou quando o campo 'SLA Status' mudar para 'Violated'. Tipo de evento calculated
	Primeira resposta enviada	Esta atividade representa a primeira comunicação do agente com o usuário após a abertura do incidente. Pode ser uma nota pública ou uma resposta direta. O Freshservice registra todas as comunicações dos agentes com seus respectivos timestamps.
Por que é importante Cumprir o SLA de Primeira Resposta é um KPI crítico para a satisfação do cliente. Essa atividade permite medir e analisar a rapidez com que os agentes respondem a novos incidentes. Onde obter Identifica-se pelo timestamp da primeira nota pública ou resposta adicionada por um agente no log de conversas do incidente. Captura No histórico de conversas do incidente, filtre a primeira entrada feita por um agente. Tipo de evento explicit
	Status alterado para Pendente	Representa um ponto em que o processo de resolução fica em pausa, normalmente aguardando informações do usuário ou de um terceiro. É inferido por uma mudança de status para um estado 'Pending'. O tempo nesse estado geralmente é excluído dos cálculos de SLA.
Por que é importante Mapear o tempo gasto em estados pendentes é crucial para entender dependências externas e atrasos. Isso ajuda a separar o tempo de trabalho do agente do tempo de espera. Onde obter Inferido pelo log de atividades do incidente quando o campo 'Status' é atualizado para um valor como 'Pending' ou 'Awaiting User Response'. Captura No log de atividades, filtre mudanças de status para qualquer estado pendente e use o timestamp associado. Tipo de evento inferred
	Workaround fornecido	Esta atividade indica que uma solução temporária (solução de contorno) foi comunicada ao usuário para mitigar o impacto do incidente. Registrar esse marco geralmente exige uma configuração específica no sistema, como uma checkbox dedicada, um tipo de nota específico ou análise de palavras-chave nas notas do agente.
Por que é importante Isso ajuda a analisar a eficácia das soluções de contorno na redução do impacto ao negócio e sua relação com o tempo final de resolução. Também alimenta o Dashboard 'Métricas de Eficácia de Soluções de Contorno'. Onde obter Provavelmente não é um evento explícito. Pode ser inferido ao sinalizar notas com palavras-chave como 'workaround', ou se um campo personalizado de checkbox 'Workaround Provided' for usado e sua alteração for registrada. Captura Inferido a partir de uma alteração em campo personalizado ou análise de palavras-chave nas anotações do agente. Tipo de evento inferred

Recomendado Opcional

Guias de Extração

Como extrair seus dados do Freshservice

Etapas

Acesse o Freshservice Analytics: Faça login na sua instância do Freshservice com uma conta que tenha permissões para acessar e criar relatórios. No menu principal, acesse o módulo Analytics.
Crie um novo relatório: Clique em New Report. Dê um nome descritivo, como "Incident Management Event Log". Ao escolher a fonte de dados, selecione o módulo Incident Management.
Selecione o widget do relatório: No editor do relatório, adicione um novo widget e selecione o tipo Table. Ele será a base do seu Event Log.
Adicione colunas de dados principais: No painel de origem de dados à direita, arraste e solte os campos necessários na configuração de colunas da tabela. Comece com Incident ID, Created at, Agent, Group, Priority, Severity, Status e Category.
Incorpore os dados de atividades: Para capturar eventos individuais, inclua os dados das atividades do ticket. Adicione a fonte de dados Activities ao widget. Dessa fonte, inclua Performed at (para o timestamp do evento) e Activity description ou campos semelhantes que descrevam a mudança ocorrida.
Crie a coluna calculada 'ActivityName': Este é o passo mais crítico. Crie uma nova coluna calculada (campo de fórmula). Use instruções IF aninhadas ou a função CASE para traduzir os dados brutos de atividade nos valores esperados em ActivityName. Veja a seção Query para a lógica detalhada de cada uma das 14 atividades.
Configure o 'EventTimestamp': Crie outra coluna calculada para EventTimestamp. A lógica deve usar o Created at para a atividade 'Incident Reported' e o Performed at para todos os demais eventos.
Aplique filtros ao relatório: Configure filtros para reduzir o volume de dados. No mínimo, defina um filtro de intervalo de datas em 'Created at'. Recomenda-se uma janela móvel de 3 a 6 meses. Inclua também um filtro para considerar apenas tickets em que 'Ticket Type' seja 'Incident'.
Execute e ajuste o relatório: Execute o relatório para gerar uma prévia. Revise o resultado para garantir que as colunas ActivityName e EventTimestamp estejam sendo preenchidas corretamente. Ajuste fórmulas e filtros conforme necessário.
Salve e exporte o relatório: Quando estiver satisfeito com o resultado, salve o relatório. Use a opção Export e selecione CSV como formato.
Agende a exportação (opcional): Para análise contínua, você pode agendar a execução e a exportação automáticas. Defina uma periodicidade (por exemplo, diária ou semanal) para receber o CSV por e-mail ou em outro destino.
Prepare os dados para upload: Abra o arquivo CSV exportado. Renomeie os cabeçalhos para corresponder ao schema exigido pelo ProcessMind: IncidentId, ActivityName, EventTimestamp, AssignedAgent, AssignedGroup etc. Adicione as colunas estáticas SourceSystem (com o valor 'Freshservice') e LastDataUpdate (com o timestamp atual). O arquivo agora está pronto para upload.

Configuração

Módulo Analytics: Esta extração requer acesso ao módulo Analytics do Freshservice, disponível nos planos mais avançados (por exemplo, Pro e Enterprise).
Permissões necessárias: Sua conta precisa de uma função com permissões para criar, editar e executar relatórios no módulo Analytics.
Intervalo de datas: É fundamental aplicar um filtro de data pela data de criação do incidente para controlar o volume de dados. Uma janela móvel de 3 a 6 meses equilibra histórico e desempenho.
Filtros do relatório: Defina 'Ticket Type' como 'Incident' para excluir solicitações de serviço ou outros tipos de ticket da sua análise de processo.
Campos calculados: O método depende fortemente do uso de campos calculados (fórmulas) para derivar ActivityName e EventTimestamp para cada evento. Familiaridade com o editor de fórmulas do Freshservice ajuda bastante.
Volume de dados: Tenha em mente que, para cada incidente, essa extração gera várias linhas (uma por atividade). Em instâncias grandes do Freshservice, o arquivo CSV pode ficar muito grande, impactando o tempo de geração do relatório e a velocidade de exportação.

a Consulta de Exemplo config

// This is a conceptual configuration for the Freshservice Analytics report builder, not an executable script.
// The logic should be implemented using the UI's formula fields and widget settings.

REPORT_WIDGET_TYPE: Table

DATA_SOURCES:
  - Primary: Incidents
  - Additional: Ticket Activities

COLUMNS_AND_DERIVATION_LOGIC:

1.  **IncidentId**
    - Source: Incidents."ID"

2.  **ActivityName** (Calculated Column using a Formula)
    - This formula combines multiple IF conditions to generate the activity name based on the activity type and data changes. The logic below represents a CASE statement structure.
    - **WHEN** Activity Type is 'Created': 'Incident Reported'
    - **WHEN** Activity Field is 'Group' and it is the first update to this field for the ticket: 'Incident Assigned to Group'
    - **WHEN** Activity Field is 'Agent' and it is the first update to this field for the ticket: 'Agent Assigned to Incident'
    - **WHEN** Activity Field is 'Priority': 'Incident Prioritized'
    - **WHEN** Activity Type is 'First Response Sent': 'First Response Sent'
    - **WHEN** Activity Field is 'Group' and it is NOT the first update: 'Incident Reassigned'
    - **WHEN** Activity Field is 'Agent' and it is NOT the first update: 'Incident Reassigned'
    - **WHEN** Activity Field is 'Status' and New Value is 'In Progress': 'Status Changed to In Progress'
    - **WHEN** Activity Field is 'Status' and New Value is 'Pending': 'Status Changed to Pending'
    - **WHEN** Activity Note contains 'Workaround Provided' or a specific workaround tag is added: 'Workaround Provided'
    - **WHEN** Activity Type is 'Resolution Note Added': 'Resolution Note Added'
    - **WHEN** Activity Field is 'Status' and New Value is 'Resolved': 'Incident Resolved'
    - **WHEN** Activity Type is 'SLA Violated' and SLA Type is 'Resolution': 'SLA Target Breached'
    - **WHEN** Activity Field is 'Status' and Old Value was 'Resolved' and New Value is 'Open': 'Incident Reopened'
    - **WHEN** Activity Field is 'Status' and New Value is 'Closed': 'Incident Closed'

3.  **EventTimestamp** (Calculated Column using a Formula)
    - **IF** ActivityName is 'Incident Reported', THEN use Incidents."Created at"
    - **ELSE**, use Ticket Activities."Performed at"

4.  **SourceSystem** (Calculated Column)
    - Value: 'Freshservice'

5.  **LastDataUpdate** (Calculated Column)
    - Value: Use a formula function that returns the current timestamp of the report execution.

6.  **AssignedAgent**
    - Source: Ticket Activities."Performed By" if available, otherwise the current Incidents."Agent"

7.  **AssignedGroup**
    - Source: The value of the 'Group' field at the time of the activity.

8.  **IncidentPriority**
    - Source: The value of the 'Priority' field at the time of the activity.

9.  **IncidentSeverity**
    - Source: The value of the 'Severity' field at the time of the activity.

10. **IncidentStatus**
    - Source: The new value from the 'Status' field change activity.

11. **IncidentCategory**
    - Source: The value of the 'Category' field at the time of the activity.

12. **ResolutionSlaTargetTime**
    - Source: Incidents."Resolution due by"

REPORT_FILTERS:
  - Incidents."Created at" BETWEEN '[Specify Start Date]' AND '[Specify End Date]'
  - Incidents."Type" EQUALS 'Incident'

Etapas

Pré-requisitos: Certifique-se de ter o Python 3.6+ instalado, junto com as bibliotecas requests e pandas. Você pode instalá-las com pip: pip install requests pandas.
Gerar chave de API: Faça login na sua instância do Freshservice como administrador. Acesse as configurações do perfil clicando na sua foto no canto superior direito. Vá até a seção 'API Key' e copie sua chave de API pessoal. Trate essa chave como uma senha.
Configurar o script: Salve o código Python fornecido em um arquivo chamado extract_freshservice_incidents.py no seu computador.
Configurar parâmetros: Abra o arquivo do script em um editor de texto. Atualize os valores de FRESHSERVICE_DOMAIN (ex.: 'yourcompany.freshservice.com'), API_KEY (a chave que você acabou de copiar) e START_DATE_STR (início do período de extração desejado no formato 'YYYY-MM-DD').
Entender a lógica do script: O script primeiro obtém todos os tickets de incidente criados após a data inicial informada. Percorre cada página de resultados retornados pela API. Para cada ticket, faz uma segunda chamada à API para buscar o histórico detalhado de atividades.
Geração do Event Log: O script processa os dados principais do ticket e o log de atividades para identificar e criar registros para cada uma das 14 atividades de negócio necessárias. Por exemplo, 'Incident Reported' é criado a partir da data de criação do ticket, enquanto 'Status Changed to In Progress' é derivado de uma entrada específica no log de atividades.
Derivar eventos complexos: Eventos como 'SLA Target Breached' são derivados. O script verifica se o SLA de resolução do ticket foi violado. Se sim, cria um evento com o timestamp de due_by, marcando o momento em que a violação ocorreu.
Executar o script: Abra um terminal ou prompt de comando, navegue até a pasta onde salvou o script e execute: python extract_freshservice_incidents.py.
Monitorar a execução: O script exibirá atualizações de progresso no console, mostrando quantos tickets já foram processados. Dependendo do volume de tickets e dos limites de requisição (rate limit) da API, isso pode levar algum tempo.
Revisar a saída: Quando o script terminar, ele gerará um arquivo CSV chamado freshservice_incident_event_log.csv na mesma pasta. Esse arquivo contém o Event Log completo.
Preparar para upload: Abra o CSV em um programa de planilhas e verifique se as colunas (IncidentId, ActivityName, EventTimestamp, etc.) estão preenchidas como esperado. O arquivo está pronto para upload no ProcessMind ou em outra ferramenta de Process Mining.

Configuração

FRESHSERVICE_DOMAIN: URL específica do Freshservice da sua empresa, por exemplo, mycompany.freshservice.com. Parâmetro obrigatório no script.
API_KEY: Chave de API pessoal de um usuário com permissões suficientes para ler todos os dados de incidentes. Parâmetro obrigatório.
START_DATE_STR: Data inicial da extração, no formato 'YYYY-MM-DD'. Recomenda-se extrair de 3 a 6 meses iniciais de dados para uma análise mais significativa.
PAGE_SIZE: Definido para 100, o máximo permitido pela API do Freshservice, para minimizar o número de chamadas e melhorar o desempenho. Em geral, não é recomendado mudar esse valor.
Limite de taxa da API: O script inclui um time.sleep(1) após processar cada ticket para respeitar os limites de taxa da API do Freshservice. Em ambientes de alto volume, pode ser necessário ajustar esse tempo para evitar erros.
Permissões necessárias: A chave de API deve pertencer a uma conta de usuário (por exemplo, uma conta de serviço dedicada) com pelo menos a função 'SD Agent' para garantir acesso a todos os campos do ticket e logs de atividade em diferentes grupos do service desk.

a Consulta de Exemplo python

import requests
import pandas as pd
import time
import datetime
import os

class=class="hl-string">"hl-comment"># --- Configuration Settings ---
class=class="hl-string">"hl-comment"># Replace with your Freshservice domain
FRESHSERVICE_DOMAIN = class="hl-string">"[your_domain].freshservice.com"
class=class="hl-string">"hl-comment"># Replace with your Freshservice API Key
API_KEY = class="hl-string">"[your_api_key]"
class=class="hl-string">"hl-comment"># Set the start date for the extraction (YYYY-MM-DD)
START_DATE_STR = class="hl-string">"2023-01-01"

class=class="hl-string">"hl-comment"># --- Constants ---
BASE_URL = fclass="hl-string">"https протокол://{FRESHSERVICE_DOMAIN}/api/v2"
PAGE_SIZE = 100
OUTPUT_FILENAME = class="hl-string">"freshservice_incident_event_log.csv"

class=class="hl-string">"hl-comment"># --- Main Extraction Logic ---
def create_event(incident_id, activity_name, event_timestamp, ticket_data, source_system, last_data_update):
    class="hl-string">"""Helper function to create a structured event dictionary."""
    class=class="hl-string">"hl-comment"># Use latest known values for attributes if available
    sla_policy = ticket_data.get(class="hl-string">'sla_policy', {})
    resolution_due = None
    if sla_policy and sla_policy.get(class="hl-string">'resolution_sla', {}):
        resolution_due = sla_policy.get(class="hl-string">'resolution_sla', {}).get(class="hl-string">'due_by')

    return {
        class="hl-string">"IncidentId": incident_id,
        class="hl-string">"ActivityName": activity_name,
        class="hl-string">"EventTimestamp": event_timestamp,
        class="hl-string">"SourceSystem": source_system,
        class="hl-string">"LastDataUpdate": last_data_update,
        class="hl-string">"AssignedAgent": ticket_data.get(class="hl-string">'responder_id'),
        class="hl-string">"AssignedGroup": ticket_data.get(class="hl-string">'group_id'),
        class="hl-string">"IncidentPriority": ticket_data.get(class="hl-string">'priority'),
        class="hl-string">"IncidentSeverity": ticket_data.get(class="hl-string">'impact'), class=class="hl-string">"hl-comment"># Impact is often used for Severity
        class="hl-string">"IncidentStatus": ticket_data.get(class="hl-string">'status'),
        class="hl-string">"IncidentCategory": ticket_data.get(class="hl-string">'category'),
        class="hl-string">"ResolutionSlaTargetTime": resolution_due
    }

def get_all_tickets(session, start_date):
    class="hl-string">"""Fetches all tickets from Freshservice updated since the start date, handling pagination."""
    tickets = []
    page = 1
    while True:
        params = {
            class="hl-string">"updated_since": start_date + class="hl-string">"T00:00:00Z",
            class="hl-string">"per_page": PAGE_SIZE,
            class="hl-string">"page": page,
            class="hl-string">"order_type": class="hl-string">"asc" class=class="hl-string">"hl-comment"># Process tickets in chronological order
        }
        try:
            response = session.get(fclass="hl-string">"{BASE_URL}/tickets", params=params)
            response.raise_for_status()
            data = response.json().get(class="hl-string">"tickets", [])
            if not data:
                break
            tickets.extend(data)
            print(fclass="hl-string">"Fetched page {page}, {len(data)} tickets...")
            page += 1
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error fetching tickets: {e}")
            break
    return tickets

def get_ticket_activities(session, ticket_id):
    class="hl-string">"""Fetches all activities (audit log) for a specific ticket."""
    try:
        response = session.get(fclass="hl-string">"{BASE_URL}/tickets/{ticket_id}/activities")
        response.raise_for_status()
        return response.json().get(class="hl-string">"activities", [])
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Error fetching activities for ticket {ticket_id}: {e}")
        return []

def main():
    class="hl-string">"""Main function to run the extraction process."""
    session = requests.Session()
    session.auth = (API_KEY, class="hl-string">'X') class=class="hl-string">"hl-comment"># class="hl-string">'X' is a placeholder password
    session.headers.update({class="hl-string">'Content-Type': class="hl-string">'application/json'})

    last_data_update = datetime.datetime.now(datetime.timezone.utc).isoformat()
    source_system = class="hl-string">'Freshservice'
    event_log = []

    print(class="hl-string">"Starting Freshservice incident extraction...")
    all_tickets = get_all_tickets(session, START_DATE_STR)
    print(fclass="hl-string">"Total tickets to process: {len(all_tickets)}")

    for i, ticket in enumerate(all_tickets):
        incident_id = ticket[class="hl-string">'id']
        print(fclass="hl-string">"Processing ticket {i+1}/{len(all_tickets)}: ID {incident_id}")

        class=class="hl-string">"hl-comment"># 1. Incident Reported
        event_log.append(create_event(incident_id, class="hl-string">"Incident Reported", ticket[class="hl-string">'created_at'], ticket, source_system, last_data_update))

        class=class="hl-string">"hl-comment"># Fetch detailed activities for more events
        activities = get_ticket_activities(session, incident_id)
        
        assigned_group_done = False
        agent_assigned_done = False
        first_response_done = False

        for activity in sorted(activities, key=lambda x: x[class="hl-string">'performed_at']):
            activity_ts = activity[class="hl-string">'performed_at']
            class=class="hl-string">"hl-comment"># 2. Incident Assigned to Group (first occurrence)
            if not assigned_group_done and activity[class="hl-string">'activity_type'] == class="hl-string">'Update' and class="hl-string">'group_id' in activity.get(class="hl-string">'changes', {}):
                event_log.append(create_event(incident_id, class="hl-string">"Incident Assigned to Group", activity_ts, ticket, source_system, last_data_update))
                assigned_group_done = True
            
            class=class="hl-string">"hl-comment"># 3. Agent Assigned to Incident (first occurrence)
            if not agent_assigned_done and activity[class="hl-string">'activity_type'] == class="hl-string">'Update' and class="hl-string">'responder_id' in activity.get(class="hl-string">'changes', {}):
                event_log.append(create_event(incident_id, class="hl-string">"Agent Assigned to Incident", activity_ts, ticket, source_system, last_data_update))
                agent_assigned_done = True

            class=class="hl-string">"hl-comment"># 4. Incident Prioritized
            if activity[class="hl-string">'activity_type'] == class="hl-string">'Update' and class="hl-string">'priority' in activity.get(class="hl-string">'changes', {}):
                event_log.append(create_event(incident_id, class="hl-string">"Incident Prioritized", activity_ts, ticket, source_system, last_data_update))

            class=class="hl-string">"hl-comment"># 5. First Response Sent (first public note by an agent)
            if not first_response_done and activity[class="hl-string">'activity_type'] == class="hl-string">'Note' and activity.get(class="hl-string">'note', {}).get(class="hl-string">'private') is False and activity.get(class="hl-string">'performer_type') == class="hl-string">'User':
                event_log.append(create_event(incident_id, class="hl-string">"First Response Sent", activity_ts, ticket, source_system, last_data_update))
                first_response_done = True

            class=class="hl-string">"hl-comment"># 6. Incident Reassigned (subsequent assignments)
            if (assigned_group_done and activity[class="hl-string">'activity_type'] == class="hl-string">'Update' and class="hl-string">'group_id' in activity.get(class="hl-string">'changes', {})) or \
               (agent_assigned_done and activity[class="hl-string">'activity_type'] == class="hl-string">'Update' and class="hl-string">'responder_id' in activity.get(class="hl-string">'changes', {})):
                event_log.append(create_event(incident_id, class="hl-string">"Incident Reassigned", activity_ts, ticket, source_system, last_data_update))

            class=class="hl-string">"hl-comment"># Status Changes
            if activity[class="hl-string">'activity_type'] == class="hl-string">'Update' and class="hl-string">'status' in activity.get(class="hl-string">'changes', {}):
                new_status = activity[class="hl-string">'changes'][class="hl-string">'status'][1]
                class=class="hl-string">"hl-comment"># 7. Status Changed to In Progress
                if new_status == 3: class=class="hl-string">"hl-comment"># Assuming 3 is class="hl-string">'In Progress'
                    event_log.append(create_event(incident_id, class="hl-string">"Status Changed to In Progress", activity_ts, ticket, source_system, last_data_update))
                class=class="hl-string">"hl-comment"># 8. Status Changed to Pending
                elif new_status == 6: class=class="hl-string">"hl-comment"># Assuming 6 is class="hl-string">'Pending'
                    event_log.append(create_event(incident_id, class="hl-string">"Status Changed to Pending", activity_ts, ticket, source_system, last_data_update))

            class=class="hl-string">"hl-comment"># 9. Workaround Provided (Keyword search in notes)
            if activity[class="hl-string">'activity_type'] == class="hl-string">'Note' and class="hl-string">'workaround' in activity.get(class="hl-string">'note', {}).get(class="hl-string">'body_text', class="hl-string">'').lower():
                event_log.append(create_event(incident_id, class="hl-string">"Workaround Provided", activity_ts, ticket, source_system, last_data_update))
            
            class=class="hl-string">"hl-comment"># 10. Resolution Note Added
            if activity[class="hl-string">'activity_type'] == class="hl-string">'Note' and activity.get(class="hl-string">'note', {}).get(class="hl-string">'note_type') == class="hl-string">'resolution':
                event_log.append(create_event(incident_id, class="hl-string">"Resolution Note Added", activity_ts, ticket, source_system, last_data_update))

        class=class="hl-string">"hl-comment"># 11. Incident Resolved
        if ticket.get(class="hl-string">'resolved_at'):
            event_log.append(create_event(incident_id, class="hl-string">"Incident Resolved", ticket[class="hl-string">'resolved_at'], ticket, source_system, last_data_update))

        class=class="hl-string">"hl-comment"># 12. SLA Target Breached
        if ticket.get(class="hl-string">'sla_policy') and ticket[class="hl-string">'sla_policy'].get(class="hl-string">'violation_details', {}).get(class="hl-string">'resolution_sla', {}).get(class="hl-string">'is_violated'):
            breach_time = ticket[class="hl-string">'sla_policy'][class="hl-string">'violation_details'][class="hl-string">'resolution_sla'][class="hl-string">'due_by']
            event_log.append(create_event(incident_id, class="hl-string">"SLA Target Breached", breach_time, ticket, source_system, last_data_update))

        class=class="hl-string">"hl-comment"># 13. Incident Reopened
        if ticket.get(class="hl-string">'reopened'):
            class=class="hl-string">"hl-comment"># Finding the exact reopened timestamp can be tricky, we approximate from class="hl-string">'stats'
            reopen_ts = ticket.get(class="hl-string">'stats', {}).get(class="hl-string">'reopened_at', ticket[class="hl-string">'updated_at'])
            event_log.append(create_event(incident_id, class="hl-string">"Incident Reopened", reopen_ts, ticket, source_system, last_data_update))

        class=class="hl-string">"hl-comment"># 14. Incident Closed
        if ticket.get(class="hl-string">'closed_at'):
            event_log.append(create_event(incident_id, class="hl-string">"Incident Closed", ticket[class="hl-string">'closed_at'], ticket, source_system, last_data_update))

        class=class="hl-string">"hl-comment"># Be respectful of API rate limits
        time.sleep(1)

    class=class="hl-string">"hl-comment"># Convert to DataFrame and save
    if event_log:
        df = pd.DataFrame(event_log)
        df[class="hl-string">'EventTimestamp'] = pd.to_datetime(df[class="hl-string">'EventTimestamp'])
        df = df.sort_values(by=[class="hl-string">'IncidentId', class="hl-string">'EventTimestamp'])
        df.to_csv(OUTPUT_FILENAME, index=False, date_format=class="hl-string">'%Y-%m-%dT%H:%M:%S.%f%z')
        print(fclass="hl-string">"\nSuccessfully extracted {len(df)} events for {df['IncidentId'].nunique()} incidents.")
        print(fclass="hl-string">"Event log saved to {OUTPUT_FILENAME}")
    else:
        print(class="hl-string">"No events were generated.")

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

Etapas

Acesse o Freshservice Analytics: Faça login na sua instância do Freshservice com uma conta que tenha permissões para acessar e criar relatórios. No menu principal, acesse o módulo Analytics.
Crie um novo relatório: Clique em New Report. Dê um nome descritivo, como "Incident Management Event Log". Ao escolher a fonte de dados, selecione o módulo Incident Management.
Selecione o widget do relatório: No editor do relatório, adicione um novo widget e selecione o tipo Table. Ele será a base do seu Event Log.
Adicione colunas de dados principais: No painel de origem de dados à direita, arraste e solte os campos necessários na configuração de colunas da tabela. Comece com Incident ID, Created at, Agent, Group, Priority, Severity, Status e Category.
Incorpore os dados de atividades: Para capturar eventos individuais, inclua os dados das atividades do ticket. Adicione a fonte de dados Activities ao widget. Dessa fonte, inclua Performed at (para o timestamp do evento) e Activity description ou campos semelhantes que descrevam a mudança ocorrida.
Crie a coluna calculada 'ActivityName': Este é o passo mais crítico. Crie uma nova coluna calculada (campo de fórmula). Use instruções IF aninhadas ou a função CASE para traduzir os dados brutos de atividade nos valores esperados em ActivityName. Veja a seção Query para a lógica detalhada de cada uma das 14 atividades.
Configure o 'EventTimestamp': Crie outra coluna calculada para EventTimestamp. A lógica deve usar o Created at para a atividade 'Incident Reported' e o Performed at para todos os demais eventos.
Aplique filtros ao relatório: Configure filtros para reduzir o volume de dados. No mínimo, defina um filtro de intervalo de datas em 'Created at'. Recomenda-se uma janela móvel de 3 a 6 meses. Inclua também um filtro para considerar apenas tickets em que 'Ticket Type' seja 'Incident'.
Execute e ajuste o relatório: Execute o relatório para gerar uma prévia. Revise o resultado para garantir que as colunas ActivityName e EventTimestamp estejam sendo preenchidas corretamente. Ajuste fórmulas e filtros conforme necessário.
Salve e exporte o relatório: Quando estiver satisfeito com o resultado, salve o relatório. Use a opção Export e selecione CSV como formato.
Agende a exportação (opcional): Para análise contínua, você pode agendar a execução e a exportação automáticas. Defina uma periodicidade (por exemplo, diária ou semanal) para receber o CSV por e-mail ou em outro destino.
Prepare os dados para upload: Abra o arquivo CSV exportado. Renomeie os cabeçalhos para corresponder ao schema exigido pelo ProcessMind: IncidentId, ActivityName, EventTimestamp, AssignedAgent, AssignedGroup etc. Adicione as colunas estáticas SourceSystem (com o valor 'Freshservice') e LastDataUpdate (com o timestamp atual). O arquivo agora está pronto para upload.

Configuração

Módulo Analytics: Esta extração requer acesso ao módulo Analytics do Freshservice, disponível nos planos mais avançados (por exemplo, Pro e Enterprise).
Permissões necessárias: Sua conta precisa de uma função com permissões para criar, editar e executar relatórios no módulo Analytics.
Intervalo de datas: É fundamental aplicar um filtro de data pela data de criação do incidente para controlar o volume de dados. Uma janela móvel de 3 a 6 meses equilibra histórico e desempenho.
Filtros do relatório: Defina 'Ticket Type' como 'Incident' para excluir solicitações de serviço ou outros tipos de ticket da sua análise de processo.
Campos calculados: O método depende fortemente do uso de campos calculados (fórmulas) para derivar ActivityName e EventTimestamp para cada evento. Familiaridade com o editor de fórmulas do Freshservice ajuda bastante.
Volume de dados: Tenha em mente que, para cada incidente, essa extração gera várias linhas (uma por atividade). Em instâncias grandes do Freshservice, o arquivo CSV pode ficar muito grande, impactando o tempo de geração do relatório e a velocidade de exportação.

a Consulta de Exemplo config

// This is a conceptual configuration for the Freshservice Analytics report builder, not an executable script.
// The logic should be implemented using the UI's formula fields and widget settings.

REPORT_WIDGET_TYPE: Table

DATA_SOURCES:
  - Primary: Incidents
  - Additional: Ticket Activities

COLUMNS_AND_DERIVATION_LOGIC:

1.  **IncidentId**
    - Source: Incidents."ID"

2.  **ActivityName** (Calculated Column using a Formula)
    - This formula combines multiple IF conditions to generate the activity name based on the activity type and data changes. The logic below represents a CASE statement structure.
    - **WHEN** Activity Type is 'Created': 'Incident Reported'
    - **WHEN** Activity Field is 'Group' and it is the first update to this field for the ticket: 'Incident Assigned to Group'
    - **WHEN** Activity Field is 'Agent' and it is the first update to this field for the ticket: 'Agent Assigned to Incident'
    - **WHEN** Activity Field is 'Priority': 'Incident Prioritized'
    - **WHEN** Activity Type is 'First Response Sent': 'First Response Sent'
    - **WHEN** Activity Field is 'Group' and it is NOT the first update: 'Incident Reassigned'
    - **WHEN** Activity Field is 'Agent' and it is NOT the first update: 'Incident Reassigned'
    - **WHEN** Activity Field is 'Status' and New Value is 'In Progress': 'Status Changed to In Progress'
    - **WHEN** Activity Field is 'Status' and New Value is 'Pending': 'Status Changed to Pending'
    - **WHEN** Activity Note contains 'Workaround Provided' or a specific workaround tag is added: 'Workaround Provided'
    - **WHEN** Activity Type is 'Resolution Note Added': 'Resolution Note Added'
    - **WHEN** Activity Field is 'Status' and New Value is 'Resolved': 'Incident Resolved'
    - **WHEN** Activity Type is 'SLA Violated' and SLA Type is 'Resolution': 'SLA Target Breached'
    - **WHEN** Activity Field is 'Status' and Old Value was 'Resolved' and New Value is 'Open': 'Incident Reopened'
    - **WHEN** Activity Field is 'Status' and New Value is 'Closed': 'Incident Closed'

3.  **EventTimestamp** (Calculated Column using a Formula)
    - **IF** ActivityName is 'Incident Reported', THEN use Incidents."Created at"
    - **ELSE**, use Ticket Activities."Performed at"

4.  **SourceSystem** (Calculated Column)
    - Value: 'Freshservice'

5.  **LastDataUpdate** (Calculated Column)
    - Value: Use a formula function that returns the current timestamp of the report execution.

6.  **AssignedAgent**
    - Source: Ticket Activities."Performed By" if available, otherwise the current Incidents."Agent"

7.  **AssignedGroup**
    - Source: The value of the 'Group' field at the time of the activity.

8.  **IncidentPriority**
    - Source: The value of the 'Priority' field at the time of the activity.

9.  **IncidentSeverity**
    - Source: The value of the 'Severity' field at the time of the activity.

10. **IncidentStatus**
    - Source: The new value from the 'Status' field change activity.

11. **IncidentCategory**
    - Source: The value of the 'Category' field at the time of the activity.

12. **ResolutionSlaTargetTime**
    - Source: Incidents."Resolution due by"

REPORT_FILTERS:
  - Incidents."Created at" BETWEEN '[Specify Start Date]' AND '[Specify End Date]'
  - Incidents."Type" EQUALS 'Incident'

Template de dados: Gestão de Incidentes

Seu Template de dados de Gerenciamento de Incidentes

Atributos de Gerenciamento de Incidentes

Atividades de Gerenciamento de Incidentes

Guias de Extração

Exportação de dados do módulo Analytics do Freshservice para CSV

Etapas

Configuração

a Consulta de Exemplo config

Extração por script Python via REST API do Freshservice

Etapas

Configuração

a Consulta de Exemplo python

Envio de dados em tempo real via webhooks do Workflow Automator

Etapas

Configuração

a Consulta de Exemplo config

Pronto para Começar?

Acabe com as violações de SLA: otimize o gerenciamento de incidentes hoje mesmo