Como definir os limites do suporte ao cliente no WebChat e no WhatsApp

Porque é que as equipas de mensagens precisam de limites de serviço claros e documentados

Um limite de serviço define o que uma equipa de suporte pode concluir numa conversa, aquilo em que pode ajudar sob condições específicas e o que tem de ser tratado através de outro processo. Não é simplesmente uma lista de temas que os operadores devem recusar. Um bom limite ajuda o cliente a perceber o que vai acontecer a seguir.

Sem limites por escrito, dois operadores podem dar respostas diferentes ao mesmo pedido. Também podem pedir aos clientes informações de que a equipa não precisa ou encaminhá-los para outro canal sem contexto suficiente para avançarem. Documentar a decisão e o passo seguinte torna as respostas mais consistentes no WebChat e no WhatsApp.

Um limite é uma política operacional, não uma funcionalidade da plataforma de mensagens. Uma caixa de entrada partilhada pode ajudar as equipas a organizar conversas, operadores, departamentos, encaminhamento, horários, níveis de serviço, modelos e etiquetas; ainda assim, cabe à organização definir o que cada equipa está autorizada e preparada para fazer.

• Defina o resultado permitido, não apenas o tema. Por exemplo, uma equipa pode explicar uma política, mas não aprovar uma exceção.
• Identifique quem é responsável pelos pedidos que não podem ser concluídos na conversa atual.
• Registe exceções, regras de urgência e o percurso de escalamento para uma pessoa, para que os operadores não tenham de improvisar.

Avalie cada pedido com quatro critérios de decisão

Use as mesmas quatro perguntas para cada pedido antes de decidir se pode ser concluído na conversa. Em geral, um pedido pode ser adequado para mensagens e, ainda assim, exigir outro canal devido ao risco, às informações necessárias ou às opções de suporte disponíveis.

Adequação da tarefa: É possível concluir o trabalho claramente através de uma troca de mensagens, ou depende de um pedido formal, da análise de documentos, de uma ação física ou de outro processo? Distinga entre fornecer informações, tomar uma decisão e executar uma ação.

Risco: O que pode correr mal se a resposta estiver errada, for mal interpretada ou sofrer atrasos? Considere as consequências financeiras, de segurança, privacidade, legais ou outras consequências relevantes para o seu serviço. Defina limites mais rigorosos quando um erro possa causar danos significativos e não peça aos operadores que tomem decisões fora da sua autoridade.

Necessidades de informação: Quais são as informações mínimas necessárias para avançar? Se a tarefa exigir informações que não possam ser recolhidas através da conversa atual segundo as regras aprovadas, ou que não possam ser analisadas de forma fiável nesse canal, use o processo aprovado pela organização. Não recolha dados sensíveis adicionais apenas para dar a impressão de que a conversa ficou completa.

Canais disponíveis: Existe um canal real, com equipa disponível, capaz de tratar do pedido, e o cliente consegue aceder-lhe? Identifique a equipa responsável, como contactá-la, que informações preparar e o que fazer se o canal preferido não estiver disponível. Um canal que só existe no papel não é um próximo passo útil.

• Pergunte: Esta tarefa está dentro da autoridade e das capacidades desta equipa?
• Pergunte: O risco é aceitável para este canal e processo?
• Pergunte: Podemos recolher e utilizar as informações necessárias de forma adequada?
• Pergunte: Podemos indicar um próximo passo acessível e disponível, bem como uma pessoa responsável?

Crie uma matriz de limites de serviço com três resultados

Crie uma matriz breve que os operadores possam consultar rapidamente. Adapte-a ao seu serviço: os exemplos abaixo descrevem padrões de decisão, não regras universais. Confirme as equipas responsáveis, as ações permitidas e os canais aprovados junto das pessoas responsáveis pelas políticas relevantes.

Concluir aqui: Use este resultado quando o pedido for adequado para mensagens, o operador tiver autoridade, as informações necessárias puderem ser tratadas de forma adequada e o risco for aceitável. Indique o que foi feito e qualquer ação ou limitação ainda pendente.

Continuar com salvaguardas: Use este resultado quando o pedido puder continuar na conversa, mas depender de uma condição definida — por exemplo, uma resposta mais limitada, uma verificação por um colega autorizado ou um limite sobre as informações partilhadas. Explique a condição e o que o cliente pode esperar a seguir. Se não for possível cumprir a salvaguarda, encaminhe o pedido para outro processo.

Recorrer a outro processo: Use este resultado quando a tarefa estiver fora da autoridade da equipa, as informações ou a ação exigirem outro processo aprovado, o risco for demasiado elevado para a conversa atual ou não for possível concluir o pedido de forma fiável no chat. Indique ao cliente um canal concreto e, quando adequado, encaminhe o pedido para uma equipa identificada ou uma pessoa responsável.

• Para cada tipo de pedido frequente, registe: resultado, motivo, ação autorizada, informações permitidas, responsável e próximo passo a comunicar ao cliente.
• Identifique separadamente as situações urgentes ou potencialmente prejudiciais e especifique o percurso de escalamento para uma pessoa e as expectativas de resposta da organização. Não deixe os operadores decidirem sem orientação se uma situação é urgente.
• Analise casos ambíguos com os responsáveis pelas políticas, privacidade, segurança ou áreas especializadas antes de acrescentar uma nova regra.

Explique o limite e torne útil o próximo passo

Uma recusa sem indicar outro canal cria um impasse. Uma mensagem útil sobre o limite reconhece o pedido, explica brevemente a restrição e apresenta um próximo passo que o cliente possa seguir. Evite linguagem interna, atribuição de culpa, instruções vagas como «contacte o departamento responsável» e promessas que a equipa não possa cumprir.

Quando o cliente tiver de fornecer informações, indique o que é necessário e porquê, e explique como enviá-las pelo canal aprovado. As orientações da W3C sobre o Critério de Sucesso 3.3.2 das WCAG pedem etiquetas ou instruções que ajudem as pessoas a saber que informações devem introduzir. Quando é detetado um erro de introdução de dados e se conhece uma sugestão de correção, o Critério de Sucesso 3.3.3 das WCAG exige que essa sugestão seja fornecida, salvo se isso puser em risco a segurança ou a finalidade do conteúdo.

Se o cliente não conseguir utilizar o canal sugerido, não se limite a repeti-lo. Pergunte que obstáculo está a encontrar e, em seguida, siga as opções de apoio assistido documentadas. As necessidades de suporte variam; entre os canais possíveis na conceção de serviços estão o telefone, o atendimento presencial ou, quando adequado, o chat na web. Ofereça apenas opções que a sua organização disponibilize de facto.

• Reconheça: «Compreendo que nos está a pedir para…»
• Explique: «Não consigo concluir essa alteração nesta conversa porque…»
• Indique uma ação específica: «Submeta o pedido através de [canal aprovado] e inclua [informações necessárias].»
• Defina expectativas apenas quando estiverem confirmadas: identifique a equipa ou o próximo passo, mas não invente um prazo de resposta.
• Ofereça uma via de contacto humano: «Se não conseguir utilizar esse processo, diga-me o que o está a impedir e explicarei as opções de suporte disponíveis.»

Mantenha a política consistente no WebChat e no WhatsApp sem presumir que os canais são iguais

Comece com uma política única para o serviço e, em seguida, documente quaisquer limites específicos de cada canal que a equipa tenha confirmado. O limite não deve mudar apenas porque o operador está a responder no WebChat em vez de no WhatsApp. No entanto, as informações que podem ser recolhidas, o contexto do cliente e as formas práticas de continuar podem ser diferentes; por isso, teste as instruções em cada canal.

O webchat.vip disponibiliza uma caixa de entrada partilhada para conversas no WebChat e no WhatsApp. Cada canal de WebChat também inclui um widget instalável, personalizável e multilingue. Estas capacidades podem ajudar as equipas a organizar conversas e apresentar orientações, mas não definem que pedidos a sua organização deve aceitar ou autorizar.

Aplique as orientações WCAG aos conteúdos web que a sua organização controla, como o widget de WebChat. As WCAG abrangem conteúdos dinâmicos e a web em dispositivos móveis; isso não significa que a sua organização controle a interface do WhatsApp. Use texto legível em dispositivos móveis, etiquetas e instruções claras, e não dependa apenas da formatação ou de indicações visuais. Quando um processo tiver de continuar noutro canal, explique o percurso na conversa atual e evite obrigar os clientes a repetir informações sem necessidade, quando os seus procedimentos permitirem preservar o contexto.

• Use as mesmas categorias de resultado e a mesma justificação da política em todos os canais.
• Confirme se as ligações, os dados de contacto, as instruções e as opções de idioma disponíveis estão corretos em cada canal.
• Não prometa que o cliente pode concluir uma tarefa num canal sem que a equipa tenha confirmado que esse canal está disponível e é adequado.
• Trate os requisitos de privacidade, consentimento e segurança como regras operacionais; recolha apenas as informações necessárias para o próximo passo definido.

Transforme a política numa lista de verificação para operadores

Uma lista de verificação breve torna este enquadramento útil durante conversas em curso. Mantenha-a junto das orientações da equipa e certifique-se de que os operadores sabem onde pedir ajuda quando um caso não se enquadra. Uma política de limites deve apoiar o discernimento dentro de parâmetros claros, não incentivar os agentes a adivinhar.

Para os pedidos que exigem informações, especifique o que é necessário e como o cliente deve fornecê-las. O Privacy Framework do NIST é um recurso voluntário para identificar e gerir riscos de privacidade, protegendo a privacidade das pessoas; recorra aos responsáveis pela privacidade da sua organização e aos requisitos aplicáveis para definir as regras efetivas do seu serviço.

No que respeita aos controlos técnicos de segurança, não dependa apenas da formulação das mensagens. O Application Security Verification Standard da OWASP fornece uma base para testar controlos de segurança de aplicações web. Peça aos responsáveis técnicos e de segurança adequados que determinem que controlos se aplicam aos sistemas e processos envolvidos.

• Identifique o resultado pretendido pelo cliente; não deduza mais do que aquilo que o cliente disse.
• Compare a tarefa com a matriz de três resultados e confirme a autoridade do operador.
• Limite as perguntas às informações necessárias para a ação aprovada; explique em linguagem simples os dados que o cliente tem de fornecer.
• Se o caso estiver fora do âmbito ou for incerto, indique o limite e siga o percurso documentado até uma pessoa ou equipa autorizada.
• Registe o motivo e o resultado segundo o processo aprovado pela equipa, sem acrescentar dados pessoais desnecessários.
• Confirme que o cliente tem um próximo passo viável e sabe o que fazer se não conseguir aceder ao canal indicado.

Reveja as decisões sobre limites e corrija os impasses recorrentes

Os limites precisam de ser revistos à medida que as necessidades dos clientes, as políticas e as condições operacionais mudam. Procure pedidos recorrentes que os agentes não conseguem concluir, encaminhamentos repetidos para a mesma equipa, comentários de clientes que revelem confusão e conversas que terminem sem uma resolução ou próximo passo claro. Estes padrões podem indicar a falta de um canal, instruções pouco claras, uma regra desatualizada ou uma tarefa que deve ser reavaliada — não apenas a necessidade de recusar de forma mais consistente.

Analise exemplos com os operadores que contactam diretamente com os clientes e com os responsáveis pela política relevante. Confirme que a regra escrita corresponde à autoridade efetiva e aos canais de serviço disponíveis. Sempre que possível, teste a redação revista com utilizadores e verifique se continua a ser compreensível e consistente do início ao fim. As orientações de serviço da GOV.UK recomendam a integração dos canais de serviço, a criação de serviços simples de utilizar e a sua melhoria ao longo de todo o ciclo de vida.

• Acompanhe os resultados relativos aos limites, os pedidos não resolvidos, os encaminhamentos repetidos e o feedback dos clientes, utilizando os dados operacionais que a equipa já recolhe.
• Analise uma amostra de conversas para verificar se os agentes explicam o motivo, seguem o canal aprovado e evitam recolher dados desnecessários.
• Ao atualizar uma regra, informe os operadores afetados, atualize os modelos ou as orientações e confirme se o novo canal está efetivamente disponível.
• Encaminhe questões contestadas sobre políticas, privacidade ou segurança para a pessoa responsável, em vez de as resolver informalmente durante uma conversa com o cliente.