Fui resolver o desafio do time de Customer Success e queria compartilhar como organizei o raciocínio aplicando os quatro fundamentos.
Decomposição
Separei em duas dimensões:
- Por tipo de pedido: acesso, pagamento, uso da plataforma, conta/dados, outros
- Por etapa do ciclo: recepção → triagem → roteamento → resolução → confirmação → pós-atendimento
A ideia é que "está confuso" não é só sobre o que o usuário pede, é sobre como o processo flui internamente. Atacar nas duas dimensões dá mais alavanca.
Reconhecimento de padrões
Olhar o histórico (uns 3-6 meses) procurando:
- As 10-15 dúvidas que respondem por 70-80% do volume (Pareto sempre aparece)
- Vocabulário do usuário ("não consigo entrar", "cobrou duas vezes") — insumo pra classificador
- Sazonalidade (pagamento concentra no início do mês)
- Quando dúvidas diferentes resolvem com o mesmo tutorial → não é problema de suporte, é UX da interface
- Sinais de risco/churn que NÃO podem cair em automação
Abstração
Quatro camadas que escondem complexidade:
- Base de conhecimento estruturada (perguntas → respostas)
- Templates com variáveis ({nome}, {pedido}, {prazo})
- Categorias com nome do modelo mental do usuário ("problema de pagamento", não "billing tier 2")
- Persona única de atendimento — o usuário sente a marca, não o operador
A melhor abstração é a que coincide com o modelo mental do usuário.
Algoritmo
- Recebe mensagem
- Classifica categoria (regras + IA)
→ confiança baixa? vai pra fila humana com tag "não classificado" - Tem resposta padrão pra subcategoria?
→ SIM: envia + pergunta "resolveu?"
→ "sim" fecha ticket
→ "não" escala pra humano com contexto da resposta tentada
→ NÃO: roteia pro time da categoria com histórico pré-carregado - Humano resolve e registra
- Se a mesma solução virar padrão (X+ usos), entra automaticamente na base
- Métricas sempre ligadas: FCR, taxa auto-resolvida, CSAT
Três coisas que eu acrescentaria
- Saída de emergência sempre visível. Bot que prende usuário gera mais frustração do que resolve. "Falar com humano" tem que estar a um clique.
- Fallback pra mensagem ambígua. "Não consigo pagar porque não consigo entrar" é acesso e pagamento. Tem que ter caminho pra isso.
- Loop de aprendizado contínuo. Sem isso, em 6 meses a base está desatualizada empurrando resposta errada.
Dois pontos que chamam atenção pra quem está pensando em desenhar suporte:
- A Luri já é o caso de "IA com retrieval na documentação viva" que tanto se fala lá fora. Não é FAQ hardcoded, é IA que busca contexto no conteúdo do curso pra responder.
- Cada interação pode virar ativo permanente, não precisa desaparecer num inbox privado. Isso é o loop de aprendizado pode funcionando no nível da plataforma inteira.
E por ultimo vi sobre métricas, tá rolando uma migração de Tempo médio de resposta para First Contact Resolution e Volume atendido virando fix de produto, não fui muito alem disto, mas é interessante esta mudança e oque ela pode refletir.
