Verificação de identidade no chat de suporte: guia de design baseado em risco

Por que a verificação de identidade em mensagens precisa de uma abordagem baseada em risco

A verificação de identidade no suporte ao cliente não é uma pergunta universal com uma resposta universal. Um cliente que pergunta sobre horários de funcionamento cria um risco muito diferente de alguém que solicita uma alteração de endereço, a divulgação do histórico da conta ou uma ação relevante na conta.

Um canal de chat pode facilitar fazer perguntas e coletar respostas. Essa conveniência não é evidência de que quem está na conversa deva receber informações protegidas ou fazer uma alteração sensível. Defina a garantia necessária pelo dano potencial caso a decisão esteja errada: exposição de privacidade, modificação não autorizada, perda financeira, perda de serviço ou dano a um cliente.

Use o caminho menos intrusivo que dê suporte seguro à ação. Solicitações de baixo risco devem permanecer simples. Solicitações de maior risco devem seguir para um caminho autenticado mais forte ou para um processo documentado de recuperação conduzido por pessoas. Não compense um modelo de risco pouco claro coletando rotineiramente mais dados pessoais no chat.

• Comece pelo resultado solicitado, não por uma lista padrão de perguntas de identidade.
• Aumente a garantia à medida que aumenta o possível impacto de uma decisão incorreta.
• Separe o tratamento normal de suporte do tratamento de recuperação de conta e de suspeita de personificação.
• Trate a minimização de dados, a acessibilidade e o escalonamento como requisitos do fluxo de trabalho, não como aprimoramentos opcionais.

Separe três decisões que as equipes frequentemente chamam de “verificação”

A palavra “verificação” frequentemente esconde três decisões distintas. Combiná-las leva à coleta desnecessária de dados em uma ponta e a uma perigosa confiança excessiva na outra.

A comprovação de identidade pergunta: “Quem é esta pessoa?”. Ela envolve coletar, validar e verificar informações para estabelecer garantia sobre uma identidade declarada. Isso não é necessário em toda conversa de suporte.

A autenticação pergunta: “Esta pessoa consegue demonstrar controle sobre um autenticador vinculado à conta?”. Ela pode estabelecer acesso a uma conta, mas não comprova todo atributo do mundo real, relacionamento ou permissão que a pessoa alega ter.

A autorização pergunta: “Esta pessoa autenticada pode realizar esta ação específica?”. Uma pessoa titular de conta autenticada ainda pode não ter permissão para aprovar um reembolso, alterar os dados de outro usuário, agir em nome de uma organização ou realizar uma ação de alto impacto. A autorização deve ser verificada para cada solicitação protegida, com uma mentalidade de negar por padrão.

• Comprovação de identidade: estabelecer garantia sobre uma identidade declarada quando o caso de uso exigir isso.
• Autenticação: estabelecer controle sobre um autenticador vinculado à conta.
• Autorização: confirmar a permissão para a ação, conta, objeto e contexto solicitados.
• Tratamento do caso: coletar somente as informações necessárias para entender e resolver o problema; isso não é automaticamente evidência de identidade.

Classifique as solicitações pelo dano potencial antes de criar os prompts

Uma classificação simples de solicitações oferece a agentes e automação uma base consistente para o encaminhamento. Ela também evita que um cliente de baixo risco seja submetido a um desafio de alto atrito que acrescenta pouca proteção.

Defina categorias em torno dos resultados que sua equipe pode divulgar ou executar e, em seguida, documente exemplos e exceções. As categorias abaixo são um modelo inicial; os limites adequados dependem do seu serviço, da população de clientes e das obrigações aplicáveis.

• Informações gerais: políticas públicas, orientações sobre produtos, horários de atendimento e solução de problemas não específica de conta. Não deve ser exigida verificação da conta apenas para responder a essas perguntas.
• Informações específicas da conta: saldos, detalhes de pedidos, mensagens privadas, histórico da conta, dados de contato ou status do serviço. Use um caminho de conta autenticada antes da divulgação.
• Alterações na conta: alterações de dados de contato, preferências, configurações de acesso, detalhes de entrega ou usuários vinculados. Exija um caminho mais forte e verifique se a parte autenticada está autorizada para essa alteração específica.
• Ações de alto impacto: recuperação de conta, alterações nas configurações de segurança, ações relacionadas a pagamentos, encerramento, grandes alterações de serviço ou ações com consequências sérias para o cliente. Use um processo de alta garantia deliberadamente projetado e revisão humana treinada onde a ambiguidade persistir.

Aplique a minimização de dados em cada etapa do chat

Antes de escrever um prompt, declare seu propósito preciso: que decisão esta resposta permitirá tomar e qual é a quantidade mínima de informação necessária para tomar essa decisão? A minimização de dados exige que as informações sejam adequadas e relevantes para a finalidade declarada, mas limitadas ao necessário.

Não peça a um cliente que comprove mais do que a ação solicitada exige. Por exemplo, um agente pode precisar de detalhes não sensíveis para localizar um caso, enquanto o sistema deve exigir um caminho de conta autenticada antes de revelar informações específicas da conta. Um pedido para enviar um documento, a data de nascimento completa ou outros dados sensíveis nunca deve ser um substituto padrão para um caminho de verificação projetado.

Torne as entradas proibidas visíveis na jornada. Os clientes devem ser informados de que não devem enviar senhas, códigos de recuperação de conta ou outros segredos reutilizáveis em uma conversa de suporte. Se eles enviarem informações sensíveis mesmo assim, siga um procedimento de contenção documentado, em vez de repeti-las ou copiá-las para registros adicionais.

• Para cada campo, registre sua finalidade, se é essencial, quem pode visualizá-lo e por quanto tempo é retido.
• Use respostas validadas apenas para informações que sejam realmente necessárias para encaminhar ou tratar o caso.
• Evite coletar credenciais, códigos de recuperação e outros segredos reutilizáveis no chat.
• Não trate uma resposta conversacional a perguntas pessoais como uma verificação universal de identidade.
• Revise modelos e macros de agentes em busca de pedidos que coletam informações “por precaução”.

Escolha um método de verificação adequado à ação

Para informações e alterações protegidas da conta, o padrão mais seguro é direcionar o cliente a um processo estabelecido de conta autenticada, em vez de pedir que estabeleça sua identidade por mensagens de chat. O chat pode explicar por que a etapa é necessária e permanecer disponível para ajudar com a solução de problemas não sensíveis.

Para perda de acesso, use um caminho de recuperação documentado e baseado em análise de risco. A recuperação pode envolver um processo aprovado de recuperação de conta, nova comprovação de identidade, um contato de recuperação ou uma interação com agente específica da aplicação. A regra operacional essencial é não reduzir o limite normal apenas porque o cliente não consegue atendê-lo no chat.

Quando a recuperação for bem-sucedida, notifique o assinante ou a pessoa indicada apropriada após o evento de recuperação para que uma recuperação potencialmente fraudulenta possa ser detectada. Incentive os clientes, quando o design da sua conta permitir, a manter mais de uma forma independente de autenticação para reduzir a dependência de jornadas de recuperação excepcionais.

• Use informações públicas no chat para perguntas públicas.
• Use um caminho de conta autenticada para divulgação específica da conta.
• Verifique a função, o relacionamento e a permissão na conta para alterações solicitadas por um usuário autenticado.
• Use um processo separado e documentado de alto impacto ou recuperação para casos excepcionais.
• Não peça uma senha ou código de recuperação como prova em uma mensagem de chat.

Crie um fluxo de mensagens seguro e compreensível

Um fluxo seguro também deve ser compreensível. Explique o que a equipe precisa fazer, por que a etapa é necessária, o que o cliente não deve enviar e o que acontecerá se ele não conseguir concluí-la. Uma explicação clara reduz o compartilhamento excessivo acidental e faz uma recusa parecer um controle de proteção, e não um beco sem saída.

Um padrão prático é: classificar a solicitação, explicar a finalidade, oferecer o caminho apropriado, validar o status resultante, tomar a decisão autorizada e registrar o contexto operacional mínimo. Evite revelar detalhes protegidos enquanto o cliente ainda está tentando concluir a verificação.

Ofereça uma alternativa acessível. A autenticação não deve tornar um teste de função cognitiva o único caminho disponível. As opções de ajuda e recuperação devem estar disponíveis de forma consistente nas jornadas do WebChat para que os clientes possam encontrá-las quando uma tentativa falhar.

• Use linguagem simples: “Para proteger sua conta, precisamos que você use o caminho seguro de login da conta antes de podermos discutir este detalhe.”
• Declare uma proibição clara: “Não envie sua senha nem qualquer código de recuperação de conta aqui.”
• Explique a alternativa: “Se você não conseguir entrar, escolha ajuda para acesso à conta ou peça um especialista de suporte.”
• Mantenha o mesmo local de ajuda e a mesma redação em todos os pontos de entrada, quando possível.
• Confirme somente o que for seguro confirmar; não exponha dados da conta enquanto a decisão permanecer sem resolução.

Trate o contexto de mensagens como contexto, não como prova de autoridade

Uma mensagem recebida de uma conversa ou número de telefone familiar pode ser um contexto útil, mas não é prova suficiente para uma solicitação sensível. Um dispositivo pode ser compartilhado, uma mensagem pode ser encaminhada, um número de telefone pode mudar e o acesso a uma conversa não estabelece automaticamente autoridade sobre uma conta ou uma ação.

Quando um cliente informar um novo número ou perda de acesso, não atualize o registro sensível da conta apenas por causa da solicitação no chat. Encaminhe o caso pelo procedimento relevante de alteração autenticada ou recuperação. Da mesma forma, não divulgue detalhes da conta a alguém que consegue citar informações de uma mensagem encaminhada.

Representantes de terceiros exigem duas decisões: estabelecer a identidade relevante da pessoa ou sua relação autenticada e, depois, confirmar as permissões aplicáveis à ação precisa. Uma alegação ampla como “Eu gerencio esta conta” não é uma decisão de autorização.

• Dispositivo compartilhado: não infira controle exclusivo da conta a partir da conversa aberta.
• Mensagem encaminhada: não trate contexto copiado como evidência de permissão.
• Novo número de telefone: use o caminho aprovado de alteração ou recuperação antes de alterar os dados de contato.
• Representante de terceiro: valide o relacionamento relevante e a permissão de menor privilégio para a solicitação específica.
• Relacionamento ou autoridade incertos: negue a ação protegida e escale o caso.

Defina expectativas específicas por canal sem confundir o comportamento do canal com os controles da equipe

WebChat e WhatsApp são pontos de entrada de mensagens, não uma política completa de autorização. Sua organização continua responsável por definir quais solicitações podem ser tratadas em cada canal, quais evidências são aceitas, como casos sensíveis são transferidos e o que a equipe pode divulgar ou alterar.

Nas orientações para WhatsApp, lembre os clientes de não compartilhar credenciais ou informações pessoais sensíveis em resposta a pedidos inesperados. Trata-se de orientação de segurança para clientes, não de uma alegação de que uma conversa de mensagens, por si só, comprova identidade ou autoridade.

No webchat.vip, uma caixa de entrada compartilhada pode ajudar as equipes a organizar conversas de WebChat e WhatsApp entre operadores, departamentos, encaminhamentos, horários, níveis de serviço, modelos e etiquetas. Configure essas ferramentas operacionais de acordo com sua política; não deixe que uma etiqueta de encaminhamento ou um identificador de canal substitua a autenticação ou a autorização.

Cada canal de WebChat pode usar um widget instalável, personalizável e multilíngue. Mantenha o aviso de segurança, o caminho de ajuda acessível e a redação de escalonamento consistentes em todos os idiomas do widget e, então, valide as traduções com o mesmo cuidado aplicado à jornada principal.

• Defina limites adequados a cada canal para divulgações e alterações.
• Mantenha o comportamento do canal controlado pelo provedor separado de seus próprios procedimentos de suporte e controles de conta.
• Use modelos aprovados para avisos de não compartilhamento de segredos e explicações sobre o caminho seguro.
• Garanta que a opção de escalonamento seja fácil de localizar em todos os idiomas compatíveis.
• Treine os agentes para nunca improvisarem um desafio de identidade mais fraco por conveniência.