Voltar ao blog
Customer context

Como usar números de referência de casos no chat de apoio ao cliente sem gerar mais esforço para o cliente

Uma política prática para usar referências de encomendas, entregas, reclamações e contactos anteriores para encontrar registos sem confundir pesquisa, autenticação de identidade e autorização.

Operador de apoio a usar uma política clara de referências de caso numa caixa de entrada partilhada de conversas com clientes

Porque é que os pedidos de números de referência geram esforço evitável

Um número de referência pode acelerar uma conversa de apoio, mas apenas quando é a via fiável mais curta para chegar ao registo. Gera esforço quando um operador o pede antes de verificar a conversa atual, os registos disponíveis através dos sistemas aprovados pela organização ou os dados que o cliente já forneceu na mesma jornada.

A falha habitual é tratar todos os pedidos como «Indique o seu número de referência, por favor». Os clientes podem não saber qual é o número pretendido, não o conseguir encontrar ou já o terem fornecido. Um pedido vago também aumenta a probabilidade de enviarem informações pessoais não relacionadas ou excessivas.

Defina claramente o objetivo da política: usar uma referência como auxílio de contexto e pesquisa, não como uma barreira que os clientes têm de ultrapassar antes de receberem ajuda razoável.

  • Pesquise primeiro a conversa atual e os registos relevantes disponíveis através dos sistemas aprovados, quando tal for operacionalmente adequado.
  • Peça apenas o identificador necessário para o pedido atual.
  • Ofereça de imediato uma via alternativa quando o cliente não tiver o número.
  • Não exija a reintrodução de informações já fornecidas no mesmo processo digital, salvo quando tal for essencial ou necessário para segurança.
Porque é que os pedidos de números de referência geram esforço evitável

Mantenha separados pesquisa, autenticação e autorização

Um procedimento operacional sólido separa três decisões. Encontrar um caso responde a «De que registo estamos a falar?». A autenticação responde a «Esta pessoa comprovou controlo sobre o autenticador necessário?». A autorização responde a «Esta pessoa autenticada pode realizar esta ação?».

Uma referência de caso, encomenda ou reclamação pode ajudar a localizar um registo. Não prova quem está a participar no chat, nem concede permissão para divulgar dados protegidos, alterar uma morada, cancelar uma encomenda, modificar definições de conta ou realizar outra ação sensível.

Defina procedimentos de verificação e aprovação específicos para cada ação fora do fluxo de trabalho dos números de referência. Os operadores não devem improvisar, pedindo mais identificadores até se sentirem confiantes.

  • Pesquisa: use a referência mínima necessária para localizar um registo relevante.
  • Autenticação: use o método aprovado pela organização quando for necessário confirmar a identidade.
  • Autorização: confirme se a pessoa autenticada pode pedir a ação específica.
  • Nunca peça aos clientes que divulguem palavras-passe, palavras-passe de utilização única ou outros fatores de autenticação num chat comum.
Mantenha separados pesquisa, autenticação e autorização

Crie um mapa de identificadores por tipo de pedido

Substitua a expressão genérica «número de referência» por um mapa de identificadores controlado. Cada tipo de pedido deve indicar o identificador preferencial, uma alternativa aceitável, a finalidade da recolha e as ações que continuam a exigir verificação separada.

Isto melhora a compreensão do cliente e torna o tratamento interno mais consistente. Também evita que uma referência de entrega seja tratada como equivalente a um registo de reclamação ou identificador de conta.

  • Consulta sobre encomenda: peça a referência da encomenda; use a mensagem de confirmação da encomenda como indicação de onde a encontrar.
  • Problema de entrega: peça a referência de entrega ou de rastreio quando o problema disser respeito a uma remessa.
  • Acompanhamento de reclamação: peça a referência da reclamação ou a referência de um caso de apoio anterior.
  • Pedido sobre conta: use a via aprovada de pesquisa de conta; não dê a entender que uma referência de encomenda confirma a titularidade da conta.
  • Conversa anterior: use a referência de apoio anterior apenas para localizar a interação anterior, não para autorizar uma nova ação.

Decida quando um operador deve pedir uma referência

Crie uma sequência de decisão curta que os operadores possam seguir de forma consistente. Primeiro, identifique o objetivo do cliente. Depois, reveja a conversa ativa e os registos relevantes disponíveis através dos sistemas aprovados pela organização para encontrar um identificador utilizável. Peça uma referência apenas se for necessária para localizar ou distinguir o registo relevante e não puder ser razoavelmente encontrada a partir das informações disponíveis.

Evite recolher uma referência apenas porque poderá ser útil mais tarde. Se o pedido puder ser respondido sem abrir um registo específico do cliente, não peça uma. Se for solicitada uma ação sensível, avance para o processo aprovado de autenticação e autorização, em vez de depender da referência.

Em operações partilhadas de WebChat e WhatsApp, disponibilize a mesma sequência de decisão a todos os departamentos para que as transferências não reiniciem o processo de recolha de informações.

  • Peça quando vários registos possam corresponder de forma plausível e a referência for o meio de distinção menos oneroso.
  • Não peça quando a referência já estiver visível na conversa atual ou disponível através de sistemas aprovados.
  • Não peça quando ajuda genérica resolver o problema.
  • Encaminhe em vez de adivinhar quando os registos entrarem em conflito, uma correspondência for ambígua ou a ação solicitada for sensível.

Use uma mensagem clara e acessível para o cliente

Uma boa mensagem indica o que é necessário, porque é necessário, onde o encontrar e o que acontece se o cliente não o conseguir localizar. Identifique o identificador com precisão. Se for útil indicar um formato esperado, forneça um exemplo curto sem sugerir que o formato comprova o direito ao registo.

Evite abreviaturas sem explicação, listas longas de números possíveis e mensagens que façam o cliente procurar em todos os emails. Rótulos e instruções claros reduzem erros de introdução; mensagens de erro úteis devem identificar o problema em texto, em vez de apenas dizer que a pesquisa falhou.

  • Mensagem preferencial: «Para encontrar a entrega, envie a referência de entrega presente no seu email de expedição. Normalmente surge junto de “Referência de entrega”. Se não a encontrar, diga-me e ajudarei através de outra via.»
  • Mensagem de formato: «A referência da encomenda começa normalmente por ORD-, seguido de algarismos, por exemplo, ORD-12345. Envie apenas a referência da encomenda.»
  • Mensagem de formato inválido: «Isto não parece ser uma referência de encomenda. Consulte o email de confirmação para encontrar um número que comece por ORD-. Se não estiver disponível, responda “Não consigo encontrar” e encaminharei o pedido para obter ajuda.»
  • Mensagem de pesquisa falhada: «Não encontrei um registo correspondente a essa referência de entrega. Confirme os carateres e envie-a novamente ou diga-me se precisa que uma pessoa a reveja.»

Minimize os dados no chat de texto livre

O chat de texto livre incentiva os clientes a enviarem mais do que é necessário. A política deve dizer-lhes exatamente que identificador fornecer e desencorajar explicitamente dados não relacionados. Os operadores não devem pedir um conjunto de dados pessoais «por precaução».

Use a recolha de respostas validadas quando um formato previsível for realmente útil, mas mantenha-a proporcional. A validação de formato pode melhorar a qualidade dos dados; não pode estabelecer identidade, comprovar titularidade nem determinar se um cliente pode realizar uma ação.

Reveja periodicamente os dados armazenados relacionados com identificadores e remova informações que já não sejam relevantes para a finalidade de apoio definida.

  • Peça um identificador de cada vez sempre que possível.
  • Não peça aos clientes que colem segredos de autenticação no chat.
  • Não peça várias referências como substituto de um processo de verificação aprovado.
  • Use uma via de exceção com revisão humana quando uma validação rígida excluiria um cliente legítimo.
  • Limite os registos internos ao identificador, ao seu tipo, ao resultado da pesquisa e à ação seguinte, em conformidade com a política de privacidade e segurança da organização.

Registe identificadores de forma consistente na caixa de entrada partilhada

Uma caixa de entrada partilhada precisa de uma convenção de registo para que o operador seguinte compreenda o que foi fornecido sem voltar a perguntar. No webchat.vip, as equipas podem usar uma caixa de entrada partilhada com operadores, departamentos, encaminhamento, modelos e etiquetas. Configure o fluxo de trabalho em torno de um conjunto pequeno e documentado de etiquetas e modelos aprovados, em vez de inserir identificadores não estruturados nas mensagens da conversa.

Mantenha o registo operacional factual. Anote o tipo de referência, o resultado da pesquisa, se continua a ser necessária verificação e o próximo responsável no sistema de registos permitido pela organização. Não registe conclusões de que a própria referência autenticou o cliente.

Qualquer registo de identificadores, controlos de acesso e períodos de retenção deve cumprir a política de privacidade e segurança da organização. Evite copiar um identificador para notas quando já existe num registo estruturado permitido. Quando a organização usar notas internas de transferência num sistema permitido, utilize-as para preservar o contexto essencial entre departamentos e use etiquetas apenas para estados operacionais definidos.

  • Etiquetas recomendadas: referencia-solicitada, referencia-recebida, pesquisa-correspondente, pesquisa-sem-resultado, verificacao-necessaria, revisao-humana-necessaria.
  • Exemplo de registo de transferência, quando permitido: «Referência de entrega recebida; pesquisa correspondeu a um registo; nenhuma verificação de identidade concluída; cliente pede alteração de morada; encaminhar para processo de verificação aprovado.»
  • Evite registos vagos como «cliente verificado» quando foi fornecida apenas uma referência.
  • Disponibilize aos operadores modelos aprovados para pedidos, falhas e transferências.

Conceba alternativas seguras e uma via de escalonamento humano

Uma referência em falta ou sem correspondência não deve tornar-se um beco sem saída. Os clientes podem ter eliminado uma mensagem, recebido um número incorreto, não ter acesso a um dispositivo ou conta de email, ou necessitar de apoio de acessibilidade. Dê aos operadores uma via alternativa documentada, adequada ao pedido e que não incentive a recolha desnecessária de dados.

A automação pode recolher uma referência, verificar um formato definido, criar ramificações conforme o resultado e transferir a conversa. No webchat.vip, os fluxos automatizados podem recolher respostas validadas, enviar mensagens ou ficheiros, criar ramificações e transferir conversas para pessoas. Use estas capacidades para reduzir fricção rotineira, não para tomar uma decisão não revista sobre identidade ou legitimidade.

Defina acionadores explícitos para intervenção humana. A transferência deve informar o cliente sobre o que acontecerá a seguir, e o operador que recebe a conversa deve usar a conversa atual e os registos permitidos para evitar pedidos repetidos desnecessários.

  • Encaminhe para uma pessoa quando o cliente não conseguir encontrar o identificador após orientações claras.
  • Encaminhe quando uma referência falhar na pesquisa após uma verificação cuidadosa, ou quando vários registos parecerem possíveis.
  • Encaminhe imediatamente em caso de limitações de acessibilidade ou tecnologia, suspeita de comprometimento da conta, preocupações de privacidade, litígios, preocupações de salvaguarda ou ações sensíveis que exijam verificação aprovada.
  • Diga ao cliente: «Vou transferir isto para um especialista de apoio que pode analisar as alternativas. Garantirei que ele vê as informações que já partilhou, quando o nosso processo o permitir.»
  • Forneça ao operador que recebe a conversa o tipo de pedido, o resultado da pesquisa, as informações relevantes da conversa e o motivo do escalonamento através do processo permitido pela organização.

Perguntas frequentes

Um número de referência de caso de apoio ao cliente é prova de identidade?

Não. Uma referência de caso ajuda a encontrar um registo. A autenticação da identidade e a permissão para realizar uma ação exigem processos separados e aprovados.

O que deve um operador fazer se o cliente não tiver o número de referência?

Explique onde pode encontrá-lo e, em seguida, ofereça a via alternativa documentada. Se o problema não puder ser resolvido em segurança, transfira a conversa para uma pessoa ou equipa de tratamento de exceções, em vez de terminar o chat.

Um chatbot deve rejeitar todas as referências que não correspondam a um formato?

Não. As verificações de formato podem identificar erros de introdução prováveis, mas os clientes podem ter um identificador válido noutra forma. Explique o erro, ofereça uma sugestão de correção quando for seguro e disponibilize uma via humana.

O que deve ser registado após uma pesquisa de referência?

Registe o tipo de referência, o resultado da pesquisa, a ação seguinte e se continua a ser necessária verificação separada, em conformidade com a política de privacidade, segurança e retenção da organização. Use etiquetas definidas e registos operacionais permitidos para que os clientes não tenham de repetir informações desnecessariamente.

Como podem as equipas melhorar uma política de referências de casos ao longo do tempo?

Reveja os registos de conversas, as análises operacionais e os relatórios exportáveis, e obtenha ou monitorize localmente medidas registadas, como pesquisas falhadas, pedidos repetidos e padrões de transferência, quando a organização os registar. Atualize mensagens, mapas de identificadores, modelos e regras de escalonamento quando os padrões revelarem esforço evitável.

Fontes e leituras adicionais

Referências primárias e autorizadas usadas para verificar a base factual deste guia.

  1. NIST SP 800-63-4 — Digital Identity Guidelines — National Institute of Standards and Technology
  2. NIST SP 800-63A-4 — Identity Proofing and Enrollment — National Institute of Standards and Technology
  3. NIST SP 800-63B-4 — Authentication Assurance Levels — National Institute of Standards and Technology
  4. WCAG 2.2 — World Wide Web Consortium
  5. Understanding Success Criterion 3.3.2: Labels or Instructions — W3C Web Accessibility Initiative
  6. Understanding Success Criterion 3.3.1: Error Identification — W3C Web Accessibility Initiative
  7. Data minimisation guidance — Information Commissioner's Office