Para reduzir o abandono na verificação de identidade, descubra primeiro em qual etapa a pessoa sai e o que a impede de continuar. Trocar o fornecedor ou retirar uma tela sem esse diagnóstico pode apenas deslocar o problema. O fluxo precisa explicar a tarefa, funcionar nas condições reais de uso e permitir uma recuperação compreensível.
A pergunta de produto não é somente quantas pessoas começam a verificação. É quantas conseguem concluir a ação pretendida, quais ficam esperando e quais desistem por um motivo que a equipe poderia corrigir. Uma recusa por risco e uma câmera que não abre não devem entrar na mesma categoria de análise.
Este texto integra uma campanha editorial encomendada para a Didit. As propostas de diagnóstico são análise de produto; não apresentamos uma experiência de implantação nem uma promessa de aumento de conversão.
Desenhe o percurso antes de medir
Registre o caminho desde o convite para verificar até o retorno ao produto. Inclua o momento em que a pessoa entende o motivo, prepara o documento, autoriza a câmera, envia a captura e recebe uma orientação sobre o resultado.
Em cada passagem, descreva o que a pessoa precisa saber e o que o sistema precisa confirmar. Pode existir uma espera entre terminar a captura e receber a decisão. Se o produto não representa essa espera, o usuário pode acreditar que perdeu tudo e começar novamente.
Essa abordagem segue a ideia de planejar um sistema web pelas tarefas e decisões. O diagrama interno deve servir para localizar dúvidas, não para decorar uma apresentação. Quando uma etapa não tem um responsável ou uma saída definida, o abandono pode ser consequência desse vazio.
Separe abandono, recusa e falha técnica
Abandono significa que o percurso ficou incompleto, mas não explica por quê. Uma pessoa pode ter decidido não fornecer os dados, não ter o documento em mãos ou simplesmente ter sido interrompida. A interface não deve transformar todas essas situações em um erro pessoal.
Uma recusa é outro evento: houve uma avaliação com um resultado que impede continuar naquele fluxo. Já uma falha técnica pode ocorrer antes de qualquer avaliação útil. Separar esses casos permite escolher uma intervenção adequada em vez de enviar a mesma mensagem para todos.
Crie uma taxonomia pequena e estável. Ela pode distinguir convite não aberto, captura não iniciada, captura interrompida, resultado pendente e resultado concluído. Esses nomes são uma proposta de medição do produto, não uma lista de estados prometidos por um fornecedor.
Explique a necessidade antes de pedir o documento
A tela anterior à verificação precisa responder por que a checagem aparece naquele momento. Se a pessoa só descobre a exigência depois de preencher um formulário longo, pode interpretar a mudança como uma surpresa ou uma tentativa de obter mais dados.
Diga qual ação depende da verificação e quais informações serão solicitadas. Informe como pedir ajuda e onde encontrar a explicação sobre tratamento de dados. Evite frases vagas como “para sua segurança” quando é possível explicar a finalidade concreta.
Também deixe claro quem solicita a verificação. A presença de um fornecedor externo pode ser legítima, mas uma mudança de domínio sem contexto pode gerar desconfiança. A transição deve preservar a continuidade da tarefa e permitir que a pessoa reconheça a empresa responsável.
Observe câmera, documento e ambiente
A captura pode falhar por motivos que o texto da interface consegue ajudar a resolver. Iluminação inadequada, reflexos e enquadramento ruim são problemas diferentes de documento não aceito. A orientação deve corresponder ao que realmente aconteceu.
Teste o percurso em condições plausíveis para seu público. Um computador de escritório, um celular mais antigo e uma conexão instável podem produzir experiências diferentes. Não use um único aparelho recente como representação de todos os usuários.
Quando existir uma mudança de dispositivo, preserve o contexto de forma segura. A pessoa precisa entender como continuar, e o sistema precisa manter a relação com a conta correta. Uma instrução clara vale mais do que uma sequência de tentativas sem explicação.
Construa caminhos de recuperação
Uma pessoa interrompida deve saber se pode retomar, se precisa iniciar uma nova sessão ou se deve procurar suporte. Não prometa retomada automática sem confirmar que a implementação realmente a oferece.
O guia de fluxos da Didit pode ajudar a estudar a configuração do fornecedor. A experiência de recuperação, porém, precisa ser examinada junto com as telas e regras do seu próprio produto. O problema pode estar na volta ao sistema, e não na captura.
Para casos pendentes, mostre uma mensagem fiel ao estado conhecido. Evite um prazo inventado ou uma aprovação implícita. Se a equipe ainda precisa revisar algo, explique o próximo passo possível e mantenha um identificador que o suporte consiga localizar.
Meça o resultado sem coletar documentos no analytics
O diagnóstico precisa de eventos, tempos e categorias de erro; não precisa necessariamente de imagens de documentos ou dados biométricos dentro da ferramenta de analytics. Defina um conjunto mínimo de informações para entender o funil.
A documentação de analytics da Didit é uma referência para investigar os indicadores disponíveis no fornecedor. Compare esses indicadores com os do produto e descubra onde os dois sistemas começam e terminam suas contagens.
| Observação | Pergunta de diagnóstico |
|---|---|
| Muitos convites sem início | A exigência foi explicada no momento certo? |
| Saída após abrir a câmera | Há dificuldade de permissão ou captura? |
| Conclusão no fornecedor sem avanço | O retorno e a atualização da conta funcionam? |
| Muitos contatos de suporte | A mensagem orienta uma ação possível? |
A tabela apresenta hipóteses. Cada uma precisa ser confirmada antes de alterar o fluxo. Uma correlação entre dispositivo e abandono, por exemplo, não identifica sozinha a causa.
Faça uma mudança de cada vez
Escolha um ponto de fricção documentado e uma alteração pequena. Pode ser antecipar a lista de documentos, melhorar uma mensagem ou corrigir a tela de retorno. Defina o resultado esperado antes de avaliar a mudança.
Observe também efeitos indesejados. Uma taxa maior de conclusão não basta se a alteração removeu uma checagem necessária ou deixou a equipe sem evidência para resolver exceções. O objetivo é facilitar a tarefa legítima preservando o requisito que motivou a verificação.
Registre a versão do fluxo e o período observado. Sem isso, uma mudança no público, na campanha de aquisição ou no fornecedor pode ser confundida com efeito da nova interface. Apresente os limites da análise junto com o resultado.
Trate a assistência como parte do percurso
Uma mensagem de ajuda precisa levar a uma ação que realmente existe. Se o botão abre um canal sem equipe responsável, o produto apenas transfere a frustração para outro lugar. Defina quem recebe a solicitação e quais informações mínimas permitem localizar o caso.
Prepare orientações diferentes para problemas diferentes. A pessoa que não consegue permitir o uso da câmera precisa de instruções distintas daquela que aguarda revisão. Evite pedir repetidamente o mesmo documento quando a equipe ainda não entendeu por que a primeira tentativa ficou parada.
Considere também quem usa recursos de acessibilidade ou não consegue seguir o percurso padrão. O objetivo do atendimento é explicar uma alternativa autorizada, quando houver, e registrar limitações reais. Não invente uma solução automática que a integração não oferece.
Depois de resolver um caso, registre a causa de forma útil para o produto. Um conjunto de reclamações bem classificado pode revelar que a mesma instrução é mal interpretada ou que a volta para a aplicação falha em uma condição específica. Assim, o suporte deixa de ser apenas uma saída de emergência e passa a fornecer evidência para melhorar o fluxo.
Transforme o diagnóstico em responsabilidade
Ao final, cada problema identificado deve ter um responsável: produto para clareza do percurso, engenharia para integração, operação para revisão e suporte para orientação. O fornecedor participa onde a evidência aponta uma questão no serviço contratado.
Use um registro curto com etapa, problema observado, hipótese, alteração e resultado. Esse documento permite continuar aprendendo sem recomeçar a investigação a cada reclamação.
A área de integrações da Lisko ajuda a situar esses contratos entre sistemas. Reduzir abandono não significa pressionar todas as pessoas a entregar mais dados. Significa tornar uma tarefa justificada compreensível, acessível e recuperável, com decisões que a equipe consegue explicar.