Como criar uma rota alternativa de WebChat quando o chat não está disponível ou é difícil de usar

Uma rota alternativa faz parte do serviço, não é uma ligação de contacto de último recurso

Uma rota alternativa de WebChat é o caminho prático que um cliente pode seguir quando o chat incorporado não está disponível, não é acessível, não é adequado à tarefa ou simplesmente não é a sua forma preferida de obter ajuda. Deve encaminhar para um serviço que consiga efetivamente fazer avançar a questão do cliente, em vez de uma página genérica que reinicia a sua jornada.

Isto é importante para além da deficiência. As pessoas podem não ter acesso fiável à internet, confiança digital, competências, confiança no canal ou motivação para concluir uma tarefa online. Uma operação de apoio deve planear estas circunstâncias como condições normais de serviço, e não como casos excecionais.

Coloque a alternativa onde surge a necessidade: junto ao iniciador ou ponto de entrada do chat, nos estados de erro do chat, nas etapas de maior fricção e dentro da transação relevante. Utilize a mesma localização relativa e a mesma redação onde quer que o mecanismo de ajuda se repita, para que os clientes o encontrem de forma previsível.

• Trate a rota como um serviço apoiado, com destino, responsável, horários e processo de conclusão.
• Disponibilize-a antes de o cliente concluir um fluxo de chat ou revelar informação desnecessária.
• Indique claramente as alternativas disponíveis, como telefone, formulário web acessível, pedido de chamada de retorno ou uma rota presencial específica do serviço.
• Não faça do chat a única forma de comunicar um problema com o próprio chat.

Mapeie onde o chat pode falhar ou tornar-se difícil de usar

Comece com um mapa de falhas de ponta a ponta. Um widget pode não carregar; pode carregar, mas ser difícil de operar com teclado; um cliente pode ficar bloqueado pela autenticação, pelo envio de ficheiros, pela validação ou por uma resposta automatizada; ou a conversa pode chegar a uma fila sem ninguém adequadamente disponível. Cada ponto precisa de um passo seguinte definido.

Separe as falhas para as quais a sua equipa de website pode criar soluções das condições que não consegue controlar totalmente. A sua equipa controla a visibilidade e a acessibilidade da rota alternativa, a redação, o design do formulário, os dados recolhidos, as regras de encaminhamento e a política de equipa. A compatibilidade do navegador, as condições de rede e a disponibilidade de canais de terceiros podem afetar a experiência, mas não eliminam a necessidade de uma alternativa utilizável.

Inclua a escolha do cliente no mapa. Uma pessoa que diz preferir telefonar, precisar de intérprete ou não conseguir continuar em segurança no chat não é uma conversão falhada. Está a pedir uma rota de serviço adequada.

• O widget não aparece porque os scripts estão bloqueados, a ligação é lenta ou o navegador não é suportado.
• O iniciador, os controlos, o movimento do foco ou a introdução de mensagens não podem ser usados eficazmente com teclado ou tecnologia de apoio.
• O início de sessão, as verificações de identidade ou os processos de código de utilização única impedem o progresso.
• O envio de ficheiros, a validação de dados ou o feedback de submissão não são claros ou falham repetidamente.
• A automação não compreende o pedido, não consegue validar uma resposta ou chega a um caso fora do âmbito.
• Não há nenhum humano com formação disponível no período de tempo necessário ao cliente.
• A questão exige um canal com capacidades que o chat não consegue disponibilizar em segurança, como uma marcação específica do serviço ou assistência presencial.

Defina um padrão mínimo para cada rota alternativa

Utilize quatro testes: visível, compreensível, operável e disponível. Um cliente deve conseguir ver a rota sem concluir o chat, compreender o que acontecerá a seguir, utilizá-la sem um apontador ou barreiras desnecessárias e chegar a um serviço que tenha efetivamente equipa ou que forneça um resultado claro fora do horário de atendimento.

Para um formulário alternativo acessível, peça apenas o necessário para tratar a interação de apoio. Dê a cada controlo uma etiqueta visível associada, forneça instruções quando necessário e não dependa do texto de exemplo para comunicar informação obrigatória. Se ocorrer um erro, identifique o campo afetado, explique o problema e a correção e, quando apropriado, inclua uma ligação para o campo.

Teste os formulários no servidor, bem como no navegador. As verificações no lado do cliente podem ser contornadas e a compatibilidade dos navegadores varia. Após a submissão, forneça uma confirmação inequívoca de que o pedido foi recebido ou um resultado de erro claro e uma forma de continuar caso a submissão não possa ser concluída.

• Teclado: todos os controlos da rota, campos e ações de submissão funcionam sem rato, e o foco visível mantém-se aparente.
• Zoom e reorganização: numa largura equivalente a 320 píxeis CSS, não se perde informação nem funcionalidade e a utilização normal não exige deslocamento em duas dimensões.
• Autenticação: não exija um teste de função cognitiva, a menos que esteja disponível um método alternativo ou mecanismo de assistência.
• Feedback: as mensagens de sucesso, falha e próximo passo são claras e disponibilizadas de forma acessível.
• Consistência: as rotas de ajuda repetidas aparecem numa localização relativa consistente em todas as páginas relevantes.

Escolha uma rota adequada à tarefa e ao cliente

Não existe uma alternativa universalmente correta. Selecione as rotas através da investigação com utilizadores, do risco do serviço e da capacidade operacional. O telefone pode ser o melhor para questões urgentes ou complexas; um pedido de chamada de retorno pode reduzir o tempo de espera em linha; um formulário acessível é adequado para casos não urgentes que necessitam de um registo escrito; e uma rota presencial ou específica do serviço pode ser necessária quando o cliente precisa de assistência prática.

Não publique uma rota apenas porque ela existe noutro ponto da organização. Confirme que aceita o tipo de questão relevante, tem uma equipa recetora, protege a informação do cliente e consegue comunicar um resultado. Uma alternativa que chega a uma caixa de correio não monitorizada cria uma segunda falha.

Quando o chat e a alternativa fazem parte do mesmo processo, evite pedir aos clientes que repitam informação que já forneceram. Sujeita a controlos de privacidade adequados, a informação necessária novamente deve estar disponível para seleção ou ser pré-preenchida. Não transfira automaticamente informação sensível apenas porque foi introduzida no chat.

• Telefone: utilize para assuntos urgentes, sensíveis ou de elevada complexidade; publique os horários de chamada e as adaptações de acessibilidade, quando aplicável.
• Formulário web acessível: utilize para pedidos estruturados e não urgentes; forneça uma referência ou confirmação após uma submissão bem-sucedida.
• Pedido de chamada de retorno: utilize quando os clientes não devem ter de esperar numa fila; recolha um método de contacto adequado e apenas os detalhes de agendamento necessários.
• Rota presencial ou especializada: utilize quando uma tarefa exige assistência local, prática ou regulamentada.
• Rota de emergência ou salvaguarda: quando relevante, diferencie-a do apoio comum, com redação e responsabilidade aprovadas pela equipa de serviço responsável.

Escreva textos que indiquem o próximo passo sem fazer promessas que não pode cumprir

O texto da alternativa deve reconhecer a situação, indicar a ação disponível e explicar o que acontece depois. Evite culpabilizar o cliente, usar jargão técnico e recorrer a formulações vagas como “tente novamente mais tarde” sem outra opção. Evite promessas de tempo de resposta, salvo se a equipa responsável conseguir cumpri-las de forma fiável e tiver aprovado a redação.

Utilize textos específicos de cada canal. Uma opção de telefone precisa de um número e horários. Um pedido de chamada de retorno precisa do mecanismo de confirmação esperado e de eventuais restrições. Um formulário precisa de indicar o que o cliente pode submeter e de uma mensagem de sucesso clara. Um estado fora do horário de atendimento precisa da próxima ação disponível, e não de um beco sem saída.

• Exemplo de mensagem de falha do widget: “O chat não está disponível neste momento. Pode pedir apoio através do nosso formulário acessível ou ligar para [número] durante [horário].”
• Exemplo de saída da automação: “Não consegui resolver esta questão no chat. Escolha ‘Pedir ajuda a uma pessoa’ para enviar os seus dados à equipa de apoio ou utilize [rota alternativa].”
• Exemplo de confirmação do formulário: “O seu pedido foi recebido. Guarde esta confirmação para os seus registos. Se a sua questão for urgente, ligue para [número].”
• Evite: “Responderemos em breve”, a menos que “em breve” tenha um significado operacional definido e monitorizado.

Transfira o contexto com cuidado, com limites de consentimento e verificação

A transferência de contexto pode reduzir o esforço do cliente, mas deve ser proporcional. Defina um pequeno registo de passagem para cada rota alternativa: a categoria da questão, um resumo curto escrito pelo cliente, a etapa da jornada, a referência relevante do caso e o método de contacto preferido podem ser suficientes. Identifique o que nunca é copiado automaticamente, como anexos desnecessários, texto livre sensível ou credenciais.

Diga aos clientes o que será enviado para a equipa seguinte e dê-lhes a possibilidade de rever ou alterar essa informação, quando apropriado. Se estiver envolvido um departamento, sistema ou finalidade diferente, os revisores de privacidade devem determinar se é necessário novo consentimento, novo aviso ou outra base legal. Uma rota alternativa não é razão para recolher mais dados do que a tarefa exige.

A equipa recetora deve verificar a identidade através do processo aprovado pela organização antes de divulgar informação da conta ou agir sobre pedidos sensíveis. Uma referência de caso pode ajudar a localizar o trabalho; não é automaticamente prova de identidade.

• Defina os campos mínimos de passagem e a regra de conservação para cada rota.
• Nunca peça aos clientes que enviem palavras-passe, códigos de autenticação ou outras credenciais pelo chat ou por um formulário alternativo.
• Mantenha uma explicação dirigida ao cliente sobre que informação é transferida e porquê.
• Permita que a equipa veja a conversa original apenas quando a respetiva função e o caso o exigirem.
• Disponibilize uma via manual quando o contexto não puder ser transferido em segurança ou por motivos técnicos.

Crie saídas explícitas da automação e uma via de escalonamento humano

A automação deve oferecer uma saída antes de a frustração se transformar em abandono. Defina gatilhos para uma via assistida: intenção mal compreendida repetidamente, falhas repetidas de respostas validadas, pedido explícito para falar com uma pessoa, tema de risco elevado, pedido fora do âmbito ou um fluxo automatizado que não consegue concluir uma etapa obrigatória.

A rota de escalonamento tem de indicar uma fila recetora ou canal alternativo, e não apenas apresentar uma mensagem tranquilizadora. Defina o que a automação transmite, o que os clientes precisam de fazer a seguir e o que acontece se não houver ninguém disponível naquele momento. Quando uma passagem não puder ter equipa, ofereça em alternativa a rota aprovada de chamada de retorno, formulário ou telefone.

O julgamento humano continua a ser necessário para exceções, pedidos ambíguos, reclamações, indicadores de vulnerabilidade e casos em que a política ou a segurança exige revisão. A equipa precisa de instruções para aceitar, reencaminhar e encerrar pedidos alternativos, incluindo o que fazer quando o pedido chega ao departamento errado.

• Gatilho: o cliente seleciona “falar com uma pessoa” ou equivalente; ação: oferecer transferência para equipa disponível ou uma rota alternativa claramente identificada.
• Gatilho: duas ou mais tentativas sem sucesso da mesma resposta validada; ação: explicar o bloqueio e oferecer assistência sem forçar outra tentativa.
• Gatilho: questão sensível, urgente ou definida pela política; ação: suprimir automação inadequada e encaminhar para a rota de serviço responsável.
• Gatilho: fora do horário de atendimento; ação: mostrar a disponibilidade atual e a próxima ação com apoio, sem sugerir que existe ajuda em direto.

Atribua responsabilidades entre filas, horários e departamentos

Cada pedido alternativo precisa de um responsável que preste contas desde a receção até à resolução. Mapeie o modelo operacional por tipo de pedido, canal, equipa interna, horário de cobertura, contacto de escalonamento e padrão de encerramento. Distinga a equipa responsável pela apresentação no website da equipa responsável pelo resultado do serviço; podem não ser a mesma.

Uma caixa de entrada partilhada pode ser útil quando as conversas de WebChat e WhatsApp precisam de tratamento coordenado, mas nem todas as alternativas têm de entrar no mesmo espaço de trabalho. As rotas de telefone, presenciais e especializadas podem ter sistemas e controlos separados. O que importa é uma passagem documentada e uma forma de identificar pedidos que não receberam uma resposta responsável.

Planeie as alterações de procura, a cobertura com formação, a proteção da privacidade e os ciclos de feedback. Se uma rota não estiver disponível fora do horário de funcionamento, defina e teste a redação fora de horário e a responsabilidade pelos pedidos recebidos nesse período.

• Indique um responsável pelo serviço, um responsável diário pela fila e um responsável pelo escalonamento para cada rota.
• Documente horários de abertura, cobertura linguística, cobertura especializada e tratamento fora do horário de atendimento.
• Defina regras de encaminhamento para pedidos dirigidos à equipa errada, duplicados, incompletos e urgentes.
• Forneça à equipa modelos, instruções de verificação e uma rota clara para questões de acessibilidade ou privacidade.
• Reveja os pedidos não resolvidos e os padrões de falha repetidos com as equipas que os podem corrigir.