O encaminhamento de conversas de atendimento ao cliente determina que equipa, fila ou pessoa recebe um contacto e por que ordem. Quando se limita a distribuir por ordem de chegada, parece neutro, mas tende a produzir esperas desnecessárias: uma incidência técnica chega a uma equipa comercial, uma consulta urgente fica atrás de um pedido administrativo ou um cliente tem de repetir informações em cada transferência.
A alternativa não é criar dezenas de regras difíceis de manter. É conceber uma lógica explícita que use sinais fiáveis, tenha prioridades claras e ofereça sempre uma rota alternativa. O objetivo não é acertar automaticamente em todos os casos, mas reduzir atribuições incorretas sem bloquear conversas ambíguas, incompletas ou excecionais.
Separar classificação, prioridade, encaminhamento e escalonamento
Estes conceitos estão relacionados, mas resolvê-los com uma única regra gera configurações opacas.
- Classificação: identifica o motivo provável do contacto, como “alteração de morada”, “erro de acesso” ou “consulta de faturação”. Pode resultar de um formulário, de dados estruturados ou de uma revisão humana.
- Prioridade: determina a urgência operacional. Por exemplo, uma interrupção de serviço, um risco de fraude ou um pedido com prazo contratual podem exigir atenção preferencial.
- Encaminhamento: decide a fila ou a equipa de destino inicial com base na classificação, na prioridade e nas condições aplicáveis.
- Atribuição: escolhe um agente específico dentro dessa fila, considerando disponibilidade, competências, carga de trabalho e continuidade com um caso anterior.
- Escalonamento: altera a rota após a atribuição inicial quando o caso ultrapassa o âmbito da equipa, incumpre um prazo ou exige uma aprovação.
A separação permite diagnosticar falhas. Se muitos contactos chegam à equipa certa, mas esperam demasiado, o problema pode ser de capacidade ou de atribuição, e não de classificação. Se houver muitas transferências após a primeira resposta, talvez a taxonomia ou as regras iniciais não representem o trabalho real.
Definir sinais de decisão fiáveis e proporcionados
Uma regra deve basear-se em dados disponíveis no momento da decisão e que tenham uma relação clara com o tratamento do caso. Os sinais habituais incluem:
- Intenção ou motivo: categoria declarada num formulário, opção escolhida num menu ou classificação de texto com um nível de confiança conhecido.
- Identidade e relação: se o contacto é reconhecido, o seu segmento de serviço ou se já tem uma conversa ou processo em aberto.
- Encomenda, contrato ou processo relacionado: estado de uma entrega, uma devolução em curso, uma incidência aberta ou uma renovação próxima.
- Idioma e canal: idioma preferencial, horário do canal e restrições próprias de chat, e-mail ou mensagens.
- Urgência: impacto comunicado, prazos, alertas operacionais ou palavras-chave que devam ser verificadas por uma pessoa.
- Consentimento e permissões: dados que determinam se um pedido pode ser tratado ou se deve ser aplicado um fluxo de verificação.
Convém evitar utilizar dados que não sejam necessários para decidir o atendimento, que possam estar desatualizados ou que introduzam enviesamentos injustificados. Também é necessário distinguir um dado confirmado de uma inferência. Uma intenção detetada automaticamente com baixa confiança não deve ativar uma rota altamente especializada sem uma alternativa de revisão.
Criar uma taxonomia de motivos que seja útil para a operação
A taxonomia é o vocabulário com o qual as conversas são classificadas. Deve ser suficientemente concreta para decidir uma ação e suficientemente estável para medir tendências. Categorias como “problema” ou “consulta” são demasiado abrangentes; uma lista com centenas de etiquetas quase idênticas é difícil de selecionar e manter.
Uma estrutura prática costuma ter dois ou três níveis: um domínio, um motivo e, apenas quando alterar a ação, um submotivo. Por exemplo: conta > acesso > reposição de credenciais ou encomenda > entrega > atraso. Cada categoria deve documentar a sua definição, exemplos incluídos e excluídos, equipa responsável, prioridade possível e rota predefinida.
Antes de automatizar, analise uma amostra representativa de conversas reais. Agrupe pelo trabalho que tem de ser realizado, e não apenas pelas palavras usadas pelo cliente. Se “não consigo entrar” puder significar credenciais esquecidas, bloqueio de segurança ou indisponibilidade do serviço, as rotas podem ser diferentes; se todas receberem o mesmo procedimento, separá-las não acrescenta valor.
Converter sinais em regras ordenadas e explicáveis
As regras necessitam de uma ordem de avaliação e de um responsável pela manutenção. Uma lógica simples pode ser expressa da seguinte forma:
1. Se existir um alerta de segurança verificado, enviar para a fila especializada prioritária. 2. Se houver um caso aberto compatível, manter a continuidade com a respetiva equipa responsável. 3. Se o motivo for “incidência técnica” e o idioma estiver coberto, enviar para o suporte técnico. 4. Se o motivo for “faturação”, enviar para a administração. 5. Se faltarem dados ou a confiança da classificação for baixa, enviar para a triagem geral.
Esta ordem reflete uma decisão deliberada: a segurança e a continuidade prevalecem sobre a classificação genérica. Cada regra deve incluir a sua condição, destino, prioridade, responsável, data de revisão e resultado esperado. Evite condições implícitas, como assumir que uma fila estará sempre aberta ou que existirá sempre um dado no sistema de gestão da relação com clientes.
Resolver conflitos de forma previsível
Os conflitos são inevitáveis. Um contacto pode ser urgente, corresponder a uma equipa sem cobertura e ter ainda um caso anterior atribuído a outra área. Defina uma hierarquia que o pessoal possa explicar: proteger a segurança e as obrigações críticas; preservar a continuidade quando adequado; respeitar competências e idioma; e, por último, equilibrar a carga de trabalho.
A disponibilidade não deve eliminar a prioridade. Se não houver uma equipa especializada disponível, a regra pode criar uma fila prioritária de recurso, alertar um responsável ou registar um compromisso de contacto posterior. Enviar silenciosamente o caso para qualquer agente disponível pode reduzir a espera inicial, mas aumenta o risco de uma resposta incorreta e de transferências posteriores.
Preservar o contexto em transferências e escalonamentos
Uma transferência só é aceitável se evitar que o cliente tenha de voltar a explicar o caso. O destino deve receber, no mínimo, o canal e a hora de origem, a identidade verificada quando aplicável, o motivo detetado, a prioridade, a encomenda ou o processo relacionado, o resumo da conversa, as ações já realizadas e o motivo concreto da alteração de rota.
O resumo não deve limitar-se a “transferido para o suporte”. Um registo útil seria: “Cliente identificado; encomenda associada; comunica erro ao confirmar; foram verificados os dados básicos; não foi solicitada nenhuma ação irreversível; é escalado devido a erro reproduzível.” Manter um histórico de rotas e reatribuições permite identificar posteriormente regras que desviam casos de forma recorrente.
Ao integrar WebChat, formulários, mensagens, sistemas de gestão da relação com clientes e ferramentas operacionais, utilize identificadores partilhados ou ligações consistentes. O princípio é uma conversa e um registo de caso por necessidade operacional, e não uma cópia independente por sistema. Antes de sincronizar dados, defina que sistema é a fonte de cada campo e como são resolvidas atualizações simultâneas.
Conceber rotas de exceção antes de precisar delas
Uma regra robusta contempla sempre o que acontece quando não pode ser cumprida. No mínimo, conceba rotas para dados incompletos, intenção ambígua, ausência de agentes qualificados, filas saturadas, horários fora de cobertura e falhas de integração.
- Dados incompletos: solicitar o dado mínimo necessário ou enviar para uma fila de triagem com acesso à conversa original.
- Ambiguidade: aplicar uma categoria geral e marcar o caso para revisão, em vez de forçar uma classificação específica.
- Saturação: definir limiares observáveis, uma fila de recurso e o responsável que decide medidas temporárias.
- Falha de integração: manter uma rota segura baseada na informação disponível e registar a falha para a sua correção.
As exceções não são uma falha de conceção: fazem parte da conceção. O importante é que não se transformem numa gaveta permanente. Se a fila de triagem concentrar muitos casos, é necessário investigar que sinal falta, que categoria causa confusão ou que dependência técnica não é fiável.
Medir, rever e ativar novas regras com controlo
Avalie a lógica por rota, e não apenas com uma média global. Meça o tempo até à primeira resposta, a taxa de transferências, as reatribuições, o tempo de resolução, a resolução por rota, o volume não classificado e a proporção de conversas que chegam a uma exceção. Reveja também amostras qualitativas: uma baixa taxa de transferências não é positiva se os casos forem encerrados sem resolução.
Antes de implementar uma regra, teste-a com casos históricos anonimizados ou com um grupo limitado, compare o destino esperado com o real e reveja os falsos positivos. Estabeleça uma data de revisão. As rotas criadas para campanhas, incidências temporárias ou equipas que já não existem devem ser removidas para não distorcerem o sistema.
Lista de verificação para ativação
- A intenção ou condição de entrada tem uma definição verificável?
- A regra tem prioridade, destino principal e rota alternativa?
- Sabe-se o que acontece sem dados, fora do horário ou sem capacidade disponível?
- A equipa recetora dispõe do contexto e das permissões para atuar?
- Existe um responsável, uma métrica de acompanhamento e uma data de revisão?
- Foi verificado que a integração não duplica conversas nem registos?
Um bom encaminhamento não consiste em automatizar todas as decisões. Consiste em levar cada conversa à melhor ação seguinte com a informação disponível, tornar as exceções visíveis e melhorar as regras com base em evidências.