IA não conserta processo quebrado. Escala.

há 2 dias

9 min de leitura

Quatro testes antes de automatizar o atendimento

Um cliente abre o chat da empresa na terça-feira e explica que a cobrança veio em duplicidade. O robô pede o número do pedido, confirma o valor, informa que o estorno será processado em até dez dias úteis e pergunta se pode ajudar em mais alguma coisa.

O cliente escreve que não. Atendimento encerrado. Resolvido.

Na quinta-feira, ele volta. O robô não reconhece a conversa anterior e pede o número do pedido novamente.

Na semana seguinte, volta uma terceira vez, agora por telefone. Uma pessoa atende e pede que ele explique o caso desde o início.

Aqui vale olhar para o que a empresa viu:

Três atendimentos encerrados.
Boa contenção, porque duas das três conversas terminaram sem chegar a uma pessoa.
Uma nota de satisfação razoável, porque a pesquisa saiu logo depois do primeiro encerramento, quando a promessa de estorno ainda parecia suficiente.
Custo por contato em queda.

O que a empresa não viu era mais simples: o cliente continuava com o problema.

Esse cenário é ilustrativo, mas expõe uma diferença importante: contenção mede o que o robô evitou; não mede o que o cliente resolveu.

Um robô que encerra uma conversa não necessariamente resolveu alguma coisa. Às vezes, apenas terminou a conversa. Automatizar um atendimento confuso não elimina a confusão. Industrializa.

Este não é um argumento contra IA. É uma discussão sobre a ordem das coisas.

Antes de automatizar um fluxo, há perguntas que a empresa precisa saber responder. Quando não sabe, pode descobrir tarde demais que escalou exatamente aquilo que deveria ter corrigido primeiro.

Quatro testes ajudam a perceber a diferença. Afinal, a IA não escolhe o que multiplica. A tecnologia é amplificador, não origem. No atendimento, a automação amplifica pelo menos quatro coisas: processo, dado, regra e critério de sucesso.

Se o processo funciona, o cliente pode chegar à solução mais rápido.
Se o processo é ruim, ele chega ao beco sem saída mais rápido.
Se os dados estão fragmentados, a automação trabalha com uma história incompleta.
Se a regra interna é contraditória, a tecnologia não elimina a contradição. Pode apenas aplicá-la com maior consistência e escala.

E é justamente o quarto elemento que costuma receber menos atenção: aquilo que a empresa decidiu chamar de sucesso.

Quando uma medida deixa de ser apenas um indicador e passa a determinar aquilo que pessoas, áreas e fornecedores devem otimizar, ela pode perder a capacidade de representar o fenômeno que deveria medir. É a lógica associada à Lei de Goodhart[1].

Imagine uma operação cujo principal indicador de sucesso da automação seja a redução das transferências para atendentes humanos. O indicador pode fazer sentido. O problema começa quando passa a representar, sozinho, o objetivo. A partir daí, desenho do fluxo, parametrização, operação e fornecedor recebem o mesmo sinal: transfira menos.

E é perfeitamente possível melhorar esse número sem melhorar a resolução. A contenção sobe. O contato humano cai. O custo aparente melhora. Ao mesmo tempo, o cliente volta, muda de canal, procura a ouvidoria ou simplesmente desiste.

Nenhuma dessas coisas contradiz necessariamente o indicador. Esse é justamente o problema: o número pode continuar melhorando enquanto parte da experiência se deteriora. E esse tipo de distorção não nasce apenas da tecnologia ou de quem a implementa. Nasce também dos indicadores que nós, em CX e Atendimento, escolhemos legitimar.

Durante muito tempo, contenção foi celebrada porque cabia bem ao lado da redução de custo e oferecia um número simples de eficiência para levar à diretoria.

Só que eficiência de quê? A discussão sobre IA em atendimento não começa na ferramenta. Começa na definição de sucesso e na pergunta que deveria acompanhá-la: o cliente reconheceria esse resultado como sucesso também?

Teste 1: fechado não é resolvido

A primeira pergunta é direta: dos atendimentos que o fluxo automatizado encerrou, quantos o cliente consideraria efetivamente resolvidos?

“Encerrado” é um status do sistema. “Resolvido” é uma condição do problema.

Os dois podem coincidir. Mas não são sinônimos.

O Teste Fechado × Resolvido pode ser feito sem uma grande estrutura de pesquisa.

Primeiro, separe uma amostra de atendimentos encerrados pela automação sem transferência para uma pessoa. Distribua a amostra pelos principais motivos de contato. Aqui lembre-se: olhar apenas a média pode esconder um assunto muito ruim dentro de vários fluxos simples que funcionam bem.

Depois, defina resolução pela ótica do problema: aquilo que levou o cliente a procurar a empresa deixou de existir e ele tem condições de saber disso?

Link enviado não significa necessariamente problema resolvido. Resposta entregue também não. Protocolo encerrado, menos ainda.

Para os SACs abrangidos pelo Decreto 11.034/2022, essa distinção aparece inclusive na regulamentação: a taxa de resolução das demandas sob a ótica do consumidor está entre os parâmetros de efetividade do SAC.

O passo seguinte é procurar evidência que contradiga a resolução registrada. O mesmo cliente voltou com o mesmo assunto dentro de um intervalo compatível com aquele tipo de problema? Procurou outro canal? Apareceu na ouvidoria? Escalou a reclamação?

O recontato, sozinho, não prova ausência de resolução. Ele é uma evidência para investigação, especialmente quando motivo, contexto e temporalidade apontam para a continuidade do mesmo problema.

O prazo precisa fazer sentido para a demanda. Uma segunda via não deve ser observada com a mesma janela de um estorno.

Finalmente, coloque as duas leituras lado a lado:

o que o painel registra como encerrado ou resolvido;
e o que a trajetória do cliente permite considerar realmente solucionado.

A distância entre as duas medidas merece mais atenção do que a contenção isolada.

Não há um percentual universal que determine quando essa distância é aceitável. Há algo mais útil: enquanto a operação não entende por que as duas leituras divergem, ampliar aquele fluxo significa ampliar uma incerteza.

E há uma descoberta frequente nesse exercício: dentro da mesma organização, ‘resolução’ pode ter três significados diferentes — o do sistema, o da operação e o do cliente.

Teste 2: a causa mora no atendimento?

Nem toda dor que chega ao atendimento nasceu ali. Muitas só se tornam visíveis lá.

Uma cobrança errada pode ter origem no faturamento. Um prazo não cumprido pode nascer na logística. Uma regra incompreensível pode ter sido criada em produto. Uma comunicação ruim pode ser resultado de uma decisão comercial.

O atendimento recebe o problema, mas isso não faz dele a causa.

Nesses casos, colocar um robô no meio pode produzir uma experiência curiosa: a empresa passa a explicar um erro mais rapidamente, vinte e quatro horas por dia e em linguagem cordial. Oerro continua lá.

Antes de automatizar os principais motivos de contato, faça uma triagem simples. Liste os dez motivos mais frequentes atendidos pelo fluxo e para cada um, pergunte: se a automação fosse perfeita, o cliente ainda teria motivo para estar insatisfeito?

A pergunta é contrafactual de propósito: ela não tenta prever o desempenho do robô, mas separar aquilo que o atendimento pode resolver daquilo cuja origem está em outra parte da organização.

Se a resposta for sim, a causa provavelmente está fora do atendimento. Pode estar em uma decisão de negócio, em um defeito de produto, em uma limitação tecnológica, em uma política ou em uma escolha de investimento. Automatizar a resposta não toca necessariamente a origem.

Se a resposta for não, existe maior chance de a causa estar no próprio fluxo de atendimento — acesso à informação, execução de uma tarefa, tempo de resposta, interpretação de uma solicitação — e a automação pode encontrar terreno mais fértil.

Essa distinção muda também a forma de usar IA.

Quando a causa está fora do atendimento, talvez a aplicação mais valiosa não seja responder melhor. Pode ser enxergar melhor, ler milhares de contatos, agrupar motivos semelhantes, identificar recorrência, cruzar volume, impacto e custo e dar evidência para a área que tem poder de remover a causa.

Existe uma diferença enorme entre usar IA para responder a um problema em escala e usar IA para tornar a origem desse problema visível em escala. Somente a segunda opção pode fazer o contato desaparecer porque deixou de ser necessário.

Teste 3: quando a automação não resolve, existe saída?

Todo fluxo automatizado funciona melhor enquanto o cliente permanece dentro daquilo que foi previsto. O teste real começa quando ele sai do roteiro: o robô não entendeu, a situação tem uma exceção, a resposta não serviu, o cliente já tentou aquilo, a regra não cobre o caso ou o problema agora é outro.

O que acontece? Todo fluxo automatizado precisa de uma saída. Sem ela, deixa de ser apenas uma ferramenta e pode virar uma barreira.

Esse teste pode ser feito do lado do cliente:

Escolha três situações: uma simples, uma fora do roteiro e uma em que a pessoa já esteja frustrada porque tentou resolver antes.
Entre no canal como cliente. Observe quanto tempo e quantas interações são necessárias até que apareça uma alternativa real.
Veja o que acontece quando a automação não entende duas vezes seguidas: repete? Reformula? Oferece outra rota? Transfere? E, principalmente: se uma pessoa assume o atendimento, ela recebe o contexto ou o cliente precisa reconstruir a história?

A transferência sem contexto é uma falsa transferência. O canal muda, mas parte do trabalho é devolvida ao consumidor.

Nos serviços abrangidos pelo Decreto 11.034/2022[2], existe ainda uma obrigação relevante: após o registro da demanda no primeiro atendimento, é vedado solicitar sua repetição. O decreto também estabelece requisitos de resolutividade e prevê atendimento humano no canal telefônico em condições definidas pela regulamentação.

Fora do alcance específico do decreto, permanece uma pergunta de experiência: por que alguém deveria explicar duas vezes aquilo que a empresa já ouviu uma?

Teste 4: o cliente aprovaria o fluxo?

O quarto teste muda o ponto de observação.

Em vez de perguntar se o fluxo funciona para a empresa, pergunte se ele funciona para quem precisa utilizá-lo.

Escolha um fluxo e responda apenas sim ou não:

O cliente entende, logo no início, o que a automação consegue e não consegue fazer?
Ele sabe o que acontecerá depois?
Precisa contar o problema apenas uma vez?
Quando a automação falha, existe uma saída compreensível?
Ao final, ele consegue saber se o problema foi realmente resolvido ou qual é o próximo passo?

Os “nãos” importam mais do que uma média bonita. Um deles pode ser apenas um ajuste; vários indicam que o fluxo ainda depende da tolerância do cliente para parecer eficiente.

Nesse ponto, não é hora de ampliar. É hora de consertar. E há ainda uma consequência importante que merece uma discussão própria: quando a automação absorve os contatos simples, os casos que chegam às pessoas tendem a mudar. Ficam para o humano as exceções, os problemas que exigem julgamento, os clientes que já tentaram resolver e aquilo que a automação não conseguiu interpretar.

A empresa automatiza uma parte do atendimento, mas muitas vezes continua medindo e preparando o trabalho humano como se nada tivesse mudado.

Esse será assunto de outro texto.

A pergunta que antecede a compra

Os quatro testes têm a mesma lógica. Antes de ampliar uma automação, a empresa precisa saber:

o que o cliente realmente resolveu;
onde nasce a causa do contato;
o que acontece quando a automação não dá conta;
e se o fluxo continua fazendo sentido quando observado pelo lado de quem precisa usá-lo.

Se essas respostas não existem, o fluxo ainda não é exatamente uma solução. É uma hipótese. E existe uma pergunta que cabe em qualquer reunião em que se discute ampliar automação: se uma pessoa tivesse entregado este resultado, a empresa o aprovaria?

Se a resposta for não, talvez o problema não esteja na pessoa nem no robô. Pode estar no critério de sucesso que a organização aceitou sem discutir.

Para começar na segunda-feira, escolha um fluxo. Não dez. Um.

Aplique os quatro testes e leve as divergências encontradas para a próxima reunião em que alguém estiver decidindo o que automatizar.

A IA acelera o que a empresa já faz. A questão é descobrir, antes de escalar, se é justamente isso que deveria ser acelerado.

Os testes apresentados aqui dialogam com as metodologias que venho desenvolvendo para diagnóstico, decisão e desenho da experiência do cliente. Parte dessa lógica está em A Máquina na Garagem, publicado pela Actual/Alta Books.

[1] A chamada Lei de Goodhart tem origem no trabalho do economista britânico Charles A. E. Goodhart sobre política monetária. Em “Problems of Monetary Management: The U.K. Experience”, publicado originalmente em 1975, Goodhart formulou a ideia de que regularidades estatísticas observadas tendem a perder sua estabilidade quando passam a ser utilizadas deliberadamente para fins de controle. A formulação hoje mais conhecida — “quando uma medida se torna uma meta, deixa de ser uma boa medida” — é uma generalização posterior, associada especialmente à antropóloga Marilyn Strathern em seu artigo “‘Improving Ratings’: Audit in the British University System”, publicado em 1997. O ponto não é que toda métrica deixe automaticamente de ter valor ao se transformar em meta. O risco surge porque pessoas e sistemas passam a otimizar o indicador, e essa otimização pode separar o número daquilo que ele deveria representar. Em atendimento, contenção é um exemplo útil: como indicador, ajuda a entender quantos contatos foram concluídos sem intervenção humana; transformada isoladamente em objetivo, pode incentivar fluxos que impedem transferência sem necessariamente elevar a resolução. Ver: GOODHART, C. A. E. “Problems of Monetary Management: The U.K. Experience”. Papers in Monetary Economics, Reserve Bank of Australia, 1975; STRATHERN, Marilyn. “‘Improving Ratings’: Audit in the British University System”. European Review, v. 5, n. 3, p. 305–321, 1997.

[2] BRASIL. Decreto nº 11.034, de 5 de abril de 2022. Regulamenta o Código de Defesa do Consumidor para estabelecer diretrizes e normas sobre o Serviço de Atendimento ao Consumidor — SAC. O decreto se aplica aos fornecedores de serviços regulados pelo Poder Executivo federal; portanto, suas disposições não devem ser generalizadas como obrigação específica para setores não abrangidos.