Seu Template de Dados para Gestão de Solicitações

ServiceNow
Seu Template de Dados para Gestão de Solicitações

Seu Template de Dados para Gestão de Solicitações

Este template de dados foi criado para simplificar sua jornada de Process Mining na Gestão de Solicitações. Ele traz orientações claras sobre quais atributos coletar, quais atividades rastrear e como fazer a extração no ServiceNow. Usá-lo garante que você tenha todos os dados necessários para uma análise precisa e uma otimização real.
  • Atributos recomendados para coletar
  • Principais atividades para monitorar na descoberta de processos
  • Orientação passo a passo para extração de dados
É novo em event logs? Saiba como criar um event log para Process Mining.

Atributos da Gestão de Solicitações de Serviço

Estes são os campos de dados recomendados para incluir no seu event log para uma análise completa do seu processo de gestão de solicitações.
5 Obrigatório 6 Recomendado 11 Opcional
Nome Descrição
Atividade
ActivityName
O nome do evento ou tarefa específica que ocorreu no ciclo de vida da solicitação de serviço.
Descrição

O atributo Atividade registra o nome de cada passo ou mudança de status no processo. Pode incluir eventos como "Solicitação criada", "Aprovada", "Atribuída ao agente" ou "Fechada".\n\nAnalisar essas atividades permite visualizar o fluxo real, identificar caminhos comuns e detectar desvios do padrão. É a base para entender o que realmente acontece durante o atendimento de um pedido.

Por que é importante

Atributo obrigatório que define os passos no mapa do processo. É a base de toda a análise, permitindo achar gargalos, loops de retrabalho e falhas de conformidade.

Onde obter

Derivado de mudanças nos campos 'State' ou 'Stage' das tabelas 'sc_request'/'sc_req_item' ou da trilha de auditoria (sys_audit).

Exemplos
Solicitação de Serviço CriadaSolicitação atribuída ao grupoSolicitação de Serviço ResolvidaInformação solicitada ao usuário
Hora de Início
EventTime
O timestamp indicando quando uma atividade ou evento começou.
Descrição

Este atributo registra a data e hora exatas de cada atividade. Ele fornece a sequência cronológica para montar o mapa do processo e fazer análises de tempo.\n\nTimestamps precisos são vitais para calcular tempos de ciclo, espera e processamento. Esses dados permitem achar gargalos, violações de SLA e tendências de desempenho ao longo do tempo.

Por que é importante

Timestamp obrigatório para ordenar os eventos. É a base de todas as análises de desempenho e duração, como tempo de ciclo e identificação de gargalos.

Onde obter

Geralmente encontrado nos campos "sys_updated_on" ou "sys_created_on" das tabelas do ServiceNow (ex: sc_request, sc_task) ou na trilha de auditoria (sys_audit).

Exemplos
2023-04-15T10:00:00Z2023-04-15T11:30:15Z2023-04-16T09:05:45Z
ID da Solicitação de Serviço
ServiceRequestID
O identificador exclusivo de cada registro de solicitação de serviço.
Descrição

O ID da Solicitação é a chave única que identifica cada pedido feito por um usuário ou sistema. Ele conecta todos os eventos, do registro inicial ao fechamento. No Process Mining, este ID é essencial para reconstruir toda a jornada de cada solicitação, permitindo uma análise completa do seu ciclo de vida.

Por que é importante

Este é o ID do Caso obrigatório. Ele une todas as atividades em uma única instância, permitindo analisar fluxos, variações e tempos de ciclo.

Onde obter

Tabela de Solicitação [sc_request], campo "number".

Exemplos
REQ0010001REQ0010025REQ0010112
Sistema de Origem
SourceSystem
O sistema de onde os dados se originaram.
Descrição

Este atributo identifica o sistema de origem dos dados, que neste caso é o ServiceNow. É útil quando dados de vários sistemas são mesclados para uma visão holística.\n\nEm análises de fonte única, ele fornece contexto importante para governança e gestão, garantindo que qualquer usuário saiba de onde vêm as informações analisadas.

Por que é importante

Fornece metadados essenciais para governança de dados, rastreabilidade e contexto, especialmente ao combinar informações de vários sistemas corporativos.

Onde obter

Este é tipicamente um valor estático adicionado durante o processo de extração e transformação de dados.

Exemplos
ServiceNow
Última Atualização de Dados
LastDataUpdate
O timestamp da extração ou atualização de dados mais recente.
Descrição

Indica quando os dados foram extraídos e carregados na ferramenta de Process Mining, garantindo transparência sobre a atualidade das informações.\n\nOs analistas usam isso para saber se estão vendo dados recentes, o que é crucial para o monitoramento operacional e decisões em tempo real. Ajuda a alinhar expectativas sobre o quão atuais são os insights.

Por que é importante

Garante que os usuários saibam quão recentes são os dados, algo crucial para a confiança na análise e decisões rápidas.

Onde obter

Campo de metadados adicionado durante a ingestão, refletindo o horário de conclusão da tarefa de ETL.

Exemplos
2023-10-27T04:00:00Z
Atribuído A
AssignedTo
O usuário individual responsável por trabalhar na solicitação em um dado momento.
Descrição

Identifica o agente ou técnico atribuído à solicitação. Ele muda conforme o pedido passa por diferentes pessoas.\n\nAnalisar o campo "Assigned To" é vital para entender a carga de trabalho, o desempenho individual e como as transferências afetam o tempo de resolução. Ajuda a otimizar o uso de recursos e aponta necessidades de treinamento para reduzir reatribuições.

Por que é importante

Permite analisar a carga de trabalho, desempenho e transferências entre agentes. Vital para gestão de recursos.

Onde obter

Tabelas de Item de Solicitação [sc_req_item] ou Tarefa de Catálogo [sc_task], campo "assigned_to".

Exemplos
Beth AnglinDavid LooHoward Johnson
Categoria
Category
A classificação principal do pedido, como Hardware ou Software.
Descrição

A Categoria fornece uma classificação geral da solicitação. É usada para rotear o pedido para o time certo e para relatórios de volume.

No Process Mining, a Categoria é uma ferramenta poderosa para análise dimensional. Ela permite comparar fluxos, tempos de ciclo e taxas de automação entre diferentes tipos de pedidos, revelando variações ocultas. Por exemplo: o fluxo de uma solicitação de 'Hardware' pode ser totalmente diferente de uma de 'Software'.

Por que é importante

Permite segmentar e comparar processos entre diferentes tipos de serviço, ajudando a identificar problemas específicos de cada categoria.

Onde obter

Tabela de Item de Solicitação [sc_req_item], geralmente através da categoria do Item de Catálogo [sc_cat_item] associado.

Exemplos
HardwareSoftwareSolicitação de AcessoRede
Estado
State
O status operacional atual da solicitação de serviço.
Descrição

O atributo Estado indica a fase atual do pedido (ex: Aberto, Em andamento, Pendente, Fechado). Mudanças neste campo geram as atividades do mapa de processo.\n\nAnalisar o Estado é crucial para entender quanto tempo os pedidos ficam parados, especialmente em espera. Isso ajuda a identificar filas e atrasos, como o tempo em "Aguardando Informações do Usuário", um motivo comum para ciclos demorados.

Por que é importante

Oferece visão sobre o status da solicitação a qualquer momento, permitindo analisar tempos de espera, filas e a duração de etapas específicas do processo.

Onde obter

Tabelas de Solicitação [sc_request] ou Item de Solicitação [sc_req_item], campo "state" ou "stage".

Exemplos
AbertoTrabalho em AndamentoAguardando informações do usuárioFechado Concluído
Grupo de atribuição
AssignmentGroup
A equipe ou grupo responsável pelo atendimento da solicitação.
Descrição

O Grupo de Atribuição representa a equipe (ex: Service Desk, Operações de Rede) responsável pelo pedido em uma fase específica. É um atributo essencial para analisar o fluxo entre diferentes áreas.\n\nAo rastrear mudanças no grupo, as empresas visualizam transferências (handoffs) entre times, medem o tempo de fila em cada backlog e identificam atrasos ou dependências entre equipes, o que é fundamental para a colaboração multifuncional.

Por que é importante

Acompanha a distribuição de trabalho, destaca transferências entre times e ajuda a achar gargalos ou problemas de desempenho em equipes específicas.

Onde obter

Tabelas de Item de Solicitação [sc_req_item] ou Tarefa de Catálogo [sc_task], campo "assignment_group".

Exemplos
Service DeskSuporte de TI L2Provisionamento de Hardware
Prioridade
Priority
O nível de prioridade da solicitação de serviço, que influencia sua urgência.
Descrição

A prioridade é uma classificação que define a importância e a urgência de uma solicitação. Geralmente baseada no impacto e na urgência, ela orienta os agentes sobre quais pedidos atender primeiro.\n\nAnalisar os dados por prioridade é fundamental para saber se as solicitações críticas estão sendo resolvidas mais rápido que as comuns. Isso permite filtrar os dashboards para verificar se os SLAs de pedidos urgentes estão sendo cumpridos e ajuda a validar se o sistema de priorização está funcionando como deveria.

Por que é importante

Permite segmentar solicitações para garantir que itens de alta prioridade sejam resolvidos primeiro. Essencial para análise de SLA.

Onde obter

Tabelas de Solicitação [sc_request] ou Item de Solicitação [sc_req_item], campo "priority".

Exemplos
1 - Crítico2 - Alto3 - Moderada4 - Baixo
SLA cumprido
MadeSLA
Um campo booleano que indica se a solicitação foi resolvida dentro do prazo do SLA.
Descrição

Indica se o pedido cumpriu o SLA de tempo de resolução. É uma métrica crítica de resultado que mede o desempenho frente aos compromissos assumidos.\n\nAnalisar este marcador ajuda a medir o KPI de Taxa de Adesão ao SLA. Serve para comparar os caminhos de pedidos que cumpriram o prazo versus os que atrasaram, revelando padrões que causam falhas. É essencial para monitorar riscos e melhorar o serviço continuamente.

Por que é importante

Mede o desempenho em relação aos compromissos de serviço e permite a análise de causa raiz de quebras de SLA.

Onde obter

Tabela Task SLA [task_sla] do ServiceNow, campo "has_breached". O valor precisa ser invertido (ex: MadeSLA = NOT has_breached).

Exemplos
verdadeirofalse
Aberto por
OpenedBy
A pessoa que abriu inicialmente a solicitação de serviço.
Descrição

Identifica quem criou a solicitação. Pode ser o próprio afetado, um gestor ou um sistema automático.\n\nAnalisar quem abriu o pedido ajuda a notar padrões, como departamentos que enviam muitos pedidos complexos. Isso pode orientar treinamentos específicos ou indicar a necessidade de melhorar a base de conhecimento para incentivar o autoatendimento.

Por que é importante

Auxilia na análise de padrões de solicitações por usuário ou departamento, orientando treinamentos e melhorias.

Onde obter

Tabela de Solicitação [sc_request], campo "opened_by".

Exemplos
Abel TuterFred LuddyDon Goodliffe
Canal
ContactType
O método usado pelo solicitante para enviar o pedido de serviço.
Descrição

O Tipo de Contato define como o pedido foi feito. Canais comuns incluem portal de serviços, e-mail, telefone ou alertas automáticos.\n\nEntender o canal é importante para analisar variações causadas pelo método de envio. Por exemplo, pedidos via portal tendem a ser mais estruturados e rápidos do que por e-mail. Essa análise ajuda a incentivar o uso dos canais mais eficientes.

Por que é importante

Ajuda a identificar como os diferentes canais de entrada afetam a eficiência e os tempos de ciclo.

Onde obter

Tabelas de Solicitação [sc_request] ou Interação [interaction] do ServiceNow. O campo geralmente se chama "contact_type".

Exemplos
PortalEmailTelefoneSelf-service
Código de resolução
ResolutionCode
Um código que categoriza a resolução final da solicitação de serviço.
Descrição

O Código de Resolução classifica como o pedido foi encerrado (ex: Atendido por Automação, Erro do Usuário). \n\nEste atributo é vital para o dashboard de Análise de Causa Raiz de Atrasos. Ao correlacionar códigos de resolução com tempos longos de ciclo ou altas taxas de retrabalho, os analistas acham problemas sistêmicos. Se pedidos com o código "Informação Incompleta" atrasam sempre, o problema está na coleta inicial de dados.

Por que é importante

Oferece dados estruturados sobre os resultados da resolução, permitindo a análise de causa raiz de atrasos, retrabalho e outras ineficiências.

Onde obter

Tabela de Item de Solicitação [sc_req_item] ou tarefa relacionada, o campo geralmente é "close_code" ou "resolution_code".

Exemplos
Resolvido (permanente)Não resolvido (não reproduzível)Solicitação atendidaCancelado pelo usuário
Contagem de Reaberturas
ReopenCount
Quantas vezes o pedido foi reaberto após ter sido marcado como resolvido.
Descrição

É um contador de quantas vezes um pedido resolvido voltou para o estado aberto ou em andamento. Qualquer valor acima de zero mostra que a primeira resolução falhou.\n\nÉ um indicador direto de retrabalho e essencial para o KPI de Taxa de Resolução de Primeira Tentativa. Números altos de reabertura sugerem má qualidade na solução ou erro de interpretação das necessidades do usuário, gerando ineficiência e insatisfação.

Por que é importante

Quantifica o retrabalho e a qualidade da resolução. Um número alto de reaberturas indica ineficiências, baixas taxas de acerto na primeira tentativa e queda na satisfação do cliente.

Onde obter

Tabelas de Solicitação [sc_request] ou Item de Solicitação [sc_req_item], campo "reopen_count".

Exemplos
012
É Automatizado
IsAutomated
Um marcador que indica se a atividade foi executada por um sistema ou automação.
Descrição

Diferencia tarefas feitas por humanos daquelas feitas por sistemas (workflows ou integrações). Por exemplo, o envio de um pedido de aprovação pode ser automático, enquanto a atribuição de um agente pode ser manual.\n\nAnalisar este atributo é a chave para medir e aumentar o nível de automação. Ajuda a achar tarefas manuais demoradas que poderiam ser automatizadas para reduzir custos e ganhar eficiência.

Por que é importante

Permite medir as taxas de automação e ajuda a identificar tarefas manuais que podem ser automatizadas, aumentando a eficiência.

Onde obter

Derivado ao verificar se o usuário que realizou a ação é um usuário de sistema ou integração.

Exemplos
verdadeirofalse
É resolução de primeira tentativa
IsFirstPassResolution
Um indicador de que a solicitação foi resolvida na primeira tentativa, sem reaberturas.
Descrição

Este marcador é "true" apenas se o pedido foi resolvido e fechado sem nunca ser reaberto. É o principal indicador da qualidade do atendimento do service desk.\n\nApoia diretamente o KPI de Resolução de Primeira Tentativa. Uma taxa alta indica serviço eficiente e de qualidade. Analisar os casos que falham aqui revela causas como falta de treinamento, documentação ruim ou diagnóstico inicial errado.

Por que é importante

Mede a qualidade e a eficiência do processo de resolução. Uma taxa baixa de resolução de primeira tentativa indica problemas ocultos que causam retrabalho e frustração no cliente.

Onde obter

Calculado no nível do caso. Considera-se resolução de primeira tentativa (FPR) se o 'ReopenCount' for zero.

Exemplos
verdadeirofalse
É Retrabalho
IsRework
Um marcador calculado que indica se uma atividade é uma repetição de uma etapa anterior no mesmo caso.
Descrição

Este marcador identifica loops de retrabalho. Fica como "true" se uma atividade se repete no mesmo pedido (ex: pedido atribuído ao mesmo time duas vezes). \n\nÉ essencial para o dashboard de Handoffs e Incidentes de Retrabalho e para o KPI de Taxa de Retrabalho. Permite visualizar e medir loops ineficientes que costumam ficar escondidos em dados agregados.

Por que é importante

Sinaliza e quantifica o retrabalho, permitindo analisar causas e impactos de loops ineficientes que elevam custos.

Onde obter

Calculado durante a transformação dos dados ao verificar ocorrências anteriores da mesma atividade no mesmo caso.

Exemplos
falseverdadeiro
End Time
EndTime
O timestamp que indica quando uma atividade ou evento foi concluído.
Descrição

O Tempo Final marca a conclusão de uma atividade. É o timestamp da próxima atividade, fechando a duração da atual. Esse dado é vital para saber quanto tempo cada etapa do processo consome.\n\nAo comparar o início e o fim, os analistas calculam tempos de processamento e de espera, o que é essencial para achar gargalos, medir a eficiência de recursos e monitorar metas de tempo.

Por que é importante

Este atributo é necessário para calcular a duração de cada atividade, item fundamental na análise de desempenho, identificação de gargalos e estudos de uso de recursos.

Onde obter

Este é um atributo derivado, calculado com base no "StartTime" do evento seguinte no mesmo caso.

Exemplos
2023-04-15T10:05:10Z2023-04-15T11:45:00Z2023-04-16T09:15:30Z
Pontuação de satisfação
SatisfactionScore
A nota de satisfação dada pelo solicitante ao fechar o pedido.
Descrição

Este atributo registra a nota de satisfação (geralmente de 1 a 5) dada pelo usuário final após a resolução. É uma medida direta da qualidade percebida do serviço.\n\nEstes dados são essenciais para o dashboard de Análise de Impacto na Satisfação do Cliente. Eles permitem correlacionar métricas de processo, como tempo de ciclo e retrabalho, com a experiência final do cliente, provando o valor das melhorias operacionais.

Por que é importante

Vincula métricas de desempenho aos resultados do cliente, ajudando a quantificar o impacto das falhas do processo na experiência do usuário.

Onde obter

Geralmente encontrado na tabela de Pesquisa [asmt_assessment_instance] relacionada, que está vinculada ao pedido original.

Exemplos
5431
Tempo de Ciclo do Caso
CaseCycleTime
O tempo total transcorrido desde a criação até o fechamento final da solicitação.
Descrição

O Tempo de Ciclo do Caso (Case Cycle Time) mede a duração total de uma solicitação, do primeiro ao último evento. Representa o tempo total de processamento sob a ótica do cliente.

Este é um KPI fundamental para medir a eficiência do processo. Ele é usado em dashboards para monitorar o desempenho e analisar tendências. Pode ser segmentado por Categoria ou Prioridade para identificar quais pedidos demoram mais para serem concluídos.

Por que é importante

Este é um KPI crítico que mede o desempenho do processo de ponta a ponta. É essencial para o monitoramento estratégico e para achar áreas que precisam de melhoria.

Onde obter

Calculado subtraindo o 'StartTime' mínimo do 'EndTime' máximo para cada 'ServiceRequestID' único.

Exemplos
2 10:30:000 04:15:2210 00:05:00
Tempo de Processamento
ProcessingTime
O período de tempo gasto ativamente trabalhando em uma atividade específica.
Descrição

O Tempo de Processamento, também chamado de tempo ativo ou handling time, é o período gasto executando uma tarefa. É a diferença entre o fim e o início de uma atividade, sem contar o tempo em que o pedido ficou parado na fila.\n\nEssa métrica é vital para o dashboard de Análise de Gargalos e Filas. Ao somar os tempos de processamento por atividade, os analistas conseguem identificar quais etapas consomem mais recursos e esforço, permitindo priorizar melhorias nas tarefas que mais tomam tempo.

Por que é importante

Mede a duração do trabalho ativo em cada atividade, ajudando a identificar os passos mais demorados do processo e localizar gargalos operacionais.

Onde obter

Calculado como 'EndTime' menos 'StartTime' para cada registro de evento.

Exemplos
0 00:05:100 01:14:450 00:09:55
Obrigatório Recomendado Opcional

Atividades da Gestão de Solicitações de Serviço

Estas são as principais etapas do processo e marcos a serem capturados no seu log de eventos para uma descoberta precisa de processos e identificação de gargalos.
6 Recomendado 8 Opcional
Atividade Descrição
Informação solicitada ao usuário
Ocorre quando o agente de atendimento precisa de mais informações do solicitante para prosseguir. Isso geralmente é identificado quando o estado da solicitação muda para algo como "Aguardando informações do usuário".
Por que é importante

Esta atividade é vital para o dashboard de Análise de Atraso por Informação do Solicitante, ajudando a medir o tempo perdido esperando respostas dos usuários.

Onde obter

Identificado quando o campo de estado do sc_req_item muda para um status designado como "aguardando informações". A alteração é registrada na tabela sys_audit.

Captura

Identifica o timestamp quando sc_req_item.state muda para 'Aguardando Informações do Usuário'.

Tipo de evento inferred
Solicitação aprovada
Esta atividade indica que o pedido foi aprovado oficialmente e pode seguir para o atendimento. É registrada quando o aprovador marca o registro de aprovação como "approved".
Por que é importante

Este marco indica a mudança da fase de aprovação para a de atendimento. Analisar este tempo é crucial para entender atrasos antes do início do trabalho.

Onde obter

Identificado quando o campo de estado do registro sysapproval_approver relacionado muda para "approved", o que aciona uma mudança de estado no sc_req_item.

Captura

Identifique o timestamp de quando o campo sysapproval_approver.state muda para "approved".

Tipo de evento inferred
Solicitação Atribuída ao Agente
Esta atividade ocorre quando um agente específico é designado para o pedido. É registrada monitorando as mudanças no campo "Assigned to" na solicitação ou em suas tarefas de atendimento.
Por que é importante

Crucial para medir transferências, calcular a carga de trabalho por agente e analisar o tempo de fila antes de o trabalho começar.

Onde obter

Identificado por uma alteração no campo assigned_to na tabela sc_req_item ou sc_task. O histórico de alterações é registrado na tabela sys_audit.

Captura

Rastreie mudanças no campo assigned_to na tabela sys_audit.

Tipo de evento inferred
Solicitação de Serviço Criada
Esta atividade inicia o ciclo de vida da solicitação, registrada quando o usuário faz o pedido via catálogo. O sistema marca isso como o evento de criação de um novo registro na tabela sc_req_item (Requested Item).
Por que é importante

Evento inicial do processo. É essencial para calcular o tempo total de ciclo e analisar o volume de pedidos e padrões de envio.

Onde obter

Evento explícito capturado do campo sys_created_on do registro na tabela sc_req_item.

Captura

Use o timestamp sys_created_on do registro sc_req_item.

Tipo de evento explicit
Solicitação de Serviço Encerrada
Marca o fim definitivo do ciclo de vida da solicitação de serviço. Isso geralmente ocorre de forma automática após um período definido no estado "Resolved", durante o qual o usuário ainda pode reabrir a solicitação.
Por que é importante

Principal evento de fim bem-sucedido. O tempo entre resolvido e fechado também pode ser analisado para validar políticas de fechamento automático.

Onde obter

Identificado quando o campo de estado do sc_req_item é atualizado para um estado final de fechamento, como "Closed Complete". Isso é registrado na tabela sys_audit.

Captura

Identifica o timestamp quando sc_req_item.state muda para 'Fechado Concluído'.

Tipo de evento inferred
Solicitação de Serviço Resolvida
Esta atividade indica que o agente de atendimento terminou o trabalho e enviou uma solução. Ela é registrada quando o estado da solicitação muda para "Resolved" ou similar.
Por que é importante

Este é um marco crítico que geralmente para o cronômetro do SLA. Ele marca o fim do trabalho de atendimento ativo e é essencial para o cálculo do tempo total de resolução.

Onde obter

Identificado quando o campo de estado do sc_req_item é atualizado para "Resolved" ou um estado terminal similar antes do fechamento final. A alteração é rastreada na tabela sys_audit.

Captura

Identifica o timestamp quando sc_req_item.state muda para 'Resolvido'.

Tipo de evento inferred
Aprovação Solicitada
Representa o momento em que uma solicitação é enviada para aprovação de um gestor ou aprovador designado. Geralmente é identificado quando o estado da solicitação muda para "Pending Approval" ou similar.
Por que é importante

Monitorar aprovações ajuda a achar gargalos na autorização e mede quanto tempo os pedidos esperam antes de o atendimento começar de fato.

Onde obter

Identificado quando o campo de estado do sc_req_item muda para um valor de aprovação pendente ou pela criação de um registro correspondente na tabela sysapproval_approver. As alterações são registradas na tabela sys_audit.

Captura

Identifica o timestamp quando sc_req_item.state muda para 'Aprovação Pendente'.

Tipo de evento inferred
Informação fornecida pelo usuário
Esta atividade marca o momento em que o solicitante fornece a informação necessária. É identificada quando o pedido sai do status "Aguardando Informações do Usuário" e volta para um estado ativo.
Por que é importante

Combinada com "Informação solicitada ao usuário", esta atividade permite medir com precisão os atrasos causados pelo solicitante e ajuda a avaliar a eficiência do processo de comunicação.

Onde obter

Identificado quando o campo de estado do sc_req_item muda de um status de "aguardando informações" para um status ativo. Isso geralmente é acionado quando o usuário adiciona um comentário ou responde a um e-mail.

Captura

Identifique o timestamp de quando o estado muda de "Aguardando informações do usuário" para "Trabalho em andamento".

Tipo de evento inferred
Requisição Rejeitada
Esta atividade representa os casos em que um pedido é formalmente rejeitado na fase de aprovação. É um caminho alternativo para o encerramento, registrado quando um aprovador marca o pedido como "rejected".
Por que é importante

Monitorar rejeições ajuda a identificar pedidos inválidos ou mal direcionados, além de falhas no processo de envio, servindo como uma trilha de exceção importante.

Onde obter

Identificado quando o campo de estado do registro sysapproval_approver relacionado muda para "rejected". Isso geralmente define o sc_req_item pai como um estado fechado e incompleto.

Captura

Identifique o timestamp de quando o campo sysapproval_approver.state muda para "rejected".

Tipo de evento inferred
Solicitação atribuída ao grupo
Indica que a solicitação de serviço foi atribuída a uma equipe ou grupo de atendimento específico. Este evento é identificado ao detectar uma mudança no campo de grupo de atribuição (assignment group) no item da solicitação ou em suas tarefas associadas.
Por que é importante

Rastrear atribuições por grupo ajuda a analisar a carga de trabalho entre times e achar atrasos no roteamento das solicitações.

Onde obter

Identificado por uma alteração no campo assignment_group na tabela sc_req_item ou sc_task. O histórico de alterações é registrado na tabela sys_audit.

Captura

Rastreie mudanças no campo assignment_group na tabela sys_audit.

Tipo de evento inferred
Solicitação Cancelada
Esta atividade é o estado terminal de pedidos cancelados antes da conclusão. É registrada quando o status muda para "Cancelled" ou "Closed Cancelled".
Por que é importante

Este é um evento de fim malsucedido. Analisar por que os pedidos são cancelados ajuda a entender melhor as necessidades do usuário ou ineficiências do processo.

Onde obter

Identificado quando o campo de estado do sc_req_item é atualizado para um estado final de cancelamento, como "Closed Cancelled". A alteração é registrada na tabela sys_audit.

Captura

Identifica o timestamp quando sc_req_item.state muda para 'Cancelado'.

Tipo de evento inferred
Solicitação Reaberta
Esta atividade registra os casos em que um pedido resolvido volta ao estado aberto. Isso é identificado pela mudança de status de "Resolved" para "Work in Progress" ou equivalente.
Por que é importante

Mede o retrabalho diretamente e é vital para o KPI de "Taxa de Resolução de Primeira Tentativa". Números altos indicam soluções de baixa qualidade ou incompletas.

Onde obter

Identificado por uma mudança no campo de estado do sc_req_item, movendo-se de um estado resolvido ou fechado de volta para um estado aberto ou em andamento. Essa alteração é registrada na tabela sys_audit.

Captura

Detecta mudança de estado de 'Resolvido' para 'Em Andamento' no sys_audit.

Tipo de evento inferred
Tarefa de Execução Criada
Representa a criação de um item de trabalho ou tarefa específica necessária para atender à solicitação. Este é um evento explícito registrado quando um novo registro é criado na tabela Catalog Task.
Por que é importante

Para pedidos complexos, analisar a criação e conclusão de tarefas individuais oferece uma visão detalhada da execução.

Onde obter

Evento explícito capturado do campo sys_created_on de um registro na tabela sc_task vinculado ao sc_req_item.

Captura

Use o timestamp sys_created_on dos registros sc_task.

Tipo de evento explicit
Vendedor Externo Acionado
Representa a transferência de uma solicitação ou tarefa para um fornecedor externo. Isso pode ser identificado pela atribuição a um grupo específico de fornecedor ou por um marcador (flag) na solicitação.
Por que é importante

Esta atividade permite analisar o desempenho dos fornecedores e seu impacto no ciclo de vida do pedido, dado essencial para o dashboard de Ciclo de Engajamento de Fornecedores Externos.

Onde obter

Geralmente identificado por indução, como um assignment_group de fornecedor ou um marcador específico no registro sc_req_item ou sc_task.

Captura

Identifica mudança do grupo de atribuição para um grupo de fornecedor conhecido.

Tipo de evento inferred
Recomendado Opcional

Guias de Extração

Como obter seus dados do ServiceNow