Seu Template de Dados para Onboarding de KYC
Seu Template de Dados para Onboarding de KYC
- Atributos recomendados para seu event log
- Principais atividades para rastrear durante o processo
- Orientação prática para extração de dados
Atributos de Onboarding de Clientes KYC
| Nome | Descrição | ||
|---|---|---|---|
|
Atividade
ActivityName
|
O nome do evento ou tarefa específica ocorrida no processo de onboarding. | ||
|
Descrição
Este atributo registra o nome da atividade ou evento, como 'Solicitação Enviada' ou 'Revisão Iniciada'. Analisar atividades é a essência do Process Mining. Usamos esse campo para construir o mapa do processo, medir a frequência de cada etapa e identificar quais tarefas consomem mais tempo na jornada de onboarding.
Por que é importante
Este atributo define as etapas no mapa do processo, permitindo visualizar e analisar o fluxo de ponta a ponta.
Onde obter
Esta informação é geralmente capturada na trilha de auditoria do Pega (tabelas de histórico) ou derivada das mudanças de status do caso.
Exemplos
Triagem Inicial RealizadaRevisão de Compliance ConcluídaPedido Aprovado
|
|||
|
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 do início de uma atividade, garantindo a ordem cronológica dos eventos. Timestamps são fundamentais para analisar o desempenho: com eles, calculamos a duração de cada tarefa, os tempos de espera e o tempo total de ciclo (cycle time). Esses dados são cruciais para identificar gargalos e medir a adesão aos SLAs.
Por que é importante
Os timestamps fornecem o contexto cronológico para calcular durações, analisar o desempenho do processo e identificar atrasos.
Onde obter
Parte padrão da trilha de auditoria do Pega, frequentemente encontrada como pxTimeCreated nas tabelas de histórico.
Exemplos
2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:05:00Z
|
|||
|
Solicitação do Cliente
CustomerApplication
|
O identificador único para cada caso de solicitação de onboarding. | ||
|
Descrição
A Solicitação do Cliente é o identificador principal que agrupa todas as atividades de uma jornada de onboarding. Cada solicitação segue um caminho desde o envio até a aprovação ou rejeição. No Process Mining, este atributo é essencial para reconstruir a jornada de ponta a ponta. Ele permite que os analistas visualizem a sequência completa de eventos e comparem diferentes caminhos. Analisar casos com base neste ID ajuda a identificar variantes comuns, gargalos e desvios do procedimento padrão.
Por que é importante
Este ID é a base do Process Mining, pois conecta todos os eventos individuais em instâncias de processos coerentes de ponta a ponta para análise.
Onde obter
Normalmente é o ID principal do caso no Pega, acessível como pzInsKey ou equivalente no objeto de trabalho principal.
Exemplos
APP-2023-00123APP-2023-00124APP-2023-00125
|
|||
|
Data Alvo do SLA
SlaTargetDate
|
A data prevista para a conclusão do caso de onboarding do cliente. | ||
|
Descrição
Armazena o prazo de conclusão definido pelo SLA, que pode variar conforme o perfil do cliente ou produto. É o benchmark usado para medir a eficiência. Analisar casos que perdem o prazo ajuda a encontrar atrasos sistêmicos e priorizar melhorias para garantir o cumprimento dos acordos de serviço.
Por que é importante
Fornece o referencial para medir o cumprimento de prazos, o que é crítico para a satisfação do cliente e o controle operacional.
Onde obter
A Pega possui um framework nativo para gestão de SLAs. Essa data geralmente fica armazenada em propriedades como pySLAGoal ou em uma propriedade de SLA personalizada dentro do caso.
Exemplos
2023-11-10T17:00:00Z2023-11-15T17:00:00Z
|
|||
|
Departamento
WorkGroup
|
O departamento ou equipe funcional responsável pela atividade. | ||
|
Descrição
Este atributo identifica a equipe ou unidade responsável pela tarefa, como 'Triagem', 'Compliance' ou 'Operações'. Essa análise é vital para entender a distribuição de carga de trabalho. Ajuda os gestores a ver como o trabalho flui entre times, identificar gargalos entre áreas e ajustar a alocação de recursos para equilibrar a operação.
Por que é importante
Permite analisar o fluxo do processo e gargalos entre diferentes unidades de negócio, apoiando a gestão de recursos e a otimização organizacional.
Onde obter
Geralmente está associado ao perfil do usuário no Pega (registro de Operator ID) e pode ser vinculado aos dados do evento. A propriedade pode ser pyWorkGroup.
Exemplos
Triagem InicialRevisão de ComplianceAtivação de Conta
|
|||
|
End Time
EndTime
|
O timestamp que indica quando uma atividade ou evento foi concluído. | ||
|
Descrição
Este atributo registra o momento exato em que uma atividade foi concluída. Em conjunto com o horário de início, ele permite calcular o tempo de processamento real. Ter um horário de término distinto permite diferenciar o tempo de execução ativa do tempo de espera na fila, o que é essencial para identificar onde estão os gargalos reais do processo.
Por que é importante
Possibilita o cálculo preciso do tempo de processamento das atividades, o que é essencial para análise detalhada de desempenho e identificação de gargalos.
Onde obter
Pode estar disponível na trilha de auditoria ou ser derivado usando o início do evento seguinte como o término do atual.
Exemplos
2023-10-26T10:15:00Z2023-10-26T18:05:20Z2023-10-27T11:00:00Z
|
|||
|
Motivo da Rejeição
RejectionReason
|
Especifica o motivo pelo qual uma solicitação foi rejeitada. | ||
|
Descrição
Quando uma solicitação é 'Rejeitada', este atributo indica o motivo, como 'Falha na verificação' ou 'Documentação incompleta'. Este campo alimenta o dashboard de análise de rejeições. Ao segmentar os casos por motivo, a empresa identifica os pontos de falha mais comuns e pode agir para reduzir a taxa de rejeição, melhorando a experiência do cliente e a eficiência.
Por que é importante
Fornece insights práticos sobre os motivos de falha nas solicitações, permitindo melhorias direcionadas no processo para aumentar a taxa de sucesso.
Onde obter
Provavelmente uma propriedade definida quando o caso muda para o status 'Rejeitado'. Verifique os campos padrão de motivo de rejeição no Pega KYC.
Exemplos
Alerta de SançõesDivergência na DocumentaçãoIdentificação de PEP (Pessoa Exposta Politicamente)Informação Insuficiente
|
|||
|
Nível de Risco
RiskLevel
|
O nível de risco calculado para a solicitação do cliente. | ||
|
Descrição
Este atributo representa o risco do cliente ('Baixo', 'Médio' ou 'Alto'), geralmente definido por um motor de score automático. O nível de risco gera grandes variações no processo: casos de alto risco exigem mais diligências e revisões extras, o que aumenta o tempo de ciclo. Analisar por risco ajuda a validar se esses controles estão funcionando corretamente sem travar o fluxo desnecessariamente.
Por que é importante
Explica variações no caminho e na duração do processo, já que o nível de risco geralmente determina o nível de diligência necessária.
Onde obter
Seria uma propriedade calculada no caso, preenchida por uma regra de decisão ou modelo de score. Consulte a documentação do Pega KYC.
Exemplos
BaixoMédioAlto
|
|||
|
Status do Pedido
ApplicationStatus
|
O resultado final ou status atual da solicitação do cliente. | ||
|
Descrição
Este atributo indica o status final da solicitação, como 'Aprovada', 'Rejeitada' ou 'Desistência'. É uma dimensão essencial para analisar resultados. Com ela, segmentamos os casos para entender o que leva ao sucesso ou à falha, ajudando a replicar boas práticas de casos aprovados e a corrigir as causas de rejeição.
Por que é importante
Define o resultado de negócio de um caso, permitindo análises poderosas que comparam caminhos bem-sucedidos com os malsucedidos.
Onde obter
Geralmente é o status final (pyStatusWork) do objeto de trabalho do caso no Pega.
Exemplos
AprovadoRejeitadoPendente de ConformidadeDesistência do cliente
|
|||
|
Utilizador
OperatorId
|
O identificador único do usuário que realizou a atividade. | ||
|
Descrição
Registra o ID do funcionário ou bot responsável pela tarefa. A análise por usuário ajuda a entender a distribuição de trabalho e necessidades de treinamento. Também serve para investigar desvios, identificando quais times estão envolvidos em fluxos fora do padrão.
Por que é importante
Este atributo vincula as atividades do processo a pessoas ou equipes específicas, permitindo analisar a carga de trabalho, avaliar desempenho e realizar auditorias de conformidade.
Onde obter
Campo padrão na trilha de auditoria do Pega, geralmente armazenado como pxUpdateOperator nas tabelas de histórico.
Exemplos
j.silva@bancoacme.com.branalista_kyc_04system_auto_agent
|
|||
|
É Automatizado
IsAutomated
|
Um sinalizador que indica se uma atividade foi realizada por um sistema ou por um humano. | ||
|
Descrição
Este atributo booleano indica se a tarefa foi automática (bot/regra) ou manual (humana). Essa distinção é crucial para medir a eficácia da automação atual e identificar novas oportunidades para automatizar tarefas manuais, melhorando a interação entre humanos e sistemas.
Por que é importante
Separa atividades realizadas por humanos daquelas feitas pelo sistema, o que é fundamental para qualquer iniciativa de automação ou análise.
Onde obter
Pode ser derivado do ID do usuário. Se o OperatorId corresponder a uma conta de sistema ou agente conhecido, esta flag é marcada como verdadeira.
Exemplos
verdadeirofalse
|
|||
|
É Retrabalho
IsRework
|
Um sinalizador que indica se uma atividade faz parte de um loop de retrabalho. | ||
|
Descrição
Este atributo booleano é verdadeiro se uma atividade ocorre mais de uma vez no mesmo caso, como em pedidos de informações adicionais. Identificar retrabalho é vital para achar ineficiências e pontos de fricção. Reduzir esses loops acelera o processo, corta custos operacionais e melhora a experiência do cliente.
Por que é importante
Destaca ineficiências de processo, tarefas redundantes e loops, que são os principais alvos para melhoria de processos.
Onde obter
Esta flag é gerada durante a análise ao checar atividades repetidas para um mesmo ID de caso, como quando a 'Revisão de Documento' ocorre novamente.
Exemplos
verdadeirofalse
|
|||
|
ID do Cliente
CustomerId
|
O identificador único do cliente em processo de onboarding. | ||
|
Descrição
Este ID único vincula a solicitação ao registro do cliente no cadastro mestre. Enquanto o ID da solicitação rastreia o processo atual, o ID do Cliente permite analisar o histórico desse cliente em múltiplas interações. Isso possibilita uma visão centrada no cliente, enriquecendo a análise com dados de segmento e comportamento histórico.
Por que é importante
Conecta os dados do processo aos dados mestres do cliente, permitindo análises mais ricas baseadas em atributos e histórico dos clientes.
Onde obter
Seria uma propriedade central no caso de KYC, vinculando-o ao modelo de dados do cliente no Pega ou em um CRM externo.
Exemplos
CUST-98765CUST-98766CUST-98767
|
|||
|
País do Cliente
CustomerCountry
|
O país de residência ou constituição do cliente. | ||
|
Descrição
Armazena o país do cliente, informação essencial para a avaliação de risco e nível de diligência. Na análise, o país pode revelar padrões geográficos: certas jurisdições podem exigir processos mais complexos. Isso permite analisar o desempenho por região e garantir que as regras locais de conformidade sejam seguidas com eficiência.
Por que é importante
Permite a análise geográfica do processo, que muitas vezes está ligada à complexidade regulatória e aos níveis de risco.
Onde obter
Seria uma propriedade no objeto de dados do cliente associado ao caso.
Exemplos
EUADEUSGPGBR
|
|||
|
Produto Integrado
OnboardedProduct
|
O produto financeiro que o cliente está solicitando. | ||
|
Descrição
Este atributo indica o produto ou serviço, como 'Conta Corrente', 'Empréstimo' ou 'Investimentos'. O produto influencia o processo devido a diferentes regras regulatórias. Analisar por produto ajuda a ver se certas linhas têm tempos de ciclo maiores ou taxas de rejeição mais altas, permitindo otimizações específicas.
Por que é importante
Permite que a análise do processo seja segmentada por linha de produto, revelando diferenças de desempenho e oportunidades de otimização.
Onde obter
Seria uma propriedade no caso, selecionada no início do processo de solicitação.
Exemplos
Conta CorrenteGestão de PatrimônioLinha de Crédito PJ
|
|||
|
Sistema de Origem
SourceSystem
|
Identifica o sistema de origem dos dados. | ||
|
Descrição
Especifica o sistema de origem do evento, que neste caso seria 'Pega KYC'. Mesmo parecendo redundante, este campo é vital para a governança de dados ao integrar múltiplas fontes, garantindo a clareza sobre a origem de cada informação e facilitando a solução de problemas.
Por que é importante
Fornece o contexto essencial sobre a origem dos dados, garantindo a governança e permitindo análises entre múltiplos sistemas de origem.
Onde obter
Este é tipicamente um valor estático adicionado durante o processo de extração e transformação de dados para rotular a origem do dataset.
Exemplos
Pega KYCPega CLM
|
|||
|
Status do Documento
DocumentStatus
|
O status atual da documentação fornecida pelo cliente. | ||
|
Descrição
Rastreia o estado dos documentos ('Pendente', 'Recebido', 'Verificado' ou 'Rejeitado'). É fundamental para analisar a velocidade de verificação de documentos — um gargalo comum. Ao monitorar quanto tempo os arquivos ficam em cada status, a empresa identifica se o atraso é na submissão pelo cliente ou na análise interna.
Por que é importante
Oferece visibilidade sobre o subprocesso de manipulação de documentos, ajudando a identificar e resolver atrasos comuns na verificação de documentos.
Onde obter
Provavelmente seria uma propriedade em um objeto de dados relacionado que rastreia cada documento exigido. Consulte a documentação do Pega KYC.
Exemplos
Upload pendenteRecebido - Aguardando revisãoAprovadoRejeitado - Necessário mais informações
|
|||
|
Status do SLA
SlaStatus
|
Indica se o caso foi concluído dentro da meta de SLA. | ||
|
Descrição
Este atributo classifica cada caso concluído como 'No Prazo' ou 'Atrasado', comparando a conclusão real com a meta de SLA. Essa é a métrica central para o dashboard de monitoramento de SLAs. Ela oferece uma visão clara do desempenho em relação aos compromissos de serviço, ajudando a identificar causas de atrasos e mitigar riscos de descumprimento futuro.
Por que é importante
Mede diretamente o desempenho em relação aos compromissos assumidos, o que é crucial para a gestão operacional, compliance e satisfação do cliente.
Onde obter
Derivado da comparação entre o timestamp final e o campo SlaTargetDate. Se o término for após a meta, o status é 'Atrasado'.
Exemplos
No PrazoAtrasadoEm Risco
|
|||
|
Tempo de Ciclo
CycleTime
|
O tempo total decorrido desde o envio da solicitação até a resolução final. | ||
|
Descrição
Mede a duração de ponta a ponta da solicitação, do primeiro ao último evento. O Tempo de Ciclo (Cycle Time) é o principal KPI de eficiência e experiência do cliente. Usado para monitorar médias de tempo, identificar casos lentos e medir o impacto das melhorias implementadas.
Por que é importante
Este é um KPI crítico que mede diretamente a velocidade e eficiência do onboarding sob a ótica do cliente.
Onde obter
Calculado pela ferramenta de Process Mining como a diferença entre o maior e o menor timestamp de cada ID de caso.
Exemplos
5 dias e 4 horas12 dias e 1 hora2 dias e 8 horas
|
|||
|
Tempo de Processamento
ProcessingTime
|
A duração de uma única atividade, excluindo o tempo de espera. | ||
|
Descrição
Mede o tempo de trabalho ativo em um evento (Término menos Início), representando quanto tempo um recurso se dedicou à tarefa. O Tempo de Processamento é essencial para distinguir tarefas complexas de filas longas. Isso permite melhorias direcionadas: investir em ferramentas para agilizar a tarefa ou realocar recursos para reduzir a fila.
Por que é importante
Mede a duração do trabalho ativo nas atividades, ajudando a distinguir entre tarefas ineficientes e problemas de recursos ou de filas.
Onde obter
Calculado como (Término - Início) para cada evento. Requer que ambos os campos de timestamp estejam presentes.
Exemplos
15 minutos4 horas e 30 minutos2 dias
|
|||
|
Tipo de Caso
CaseType
|
O tipo específico de caso de onboarding de KYC. | ||
|
Descrição
Este atributo categoriza a solicitação, como 'Pessoa Física', 'Cliente Corporativo' ou 'Alta Renda'. Diferentes perfis seguem caminhos distintos, com etapas e SLAs específicos. Analisar por Tipo de Caso permite uma comparação mais justa de desempenho, ajudando a entender quais jornadas são mais propensas a atrasos e permitindo melhorias direcionadas a cada segmento.
Por que é importante
Permite segmentar os dados do processo em categorias distintas, possibilitando uma análise de desempenho mais precisa e relevante.
Onde obter
Geralmente é o class name da instância do caso no Pega, ou uma propriedade dedicada que define seu tipo.
Exemplos
Onboarding de Pessoa FísicaOnboarding CorporativoDiligência Simplificada
|
|||
|
Última Atualização de Dados
LastDataUpdate
|
O timestamp da última atualização ou extração de dados. | ||
|
Descrição
Este atributo indica a última vez que os dados foram extraídos do sistema de origem. É importante para saber o quão atualizados são os dados analisados, informando aos usuários a validade dos insights nos dashboards de monitoramento operacional.
Por que é importante
Informa os usuários sobre a atualidade dos dados, garantindo que entendam se a análise reflete o estado presente ou um período anterior.
Onde obter
Este valor é gerado e registrado no conjunto de dados durante o processo de extração, transformação e carga (ETL).
Exemplos
2023-11-01T02:00:00Z2023-11-02T02:00:00Z
|
|||
Atividades de Onboarding de Clientes KYC
| Atividade | Descrição | ||
|---|---|---|---|
|
Avaliação de Risco Realizada
|
Esta atividade marca a conclusão da avaliação e pontuação de risco do cliente. É um marco fundamental, geralmente capturado quando a etapa de avaliação de risco no Pega é finalizada. | ||
|
Por que é importante
Este é um marco crítico de conformidade. Analisar sua duração e resultado é fundamental para entender a eficiência da gestão de riscos.
Onde obter
Inferido pela conclusão de uma etapa ou fluxo específico no modelo de caso do Pega, o que resulta em uma mudança de status registrada na trilha de auditoria.
Captura
Inferido por uma mudança no pyStatusWork após a etapa de avaliação de risco, por exemplo, movendo para 'Pendente-Revisão-Compliance'.
Tipo de evento
inferred
|
|||
|
Candidatura enviada
|
Esta atividade marca a criação de um novo caso no sistema Pega. É capturada quando uma nova solicitação é iniciada oficialmente, seja via portal do cliente, usuário interno ou feed de dados automático. | ||
|
Por que é importante
Principal evento de início de todo o onboarding. Essencial para medir o cycle time total e analisar volumes e padrões de solicitações.
Onde obter
Evento explícito capturado quando um novo caso é criado. Verifique a entrada inicial na tabela pc_history_work para o ID do caso.
Captura
Capturado a partir do timestamp de criação do caso na tabela pc_work ou da primeira entrada na trilha de auditoria.
Tipo de evento
explicit
|
|||
|
Documentos Recebidos
|
Marca o momento em que o cliente carregou ou forneceu todos os documentos solicitados ao sistema. Isso costuma ser capturado como um evento explícito quando novos anexos são vinculados ao caso no Pega. | ||
|
Por que é importante
Marco crítico que inicia a contagem do SLA de verificação. Atrasos antes deste ponto dependem do cliente; após ele, são de responsabilidade interna.
Onde obter
Registrado explicitamente nas tabelas de anexo do Pega (pc_link_attachment ou pc_data_workattach) quando um novo documento é associado ao caso.
Captura
O evento é o timestamp de criação do objeto de anexo relevante vinculado ao caso.
Tipo de evento
explicit
|
|||
|
Onboarding concluído
|
Esta atividade marca o encerramento bem-sucedido de todo o processo de onboarding. É capturada quando o caso atinge o status de resolução final positiva. | ||
|
Por que é importante
Principal evento de término com sucesso. Essencial para calcular o cycle time de todos os clientes integrados corretamente.
Onde obter
Inferido pelo timestamp de quando o status de resolução do caso (pyStatusWork) é definido com seu valor final de sucesso, como 'Resolved-Completed'.
Captura
Identifique o timestamp do status final 'Resolved-Completed' na tabela History-Work.
Tipo de evento
inferred
|
|||
|
Pedido Aprovado
|
Representa a decisão final de aprovação do onboarding do cliente. Este é um marco crítico, inferido quando o status do caso é atualizado para um estado de resolução final bem-sucedido. | ||
|
Por que é importante
Marco que separa casos de sucesso dos malsucedidos, sendo um ponto ideal para medir o tempo de tomada de decisão antes da ativação final.
Onde obter
Inferido pelo timestamp de quando o status de resolução do caso (pyStatusWork) é definido com um valor terminal de sucesso, como 'Resolved-Completed' ou 'Resolved-Approved'.
Captura
Identifique a atualização final do pyStatusWork que reflete uma resolução bem-sucedida na trilha de auditoria do caso.
Tipo de evento
inferred
|
|||
|
Pedido Rejeitado
|
Representa a decisão final de rejeitar a solicitação do cliente, encerrando o processo de onboarding. Este evento é inferido quando o caso é movido para um status de resolução final malsucedido. | ||
|
Por que é importante
Principal evento de término por falha. Fundamental para analisar a taxa de rejeição e entender os motivos por trás de cada insucesso.
Onde obter
Inferido pelo timestamp de quando o status de resolução do caso (pyStatusWork) é definido com um valor terminal de falha, como 'Resolved-Rejected'.
Captura
Identifique a atualização final do pyStatusWork que reflete um status de rejeição na trilha de auditoria do caso.
Tipo de evento
inferred
|
|||
|
Revisão de Compliance Concluída
|
Esta atividade indica que a equipe de Conformidade concluiu sua análise e emitiu uma recomendação, movendo o caso para fora dessa etapa. | ||
|
Por que é importante
Evento final para o KPI de ciclo de revisão de conformidade. Essencial para analisar e melhorar a eficiência dessa etapa.
Onde obter
Inferido por uma mudança no status do caso (pyStatusWork) de 'Pendente-Compliance' para um estado como 'Pendente-Decisão-Final' ou 'Resolvido-Aprovado'.
Captura
Identifique o timestamp de quando a etapa de revisão de compliance ou a atribuição é concluída no histórico do caso.
Tipo de evento
inferred
|
|||
|
Revisão de Compliance Iniciada
|
Esta atividade marca o início da revisão formal pela equipe de Conformidade, uma etapa crítica e muitas vezes demorada. É capturada quando o caso é atribuído à fila de trabalho de Conformidade. | ||
|
Por que é importante
Evento de início para o KPI de revisão de conformidade. Ajuda a identificar gargalos nesta fase crítica e muitas vezes manual.
Onde obter
Inferido por uma mudança no status do caso (pyStatusWork) para 'Pendente-Compliance' ou por um evento de criação de atribuição no workbasket de compliance.
Captura
Identifique o timestamp de quando o caso é atribuído a um workbasket de compliance ou quando o status muda para indicar o início da revisão.
Tipo de evento
inferred
|
|||
|
Conta Ativada
|
Esta atividade significa que a conta do cliente foi ativada com sucesso no sistema bancário core ou outro sistema relevante, após a aprovação no Pega. | ||
|
Por que é importante
Representa o momento de entrega de valor para o cliente e para a empresa. O tempo entre a 'Aprovação da Solicitação' e este evento mede a eficiência das integrações entre sistemas.
Onde obter
Inferido por um status de caso específico (pyStatusWork) como 'Resolvido-ContaAtiva' ou um sinalizador definido no caso via integração, conforme registrado na trilha de auditoria.
Captura
Identifique o timestamp de uma atualização de propriedade do caso que indique que a conta de destino está ativa.
Tipo de evento
inferred
|
|||
|
Documentos Solicitados
|
Esta atividade ocorre quando o sistema ou um analista determina que documentos específicos são necessários. É capturada pela criação de uma correspondência ou mudança para status como 'Aguardando Documentos'. | ||
|
Por que é importante
Monitorar isso ajuda a medir o tempo de resposta do cliente e se o processo trava por falta de documentos. É um indicador anterior ao KPI de duração da verificação.
Onde obter
Pode ser um evento de correspondência explícito (pc_link_attachment) ou inferido por uma mudança de status do caso (pyStatusWork) registrada na trilha de auditoria.
Captura
Inferido pela mudança do pyStatusWork para 'Pendente-Documentos' ou similar. Também pode estar atrelado a um evento explícito de 'Enviar Correspondência'.
Tipo de evento
inferred
|
|||
|
Informações Adicionais Solicitadas
|
Ocorre quando um revisor, geralmente de compliance, solicita mais informações ou esclarecimentos ao cliente. Este evento costuma ser explícito, registrado quando um usuário envia uma correspondência específica do caso. | ||
|
Por que é importante
Esta atividade é o principal indicador de retrabalho e loops. Monitorar sua frequência é essencial para medir a Taxa de Processamento Direto e identificar requisitos confusos.
Onde obter
Pode ser um evento explícito de 'Enviar Correspondência' registrado na trilha de auditoria. Alternativamente, pode ser inferido por uma mudança de status para 'Pendente-Informação-Cliente'.
Captura
Capturado a partir da criação de um objeto de correspondência específico ou ação de fluxo iniciada pelo operador do caso.
Tipo de evento
explicit
|
|||
|
Revisão de Documentos Concluída
|
Esta atividade indica que um oficial de conformidade ou um processo automático concluiu a revisão dos documentos. O evento é inferido pela mudança no status do documento ou do caso. | ||
|
Por que é importante
Conclui o KPI de Duração da Verificação de Documentos. Analisar o tempo para completar esta etapa destaca ineficiências no processo de revisão manual ou automatizado.
Onde obter
Inferido por uma mudança no status do caso (pyStatusWork) de um estado 'Pendente-Revisão' para 'Revisão-Concluída' ou 'Pendente-Checagens' na trilha de auditoria.
Captura
Identifique o timestamp de quando o status do caso (pyStatusWork) muda, indicando que o sub-processo de verificação de documentos foi resolvido.
Tipo de evento
inferred
|
|||
|
Triagem Inicial Realizada
|
Representa a conclusão de uma análise inicial, muitas vezes automatizada, dos dados da solicitação para verificar a integridade e elegibilidade básica. Este evento é geralmente inferido a partir de uma mudança de status, como a transição de 'Novo' para 'Aguardando Documentos'. | ||
|
Por que é importante
Analisar o tempo gasto nesta fase inicial ajuda a identificar gargalos precoces na validação de dados ou na execução de regras automatizadas, que podem atrasar todo o processo.
Onde obter
Inferido por uma mudança na propriedade de status do caso (pyStatusWork) registrada na trilha de auditoria do Pega (tabela History-Work).
Captura
Identifique o timestamp da mudança de pyStatusWork de um estado 'Novo' ou 'Enviado' para 'ScreeningComplete' ou similar.
Tipo de evento
inferred
|
|||
|
Verificação de antecedentes iniciada
|
Representa o início das verificações de antecedentes (background checks) internas ou externas, que podem envolver integrações com serviços de terceiros. Geralmente é inferido por uma mudança de status indicando que o caso aguarda resultados dessas verificações. | ||
|
Por que é importante
Esta atividade ajuda a isolar o tempo de espera por dependências externas, permitindo analisar o desempenho de terceiros e seu impacto no tempo total de onboarding.
Onde obter
Inferido por uma mudança no status do caso (pyStatusWork) para 'Pendente-Verificação-Antecedentes' ou similar, conforme registrado na tabela History-Work do Pega.
Captura
Identifique o timestamp de quando o pyStatusWork é atualizado para refletir o início do processo de verificação de antecedentes.
Tipo de evento
inferred
|
|||