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

Seu Template de dados para gestão de incidentes

Freshservice

Atributos da gestão de incidentes(19) Atividades da gestão de incidentes(14) Guias de extração(3)

Seu Template de dados para gestão de incidentes

Este Template ajuda você a preparar os dados para analisar a gestão de incidentes com eficiência. Ele apresenta os atributos essenciais a coletar, as atividades importantes a acompanhar e orientações práticas para extrair essas informações do sistema de origem. Use este material para simplificar a preparação dos dados.

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

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

Baixar Template

Atributos da gestão de incidentes

Estes são os campos de dados recomendados para incluir no Event Log e analisar seu processo de gestão de incidentes de forma abrangente.

5 Obrigatório 7 Recomendado 7 Opcional

	Nome	Descrição
	ID do incidente IncidentId	Identificador exclusivo de cada registro de incidente, usado como chave primária para acompanhar todo o ciclo de vida do incidente.
Descrição O ID do incidente é a base da análise de gerenciamento de incidentes. Ele funciona como ID do caso, reunindo todas as atividades, datas e horas e alterações de atributos relacionadas em uma única jornada. Em Process Mining, cada registro do Event Log está associado a um ID do incidente, o que permite reconstruir o fluxo completo do processo 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 distinguir os incidentes e analisar seus caminhos, do registro à resolução. Por que isso importa Identifica cada incidente de forma exclusiva, permitindo acompanhar e analisar todo o seu ciclo de vida, da criação ao encerramento. Onde encontrar Este é o identificador principal de um chamado. Na API de chamados do Freshservice, ele está disponível no campo 'id' do objeto do chamado. Exemplos INC-10234INC-10235INC-10236
	Data e hora do evento EventTimestamp	A data e a hora exatas em que a atividade ou o evento ocorreu.
Descrição A data e hora do evento, ou hora de início, marca o momento exato em que uma atividade ocorreu. Cada atividade do ciclo de vida do incidente, da criação ao encerramento, tem uma data e hora associadas. Esse atributo é essencial para todas as análises de Process Mining baseadas em tempo. Ele é usado para ordenar eventos cronologicamente, calcular o intervalo entre atividades, medir o tempo de ciclo total do caso e analisar tempos de espera. Também é a base para criar Dashboards que acompanham a performance do SLA, atrasos no handoff e tempos gerais de resolução. Por que isso importa Mostra a ordem cronológica dos eventos, essencial para calcular durações, analisar tempos de ciclo e entender a performance do processo. Onde encontrar Este dado é derivado de vários campos de data e hora do Freshservice, como 'created_at' e 'updated_at', além das datas e horas registradas na conversa ou nos logs de auditoria do chamado. Exemplos 2023-10-26T10:00:00Z2023-10-26T10:05:14Z2023-10-27T14:30:00Z
	Nome da atividade ActivityName	Nome da atividade ou do evento de negócio específico que ocorreu em determinado momento do ciclo de vida do incidente.
Descrição O nome da atividade descreve uma etapa ou um evento do processo de gerenciamento de incidentes, como 'Incidente atribuído ao grupo', 'Status alterado para pendente' ou 'Incidente resolvido'. Essas atividades são identificadas a partir das mudanças nos dados do incidente ao longo do tempo. Esse atributo é fundamental para Process Mining, pois define os nós do mapa de processos descoberto. Ao analisar a sequência e a frequência dessas atividades, as organizações podem 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 Define as etapas do mapa de processos e permite visualizar e analisar o fluxo de resolução de incidentes, os gargalos e os desvios. Onde encontrar Este atributo não corresponde a um campo direto do Freshservice. Ele é derivado de mudanças em propriedades do chamado, como status, prioridade, atribuição de agente ou grupo e inclusão de notas. Exemplos Incidente registradoIncidente atribuído a um grupoNota de resolução adicionadaIncidente resolvido
	Sistema de origem SourceSystem	Sistema do qual os dados foram extraídos, geralmente o 'Freshservice'.
Descrição Este atributo identifica a origem dos dados. Neste contexto, o valor será sempre 'Freshservice', mas esse campo é essencial em ambientes que combinam dados de vários sistemas para oferecer uma visão completa do processo. Incluir o atributo Sistema de origem é uma boa prática de governança e rastreabilidade de dados. Isso deixa clara a procedência dos dados, o que é importante para validação, depuração e futuras expansões do projeto de Process Mining para outros sistemas de gerenciamento de serviços ou operações. Por que isso importa Garante a rastreabilidade e a governança dos dados ao identificar claramente a origem dos dados de gerenciamento de incidentes. Onde encontrar Geralmente, é um valor estático adicionado durante a transformação dos dados (ETL) para identificar o conjunto de dados. Exemplos FreshserviceFreshservice-EUFreshservice-PROD
	Última atualização dos dados LastDataUpdate	Data e hora que indicam quando os dados deste processo foram atualizados ou extraídos pela última vez.
Descrição Este atributo registra a data e hora da última atualização de todo o conjunto de dados 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 para manter a consistência. Na análise, essa informação é essencial para entender a atualidade dos dados e o período abrangido pelos Dashboards e KPIs. Ela ajuda os usuários a confiar na atualidade dos insights e a entender se os incidentes mais recentes estão incluídos na análise. Por que isso importa Informa aos usuários quando os dados foram atualizados, deixando claro o período abrangido pela análise. Onde encontrar É uma data e hora de metadados gerada durante o processo de extração dos dados (ETL). Exemplos 2023-11-01T02:00:00Z2023-11-02T02:00:00Z
	Agente atribuído AssignedAgent	Nome ou ID do agente de suporte atualmente responsável por resolver o incidente.
Descrição O agente atribuído identifica o profissional da central de serviços responsável pelo incidente em determinado momento. As mudanças nesse atributo representam a transferência de responsabilidade entre agentes. Esse atributo é essencial para analisar a performance. Com ele, é possível 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 permite analisar handoffs entre agentes, que podem causar atrasos e ineficiências. Ao acompanhar as atribuições, os gestores podem identificar necessidades de treinamento e reconhecer os integrantes da equipe com melhor performance. Por que isso importa Permite analisar a performance dos agentes, a distribuição da carga de trabalho e o impacto dos handoffs entre agentes nos tempos de resolução. Onde encontrar Disponível na API de chamados do Freshservice no campo 'responder_id'. Esse ID pode ser associado à API de agentes para obter o nome do agente. Exemplos John DoeJane SmithSupportBot
	Categoria do incidente IncidentCategory	Categoria usada para classificar o incidente, como hardware, software ou rede.
Descrição A categoria do incidente permite classificá-lo pelo tipo de problema reportado. Essa classificação hierárquica ajuda a encaminhar o incidente à equipe correta 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 classificação inicial incorreta aumenta o tempo de resolução por causa de reatribuições. Ao agrupar incidentes por categoria, as organizações podem identificar problemas recorrentes, entender onde se concentra a maior parte do esforço de suporte e direcionar iniciativas de melhoria. Por que isso importa Permite analisar tendências de incidentes e ajuda a determinar se uma categorização incorreta está causando atrasos na resolução. Onde encontrar Este é um campo padrão e personalizável do Freshservice. Ele está disponível na API de chamados como 'category', com os campos relacionados 'sub_category' e 'item_category'. Exemplos HardwareSoftwareProblema de redeAcesso à conta
	Gravidade do incidente IncidentSeverity	Nível de gravidade do incidente, que indica seu impacto nos negócios.
Descrição A gravidade do incidente mede o impacto que ele tem nos negócios e costuma ser classificada como baixa, média, alta ou crítica. Embora esteja relacionada à prioridade, a gravidade se concentra no impacto, enquanto a prioridade se concentra na urgência. A combinação entre gravidade e impacto costuma determinar a prioridade final. Analisar os incidentes por gravidade ajuda a entender como a organização lida com aqueles que têm consequências significativas para os negócios. Esse atributo é usado em Dashboards para segmentar tempos de resolução e performance do SLA, garantindo que os problemas de maior impacto recebam a atenção e os recursos adequados durante todo o ciclo de vida. Por que isso importa Mede o impacto do incidente nos negócios e permite concentrar a análise nos problemas mais prejudiciais. Onde encontrar Este é um campo padrão do Freshservice, disponível na API de chamados como 'impact'. Os valores são numéricos. Exemplos BaixaMédiaAlta
	Grupo atribuído AssignedGroup	Grupo ou equipe de suporte atualmente responsável pelo incidente.
Descrição O grupo atribuído indica qual equipe, como 'Suporte de nível 1', 'Equipe de redes' ou 'Administradores de banco de dados', é responsável pelo incidente. Mudanças nesse atributo indicam uma escalação ou transferência entre equipes de diferentes áreas. Analisar o grupo atribuído é essencial para entender atrasos em handoffs e transferências. O Process Mining pode mostrar 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 equipes. Por que isso importa Acompanha qual equipe é responsável, informação essencial para analisar handoffs, escalações e atrasos entre equipes. Onde encontrar Disponível na API de chamados do Freshservice no campo 'group_id'. Esse ID pode ser associado à API de grupos para obter o nome do grupo. Exemplos Central de serviçosOperações de redeSuporte de infraestrutura
	Prazo do SLA para resolução ResolutionSlaTargetTime	Data e hora até as quais 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 que definem o prazo para resolver um incidente. Esse prazo é determinado pela política do Acordo de Nível de Serviço (SLA) aplicada ao chamado e costuma depender de fatores como a prioridade. Esse prazo é essencial para calcular o KPI 'Taxa de cumprimento do SLA' e alimentar o Dashboard de performance do SLA. Ao comparar a data e hora da resolução real com esse prazo, é possível determinar se o incidente foi resolvido a tempo ou se houve violação do SLA. Isso é fundamental para medir a conformidade com o nível de serviço. Por que isso importa Define o prazo para a resolução, necessário para calcular a conformidade com o SLA e identificar incidentes em risco. Onde encontrar Disponível na API de chamados do Freshservice nos 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
	Prioridade do incidente IncidentPriority	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 importante que determina a rapidez e o foco necessários para tratar um incidente. Geralmente, ela é definida em uma escala como baixa, média, alta e urgente e costuma determinar as metas de SLA. Em Process Mining, a prioridade é uma dimensão essencial para filtros e análises. Ela permite comparar os processos de resolução de incidentes de alta e baixa prioridade e verificar se os problemas críticos estão sendo tratados com eficiência. Os Dashboards costumam segmentar métricas como tempo de ciclo e cumprimento do SLA por prioridade, gerando insights acionáveis para os gestores de suporte. Por que isso importa 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 encontrar Disponível na API de chamados do Freshservice no campo 'priority'. Os valores são numéricos, por exemplo, 1 para baixa e 4 para urgente. Exemplos BaixaMédiaAltaUrgente
	Status do incidente IncidentStatus	Status atual do incidente no ciclo de vida, como aberto, pendente, resolvido ou encerrado.
Descrição O status do incidente indica seu estado atual. As mudanças de status são eventos importantes que formam a base do mapa de processos descoberto, como a passagem de 'In Progress' para 'Pending' ou de 'Resolved' para 'Closed'. Esse atributo é fundamental para entender a jornada do incidente. Analisar o tempo em cada status ajuda a identificar gargalos, como incidentes que passam tempo demais no estado 'Pending' aguardando uma resposta do usuário. O atributo também é essencial para definir os pontos inicial e final dos cálculos de tempo de ciclo. Por que isso importa Acompanha o andamento do incidente ao longo do ciclo de vida e ajuda a identificar etapas em que os atrasos são frequentes. Onde encontrar Disponível na API de chamados do Freshservice no campo 'status'. Os valores são numéricos. Exemplos AbertoEm andamentoPendenteResolvidoEncerrado
	Canal de registro ReportingChannel	Método ou canal usado para reportar o incidente, como e-mail, portal ou telefone.
Descrição O canal de registro, também chamado de origem, identifica como um incidente chegou ao sistema de suporte. Entre os canais mais comuns estão e-mail, portal de autoatendimento, telefone e chat. Analisar esse atributo ajuda a avaliar a eficiência dos diferentes canais de registro. O Dashboard 'Eficiência dos canais 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 precisar de melhorias no processo. Por exemplo, incidentes registrados pelo portal podem ser resolvidos mais rapidamente quando já incluem informações estruturadas. Por que isso importa Ajuda a identificar os canais de registro mais eficientes e revela oportunidades para melhorar o processo de entrada de incidentes. Onde encontrar Disponível na API de chamados do Freshservice no campo 'source'. Os valores são numéricos. Exemplos E-mailPortalTelefoneChat
	Causa raiz RootCause	Motivo subjacente ou 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. Em geral, os agentes de suporte preenchem essa informação durante ou após a resolução, como parte da análise de causa raiz. 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 mais comuns, as organizações podem deixar de apenas corrigir incidentes de forma reativa e passar a gerenciar problemas proativamente, implementando soluções permanentes que previnem novos incidentes e reduzem recorrências. Por que isso importa Permite gerenciar problemas de forma proativa, ajudando a identificar e eliminar as causas subjacentes dos incidentes recorrentes. Onde encontrar Esse costuma ser um campo personalizado no Freshservice, pois a funcionalidade padrão pode ser limitada. Verifique a configuração de 'Ticket Fields' para encontrar um campo chamado 'Root Cause' ou algo semelhante. Exemplos Erro de softwareErro de configuração de redeProblema de treinamento do usuárioFalha de hardware
	Departamento do solicitante RequestersDepartment	Departamento ao qual pertence o usuário que reportou o incidente.
Descrição Este atributo identifica o departamento do solicitante, como 'Vendas', 'Finanças' ou 'TI'. Em geral, essa informação vem 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 ou se há problemas específicos de algum departamento. Isso oferece um contexto importante para entender o impacto dos incidentes nos negócios e ajuda a priorizar correções que afetam departamentos críticos. Por que isso importa Oferece contexto de negócio e permite analisar tendências de incidentes e seus impactos em departamentos específicos. Onde encontrar Essa informação está vinculada ao solicitante do chamado. Ela pode ser obtida no endpoint da API 'Requesters' usando o 'requester_id' do chamado e, em seguida, consultando o 'department_id' e o nome. Exemplos VendasMarketingFinançasRecursos humanos
	Número de handoffs HandoffCount	Número de vezes que um incidente foi transferido entre diferentes agentes ou grupos.
Descrição O número de handoffs é uma métrica calculada que quantifica quantas reatribuições ocorrem durante o ciclo de vida de um incidente. Cada mudança nos atributos 'AssignedAgent' ou 'AssignedGroup' aumenta essa contagem. Um número alto de handoffs costuma indicar ineficiência no processo, encaminhamento inicial incorreto ou falta de conhecimento por parte dos agentes. Essa métrica dá suporte direto ao KPI 'Número de handoffs por incidente' e ao Dashboard 'Análise de atrasos em handoffs e transferências', ajudando a identificar incidentes ou caminhos do processo com transferências excessivas que causam atrasos. Por que isso importa Quantifica o retrabalho e as reatribuições, ajudando a identificar ineficiências causadas por encaminhamentos incorretos ou lacunas de conhecimento. Onde encontrar Esta métrica calculada é derivada da contagem de valores distintos ou mudanças nos campos 'AssignedAgent' ou 'AssignedGroup' durante o ciclo de vida de um único incidente. Exemplos 0125
	Reaberto? IsReopened	Indicador calculado que retorna verdadeiro se um incidente foi reaberto após ser resolvido ou encerrado.
Descrição Este atributo booleano é um indicador calculado que identifica incidentes reabertos. Ele recebe o valor verdadeiro quando o status de um incidente, após chegar ao estado 'Resolved' ou 'Closed', muda novamente 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, uma análise de causa raiz incompleta ou um encerramento prematuro. Analisar esses casos ajuda a melhorar a qualidade e a durabilidade das correções. Por que isso importa Identifica falhas no processo de resolução, destacando incidentes em que a correção inicial não foi eficaz e gerou retrabalho. Onde encontrar Este campo calculado é derivado da sequência de atividades no Event Log. Ele retorna verdadeiro se ocorrer uma atividade como 'Incident Reopened' ou se uma atividade de estado aberto vier depois de uma atividade de estado encerrado para o mesmo ID do incidente. Exemplos truefalse
	SLA violado? IsSlaBreached	Indicador calculado que retorna verdadeiro se o incidente não foi resolvido dentro do prazo definido pela meta do SLA.
Descrição Este atributo booleano é uma métrica calculada que indica se o tempo de resolução do incidente ultrapassou a meta do SLA. Ele é derivado da comparação entre a data e hora da resolução real e o campo 'ResolutionSlaTargetTime'. Esse indicador alimenta diretamente o KPI 'Taxa de cumprimento do SLA' e o Dashboard de performance do SLA. Ele simplifica a análise ao apresentar um resultado binário claro para a performance do SLA de cada incidente, facilitando a agregação e a análise de tendências. Também ajuda a identificar rapidamente o volume e a porcentagem de incidentes que não cumprem os compromissos de serviço. Por que isso importa Mede diretamente a conformidade com o SLA de cada incidente, facilitando o cálculo das taxas gerais de cumprimento e a identificação de problemas. Onde encontrar Este é um campo calculado, derivado durante a transformação dos dados pela comparação entre a data e hora do evento 'Incident Resolved' e o campo 'ResolutionSlaTargetTime'. Exemplos truefalse
	Solução alternativa fornecida WorkaroundProvided	Indicador que informa se uma solução alternativa temporária foi fornecida ao usuário antes da resolução definitiva.
Descrição Este atributo booleano indica se uma correção temporária ou solução alternativa foi implementada para reduzir o impacto do incidente enquanto uma solução permanente era desenvolvida. Em geral, isso é registrado por meio de uma caixa de seleção ou de um status específico. Em Process Mining, esse atributo dá suporte ao Dashboard 'Métricas de eficácia das soluções alternativas'. Ele permite comparar os tempos de resolução de incidentes com e sem soluções alternativas, ajudando a determinar se as correções temporárias reduzem efetivamente a interrupção dos negócios e contribuem para uma resolução geral mais rápida na perspectiva do usuário. Por que isso importa Ajuda a medir a eficácia das soluções alternativas temporárias na redução do impacto dos incidentes e na antecipação da resolução percebida pelo usuário. Onde encontrar Geralmente, é um campo booleano personalizado, apresentado como uma caixa de seleção. É preciso verificar se ele existe na configuração de 'Ticket Fields' do Freshservice. Exemplos truefalse

Obrigatório Recomendado Opcional

Atividades da gestão de incidentes

Estas são as principais etapas e os marcos do processo que você deve registrar no Event Log para descobrir o processo com precisão e identificar gargalos.

7 Recomendado 7 Opcional

	Atividade	Descrição
	Incidente atribuído a um grupo	Representa a atribuição inicial de um incidente a um grupo de suporte. Ela pode ocorrer automaticamente por meio de regras de encaminhamento ou ser feita manualmente por um responsável pela triagem. Essa atividade é registrada quando o campo 'Grupo' é preenchido pela primeira vez no log de auditoria do incidente.
Por que isso importa Acompanhar as atribuições é essencial para medir o tempo de primeira resposta e identificar gargalos no processo de encaminhamento. Isso ajuda a avaliar a eficiência com que os incidentes chegam à equipe correta. Onde encontrar Inferido a partir do primeiro registro no log de atividades do incidente que preenche ou altera o campo 'Grupo'. Coleta Identifique o primeiro registro de data e hora em que o campo 'Grupo' é preenchido para um incidente. Tipo de evento inferred
	Incidente encerrado	Representa o encerramento formal e definitivo do registro do incidente. Isso costuma acontecer automaticamente após um período definido no estado 'Resolved', mas também 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 todo o ciclo de vida do incidente, incluindo eventuais períodos de espera pela confirmação do usuário. Onde encontrar Inferido pelo registro de atividades do incidente, identificando quando o campo 'Status' é atualizado para 'Closed'. Coleta Use a data e hora 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. Essa atividade é identificada pelo acompanhamento das alterações no campo 'Prioridade' do histórico do incidente.
Por que isso importa Uma priorização incorreta ou tardia pode causar violações de SLA e alocação ineficiente de recursos. Analisar essa atividade ajuda a garantir que os incidentes críticos recebam atenção imediata. Onde encontrar Inferido do log de atividades do incidente, que registra todas as atualizações no campo 'Prioridade'. Coleta Use os registros de data e hora do log de auditoria em que o valor do campo 'Prioridade' foi definido ou alterado. Tipo de evento inferred
	Incidente registrado	Indica a criação de um novo registro de incidente no Freshservice. Esse é o ponto de partida do ciclo de vida do incidente, geralmente iniciado quando um usuário final registra um chamado pelo portal ou por e-mail, ou quando um agente da central de serviços cria um chamado em nome dele. O sistema registra explicitamente esse evento com a data e a hora de criação.
Por que isso importa Esta atividade é o principal evento de início de todo o processo. Analisar o tempo entre esse evento e a resolução é fundamental para medir o tempo de ciclo geral e a adesão aos SLAs. Onde encontrar Obtido da data e hora de criação na tabela de incidentes. O Freshservice registra esse dado para cada novo chamado. Coleta Use o registro de data e hora de 'Criado em' no registro principal do incidente. Tipo de evento explicit
	Incidente resolvido	Indica que o agente implementou uma correção e considera o incidente resolvido. O evento é registrado quando o status do incidente muda para 'Resolvido'. No Freshservice, esse marco importante interrompe a contagem do SLA.
Por que isso importa Este é um marco essencial para medir o tempo até a resolução (TTR). O período entre os status 'Resolvido' e 'Encerrado' é importante para analisar atrasos na confirmação do usuário e políticas de encerramento automático. Onde encontrar Inferido pelo registro de atividades do incidente, identificando quando o campo 'Status' é atualizado para 'Resolved'. Coleta Use a data e hora do registro de atividades 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. Essa é uma ação específica no Freshservice, realizada antes da alteração do status para 'Resolvido'. A ação e seu conteúdo ficam registrados explicitamente.
Por que isso importa Este evento marca a identificação de uma solução. O tempo entre ele e a alteração do status para 'Incidente resolvido' pode indicar uma etapa de revisão interna ou um esforço adicional de documentação. Onde encontrar Obtido do registro de data e hora em que uma nota de resolução é adicionada ao incidente, conforme registrado no histórico de conversas. Coleta Identifique o registro de data e hora da entrada 'Nota de resolução' no histórico 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 ativo no incidente. Ela é registrada quando um agente altera o status do incidente para 'Em andamento'. Essa alteração padrão de status fica registrada no histórico de atividades do chamado.
Por que isso importa Este marco ajuda a diferenciar o tempo de espera do tempo de trabalho ativo. Analisar quanto tempo um incidente permanece 'Em andamento' é essencial para entender o esforço necessário para resolvê-lo. Onde encontrar Inferido do log de atividades do incidente, identificando quando o campo 'Status' é atualizado para 'Em andamento'. Coleta Filtre o log de atividades para encontrar uma alteração de status para 'Em andamento' e use o registro de data e hora correspondente. Tipo de evento inferred
	Agente atribuído ao incidente	Esta atividade indica quando um agente específico recebe a atribuição para tratar o incidente. Ela representa a responsabilidade individual pelo chamado. A atribuição fica registrada no histórico de atividades do chamado, com o nome do agente e a data e a hora.
Por que isso importa Isso permite analisar a carga de trabalho e a performance dos agentes, além do tempo entre a atribuição ao grupo e o momento em que um agente assume o incidente. É uma informação essencial para os dashboards de performance dos agentes. Onde encontrar Acompanhado pelas alterações no campo 'Agente' do log de atividades ou do histórico de auditoria do incidente. Coleta Identifique os registros de data e hora correspondentes às alterações no campo 'Agente'. Tipo de evento inferred
	Incidente reaberto	Ocorre quando um incidente marcado anteriormente como 'Resolved' volta a um status aberto, geralmente porque o usuário não concorda com a resolução. É possível inferir esse evento pela mudança de status de 'Resolved' para um estado como 'Open' ou 'In Progress'.
Por que isso importa Uma taxa alta de reabertura indica problemas na qualidade da resolução ou correções incompletas. Essa é uma métrica importante para analisar retrabalho e a performance dos agentes. Onde encontrar Inferido pelo registro de atividades do incidente, detectando uma mudança de status de 'Resolved' para um status ativo. Coleta Filtre o registro de atividades para encontrar 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 uma transferência durante o processo de resolução. O evento é inferido pela detecção de alterações posteriores nos campos 'Agente' ou 'Grupo', após a atribuição inicial.
Por que isso importa Reatribuições frequentes, ou transferências, costumam indicar ineficiências no processo, lacunas de conhecimento ou erros no encaminhamento inicial. Analisar esses eventos ajuda a identificar e reduzir atrasos. Onde encontrar Inferido do log de atividades do incidente, acompanhando qualquer alteração nos campos 'Agente' ou 'Grupo' após a primeira atribuição. Coleta Detecte alterações nos campos 'Agente' ou 'Grupo' no histórico de auditoria do chamado. Tipo de evento inferred
	Primeira resposta enviada	Esta atividade representa a primeira comunicação de um agente com o usuário após o registro do incidente. Pode ser uma nota pública ou uma resposta direta. O Freshservice registra todas as comunicações dos agentes com data e hora.
Por que isso importa Cumprir o SLA de primeira resposta é um KPI essencial para a satisfação dos clientes. Esta atividade permite medir e analisar a rapidez com que os agentes começam a tratar novos incidentes. Onde encontrar Identificada pelo registro de data e hora da primeira nota pública ou resposta adicionada por um agente ao histórico de conversas do incidente. Coleta Filtre o histórico de conversas do incidente para encontrar o registro mais antigo feito por um agente. Tipo de evento explicit
	Solução alternativa fornecida	Esta atividade indica que uma solução temporária ou alternativa foi comunicada ao usuário para reduzir o impacto do incidente. Para registrá-la, muitas vezes é preciso configurar o sistema, por exemplo, com uma caixa de seleção específica, um tipo 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 definitiva. Também dá suporte ao Dashboard de métricas de eficácia das soluções alternativas. Onde encontrar Provavelmente, este não é um evento explícito. Ele pode ser inferido pela identificação de palavras-chave como 'solução alternativa' nas notas ou pelo registro de alterações em um campo personalizado de caixa de seleção 'Solução alternativa fornecida'. Coleta 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 Pendente	Indica uma pausa no processo de resolução, geralmente enquanto se aguarda informações do usuário ou de terceiros. Esse evento é inferido quando o status muda para qualquer estado 'Pendente'. O tempo nesse estado costuma ser excluído dos cálculos de SLA.
Por que isso importa Identificar o tempo em estados pendentes é essencial para entender dependências externas e atrasos. Isso ajuda a separar o tempo de trabalho dos agentes do tempo de espera. Onde encontrar Inferido do log de atividades do incidente quando o campo 'Status' é atualizado para um valor como 'Pendente' ou 'Aguardando resposta do usuário'. Coleta Filtre o log de atividades para encontrar alterações de status para qualquer estado pendente e use o registro de data e hora correspondente. Tipo de evento inferred
	Violação da meta do SLA	Este é 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 identificado comparando as datas e horas 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 do SLA e para a melhoria contínua. Onde encontrar Calculado comparando a data e hora da resposta ou resolução com o prazo definido pela meta do SLA. O Freshservice costuma sinalizar os chamados como 'SLA Violated'. Coleta Identifique o evento comparando a data e hora de 'Resolved at' com a de 'Due by', ou quando o campo 'SLA Status' muda para 'Violated'. Tipo de evento calculated

Recomendado Opcional

Guias de extração

Como obter seus dados do Freshservice

Etapas

Acesse o Analytics do Freshservice: 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 Novo relatório. Dê um nome descritivo, como "Event Log de gestão de incidentes". Quando solicitado a escolher uma fonte de dados, selecione o módulo Gestão de incidentes.
Selecione o widget do relatório: No editor de relatórios, adicione um widget e selecione o tipo Tabela. Ele servirá de base para os dados do Event Log.
Adicione as colunas de dados principais: No painel da fonte de dados à direita, arraste os campos necessários para a configuração das colunas da tabela. Comece por ID do incidente, Criado em, Agente, Grupo, Prioridade, Gravidade, Status e Categoria.
Inclua os dados das atividades: Para registrar eventos individuais, você precisa combinar ou incluir dados das atividades dos chamados. Adicione a fonte de dados Atividades ao widget. Nessa fonte, inclua Realizado em (para registrar a data e hora do evento) e Descrição da atividade, ou campos semelhantes que descrevam a alteração ocorrida.
Crie uma coluna calculada 'ActivityName': Esta é a etapa mais importante. Crie uma 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 para ActivityName. Consulte a seção Consulta para ver a lógica detalhada de cada uma das 14 atividades.
Configure 'EventTimestamp': Crie outra coluna calculada para EventTimestamp. A lógica deve selecionar a data e hora de Criado em para a atividade 'Incidente registrado' e a data e hora de Realizado em da atividade para todos os outros eventos.
Aplique filtros ao relatório: Configure os filtros para restringir os dados. No mínimo, defina um intervalo de datas no campo 'Criado em'. Recomendamos um período dos últimos 3 a 6 meses. Adicione também um filtro para incluir apenas chamados em que 'Tipo de chamado' seja 'Incidente'.
Execute e ajuste o relatório: Execute o relatório para gerar uma prévia dos dados. Confira se as colunas ActivityName e EventTimestamp estão 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 Exportar e selecione CSV como formato.
Agende a exportação (opcional): Para manter a análise atualizada, você pode agendar a execução e a exportação automática do relatório. Defina uma frequência, como diária ou semanal, para receber o CSV por e-mail ou em outro destino.
Prepare os dados para carregamento: 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 a data e hora atuais). O arquivo estará pronto para ser carregado.

Configuração

Módulo Analytics: Esta extração exige acesso ao módulo Analytics do Freshservice, disponível nos planos de nível superior, 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: É essencial definir um filtro de intervalo de datas para a criação dos incidentes, a fim de controlar o volume de dados. Recomendamos um período móvel de 3 a 6 meses para equilibrar o contexto histórico e a performance.
Filtros do relatório: Sempre filtre por 'Tipo de chamado' igual a 'Incidente' para excluir solicitações de serviço e outros tipos de chamado da análise do processo.
Campos calculados: O método depende bastante do uso de campos calculados (fórmulas) para obter ActivityName e EventTimestamp de cada evento. É útil conhecer o editor de fórmulas do Freshservice.
Volume de dados: Para cada incidente, esta 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.

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: Verifique se você tem o Python 3.6 ou superior instalado, além das bibliotecas requests e pandas. Instale-as com o pip: pip install requests pandas.
Gere uma chave de API: Entre na sua instância do Freshservice como administrador. Acesse as configurações do perfil clicando na foto do perfil, no canto superior direito. Vá até a seção 'API Key' e copie sua chave de API pessoal. Proteja 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 exemplo de FRESHSERVICE_DOMAIN (por exemplo, 'suaempresa.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 incidente criados após a data inicial especificada. Em seguida, percorre cada página de resultados retornada pela API. Para cada chamado, faz uma segunda chamada à API para obter 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, 'Incidente registrado' é criado com base na data de criação do chamado, enquanto 'Status alterado para Em andamento' é obtido de uma entrada específica no registro de atividades.
Determine eventos complexos: Eventos como 'Meta de SLA descumprida' são derivados. O script verifica se o SLA de resolução do chamado foi violado. Em caso afirmativo, cria um evento com a data e hora do campo due_by, que indica quando ocorreu o descumprimento.
Execute o script: Abra um terminal ou prompt de comando, acesse o diretório onde salvou o script e execute o comando: python extract_freshservice_incidents.py.
Acompanhe a execução: O script exibirá atualizações de progresso no console, indicando quantos chamados foram processados. O processo pode levar algum tempo, dependendo do número de chamados e dos limites de requisições da API.
Confira o resultado: Ao 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 o arquivo para carregamento: Abra o CSV em um programa de planilhas e confira se as colunas (IncidentId, ActivityName, EventTimestamp etc.) foram preenchidas como esperado. O arquivo estará pronto para ser carregado no ProcessMind ou em outra ferramenta de Process Mining.

Configuração

FRESHSERVICE_DOMAIN: URL específica da sua empresa no Freshservice, por exemplo, mycompany.freshservice.com. Este parâmetro é obrigatório no script.
API_KEY: Chave de API pessoal de um usuário com permissão suficiente para ler todos os dados de incidentes. Este parâmetro é obrigatório.
START_DATE_STR: Data inicial da extração dos dados, no formato 'YYYY-MM-DD'. Recomendamos 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 recomendamos alterar esse valor.
Limite de requisições da API: O script inclui uma chamada básica a time.sleep(1) após processar cada chamado para respeitar os limites de requisições da API do Freshservice. Em instâncias com grande volume, talvez seja necessário ajustar esse intervalo para evitar erros.
Permissões necessárias: A chave de API 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'. Assim, ela poderá acessar todos os campos necessários dos chamados e os registros de atividades em diferentes grupos da central de serviços.

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 usar regras do Workflow Automator, ações de webhook, acesso a incidentes e acesso ao histórico de atividades dos chamados. Confirme 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 dos 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 sistema 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, observações, SLA e encerramento. Configure as 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 ocorrer a atividade correspondente. Não dependa do ProcessMind para inferir atividades a partir de um retrato final do incidente.
Configure o mapeamento explícito das 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 for registrada a primeira resposta ou observação pública qualificada do agente; 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 de contorno configurado; Resolution Note Added quando uma observação de resolução for adicionada; Incident Resolved quando o status mudar para Resolved; SLA Target Breached quando a condição configurada de descumprimento do SLA 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 como JSON e inclua o identificador do incidente, o nome da atividade, a data e hora do evento, o sistema de origem, a data e hora da última atualização dos dados e os atributos contextuais recomendados. Use as variáveis de webhook do Freshservice disponíveis na sua conta. Se uma variável necessária não estiver disponível no editor de webhook, preencha o valor no serviço receptor chamando uma interface aprovada do Freshservice ou deixe-o vazio, sem inventar um valor.
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 for 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 de contorno e uma observação de resolução quando configuradas, resolva, reabra e encerre o incidente. Teste separadamente o descumprimento de SLA usando uma política ou fila de teste controlada. Confirme se cada atividade esperada chega em um payload de webhook distinto.
Armazene os payloads de webhook 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 por atividade explícita do webhook. Preencha LastDataUpdate com a data e hora da atualização da extração ou ingestão, não com a data e hora do evento de negócio.
Valide o Event Log preparado, remova apenas entregas exatamente duplicadas e mantenha atividades repetidas legítimas, como várias alterações de prioridade ou transições de status. Confirme se IncidentId, ActivityName, EventTimestamp, SourceSystem e LastDataUpdate estão preenchidos 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 da atividade.

Configuração

Escopo dos gatilhos: 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 gerar eventos duplicados ou ambíguos, a menos que o sistema receptor aplique um mapeamento rigoroso das 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: Diferencie as atribuições iniciais de grupo e agente das alterações posteriores. As alterações posteriores geram Incident Reassigned, enquanto o preenchimento inicial gera a atividade de atribuição 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 observação pública ou outro tipo de comunicação conta como resposta. Aplique a definição de forma consistente e gere o evento somente para a primeira comunicação qualificada de cada incidente.
Detecção de soluções de contorno: Configure um campo dedicado, uma caixa de seleção, um tipo de observação ou uma regra aprovada por palavra-chave. Sem essa configuração, não é possível identificar Workaround Provided de forma confiável.
Descumprimento de SLA: Configure um gatilho explícito para o descumprimento do SLA ou um processo agendado separado que compare a hora atual com ResolutionSlaTargetTime. Um retrato final do incidente, por si só, não basta para reconstruir a data e a hora do descumprimento.
Intervalo de datas: Para a validação inicial, use incidentes de aproximadamente 3 a 6 meses. Na 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, espaço de trabalho, 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 solicitações recebidas em uma fila, agrupe as gravações posteriores e crie índices para IncidentId e EventTimestamp. Evite chamadas síncronas para enriquecer dados durante o recebimento do webhook.
Confiabilidade: Configure novas tentativas, tratamento de mensagens não entregues, monitoramento e supressão de duplicatas. Registre as entregas com falha e reprocese-as após corrigir o problema.
Pré-requisitos: Acesso de administrador, disponibilidade do Workflow Automator, permissões de webhook, um endpoint HTTPS, configuração de autenticação, recursos adequados no plano do Freshservice e um processo de recebimento ou carregamento compatível com o ProcessMind.
Segurança: Use HTTPS, restrinja o acesso de entrada sempre que possível, alterne as credenciais, minimize os campos confidenciais e proteja as descrições e observações dos incidentes, caso sejam incluídas nos payloads.

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 estruturar seus dados corretamente e obter insights valiosos sobre os fluxos de trabalho de gestão de incidentes. Comece hoje a reduzir o tempo de resolução.

Voltar ao guia de melhoria

Baixar Template

Evite descumprimentos de SLA: otimize a gestão de incidentes hoje

Junte-se às empresas que reduziram o MTTR em 35% e evitaram descumprimentos de SLA que geram custos.

Começar o teste grátis

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

Seu Template de dados para gestão de incidentes

Seu Template de dados para gestão de incidentes

Atributos da gestão de incidentes

Atividades da gestão de incidentes

Guias de extração

Exportar dados do módulo Analytics do Freshservice para CSV

Etapas

Configuração

Consulta de exemplo config

Extração com script Python pela API REST do Freshservice

Etapas

Configuração

Consulta de exemplo python

Envio de dados em tempo real por webhooks do Workflow Automator

Etapas

Configuração

Consulta de exemplo config

Pronto para começar?

Evite descumprimentos de SLA: otimize a gestão de incidentes hoje