> Melhoria contínua de processos > Gestão de Incidentes > Freshservice > Template de dados

Seu Template de dados de gerenciamento de incidentes

Freshservice

Atributos de Gestão de Incidentes (19) Atividades de Gestão de Incidentes (14) Guias de extração (3)

Seu Template de dados de gerenciamento de incidentes

Este Template foi criado para ajudar você a preparar seus dados para uma análise eficaz do gerenciamento de incidentes. Ele apresenta os atributos essenciais a serem coletados, as atividades críticas a serem acompanhadas e orientações práticas para extrair essas informações do seu sistema de origem. Use este recurso para simplificar a preparação dos seus dados.

Atributos recomendados para coleta
Principais atividades a acompanhar
Orientações para extração

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

Baixar Template

Atributos de Gestão de Incidentes

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

5 Obrigatório 7 Recomendado 7 Opcional

	Nome	Descrição
	ID do incidente IncidentId	O identificador exclusivo de cada registro de incidente, usado como chave primária para acompanhar 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, vinculando todas as atividades relacionadas, os timestamps e as alterações de atributos em uma única jornada coesa. No Process Mining, cada entrada do Event Log está associada a um Incident ID, permitindo reconstruir o fluxo do processo de ponta a ponta para cada incidente. Isso é essencial para calcular tempos de ciclo, analisar variantes do processo e identificar gargalos específicos de cada caso. Sem um identificador exclusivo, seria impossível diferenciar os incidentes e analisar seus caminhos desde o registro até a resolução. Por que isso importa Ele identifica exclusivamente cada incidente, permitindo acompanhar e analisar seu ciclo de vida de ponta a ponta, da criação ao encerramento. Onde obter Este é o identificador principal de um ticket, disponível na API de Tickets do Freshservice como o campo 'id' no objeto do ticket. Exemplos INC-10234INC-10235INC-10236
	Nome da atividade ActivityName	O nome da atividade de negócio ou do evento específico que ocorreu em determinado momento do ciclo de vida do incidente.
Descrição O Nome da atividade descreve uma única etapa ou evento no processo de gerenciamento de incidentes, como 'Incidente atribuído ao grupo', 'Status alterado para pendente' ou 'Incidente resolvido'. Essas atividades são derivadas das alterações nos dados do incidente ao longo do tempo. Esse atributo é fundamental para o Process Mining, pois define os nós do 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 localizar ciclos de retrabalho, como reatribuições frequentes. Por que isso importa Ele define as etapas do mapa de processo, permitindo visualizar e analisar o fluxo de resolução do incidente, os gargalos e os desvios. Onde obter Este atributo não é um campo direto do Freshservice, mas é derivado de alterações nas propriedades do ticket, como status, prioridade, atribuição de agente ou grupo e adiçã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 o 'Freshservice'.
Descrição Este atributo identifica a origem dos dados. Embora, neste contexto, ele seja sempre 'Freshservice', é um campo essencial em ambientes nos quais dados de vários sistemas podem ser combinados para oferecer uma visão holística do processo. Incluir o atributo Sistema de origem é uma boa prática de governança e rastreabilidade dos dados. Isso garante clareza sobre a procedência dos dados, algo importante para validação, depuração e futura expansão do projeto de Process Mining para incluir outros sistemas de gerenciamento de serviços ou operações. Por que isso importa Ele garante a rastreabilidade e a governança dos dados ao identificar claramente a origem dos dados de gerenciamento de incidentes. Onde obter Normalmente, este é um valor estático adicionado durante o processo de transformação de dados (ETL) para identificar o conjunto de dados. Exemplos FreshserviceFreshservice-EUFreshservice-PROD
	Timestamp do evento EventTimestamp	A data e a hora exatas em que a atividade ou o evento ocorreu.
Descrição O Timestamp do evento, ou Start Time, marca o momento exato em que uma atividade ocorreu. Cada atividade do ciclo de vida do incidente, da criação ao encerramento, tem um timestamp associado. Esse atributo é essencial para todas as análises de Process Mining baseadas em tempo. Ele é usado para ordenar os eventos cronologicamente, calcular a duração entre atividades, medir o tempo total de ciclo do caso e analisar tempos de espera. É a base para criar Dashboards que acompanham a performance de SLA, atrasos nas transferências e tempos gerais de resolução. Por que isso importa Ele fornece a ordem cronológica dos eventos, essencial para calcular durações, analisar tempos de ciclo e entender a performance do processo. Onde obter Ele é derivado de vários campos de timestamp do Freshservice, como 'created_at', 'updated_at' e timestamps presentes na conversa ou nos registros de auditoria do ticket. Exemplos 2023-10-26T10:00:00Z2023-10-26T10:05:14Z2023-10-27T14:30:00Z
	Última atualização dos dados LastDataUpdate	O timestamp que indica a última vez em que os dados desse processo foram atualizados ou extraídos.
Descrição Este atributo fornece o timestamp de quando todo o conjunto de dados foi atualizado pela última vez a partir do sistema de origem. É um campo de metadados que se aplica ao conjunto de dados inteiro, e não a eventos individuais, mas costuma ser incluído no nível do evento por consistência. Na análise, essas informações são essenciais para entender a atualidade dos dados e o período coberto pelos Dashboards e KPIs. Elas dão aos usuários mais confiança na recência dos insights e ajudam a alinhar as expectativas sobre a inclusão dos incidentes mais recentes na análise. Por que isso importa Ele informa aos usuários a atualidade dos dados, garantindo que entendam o período coberto pela análise. Onde obter Este é um 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 responsável por resolver o incidente.
Descrição O Agente atribuído identifica o funcionário do service desk responsável pelo incidente em determinado momento. As alterações nesse atributo representam uma transferência de responsabilidade entre agentes. Esse atributo é essencial para analisar a performance, permitindo criar Dashboards que acompanham a carga de trabalho dos agentes, o tempo médio de resolução por agente e as taxas de resolução no primeiro contato. Ele também é usado para analisar transferências entre agentes, que podem ser uma fonte de atrasos e ineficiências. Ao acompanhar as atribuições dos agentes, os gestores conseguem identificar necessidades de treinamento e reconhecer os membros do time com melhor performance. Por que isso importa Ele permite analisar a performance dos agentes, a distribuição da carga de trabalho e o impacto das transferências 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 à API de Agents 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 os incidentes com base no tipo de problema reportado. Essa classificação hierárquica ajuda a encaminhar o incidente ao time correto e é essencial para a análise de tendências. Esse atributo é usado no Dashboard 'Precisão da categorização de incidentes' para analisar se uma categorização inicial incorreta leva a tempos de resolução maiores devido a reatribuições. Ao agrupar os incidentes por categoria, as organizações conseguem identificar problemas recorrentes, entender onde a maior parte do esforço de suporte é empregada e direcionar iniciativas de melhoria. Por que isso importa Ele permite analisar tendências de incidentes e ajuda a determinar se uma categorização incorreta está causando atrasos na resolução. Onde obter Este é um campo padrão, mas personalizável, do Freshservice. Ele está disponível na API de Tickets como 'category', com os campos relacionados 'sub_category' e 'item_category'. Exemplos HardwareSoftwareProblema de redeAcesso à conta
	Grupo atribuído AssignedGroup	O grupo ou time de suporte atualmente responsável pelo incidente.
Descrição O Grupo atribuído indica qual time, como 'Suporte de nível 1', 'Time de redes' ou 'Administradores de banco de dados', é responsável pelo incidente. As alterações nesse atributo indicam uma escalação ou transferência entre diferentes times funcionais. Analisar o Grupo atribuído é essencial para entender atrasos em transferências e repasses. O Process Mining pode visualizar o fluxo de incidentes entre grupos, destacando caminhos comuns de escalação e medindo o tempo de espera até cada grupo agir. Isso ajuda a identificar gargalos organizacionais e oportunidades para simplificar a colaboração entre times. Por que isso importa Ele acompanha qual time é responsável, algo essencial para analisar transferências, escalações e atrasos entre times. Onde obter Disponível na API de Tickets do Freshservice como o campo 'group_id'. Esse ID pode ser associado à API de Groups para obter o nome do grupo. Exemplos Central de ServiçosOperaçõ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 essencial que define a velocidade e o foco necessários para lidar com um incidente. Normalmente, ela é definida em uma escala como Baixa, Média, Alta e Urgente e costuma orientar as metas de SLA. No Process Mining, a prioridade é uma dimensão importante para filtros e análises. Ela permite comparar os processos de resolução de incidentes de alta e baixa prioridade, garantindo que problemas críticos sejam tratados com eficiência. Os Dashboards geralmente segmentam métricas como tempo de ciclo e cumprimento do SLA por prioridade para fornecer insights acionáveis aos gestores de suporte. Por que isso importa Ela ajuda a priorizar a análise dos incidentes mais críticos e é essencial para avaliar a performance 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 e 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 causa no negócio e costuma ser categorizada como Baixa, Média, Alta ou Crítica. Embora esteja relacionada à prioridade, a severidade se concentra no impacto, enquanto a prioridade se concentra na urgência. A combinação de severidade e impacto geralmente determina a prioridade final. Analisar por severidade ajuda a entender como a organização lida com incidentes que têm consequências significativas para o negócio. Esse atributo é usado nos Dashboards para segmentar tempos de resolução e performance do SLA, garantindo que os problemas de maior impacto recebam o nível adequado de atenção e recursos durante todo o ciclo de vida. Por que isso importa Ele mede o impacto de um incidente no negócio, permitindo uma análise focada na redução dos problemas mais prejudiciais. Onde obter Este é um campo padrão do Freshservice, disponível na API de Tickets como 'impact'. Os valores são numéricos. Exemplos BaixoMédioAlto
	Status do incidente IncidentStatus	O status atual do incidente em seu ciclo de vida, como Open, Pending, Resolved ou Closed.
Descrição O Status do incidente indica o estado atual do incidente. As mudanças de status são eventos essenciais que formam a base do mapa de processo descoberto, como passar 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 permanecem tempo demais no estado 'Pending' aguardando a resposta do usuário. Ele também é essencial para definir os pontos inicial e final dos cálculos de tempo de ciclo. Por que isso importa Ele acompanha o progresso do incidente ao longo do ciclo de vida e ajuda a identificar as etapas em que os 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 andamentoPendenteResolvidoFechado
	Tempo-alvo do SLA de resolução ResolutionSlaTargetTime	O timestamp até o qual se espera que o incidente seja resolvido de acordo com a política de SLA.
Descrição Este atributo armazena a data e a hora específicas que servem como prazo para resolver um incidente. Esse objetivo é determinado pela política de Service Level Agreement (SLA) aplicada ao ticket, que normalmente depende de fatores como a prioridade. Esse tempo-alvo é essencial para calcular o KPI 'Taxa de cumprimento do SLA' e alimentar o 'Dashboard de performance do SLA'. Ao comparar o timestamp real da resolução com esse objetivo, podemos determinar se um incidente foi resolvido no prazo ou violou o SLA. Isso é fundamental para medir a conformidade com o nível de serviço. Por que isso importa Ele fornece o prazo para a resolução, necessário para calcular a conformidade com o 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 registro ReportingChannel	O método ou canal pelo qual o incidente foi reportado, como e-mail, portal ou telefone.
Descrição O Canal de registro, também conhecido como origem, identifica como um incidente entrou no sistema de suporte. Os canais comuns incluem e-mail, portal de autoatendimento, ligações telefônicas ou chat. Analisar esse atributo ajuda a avaliar a eficiência dos diferentes canais de registro. O Dashboard 'Eficiência do canal de registro' compara o volume de incidentes e o tempo médio de resolução por canal para determinar quais métodos são mais eficazes e quais podem exigir melhorias no processo. Por exemplo, incidentes registrados pelo portal podem ser resolvidos mais rapidamente se já contiverem informações mais estruturadas. Por que isso importa Ele ajuda a identificar os canais de registro mais eficientes e revela oportunidades para melhorar o processo de entrada de incidentes. Onde obter Disponível na API de Tickets do Freshservice como o campo 'source'. Os valores são numéricos. Exemplos E-mailPortalTelefoneChat
	Causa raiz RootCause	O motivo subjacente ou a causa raiz identificada para o incidente após a investigação.
Descrição O atributo Causa raiz registra o problema fundamental que levou ao incidente. Essas informações normalmente são preenchidas pelos agentes de suporte durante ou após a resolução, como parte de um 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 analisar as causas raiz comuns, as organizações conseguem passar da correção reativa de incidentes para o gerenciamento proativo de problemas, implementando soluções permanentes que evitam incidentes futuros e reduzem problemas recorrentes. Por que isso importa Ele permite o gerenciamento proativo de problemas ao ajudar a identificar e eliminar as causas subjacentes dos incidentes recorrentes. Onde obter Este costuma ser um campo personalizado no Freshservice, pois a funcionalidade padrão pode ser limitada. Verifique a configuração de 'Ticket Fields' em busca de um campo chamado 'Root Cause' ou semelhante. Exemplos Bug de softwareErro de configuração de redeProblema de treinamento do usuárioFalha de hardware
	Contagem de transferências HandoffCount	O número de vezes que um incidente foi transferido entre diferentes agentes ou grupos.
Descrição A Contagem de transferências é uma métrica calculada que quantifica o número de reatribuições sofridas por um incidente durante seu ciclo de vida. Cada alteração no atributo 'AssignedAgent' ou 'AssignedGroup' incrementa essa contagem. Uma contagem alta de transferências costuma indicar ineficiência no processo, roteamento inicial incorreto ou falta de conhecimento por parte dos agentes. Essa métrica dá suporte diretamente ao KPI 'Contagem de transferências de incidentes' e ao Dashboard 'Análise de atrasos em transferências e repasses', ajudando a identificar incidentes ou caminhos do processo com transferências excessivas que causam atrasos. Por que isso importa Ele quantifica o retrabalho e as reatribuições, ajudando a identificar ineficiências causadas por roteamento incorreto ou lacunas de conhecimento. Onde obter Esta é uma métrica calculada, derivada da contagem do número de valores distintos ou alterações nos campos 'AssignedAgent' ou 'AssignedGroup' ao longo do ciclo de vida de um único incidente. Exemplos 0125
	Departamento do solicitante RequestersDepartment	O departamento ao qual pertence o usuário que reportou o incidente.
Descrição Este atributo identifica o departamento de negócio do solicitante, como 'Vendas', 'Finanças' ou 'TI'. Essas informações normalmente vêm do perfil do usuário no Freshservice. Analisar os incidentes por departamento do solicitante pode revelar se determinadas unidades de negócio são afetadas de forma desproporcional por problemas ou se existem problemas específicos de um departamento. Isso fornece um contexto valioso para entender o impacto dos incidentes no negócio e pode ajudar a priorizar correções que afetam departamentos críticos. Por que isso importa Ele fornece contexto de negócio, permitindo analisar tendências de incidentes e impactos em departamentos específicos. Onde obter Essas informações estão vinculadas ao solicitante do ticket. Elas podem ser recuperadas no endpoint da API 'Requesters' usando o 'requester_id' do ticket e, depois, acessando o 'department_id' e o nome. Exemplos VendasMarketingFinançasRecursos Humanos
	Reaberto IsReopened	Um indicador calculado que é verdadeiro quando um incidente foi reaberto depois de ser resolvido ou fechado.
Descrição Este atributo booleano é um indicador calculado que identifica incidentes reabertos. Ele é definido como verdadeiro quando, depois de chegar ao estado 'Resolved' ou 'Closed', o status de um incidente volta para um estado aberto ou em andamento. Esse indicador é essencial para calcular o KPI 'Taxa de reabertura de incidentes' e para o Dashboard 'Incidentes recorrentes'. Uma taxa alta de incidentes reabertos pode indicar problemas na qualidade da resolução inicial, análise de causa raiz incompleta ou encerramento prematuro. Analisar esses casos ajuda a melhorar a qualidade e a sustentabilidade das correções. Por que isso importa Ele identifica falhas no processo de resolução, destacando incidentes em que a correção inicial foi ineficaz e gerou retrabalho. Onde obter Este é um campo calculado, derivado da sequência de atividades no Event Log. Ele é verdadeiro quando ocorre uma atividade como 'Incident Reopened' ou quando uma atividade de estado aberto vem depois de uma atividade de estado fechado para o mesmo Incident ID. Exemplos truefalse
	SLA violado IsSlaBreached	Um indicador calculado que é verdadeiro quando o incidente não foi resolvido dentro do tempo-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 tempo-alvo do SLA. Ele é derivado da comparação entre o timestamp real da resolução e 'ResolutionSlaTargetTime'. Esse indicador é uma entrada direta para o KPI 'Taxa de cumprimento do SLA' e para o 'Dashboard de performance do SLA'. Ele simplifica a análise ao fornecer um resultado binário claro para a performance do SLA de cada incidente, permitindo agregações e análises de tendências com facilidade. Também ajuda a identificar rapidamente o volume e o percentual de incidentes que não cumprem os compromissos de serviço. Por que isso importa Ele mede diretamente a conformidade com o SLA de cada incidente, facilitando o cálculo das taxas gerais de cumprimento e a identificação de áreas problemáticas. Onde obter Este é um campo calculado, derivado durante a transformação dos dados pela comparação do timestamp de 'Incident Resolved' com o campo 'ResolutionSlaTargetTime'. Exemplos truefalse
	Solução alternativa fornecida WorkaroundProvided	Um indicador que mostra se um workaround temporário foi fornecido ao usuário antes da resolução final.
Descrição Este atributo booleano indica se uma correção temporária ou um workaround foi implementado para reduzir o impacto do incidente enquanto uma solução permanente era desenvolvida. Isso costuma ser acompanhado por uma caixa de seleção ou um status específico. No Process Mining, esse atributo dá suporte ao Dashboard 'Métricas de eficácia do workaround'. Ele permite comparar os tempos de resolução de incidentes com e sem workarounds, ajudando a determinar se o fornecimento de correções temporárias reduz efetivamente a interrupção do negócio e contribui para uma resolução geral mais rápida na visão do usuário. Por que isso importa Ele ajuda a medir a eficácia dos workarounds temporários na redução do impacto dos incidentes e na aceleração da resolução percebida. Onde obter Normalmente, este é um campo booleano personalizado, como uma caixa de seleção. Sua existência deve ser verificada na configuração de 'Ticket Fields' do Freshservice. Exemplos truefalse

Obrigatório Recomendado Opcional

Atividades de Gestão de Incidentes

Estas são as principais etapas e marcos do processo que você deve registrar no seu Event Log para realizar uma descoberta precisa do processo e identificar 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. Isso pode ser feito automaticamente por meio de regras de roteamento ou manualmente por um despachante. Essa atividade é capturada acompanhando o primeiro preenchimento do campo "Group" no audit log do incidente.
Por que isso importa Acompanhar as atribuições é essencial para medir os tempos de primeira resposta e identificar gargalos no processo de despacho. Isso ajuda a analisar com que eficiência os incidentes são encaminhados à equipe correta. Onde obter Inferido a partir da primeira entrada no activity log do incidente que preenche ou altera o campo "Group". Captura Identifique o primeiro registro de data e hora em que o campo "Group" é preenchido para um incidente. Tipo de evento inferred
	Incidente fechado	Representa o encerramento final e formal do registro do incidente. Isso normalmente acontece automaticamente após um período definido no estado 'Resolved' ou pode ser feito manualmente por um agente. Esse evento marca o fim do ciclo de vida do incidente.
Por que isso importa Esta atividade é o ponto final definitivo do processo. O tempo total até esse evento representa a duração completa do ciclo de vida do incidente, incluindo eventuais períodos de confirmação do usuário. Onde obter Inferido do registro de atividades do incidente ao identificar quando o campo 'Status' é atualizado para 'Closed'. Captura Use o timestamp da entrada do registro de atividades 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 monitorando as alterações no campo "Priority" dentro do histórico do incidente.
Por que isso importa Uma priorização incorreta ou atrasada pode causar violações de SLA e uma alocação ineficiente de recursos. Analisar essa atividade ajuda a garantir que os incidentes críticos recebam atenção imediata. Onde obter Inferido a partir do activity log do incidente, que registra todas as atualizações no campo "Priority". Captura Use os registros de data e hora 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. Esse é o ponto de partida do ciclo de vida do incidente, normalmente acionado por um usuário final por meio de um portal ou e-mail, ou por um agente da central de serviços que cria um ticket em nome do usuário. Esse evento é registrado explicitamente com um registro de data e hora de criação.
Por que isso importa Essa atividade é o principal evento de início de todo o processo. Analisar o tempo entre esse evento e a resolução é fundamental para medir os tempos totais de ciclo e a adesão aos SLAs. Onde obter Capturado a partir do registro de data e hora de criação da tabela de incidentes. O Freshservice registra esse dado explicitamente para cada novo ticket. Captura Use o registro de data e hora "Created at" do registro principal do incidente. Tipo de evento explicit
	Incidente resolvido	Marca o momento em que o agente implementou 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 o relógio do SLA.
Por que isso importa Esse é um marco crítico para medir o Time to Resolution (TTR). O período entre "Resolved" e "Closed" é importante para analisar atrasos na confirmação do usuário e políticas de encerramento automático. Onde obter Inferido a partir do activity log do incidente, identificando quando o campo "Status" é atualizado para "Resolved". Captura Use o registro de data e hora da entrada do activity log referente à alteração 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. Essa é uma ação distinta no Freshservice, realizada antes da alteração do status para "Resolved". A ação e seu conteúdo são registrados explicitamente.
Por que isso importa Isso marca a identificação de uma solução. O tempo entre esse momento e o status "Incident Resolved" pode indicar uma revisão interna ou um esforço adicional de documentação. Onde obter Capturado a partir do registro de data e hora em que uma nota de resolução é adicionada ao incidente, informação registrada no histórico de conversas. Captura Identifique o registro de data e hora da entrada "Resolution Note" no conversation log do incidente. Tipo de evento explicit
	Status alterado para In Progress	Essa atividade marca o início oficial da investigação ativa e do trabalho no incidente. Ela é capturada quando um agente altera o status do incidente para "In Progress". Essa é uma alteração de status padrão registrada no histórico de atividades do ticket.
Por que isso importa Esse marco ajuda a diferenciar o tempo de espera do tempo de trabalho ativo. Analisar quanto tempo um incidente permanece "In Progress" é essencial para entender o esforço de resolução. Onde obter Inferido a partir do activity log do incidente, identificando quando o campo "Status" é atualizado para "In Progress". Captura Filtre o activity log por uma alteração de status para "In Progress" e use o registro de data e hora correspondente. Tipo de evento inferred
	Agente atribuído ao incidente	Essa atividade marca o momento em que um agente específico é designado para tratar o incidente. Ela representa a responsabilidade individual pelo ticket. A atribuição é registrada no histórico de atividades do ticket, mostrando qual agente foi designado e quando.
Por que isso importa Isso permite analisar a carga de trabalho, a performance dos agentes e o tempo necessário para que um incidente seja assumido por uma pessoa após a atribuição ao grupo. É essencial para os Dashboards de performance dos agentes. Onde obter Acompanhado por meio das alterações no campo "Agent" do activity log ou da trilha de auditoria do incidente. Captura Identifique os registros de data e hora correspondentes às alterações no campo "Agent". Tipo de evento inferred
	Incidente reaberto	Ocorre quando um incidente anteriormente marcado como "Resolved" retorna a um status aberto, normalmente porque o usuário não concordou com a resolução. Isso é inferido por uma alteração de status de "Resolved" de volta para um estado como "Open" ou "In Progress".
Por que isso importa Uma taxa alta de reabertura aponta para problemas na qualidade da resolução ou correções incompletas. Essa é uma métrica importante para analisar retrabalho e a performance dos agentes. Onde obter Inferido do registro de atividades do incidente ao detectar uma mudança de status de 'Resolved' para um status ativo. Captura Filtre o registro de atividades em busca de uma 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 representa um handoff no processo de resolução. Esse evento é inferido pela detecção de alterações posteriores nos campos "Agent" ou "Group" após a atribuição inicial.
Por que isso importa Reatribuições frequentes, ou handoffs, geralmente indicam ineficiências no processo, lacunas de conhecimento ou roteamento inicial incorreto. Analisar esses eventos ajuda a identificar e reduzir atrasos. Onde obter Inferido a partir do activity log do incidente, acompanhando qualquer alteração nos campos "Agent" ou "Group" após a primeira atribuição. Captura Detecte alterações nos campos "Agent" ou "Group" no histórico de auditoria do ticket. Tipo de evento inferred
	Meta de SLA violada	Esse é um evento calculado que ocorre quando o tempo decorrido de um incidente ultrapassa a meta de SLA definida para resposta ou resolução. O Freshservice acompanha o status do SLA internamente, e esse evento pode ser derivado comparando os registros de data e hora com as políticas de SLA.
Por que isso importa Mede diretamente a Conformidade com os compromissos de nível de serviço. Identificar quando e por que ocorrem violações é essencial para o Dashboard de Performance de SLA e para a melhoria contínua. Onde obter Calculado comparando o registro de data e hora da resolução ou da resposta com o prazo definido pela meta de SLA. O Freshservice geralmente sinaliza os tickets como "SLA Violated". Captura Derive comparando o registro de data e hora "Resolved at" com o registro "Due by", ou quando o campo "SLA Status" muda para "Violated". Tipo de evento calculated
	Primeira resposta enviada	Essa atividade representa a primeira comunicação de um agente com o usuário após o relato do incidente. Pode ser uma nota pública ou uma resposta direta. O Freshservice registra todas as comunicações dos agentes com registros de data e hora.
Por que isso importa Cumprir o SLA de primeira resposta é um KPI essencial para a satisfação dos clientes. Essa atividade permite medir e analisar a rapidez com que os agentes interagem com novos incidentes. Onde obter Identificado encontrando o registro de data e hora da primeira nota pública ou resposta adicionada por um agente no conversation log do incidente. Captura Filtre o histórico de conversas do incidente pela primeira entrada feita por um agente. Tipo de evento explicit
	Solução alternativa fornecida	Essa atividade indica que uma solução temporária ou alternativa foi comunicada ao usuário para reduzir o impacto do incidente. Capturá-la geralmente exige uma configuração específica do sistema, como uma caixa de seleção dedicada, um tipo específico de nota ou uma análise de palavras-chave nas notas dos agentes.
Por que isso importa Isso ajuda a analisar a eficácia das soluções alternativas na redução do impacto nos negócios e sua relação com o tempo de resolução final. Também dá suporte ao Dashboard de Métricas de Eficácia das Soluções Alternativas. Onde obter Provavelmente, esse não é um evento explícito. Ele pode ser inferido sinalizando notas que contenham palavras-chave como "workaround" ou quando um campo personalizado "Workaround Provided" é usado e sua alteração é registrada. Captura Inferido a partir de uma alteração em um campo personalizado ou da análise de palavras-chave nas notas dos agentes. Tipo de evento inferred
	Status alterado para Pending	Representa o momento em que o processo de resolução é pausado, normalmente enquanto se aguardam informações do usuário ou de terceiros. Isso é inferido a partir de uma alteração de status para qualquer estado "Pending". O tempo gasto nesse estado geralmente é excluído dos cálculos de SLA.
Por que isso importa Identificar o tempo gasto em estados pendentes é essencial para entender dependências externas e atrasos. Isso ajuda a separar o tempo de trabalho do agente do tempo de espera. Onde obter Inferido a partir do activity log do incidente quando o campo "Status" é atualizado para um valor como "Pending" ou "Awaiting User Response". Captura Filtre o activity log por alterações de status para qualquer estado pendente e use o registro de data e hora associado. Tipo de evento inferred

Recomendado Opcional

Guias de extração

Como obter seus dados do Freshservice

Etapas

Acesse o Freshservice Analytics: entre na sua instância do Freshservice com uma conta que tenha permissão para acessar e criar relatórios. No menu principal, acesse o módulo Analytics.
Crie um novo relatório: clique no botão New Report. Informe um nome descritivo, como "Incident Management Event Log". Quando solicitado a escolher uma fonte de dados, selecione o módulo Incident Management.
Selecione o widget do relatório: no editor de relatórios, adicione um novo widget e selecione o tipo Table. Ele será a base dos dados do seu Event Log.
Adicione as colunas de dados principais: no painel de fontes de dados à direita, arraste os campos necessários para a configuração de colunas da tabela. Comece com Incident ID, Created at, Agent, Group, Priority, Severity, Status e Category.
Inclua os dados de atividades: para capturar eventos individuais, você precisa combinar ou incluir dados das atividades dos chamados. Adicione a fonte de dados Activities ao widget. Nessa fonte, adicione Performed at, que representa o carimbo de data e hora do evento, e Activity description ou campos semelhantes que descrevam a alteração ocorrida.
Crie uma coluna calculada 'ActivityName': esta é a etapa mais importante. Crie uma nova coluna calculada ou um campo de fórmula. Use instruções IF aninhadas ou uma função CASE para converter os dados brutos das atividades nos valores necessários de ActivityName. Consulte a seção Query para ver a lógica detalhada de cada uma das 14 atividades.
Configure o 'EventTimestamp': crie outra coluna calculada para EventTimestamp. A lógica dessa coluna deve selecionar o carimbo de data e hora de Created at para a atividade 'Incident Reported' e o carimbo de data e hora de Performed at da atividade para todos os outros eventos.
Aplique filtros ao relatório: configure os filtros do relatório para restringir os dados. No mínimo, defina um filtro de intervalo de datas no campo 'Created at'. Recomenda-se um intervalo dos últimos 3 a 6 meses. Você também deve adicionar um filtro para incluir apenas chamados em que 'Ticket Type' seja 'Incident'.
Execute e refine o relatório: execute o relatório para gerar uma prévia dos dados. Revise o resultado para garantir que as colunas ActivityName e EventTimestamp estejam sendo preenchidas corretamente. Ajuste as fórmulas e os 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álises contínuas, você pode programar a execução e a exportação automáticas do relatório. Configure uma agenda, por exemplo, diária ou semanal, para enviar o CSV ao seu e-mail ou a outro destino.
Prepare os dados para upload: abra o arquivo CSV exportado. Renomeie os cabeçalhos das colunas para corresponder ao esquema exigido pelo ProcessMind: IncidentId, ActivityName, EventTimestamp, AssignedAgent, AssignedGroup etc. Adicione as colunas estáticas SourceSystem, com o valor 'Freshservice', e LastDataUpdate, com o carimbo de data e hora atual. O arquivo está pronto para upload.

Configuração

Módulo Analytics: esta extração exige acesso ao módulo Analytics do Freshservice, disponível em planos superiores, como Pro e Enterprise.
Permissões necessárias: sua conta de usuário precisa ter uma função com permissão para criar, editar e executar relatórios no módulo Analytics.
Intervalo de datas: é fundamental definir um filtro de intervalo de datas na data de criação dos incidentes para controlar o volume de dados. Recomenda-se um período móvel de 3 a 6 meses para equilibrar contexto histórico e performance.
Filtros do relatório: sempre filtre 'Ticket Type' para que seja igual a 'Incident', excluindo solicitações de serviço ou outros tipos de chamados da sua análise de processos.
Campos calculados: o método depende bastante do uso de campos calculados, ou fórmulas, para obter ActivityName e EventTimestamp de cada evento. É útil conhecer o editor de fórmulas do Freshservice.
Volume de dados: lembre-se de que, para cada incidente, essa extração gera várias linhas, uma para cada atividade. Em instâncias grandes do Freshservice, o arquivo CSV resultante pode ficar muito grande, afetando o tempo de geração do relatório e a velocidade da 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: confirme se o Python 3.6 ou superior está instalado, junto com as bibliotecas requests e pandas. Você pode instalá-las usando pip: pip install requests pandas.
Gere uma chave de API: entre na sua instância do Freshservice como administrador. Acesse Profile Settings clicando na sua foto de perfil no canto superior direito. Vá até a seção 'API Key' e copie sua chave de API pessoal. Trate essa chave como uma senha.
Configure o script: salve o código Python fornecido em um arquivo chamado extract_freshservice_incidents.py no seu computador.
Configure os parâmetros: abra o arquivo do script em um editor de texto. Atualize os valores de espaço reservado de FRESHSERVICE_DOMAIN, por exemplo, 'yourcompany.freshservice.com', API_KEY, a chave que você acabou de copiar, e START_DATE_STR, o início do período de extração desejado no formato 'YYYY-MM-DD'.
Entenda a lógica do script: primeiro, o script busca todos os chamados de incidentes criados depois da data inicial especificada. Em seguida, percorre cada página de resultados retornada pela API. Para cada chamado, faz uma segunda chamada à API para recuperar o histórico detalhado de atividades.
Geração do Event Log: o script processa os dados principais do chamado e seu registro 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 chamado, enquanto 'Status Changed to In Progress' é derivado de uma entrada específica no registro de atividades.
Derive eventos complexos: eventos como 'SLA Target Breached' são derivados. O script verifica se o SLA de resolução de um chamado foi violado. Se isso acontecer, ele cria um evento com o carimbo de data e hora da data due_by, indicando o momento em que a violação ocorreu.
Execute o script: abra um terminal ou prompt de comando, acesse o diretório onde salvou o script e execute-o com o comando: python extract_freshservice_incidents.py.
Acompanhe a execução: o script exibirá atualizações de progresso no console, mostrando quantos chamados foram processados. Dependendo do número de chamados e dos limites de requisições da API, isso pode levar algum tempo.
Revise o resultado: quando terminar, o script gerará um arquivo CSV chamado freshservice_incident_event_log.csv no mesmo diretório. Esse arquivo contém o Event Log completo.
Prepare para o upload: abra o arquivo CSV em um programa de planilhas para confirmar se as colunas IncidentId, ActivityName, EventTimestamp etc. foram preenchidas conforme esperado. O arquivo está pronto para upload no ProcessMind ou em outra ferramenta de Process Mining.

Configuração

FRESHSERVICE_DOMAIN: a URL específica do Freshservice da sua empresa, por exemplo, mycompany.freshservice.com. Esse parâmetro é obrigatório no script.
API_KEY: a chave de API pessoal de um usuário com permissões suficientes para ler todos os dados de incidentes. Esse parâmetro é obrigatório.
START_DATE_STR: a data inicial da extração de dados no formato 'YYYY-MM-DD'. Recomenda-se extrair inicialmente um período de 3 a 6 meses para obter uma análise relevante.
PAGE_SIZE: definido como 100, o máximo permitido pela API do Freshservice, para reduzir o número de chamadas à API e melhorar a performance. Em geral, não é recomendável alterar esse valor.
Limitação de requisições da API: o script inclui uma chamada básica time.sleep(1) após o processamento de cada chamado para respeitar os limites de requisições da API do Freshservice. Em instâncias de alto volume, talvez seja necessário ajustar esse intervalo para evitar erros.
Permissões necessárias: a chave de API usada deve pertencer a uma conta de usuário, como uma conta de serviço dedicada, com pelo menos as permissões da função 'SD Agent', garantindo acesso a todos os campos necessários dos chamados e aos registros de atividades em diferentes grupos de atendimento.

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

Confirme se seu plano do Freshservice e suas permissões de administrador permitem regras do Workflow Automator, ações de webhook, acesso a incidentes e acesso ao histórico de atividades dos tickets. Valide com a equipe responsável o endpoint de destino, o método de autenticação, os requisitos de TLS e a política de retenção.
Defina o contrato de eventos antes de configurar o automator. Use um objeto JSON por entrega de webhook com IncidentId, ActivityName, EventTimestamp, SourceSystem, LastDataUpdate, AssignedAgent, AssignedGroup, IncidentPriority, IncidentSeverity, IncidentStatus, IncidentCategory e ResolutionSlaTargetTime. Configure o receptor para preservar o payload original do webhook e a data e hora da entrega.
Crie uma regra do Workflow Automator para a criação de incidentes. Configure a regra para ser executada quando um incidente for criado e adicione uma ação de webhook que envie a atividade Incident Reported. Defina EventTimestamp como a data e hora de criação do incidente e ActivityName como Incident Reported.
Crie regras de atualização para alterações de atribuição, prioridade, status, comunicação, notas, SLA e encerramento. Configure condições usando os campos do incidente e o histórico de atividades disponíveis na sua conta do Freshservice. Cada regra deve enviar um evento de webhook separado sempre que a atividade correspondente ocorrer. Não dependa do ProcessMind para inferir atividades a partir de um instantâneo final do incidente.
Configure o mapeamento explícito de atividades. Envie Incident Assigned to Group quando o campo Group receber seu valor inicial; Agent Assigned to Incident quando o campo Agent receber seu valor inicial; Incident Prioritized quando Priority for definida ou alterada; First Response Sent quando a primeira resposta ou nota pública qualificada do agente for registrada; Incident Reassigned quando Agent ou Group mudar após a atribuição inicial; Status Changed to In Progress e Status Changed to Pending para as transições de status correspondentes; Workaround Provided somente quando houver um indicador de solução alternativa configurado; Resolution Note Added quando uma nota de resolução for adicionada; Incident Resolved quando o status mudar para Resolved; SLA Target Breached quando a condição de violação de SLA configurada for atendida; Incident Reopened quando o status mudar de Resolved para um status aberto; e Incident Closed quando o status mudar para Closed.
Configure o corpo da solicitação do webhook no formato JSON e inclua o identificador do incidente, o nome da atividade, a data e hora do evento, o sistema de origem, a última atualização dos dados e os atributos contextuais recomendados. Use as variáveis de webhook do Freshservice disponibilizadas pela sua conta. Se uma variável necessária não estiver disponível no editor de webhook, preencha-a no serviço receptor chamando uma interface aprovada do Freshservice ou deixe o valor vazio, em vez de inventá-lo.
Configure a idempotência e o tratamento das entregas no endpoint. Use um identificador de evento estável, se o Freshservice disponibilizar um. Caso contrário, crie uma chave de deduplicação com IncidentId, ActivityName, EventTimestamp e o identificador da entrega de origem. Retorne uma resposta HTTP de sucesso somente depois que o payload tiver sido aceito de forma durável.
Teste cada regra com incidentes controlados. Crie um incidente, atribua um grupo e um agente, altere a prioridade e o status, envie uma resposta qualificada, adicione uma solução alternativa e uma nota de resolução quando configuradas, resolva, reabra e feche o incidente. Teste separadamente uma violação de SLA usando uma política ou fila de teste controlada. Confirme que cada atividade esperada chega como um payload de webhook distinto.
Armazene os payloads dos webhooks em uma área de preparação durável, normalize as datas e horas para um único fuso horário e transforme cada payload em uma linha do Event Log. Preserve uma linha para cada atividade explícita do webhook. Preencha LastDataUpdate com a data e hora da atualização da extração ou ingestão, e não com a data e hora do evento de negócio.
Valide o Event Log em preparação, remova apenas entregas duplicadas exatas e mantenha repetições legítimas de atividades, como várias alterações de prioridade ou transições de status. Garanta que IncidentId, ActivityName, EventTimestamp, SourceSystem e LastDataUpdate estejam presentes em todas as linhas.
Exporte o Event Log normalizado como CSV ou em outro formato compatível com o ProcessMind. Use exatamente os nomes de coluna IncidentId, ActivityName, EventTimestamp, SourceSystem, LastDataUpdate, AssignedAgent, AssignedGroup, IncidentPriority, IncidentSeverity, IncidentStatus, IncidentCategory e ResolutionSlaTargetTime. Carregue o arquivo ou conecte a fonte de eventos preparada ao ProcessMind, mapeando IncidentId como identificador do caso e ActivityName como campo de atividade.

Configuração

Escopo do acionador: configure regras separadas do Workflow Automator para a criação de incidentes e para cada condição de atualização. Uma única regra ampla de atualização pode criar eventos duplicados ou ambíguos, a menos que o receptor aplique um mapeamento rigoroso de atividades.
Payload do webhook: inclua todos os atributos obrigatórios em cada payload. Inclua os atributos recomendados quando estiverem disponíveis no momento do evento. Preserve o payload bruto para auditoria e reprocessamento.
Semântica das atividades: as atribuições iniciais de grupo e agente devem ser diferenciadas das alterações posteriores. As alterações posteriores geram Incident Reassigned, enquanto o preenchimento inicial gera a atividade de atribuição inicial correspondente.
Tratamento de status: mapeie os valores exatos de status configurados na conta do Freshservice. Se a conta usar status personalizados de pendência ou abertura, configure mapeamentos explícitos para esses valores.
Primeira resposta: defina se uma resposta pública, uma nota pública ou outro tipo de comunicação será considerado válido. Aplique a definição de forma consistente e emita o evento somente para a primeira comunicação qualificada por incidente.
Detecção de solução alternativa: configure um campo dedicado, uma caixa de seleção, um tipo de nota ou uma regra de palavra-chave aprovada. Sem essa configuração, Workaround Provided não pode ser identificado com confiabilidade.
Violação de SLA: configure um acionador explícito de violação de SLA ou um processo agendado separado que compare o horário atual com ResolutionSlaTargetTime. Um snapshot final do incidente, sozinho, não é suficiente para reconstruir o carimbo de data e hora da violação.
Intervalo de datas: para a validação inicial, use aproximadamente 3 a 6 meses de incidentes. Para a operação em tempo real, comece a ingestão antes do período de análise desejado e mantenha o histórico de webhooks para reprocessamento.
Filtros: aplique somente filtros aprovados de empresa, workspace, departamento, serviço, categoria ou data. Não presuma nomes de campos ou sintaxe de filtros do Freshservice que não estejam disponíveis na configuração da conta.
Performance: use processamento assíncrono de webhooks, coloque as requisições recebidas em fila, faça gravações downstream em lote e crie índices para IncidentId e EventTimestamp. Evite chamadas síncronas de enriquecimento durante o recebimento do webhook.
Confiabilidade: configure novas tentativas, tratamento de dead letter, monitoramento e supressão de duplicatas. Registre as entregas com falha e reprocesse-as depois da correção.
Pré-requisitos: acesso de administrador, disponibilidade do Workflow Automator, permissões de webhook, um endpoint HTTPS, configuração de autenticação, recursos suficientes no plano do Freshservice e um processo de upload ou armazenamento compatível com o ProcessMind.
Segurança: use HTTPS, restrinja o acesso de entrada sempre que possível, alterne as credenciais, minimize os campos sensíveis e proteja as descrições e notas dos incidentes quando forem incluídas nos payloads.

a Consulta de exemplo config

const REQUIRED_ACTIVITIES = [
  "Incident Reported",
  "Incident Assigned to Group",
  "Agent Assigned to Incident",
  "Incident Prioritized",
  "First Response Sent",
  "Incident Reassigned",
  "Status Changed to In Progress",
  "Status Changed to Pending",
  "Workaround Provided",
  "Resolution Note Added",
  "Incident Resolved",
  "SLA Target Breached",
  "Incident Reopened",
  "Incident Closed"
];

const REQUIRED_COLUMNS = [
  "IncidentId",
  "ActivityName",
  "EventTimestamp",
  "SourceSystem",
  "LastDataUpdate",
  "AssignedAgent",
  "AssignedGroup",
  "IncidentPriority",
  "IncidentSeverity",
  "IncidentStatus",
  "IncidentCategory",
  "ResolutionSlaTargetTime"
];

function normalizeTimestamp(value) {
  if (value === null || value === undefined || value === "") {
    return null;
  }
  const date = new Date(value);
  if (Number.isNaN(date.getTime())) {
    throw new Error("Invalid timestamp: " + String(value));
  }
  return date.toISOString();
}

function textOrNull(value) {
  if (value === null || value === undefined || value === "") {
    return null;
  }
  return String(value);
}

function getField(payload, names) {
  for (const name of names) {
    if (payload[name] !== undefined && payload[name] !== null) {
      return payload[name];
    }
  }
  return null;
}

function normalizeWebhookPayload(payload, receivedAt) {
  const incidentId = getField(payload, ["IncidentId", "incident_id", "ticket_id", "id"]);
  const activityName = getField(payload, ["ActivityName", "activity_name"]);
  const eventTimestamp = getField(payload, ["EventTimestamp", "event_timestamp", "timestamp", "created_at", "updated_at"]);

  if (incidentId === null || incidentId === "") {
    throw new Error("IncidentId is required");
  }
  if (activityName === null || activityName === "") {
    throw new Error("ActivityName is required");
  }
  if (!REQUIRED_ACTIVITIES.includes(String(activityName))) {
    throw new Error("Unsupported ActivityName: " + String(activityName));
  }
  if (eventTimestamp === null || eventTimestamp === "") {
    throw new Error("EventTimestamp is required");
  }

  const row = {
    IncidentId: textOrNull(incidentId),
    ActivityName: textOrNull(activityName),
    EventTimestamp: normalizeTimestamp(eventTimestamp),
    SourceSystem: textOrNull(getField(payload, ["SourceSystem", "source_system"])) || "Freshservice",
    LastDataUpdate: normalizeTimestamp(getField(payload, ["LastDataUpdate", "last_data_update"])) || normalizeTimestamp(receivedAt),
    AssignedAgent: textOrNull(getField(payload, ["AssignedAgent", "assigned_agent", "agent"])),
    AssignedGroup: textOrNull(getField(payload, ["AssignedGroup", "assigned_group", "group"])),
    IncidentPriority: textOrNull(getField(payload, ["IncidentPriority", "incident_priority", "priority"])),
    IncidentSeverity: textOrNull(getField(payload, ["IncidentSeverity", "incident_severity", "severity"])),
    IncidentStatus: textOrNull(getField(payload, ["IncidentStatus", "incident_status", "status"])),
    IncidentCategory: textOrNull(getField(payload, ["IncidentCategory", "incident_category", "category"])),
    ResolutionSlaTargetTime: normalizeTimestamp(getField(payload, ["ResolutionSlaTargetTime", "resolution_sla_target_time"]))
  };

  for (const column of REQUIRED_COLUMNS) {
    if (!(column in row)) {
      throw new Error("Missing output column: " + column);
    }
  }
  return row;
}

function deduplicateRows(rows) {
  const seen = new Set();
  return rows.filter((row) => {
    const key = [
      row.IncidentId,
      row.ActivityName,
      row.EventTimestamp,
      row.SourceSystem
    ].join("|");
    if (seen.has(key)) {
      return false;
    }
    seen.add(key);
    return true;
  });
}

async function processWebhookBatch(webhookPayloads, receivedAt) {
  const rows = webhookPayloads.map((payload) => normalizeWebhookPayload(payload, receivedAt));
  const deduplicatedRows = deduplicateRows(rows);
  deduplicatedRows.sort((left, right) => {
    if (left.IncidentId !== right.IncidentId) {
      return left.IncidentId.localeCompare(right.IncidentId);
    }
    return left.EventTimestamp.localeCompare(right.EventTimestamp);
  });
  return deduplicatedRows;
}

module.exports = {
  REQUIRED_ACTIVITIES,
  REQUIRED_COLUMNS,
  normalizeWebhookPayload,
  deduplicateRows,
  processWebhookBatch
};

Pronto para começar?

Use este Template para configurar seus dados corretamente e obter insights valiosos sobre seus Workflows de gerenciamento de incidentes. Comece hoje sua jornada rumo a tempos de resolução otimizados.

Voltar ao guia de melhoria Baixar Template

Pare as violações de SLA: otimize o gerenciamento de incidentes hoje

Junte-se às empresas que reduziram o MTTR em 35% e evitaram violações de SLA dispendiosas.

Começar o teste grátis

Teste grátis por 14 dias, sem necessidade de cartão de crédito.

Seu Template de dados de gerenciamento de incidentes

Seu Template de dados de gerenciamento de incidentes

Atributos de Gestão de Incidentes

Atividades de Gestão 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 usando a API REST do Freshservice

Etapas

Configuração

a Consulta de exemplo python

Envio de dados em tempo real por Webhooks do Workflow Automator

Etapas

Configuração

a Consulta de exemplo config

Pronto para começar?

Pare as violações de SLA: otimize o gerenciamento de incidentes hoje

Seu Template de dados de gerenciamento de incidentes

Seu Template de dados de gerenciamento de incidentes

Atributos de Gestão de Incidentes

Atividades de Gestão 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 usando a API REST do Freshservice

Etapas

Configuração

a Consulta de exemplo python

Envio de dados em tempo real por Webhooks do Workflow Automator

Etapas

Configuração

a Consulta de exemplo config

Pronto para começar?

Pare as violações de SLA: otimize o gerenciamento de incidentes hoje

Valorizamos sua privacidade