Seu Template de Dados de Onboarding de Clientes KYC

ACTICO
Seu Template de Dados de Onboarding de Clientes KYC

Seu Template de Dados de Onboarding de Clientes KYC

Este Template oferece uma abordagem estruturada para coletar os dados essenciais para analisar seu processo de Onboarding KYC. Ele descreve os atributos cruciais e as principais atividades a serem rastreadas em seu Event Log. Além disso, você encontrará orientações práticas sobre como extrair esses dados de seus sistemas de origem, garantindo um início tranquilo em sua jornada de Process Mining.
  • Atributos recomendados para coletar
  • Atividades-chave a monitorizar
  • Guia de extração para ACTICO
É novo em event logs? Saiba como criar um event log para Process Mining.

Atributos de Onboarding de Clientes KYC

Estes são os campos de dados recomendados para incluir em seu Event Log para uma análise abrangente do seu processo de Onboarding KYC.
5 Obrigatório 7 Recomendado 6 Opcional
Nome Descrição
Nome da Atividade
ActivityName
O nome do evento de negócio ou tarefa específica realizada no processo de onboarding.
Descrição

Este atributo registra o nome de cada etapa ou atividade no processo KYC, como 'Pedido Enviado', 'Avaliação de Risco Realizada' ou 'Pedido Aprovado'. Ele fornece os blocos de construção sequenciais do mapa do processo.

Analisar o Nome da Atividade permite visualizar o fluxo, identificar atividades frequentes ou raras e detectar gargalos ou loops de retrabalho. É a base para entender quais ações estão sendo executadas e em que ordem, o que é crucial para a análise de variantes e verificações de conformidade.

Por que é importante

Define as etapas no mapa de processos, permitindo visualizar o fluxo, identificar desvios e analisar a frequência e sequência das atividades.

Onde obter

Essa informação costuma estar em uma tabela de Event Log no ACTICO, geralmente em um campo que descreve o evento ou tipo de tarefa. Consulte a documentação do ACTICO.

Exemplos
Candidatura enviadaAvaliação de Risco RealizadaRevisão de conformidade concluídaSolicitação rejeitada
Solicitação do cliente
CustomerApplication
O identificador único de um pedido de onboarding, servindo como ID do case para análise do processo.
Descrição

O pedido de abertura de conta (Customer Application) é o identificador principal do case que agrupa todos os eventos e atividades relacionados à jornada de onboarding de um único cliente. Ele representa uma instância completa do processo KYC, desde o envio inicial até a decisão final de aprovação ou rejeição.

No Process Mining, este atributo é essencial para reconstruir a jornada de ponta a ponta de cada pedido. Ele permite que os analistas acompanhem a sequência de atividades, meçam os tempos totais de ciclo e comparem diferentes caminhos ou variantes percorridos pelos pedidos. Todos os eventos que compartilham o mesmo ID de Pedido são considerados parte do mesmo case.

Por que é importante

Este é o atributo fundamental para o Process Mining, pois conecta todos os eventos relacionados em uma única instância de processo, permitindo a análise de ponta a ponta da experiência de cada cliente.

Onde obter

Esta é a chave primária nas tabelas de gestão de pedidos ou cases no ACTICO. Consulte a documentação do ACTICO para nomes específicos de tabelas e campos.

Exemplos
APP-2023-001234APP-2023-001235APP-2024-000001
Tempo do Evento
EventTime
O registro de data e hora indicando quando uma atividade específica começou ou ocorreu.
Descrição

O Event Time é a data e hora exatas em que uma atividade foi registrada. Ele fornece a ordem cronológica para todos os eventos em um único caso de onboarding, formando a linha do tempo da jornada.

Este atributo é fundamental para análises baseadas em tempo. Ele serve para calcular o tempo de ciclo entre atividades, identificar atrasos e esperas, medir a duração total do caso e conferir a conformidade com SLAs. A sequência desses registros permite que as ferramentas de Process Mining reconstruam o fluxo exato do processo como ele realmente ocorreu.

Por que é importante

Este atributo fornece a ordem cronológica dos eventos, o que é essencial para calcular durações, descobrir gargalos e analisar a linha do tempo do processo.

Onde obter

Localizado nas tabelas de log de eventos do ACTICO, este é o carimbo de data/hora associado a cada atividade registrada. Consulte a documentação do ACTICO.

Exemplos
2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T15:45:10Z
Sistema de Origem
SourceSystem
O sistema de registro de onde se originam os dados dos eventos.
Descrição

Este atributo identifica o sistema de informação de origem onde os dados foram gerados. Para este processo, será consistentemente 'ACTICO', mas em análises amplas com múltiplos sistemas, ajuda a diferenciar as origens dos dados.

No contexto de Process Mining, é crucial para a governança e validação de dados. Garante que as informações sejam atribuídas corretamente à sua fonte, o que é importante ao mesclar dados de diferentes sistemas para criar uma visão holística. Também auxilia na resolução de problemas de qualidade de dados, rastreando-os até o sistema de origem.

Por que é importante

Fornece contexto essencial sobre a origem dos dados, garantindo linhagem e governança, o que é crítico ao combinar dados de múltiplas fontes.

Onde obter

Geralmente é um valor estático ('ACTICO') adicionado durante a extração e transformação para rotular o conjunto de dados.

Exemplos
ACTICOPlataforma ACTICOMódulo KYC do Actico
Última Atualização de Dados
LastDataUpdate
O timestamp que indica a última vez que os dados foram atualizados ou extraídos do sistema de origem.
Descrição

Este atributo registra a data e a hora da extração de dados mais recente do ACTICO. É um campo de metadados aplicado a todo o conjunto de dados, fornecendo contexto sobre a atualidade da análise.

Em Dashboards e relatórios, essa informação é vital para que os usuários saibam o quão recentes são os dados. Ajuda a gerenciar as expectativas sobre os insights e é crucial para o monitoramento operacional onde dados em tempo real são importantes. Exibir este registro garante transparência e confiança nas informações apresentadas.

Por que é importante

Indica a atualização dos dados, permitindo que os usuários saibam se estão analisando informações recentes, o que é crucial para decisões operacionais.

Onde obter

Este valor é gerado e armazenado durante o processo de extração, transformação e carga (ETL). Reflete o registro de data e hora de quando o trabalho de ETL foi concluído com sucesso.

Exemplos
2024-05-20T08:00:00Z2024-05-21T08:00:00Z
Data Alvo do SLA
SlaTargetDate
A data em que se espera que o processo de onboarding do cliente seja concluído.
Descrição

A Data Limite do SLA (SLA Target Date) é o prazo para concluir o onboarding de um cliente, conforme definido pelos acordos de nível de serviço internos. Esta data costuma ser calculada com base na data de envio do pedido mais um tempo padrão de processamento.

Este atributo é essencial para monitorar a conformidade do SLA. Ao comparar a data real de conclusão de um case com sua Data Limite, o sistema determina se o prazo foi cumprido ou violado. Esta é a base para o Dashboard de "Performance de SLA de Onboarding" e para o KPI de "Taxa de Adesão ao SLA".

Por que é importante

Estabelece o parâmetro para medir a performance de pontualidade, permitindo o monitoramento direto e o relato da conformidade do SLA.

Onde obter

Isso pode estar em um campo na tabela principal do case no ACTICO ou ser derivado por regras de negócio (ex: Data de Envio + 5 dias úteis).

Exemplos
2023-11-01T17:00:00Z2023-11-02T17:00:00Z2023-11-03T17:00:00Z
Departamento
Department
O departamento ou equipe responsável pela execução da atividade.
Descrição

Este atributo atribui uma atividade a uma unidade organizacional específica, como 'Compliance', 'Equipe de Onboarding' ou 'Relacionamento'. Ele fornece um contexto organizacional ao fluxo do processo.

A análise por departamento é crucial para entender como o trabalho é transferido entre diferentes partes da organização. Ajuda a identificar gargalos interdepartamentais, medir a eficiência e analisar a alocação de recursos entre as equipes. Os Dashboards podem ser filtrados por departamento para oferecer aos gestores uma visão da performance específica de seu time.

Por que é importante

Fornece uma dimensão organizacional para análise, permitindo a identificação de atrasos entre departamentos e a avaliação da performance das equipes.

Onde obter

Essa informação pode estar armazenada com os dados do evento ou ser derivada cruzando dados de usuários com uma tabela mestre de RH. Consulte a documentação do ACTICO.

Exemplos
ComplianceEquipe de onboardingServiço ao Cliente
End Time
EndTime
O carimbo de data/hora (timestamp) que indica quando uma atividade específica foi concluída.
Descrição

O Horário de Término (End Time) marca a conclusão de uma atividade. Junto com o Horário de Início (EventTime), ele permite o cálculo da duração precisa de cada tarefa, conhecida como tempo de processamento. Nem todos os eventos possuem um horário de término distinto, pois alguns podem ser instantâneos.

Este atributo é fundamental para a análise de performance, especialmente para medir quanto tempo cada etapa leva. Ele permite a criação de Dashboards detalhados, ajuda a identificar quais atividades consomem mais tempo e é essencial para calcular KPIs como o 'Tempo Médio de Revisão de Documentos'.

Por que é importante

Permite o cálculo preciso da duração das atividades (tempo de processamento), essencial para identificar gargalos de desempenho e analisar a eficiência dos recursos.

Onde obter

Assim como a hora de início, isso geralmente é encontrado nas tabelas de event log do ACTICO. Alguns sistemas armazenam início e fim em colunas separadas. Consulte a documentação do ACTICO.

Exemplos
2023-10-26T10:15:00Z2023-10-26T12:00:00Z2023-10-27T16:00:15Z
Motivo da Rejeição
RejectionReason
O motivo específico fornecido quando o pedido de um cliente é rejeitado.
Descrição

Quando o status final de um pedido é 'Rejeitado', este atributo indica a causa principal. Exemplos incluem 'Documentação Incompleta', 'Falha na Verificação de Antecedentes' ou 'Perfil de Alto Risco'.

Este é um atributo vital para a análise de causa raiz. Ao analisar a frequência dos motivos de rejeição, a empresa identifica problemas sistêmicos no processo ou nos envios dos clientes. Por exemplo, muitas rejeições por documentação incompleta podem indicar que as instruções do pedido não estão claras. Isso apoia diretamente o Dashboard de 'Taxa e Motivos de Rejeição de Pedidos'.

Por que é importante

Fornece o "porquê" por trás das rejeições de pedidos, permitindo a análise de causa raiz para reduzir a taxa de rejeição e melhorar a eficiência do processo.

Onde obter

Geralmente encontrado na tabela principal de cases ou pedidos no ACTICO, sendo preenchido apenas quando o status do pedido é 'Rejeitado'.

Exemplos
Documentação IncompletaFalha na verificação de identidadeCorrespondência de SançõesPontuação de alto risco
Nível de Risco
RiskLevel
O nível de risco calculado para o pedido do cliente, como Baixo, Médio ou Alto.
Descrição

Este atributo representa a categoria de risco avaliada de um cliente, que geralmente determina a complexidade e o rigor do processo KYC subsequente. Um cliente de alto risco pode exigir verificações extras e aprovações em comparação a um de baixo risco.

No Process Mining, o Nível de Risco é uma dimensão poderosa para análise comparativa. Ele permite verificar se o processo segue corretamente os caminhos previstos conforme o risco. Por exemplo, é possível validar se todos os clientes de alto risco passaram por uma diligência aprimorada. É fundamental para o Dashboard de fluxos de avaliação de risco.

Por que é importante

Permite segmentar os casos por risco, possibilitando analisar se o processo se adapta corretamente aos diferentes perfis exigidos pelas políticas de conformidade.

Onde obter

Este é um dado importante armazenado no nível do case na tabela principal de pedidos no ACTICO.

Exemplos
BaixoMédioAlto
Status da solicitação
ApplicationStatus
O resultado final ou o estado atual do pedido de onboarding do cliente.
Descrição

Este atributo indica a disposição final de um case, normalmente 'Aprovado' ou 'Rejeitado'. Também pode mostrar o status de cases em andamento. É uma dimensão crítica para análises baseadas em resultados.

Entender por que os pedidos são aprovados ou rejeitados é um objetivo central do Process Mining em KYC. Este atributo permite filtrar o mapa para ver as jornadas típicas de pedidos aprovados versus rejeitados, ajudando a identificar padrões que levam a resultados indesejados. É também a base para o cálculo do KPI de 'Taxa de Rejeição de Pedidos'.

Por que é importante

Define o resultado de cada caso, permitindo a análise comparativa entre instâncias de sucesso e falha, além do cálculo das taxas de rejeição.

Onde obter

Este é um atributo do nível do case, geralmente na tabela principal de pedidos no ACTICO. Reflete o status final da solicitação.

Exemplos
AprovadoRejeitadoEm ProgressoInformação Pendente
Usuário solicitante
InitiatingUser
O ID de usuário ou nome do funcionário que realizou a atividade.
Descrição

Este atributo identifica o usuário específico ou agente do sistema responsável por executar uma atividade. Ele vincula as etapas do processo aos indivíduos ou equipes que as realizaram.

A análise de performance por usuário é um requisito comum. Este atributo permite criar Dashboards que mostram a distribuição da carga de trabalho, tempos de processamento individuais e comparações entre usuários ou times. Ajuda a identificar talentos de alta performance e quem precisa de treinamento, sendo fundamental para entender a alocação e utilização de recursos.

Por que é importante

Vincula as atividades do processo a usuários específicos, permitindo analisar o desempenho por pessoa ou equipe e ajudando a identificar necessidades de treinamento ou desequilíbrio de recursos.

Onde obter

Geralmente armazenado junto com cada evento nas tabelas de log ou histórico de transações do ACTICO. Consulte a documentação do ACTICO.

Exemplos
john.doejane.smithSYSTEM_USER
É Automatizado
IsAutomated
Um indicador que mostra se a atividade foi executada automaticamente pelo sistema ou manualmente por um usuário.
Descrição

Este atributo booleano diferencia tarefas executadas por humanos daquelas realizadas por automação, como uma verificação de antecedentes automática ou pontuação de risco.

Analisar esse atributo ajuda a avaliar a eficácia das iniciativas de automação. Ele permite comparar tempos de processamento entre etapas manuais e automáticas, identifica quais partes ainda são pesadamente manuais e destaca oportunidades de automação para aumentar a eficiência e reduzir custos operacionais.

Por que é importante

Diferencia tarefas humanas de tarefas do sistema, o que é fundamental para medir o impacto da automação e identificar oportunidades de ganho de eficiência.

Onde obter

Isso pode ser inferido do atributo 'InitiatingUser' (ex: se o usuário for 'SYSTEM') ou pode ser uma flag dedicada no Event Log. Consulte a documentação do ACTICO.

Exemplos
verdadeirofalse
É Retrabalho
IsRework
Um indicador calculado que identifica se uma atividade é uma etapa repetida ou parte de um loop de retrabalho.
Descrição

Este atributo booleano sinaliza atividades executadas pela segunda vez ou mais no mesmo case, como uma 'Revisão de Documentos' após um pedido de mais informações. Identifica instâncias de retrabalho, fonte comum de ineficiência.

Identificar retrabalho é um objetivo central do Process Mining. Esta flag permite quantificar o retrabalho, como no cálculo do KPI de 'Taxa de Retrabalho Documental'. No mapa, os loops de retrabalho podem ser destacados para mostrar onde o processo está voltando sobre si mesmo, ajudando a localizar problemas de qualidade onde o processo não foi feito corretamente da primeira vez.

Por que é importante

Destaca casos de trabalho repetido, permitindo medir diretamente a ineficiência do processo e identificar atividades com problemas de qualidade ou clareza.

Onde obter

Este é um atributo calculado. A lógica é definida na ferramenta de Process Mining ou durante a transformação de dados para detectar atividades repetidas no mesmo case.

Exemplos
verdadeirofalse
Estado do SLA
SlaState
Um status calculado indicando se o caso cumpriu, violou ou está em risco de violar seu SLA.
Descrição

Este atributo oferece uma avaliação categórica da performance de um case em relação ao seu SLA. É derivado da comparação do tempo de conclusão (ou tempo atual para cases abertos) com a 'SlaTargetDate'.

Este atributo simplifica os relatórios de SLA, convertendo comparações de datas em um status fácil de entender. Os Dashboards podem usar isso para visualizações claras, como gráficos de pizza que mostram a porcentagem de cases que 'Cumpriram' versus 'Violaram' o prazo. É um elemento essencial para o Dashboard de performance de SLA e suporta o KPI de 'Taxa de Adesão ao SLA'.

Por que é importante

Fornece um status categórico claro da conformidade do SLA para cada case, simplificando os relatórios e permitindo a fácil visualização da performance em relação às metas.

Onde obter

Este é um atributo calculado derivado da lógica de negócio que compara o timestamp de conclusão do case com a 'SlaTargetDate'.

Exemplos
AtingidoVioladoEm Risco
País
Country
O país de residência do cliente que está solicitando o onboarding.
Descrição

Este atributo especifica o país do cliente, o que pode impactar significativamente o processo KYC. Diferentes jurisdições têm requisitos regulatórios distintos, o que pode acionar etapas extras ou alternativas.

Analisar o processo por país permite comparar a performance entre regiões. Ajuda a identificar se certos países têm tempos de ciclo mais longos ou taxas de rejeição maiores, indicando possíveis atritos regulatórios ou desafios de mercado. Essa visão geográfica é importante para empresas globais que buscam padronizar processos respeitando as necessidades locais.

Por que é importante

Oferece uma dimensão geográfica para análise, ajudando a entender variações de processo e diferenças de performance entre várias jurisdições regulatórias.

Onde obter

Esta é uma informação fundamental do cliente, armazenada no nível do case ou do cliente no sistema ACTICO.

Exemplos
EUADEUGBRSGP
Tempo de Processamento
ProcessingTime
A duração do tempo gasto a trabalhar ativamente numa atividade.
Descrição

O Tempo de Processamento é a duração calculada entre o início e o fim de uma atividade. Esta métrica representa o "tempo de toque" ou o tempo de trabalho ativo, em oposição ao tempo de espera entre as atividades.

Este é um KPI crítico para medir a eficiência operacional. Tempos de processamento altos em certas atividades são indicadores claros de gargalos ou tarefas excessivamente complexas. Ao consolidar esta métrica, os gestores podem identificar quais etapas consomem mais recursos e priorizá-las para melhorias de processo ou iniciativas de automação. É um componente fundamental dos Dashboards de performance.

Por que é importante

Mede a duração do trabalho ativo em uma tarefa, ajudando a localizar atividades ineficientes que consomem mais tempo e recursos.

Onde obter

Esta é uma métrica calculada, subtraindo o 'EventTime' (Horário de Início) do 'EndTime' de cada atividade.

Exemplos
864000003600000600000
Tipo de Cliente
CustomerType
Categorização do cliente, como Pessoa Física ou Pessoa Jurídica.
Descrição

Este atributo classifica o solicitante em categorias, como pessoa física ou jurídica. O processo KYC costuma variar significativamente entre esses tipos, sendo o onboarding corporativo bem mais complexo.

Usar o Tipo de Cliente como dimensão permite a separação e comparação desses processos distintos no mesmo conjunto de dados. Analistas podem filtrar o mapa para ver apenas clientes 'Corporate' para entender seus desafios, gargalos e tempos de ciclo únicos, sem que os dados sejam distorcidos pelo processo muito mais simples de clientes 'Pessoa Física'.

Por que é importante

Permite segmentar o processo por diferentes categorias de clientes, que costumam ter fluxos e complexidades distintas, resultando em análises mais precisas.

Onde obter

Este é um atributo fundamental armazenado no nível do case ou do cliente dentro do ACTICO.

Exemplos
Pessoa FísicaPessoa JurídicaPequena Empresa
Obrigatório Recomendado Opcional

Atividades de Onboarding de Clientes KYC

Estes são as etapas e marcos fundamentais do processo para capturar em seu Event Log para uma descoberta e análise precisas do seu Onboarding KYC.
8 Recomendado 6 Opcional
Atividade Descrição
Avaliação de Risco Realizada
Esta atividade representa a execução do motor de decisão do ACTICO para calcular um score de risco para o pedido do cliente. Como uma função central do sistema, é capturada como um evento explícito quando o conjunto de regras de avaliação de risco é executado.
Por que é importante

A avaliação de risco é um ponto de decisão crucial que geralmente dita o caminho seguinte no processo. Analisar esta atividade ajuda a entender como os níveis de risco influenciam as variantes e os prazos.

Onde obter

Este é um evento central do ACTICO e deve estar nos logs de decisão ou execução. Esses logs costumam conter o ID do case, as regras executadas e o score de risco resultante.

Captura

Evento registrado pelo mecanismo de decisão do ACTICO após a conclusão da pontuação de risco.

Tipo de evento explicit
Candidatura enviada
Esta atividade marca o início do processo de onboarding KYC quando um novo pedido é formalmente recebido pelo sistema ACTICO. É capturada como um evento explícito, geralmente registrada com um timestamp preciso na criação de um novo case ou registro de pedido.
Por que é importante

Como principal evento inicial, esta atividade é essencial para calcular o tempo total do ciclo de onboarding e rastrear o volume. Ela serve como a base temporal para todas as medições de desempenho subsequentes.

Onde obter

Geralmente é uma entrada explícita em um log de criação de pedido ou case no ACTICO. Procure por tabelas de eventos de envio ou pelo timestamp de criação do registro principal.

Captura

Evento registrado na criação de uma nova instância de caso de solicitação.

Tipo de evento explicit
Documentos do cliente carregados
Esta atividade ocorre quando o cliente fornece a identificação e documentos obrigatórios através de um portal ou outro canal integrado ao ACTICO. Cada upload de documento costuma ser capturado como um evento explícito e distinto no log do case ou sistema de gestão documental.
Por que é importante

Este marca um marco fundamental que depende do cliente. Rastrear este evento é crucial para medir os tempos de resposta do cliente e analisar a duração da fase seguinte de revisão documental.

Onde obter

Procure logs relacionados ao manuseio de documentos ou anexos do caso. Eles costumam ser registrados em tabelas dedicadas de gerenciamento de documentos ou evidências no banco de dados do ACTICO.

Captura

Evento registrado pelo sistema quando um documento é anexado ao caso.

Tipo de evento explicit
Onboarding de cliente concluído
Esta é a atividade final do processo, indicando que o cliente está totalmente onboarded e o case foi encerrado. É inferida por um status terminal como 'Onboarded' ou 'Fechado - Aprovado'.
Por que é importante

Sendo o principal evento final de sucesso, esta atividade é essencial para calcular o tempo de ciclo de ponta a ponta dos clientes integrados. Ela fornece o carimbo de data/hora final para a análise do fluxo ideal.

Onde obter

Inferido do campo de status final do caso de solicitação. Procure o carimbo de data/hora associado à mudança do caso para um status de sucesso terminal.

Captura

Inferido a partir da atualização final do status do caso para 'Concluído' ou 'Encerrado'.

Tipo de evento inferred
Revisão de conformidade concluída
Marca o fim da revisão manual, com a decisão de aprovar, rejeitar ou pedir mais dados. Esta atividade é inferida pela mudança de status de 'Revisão de Conformidade Pendente' para um estado posterior, como 'Conformidade Aprovada'.
Por que é importante

Este é o evento de encerramento da fase de revisão de conformidade. É essencial para calcular a duração total da revisão e analisar a produtividade da equipe.

Onde obter

Inferido do log de histórico de status da solicitação. Procure o carimbo de data/hora quando o caso sai do estado 'Em Revisão de Conformidade', indicando que uma decisão foi tomada.

Captura

Inferido a partir da mudança do status do caso de 'Conformidade Pendente' para 'Conformidade Aprovada' ou similar.

Tipo de evento inferred
Revisão de conformidade iniciada
Marca o início da fase de revisão manual pela equipe de conformidade, geralmente para casos de alto risco. Costuma ser inferido pela mudança de status para 'Revisão de Conformidade Pendente' ou atribuição do caso a um revisor.
Por que é importante

Esta atividade é o ponto de partida para medir o gargalo de conformidade. O tempo decorrido até 'Revisão de Conformidade Concluída' é um KPI crítico para identificar atrasos nesta fase crucial.

Onde obter

Inferido do histórico de status ou trilha de auditoria. Procure o registro de data/hora associado à mudança para 'Em Revisão de Conformidade' ou atribuição a um grupo de usuários de conformidade.

Captura

Inferido a partir da mudança do status do caso para 'Conformidade Pendente' ou atribuição à equipe de conformidade.

Tipo de evento inferred
Solicitação aprovada
Esta atividade representa a decisão final de negócio para aprovar o pedido de onboarding do cliente. É um marco fundamental, capturado como uma mudança de status final e distinta no ciclo de vida do pedido.
Por que é importante

Este marco precede a criação da conta e indica um desfecho positivo. Analisar o tempo para atingir este ponto é crucial para entender a duração do "caminho feliz".

Onde obter

Inferido do campo de status final na tabela principal. Procure por status como 'Aprovado', 'Aprovação Concluída' ou estado terminal positivo similar.

Captura

O status final do case é atualizado para 'Aprovado' nos dados mestres do case.

Tipo de evento inferred
Solicitação rejeitada
Representa a decisão final de rejeitar o pedido do cliente, encerrando o processo de onboarding. Este é um estado final crítico, capturado através da mudança de status final no registro do pedido.
Por que é importante

Este é o principal evento de falha final. Analisar cases que terminam com esta atividade é crucial para entender as taxas de rejeição, motivos de falha e melhorar o rendimento geral do processo.

Onde obter

Inferido do campo de status final na tabela principal. Procure por status terminais como 'Rejeitado', 'Recusado' ou 'Encerrado - Rejeitado'.

Captura

O status final do case é atualizado para 'Rejeitado' nos dados mestres do case.

Tipo de evento inferred
Conta criada
Após a aprovação, esta atividade marca a criação técnica da conta do cliente no core banking. Geralmente é um evento explícito registrado pelo ACTICO após receber a confirmação de sucesso do sistema de destino.
Por que é importante

Esta atividade confirma que o processo resultou em um desfecho de negócio tangível. O tempo entre 'Pedido Aprovado' e 'Conta Criada' pode revelar atrasos de integração ou ineficiências nas etapas finais de provisionamento.

Onde obter

Essa informação provavelmente estaria em logs de integração ou de interface no ACTICO, que registram o resultado de chamadas para sistemas externos para provisionamento de conta.

Captura

Evento registrado ao receber uma resposta de API bem-sucedida do sistema de contas principal.

Tipo de evento explicit
Informações Adicionais Solicitadas
Representa um evento onde um revisor, geralmente de compliance ou análise de risco, solicita mais informações ou documentos ao cliente. Esta ação costuma ser capturada explicitamente, pois envolve o envio de uma notificação ao cliente e a pausa no case.
Por que é importante

Esta atividade é um dos principais geradores de retrabalho e aumento nos tempos de ciclo. Acompanhar sua frequência e impacto é essencial para identificar onde a coleta inicial de dados pode ser melhorada.

Onde obter

Provavelmente é um evento explícito no histórico do case ou log de comunicação. Procure por eventos como 'RFI Sent' ou mudança de status para 'Pendente de Informações do Cliente'.

Captura

Um evento explícito acionado pelo usuário, como 'Enviar RFI', é registrado na trilha de auditoria do caso.

Tipo de evento explicit
Revisão de documentos concluída
Esta atividade significa que um atendente terminou de revisar os documentos enviados pelo cliente. Geralmente é inferida a partir de uma mudança de status no documento ou no case, como 'Documentos Verificados' ou 'Revisão Concluída'.
Por que é importante

Este é um marco importante para medir a eficiência do manuseio de documentos. O tempo entre 'Documentos do Cliente Enviados' e esta atividade é um KPI crítico para identificar atrasos no processamento manual.

Onde obter

Inferido pelos logs de histórico de status do caso ou de documentos individuais. Uma mudança de 'Revisão Pendente' para 'Aprovado' ou 'Revisado' indica esta atividade.

Captura

Inferido a partir da mudança do status do documento para 'Verificado' ou 'Revisado'.

Tipo de evento inferred
Revisão inicial da solicitação
Representa a primeira revisão do pedido enviado, seja por uma regra automatizada ou por um atendente humano, para verificar se está completo e possui elegibilidade básica. Esta atividade costuma ser inferida por uma mudança de status, por exemplo, de "Enviado" para "Em Revisão".
Por que é importante

Analisar o tempo desta primeira revisão ajuda a identificar atrasos iniciais e mostra quantas solicitações passam por este primeiro filtro sem problemas.

Onde obter

Inferido das tabelas de histórico ou logs de auditoria do caso. Compare o carimbo de data/hora de quando o status muda de 'novo' ou 'enviado' para o estado de 'revisão'.

Captura

Detectar mudança de status de 'Enviado' para 'Em Revisão' no log de histórico do caso.

Tipo de evento inferred
Verificação de identidade realizada
Representa uma verificação automatizada ou manual para validar a identidade do cliente em relação a fontes de dados externas ou internas. Isso geralmente é registrado como um evento explícito quando uma chamada de API para um serviço de verificação de terceiros é feita e uma resposta é recebida.
Por que é importante

Esta atividade é uma etapa crítica de conformidade. Analisar sua duração e resultados ajuda a identificar dependências de serviços externos e possíveis gargalos no processo de verificação.

Onde obter

Essa informação costuma estar em logs de integração ou tabelas de eventos específicas que registram os resultados de verificações automáticas e chamadas de serviços externos vinculados ao case.

Captura

Evento registrado a partir de uma chamada de integração para um serviço de verificação de identidade de terceiros.

Tipo de evento explicit
Verificações de antecedentes iniciadas
Representa o ponto de início das verificações automáticas ou manuais, como AML ou histórico de crédito. Costuma ser registrado como evento explícito quando o sistema dispara essas verificações, que podem envolver provedores externos.
Por que é importante

Iniciar a verificação de antecedentes é um marco importante na due diligence. Rastrear isso ajuda a entender dependências e prazos de fornecedores externos.

Onde obter

Procure registros nos logs do sistema ou trilha de auditoria que indiquem o disparo dos procedimentos de triagem de antecedentes. Geralmente estão vinculados ao ID do caso principal.

Captura

Evento registrado quando o mecanismo de workflow inicia chamadas para serviços de verificação de antecedentes.

Tipo de evento explicit
Recomendado Opcional

Guias de Extração

Como obter seus dados do ACTICO