O atendente encerra uma conversa, abre o chamado e tenta organizar o que aconteceu. O assinante reclamou de lentidão. Houve um teste pelo Wi-Fi, mas faltou verificar a conexão por cabo. O caso vai para outra equipe. Se essa diferença desaparecer no resumo, o próximo profissional poderá tratar uma hipótese como diagnóstico.
Essa situação fictícia mostra uma boa tarefa para começar a testar inteligência artificial no provedor: preparar a passagem de um atendimento entre equipes. O trabalho tem limites claros, permite conferência e pode continuar sendo feito manualmente se a ferramenta falhar.
A proposta deste guia é usar a IA para produzir um rascunho interno, revisado antes de entrar no fluxo de trabalho. O objetivo do piloto é descobrir se o resumo fica pronto com menos esforço total e mantém as informações necessárias para a próxima pessoa. O envio ao cliente, a decisão técnica e os compromissos comerciais permanecem com os responsáveis do provedor.
Comece pelo trabalho que precisa melhorar
Antes de escolher a ferramenta, acompanhe como os resumos são feitos hoje. Quanto tempo a equipe leva? Quais informações costumam faltar? O profissional que recebe o chamado precisa voltar à conversa original? Há diferenças entre o que o atendente registra e o que o técnico precisa saber?
Essas perguntas evitam um teste em que a única medida de sucesso seja a velocidade de geração do texto. Um resumo instantâneo que exige releitura completa e correção pode consumir mais tempo do que a execução manual.
Defina, então, uma tarefa pequena: resumir um atendimento de suporte para transferência interna. Deixe cobrança, renegociação e cancelamento fora desse primeiro recorte. Misturar situações muito diferentes dificulta identificar onde a ferramenta ajuda e onde falha.
Combine com quem recebe o chamado quais informações não podem faltar. Uma estrutura inicial pode reunir problema relatado, testes realizados, resultados registrados, pendências e próxima etapa já definida. Se não existe uma próxima etapa aprovada, o resumo deve deixar isso claro.
Veja a diferença em um exemplo fictício
Registro de origem: o assinante relata lentidão à noite. Fez um teste pelo Wi-Fi e informou resultado baixo, sem registrar o valor. Não há teste por cabo. O atendimento ainda não verificou se existe ocorrência coletiva na região. O caso será encaminhado ao suporte técnico.
Resumo inadequado: “Cliente com problema no roteador. Testes confirmaram baixa velocidade. Necessária troca do equipamento.”
O texto é curto, mas inventa um diagnóstico e uma ação. Pode levar a uma visita mal preparada ou a uma promessa que ninguém autorizou.
Resumo adequado: “Assinante relata lentidão à noite. Informa resultado baixo em teste pelo Wi-Fi, sem valor registrado. Não consta teste por cabo nem verificação de ocorrência coletiva. Encaminhamento ao suporte técnico definido no atendimento.”
Esse segundo resumo preserva a diferença entre relato, teste documentado e informação ausente. É esse tipo de fidelidade que o piloto precisa avaliar. O exemplo não representa um caso real nem um resultado medido de ferramenta.
Prepare os dados antes de abrir a ferramenta
Faça a primeira rodada com situações fictícias e procedimentos aprovados pelo provedor. Inclua casos com informações ausentes, relatos contraditórios e hipóteses posteriormente descartadas. A ferramenta precisa saber lidar com um registro incompleto sem preencher as lacunas por conta própria.
Para usar atendimentos reais, avalie antes quais dados são necessários, quem poderá acessá-los e o que o fornecedor faz com as informações recebidas. Verifique retenção, uso para treinamento, exclusão, controles de acesso e condições contratuais. A análise deve envolver o responsável pelo tratamento dos dados no provedor e, quando necessário, apoio especializado.
Trocar o nome do assinante não garante anonimização. Endereço, telefone, número de contrato e detalhes da conversa podem permitir a identificação. Senhas e credenciais não devem fazer parte do material enviado ao modelo.
Também não presuma uma dispensa de cuidados por ser um ISP pequeno. O enquadramento de agente de tratamento de pequeno porte da ANPD tem condições e exclusões próprias, inclusive relacionadas a tratamento de alto risco. [1]
Monte uma comparação que faça sentido
Separe exemplos para ajustar as instruções e outros para avaliar o resultado. Se a equipe corrigir o comando até ele acertar os mesmos casos, terá demonstrado adaptação àqueles exemplos, sem saber como a ferramenta se comporta diante de situações novas.
No conjunto de avaliação, inclua casos comuns e exceções relevantes. Crie uma referência do que deve aparecer em cada resumo antes de testar a IA. Essa referência pode admitir redações diferentes, desde que os fatos e as pendências sejam preservados.
Compare a execução manual e a assistida em casos de complexidade semelhante. Alterne a ordem entre participantes ou use conjuntos equivalentes, para reduzir a vantagem de quem já conhece a resposta. Quando possível, peça que a pessoa que avalia a qualidade não saiba qual resumo foi produzido com auxílio da ferramenta.
Registre a versão do modelo, as instruções e a base de procedimentos usada. Mudanças durante o piloto precisam ficar identificadas: juntar resultados de versões diferentes pode esconder uma piora ou atribuir uma melhora ao motivo errado.
O NIST chama atenção para a possibilidade de sistemas generativos apresentarem conteúdo incorreto com confiança, inclusive justificativas e referências falsas. Uma resposta bem escrita, portanto, precisa passar pela mesma conferência de fatos aplicada às demais. [2]
Conte o tempo até o resumo estar utilizável
Cronometre desde o início da tarefa até a aprovação do resumo. Na execução assistida, entram preparação do material, espera pela resposta, revisão, correções e eventual descarte. Se o profissional precisar refazer tudo manualmente, esse tempo também pertence à conta.
O ganho líquido é a diferença entre o tempo da execução manual comparável e o tempo total da execução assistida. Considere também a manutenção das instruções e da base, o treinamento da equipe e os custos da ferramenta ao avaliar a viabilidade do uso contínuo.
Imagine, apenas para ilustrar a conta, uma tarefa manual de quatro minutos. Se gerar, revisar e corrigir o resumo consumir três minutos, o ganho será de um minuto naquele caso. Se exigir cinco minutos, haverá perda de um minuto. Esses números são hipotéticos e não representam um indicador do setor.
Tempo liberado pode permitir que a equipe absorva mais demanda ou cuide melhor dos casos difíceis. Só deve ser chamado de economia financeira quando houver redução de gasto demonstrável. Multiplicar minutos poupados pelo custo de pessoal não prova, sozinho, que a despesa caiu.
Avalie os erros que mudam o atendimento
Não dê o mesmo peso a uma frase pouco elegante e a um teste inventado. Combine uma classificação simples antes de começar:
- Erro crítico: exposição indevida de dados, compromisso não autorizado ou informação capaz de provocar uma ação prejudicial, como inventar um diagnóstico que orientaria uma intervenção.
- Erro relevante: omissão ou distorção que obriga a equipe a reabrir o registro para entender o caso.
- Ajuste de redação: mudança de clareza ou estilo que não altera os fatos nem a condução do atendimento.
Essa classificação é uma proposta prática para o piloto e deve ser adaptada à operação. Registre tanto os erros encontrados no rascunho quanto os que escaparam da revisão. A revisão humana também precisa ser testada: alguém pode aprovar uma resposta plausível sem perceber que ela acrescentou uma informação.
O playbook do NIST recomenda acompanhar a supervisão, as intervenções humanas, os erros e as reclamações, além de documentar decisões de continuar ou interromper o uso. [3]
Mantenha a saída manual funcionando
Na primeira fase, a ferramenta não precisa de permissão para escrever no sistema de atendimento. Trabalhe com rascunhos separados, confira cada saída e só depois considere um uso assistido mais próximo da rotina.
Defina quem pode interromper o teste. Exposição indevida de dados, ação fora do escopo e erro crítico devem provocar pausa e análise. Se a fila crescer a ponto de impedir uma revisão cuidadosa, volte ao fluxo manual em vez de transformar a urgência em aprovação automática.
Quando houver falha, preserve os registros necessários à análise conforme as regras de acesso e retenção do provedor. Corrija a causa, teste novamente e documente a decisão de retomar.
Antes de aplicar o piloto à operação real, confira as obrigações de atendimento que alcançam a sua prestadora. O RGC da Anatel prevê regras específicas de aplicação às prestadoras de pequeno porte no art. 90; seu Manual Operacional também diferencia determinações vinculantes e recomendações. Um checklist genérico de chatbot não substitui essa verificação. [4][5]
Decida com critérios definidos antes do teste
O piloto deve terminar com uma escolha: ampliar a tarefa, corrigir e repetir ou encerrar o uso. Registre antecipadamente o ganho mínimo que justificaria continuar, a qualidade exigida e as situações que obrigam a parar. Defina também o volume de casos e o período de observação necessários para a sua rotina.
Para este primeiro uso, uma aprovação razoável exige resumos com qualidade pelo menos equivalente à referência, ganho líquido que justifique o custo e supervisão viável. Um erro crítico exige análise e correção antes de qualquer ampliação. Não encontrar esse erro em uma amostra pequena não significa que o risco deixou de existir.
Observe também quem recebe os chamados. Se o atendente termina mais rápido, mas o suporte perde tempo reconstruindo o caso, o trabalho apenas mudou de lugar. Esse efeito deve entrar na avaliação.
Se faltarem casos suficientes ou os resultados variarem muito, registre a conclusão como inconclusiva. Um piloto de resumo interno, por si só, também não demonstra aumento de satisfação, redução de cancelamentos ou melhoria na resolução dos problemas dos assinantes.
Checklist antes de começar
[ ] Escolhemos uma única tarefa e definimos quem recebe sua entrega.
[ ] Temos procedimento de referência e exemplos separados para ajuste e avaliação.
[ ] Os dados e o ambiente de uso foram avaliados pelos responsáveis.
[ ] A equipe sabe distinguir erro crítico, erro relevante e ajuste de redação.
[ ] A medição inclui preparação, revisão, correção e retrabalho.
[ ] Há responsável pela pausa e um fluxo manual disponível.
[ ] Os critérios de continuar, repetir ou encerrar estão registrados.
Ficha curta de avaliação por caso
Identificação não pessoal do caso:
Tipo e complexidade:
Versão do modelo e das instruções:
Tempo total manual ou assistido, conforme o grupo:
Erros críticos / relevantes / ajustes de redação:
Informação inventada ou omitida:
Resumo aprovado, corrigido ou descartado:
Retrabalho percebido por quem recebeu o chamado:
Responsável pela revisão:
Primeiro passo para amanhã
Peça a um atendente e a alguém do suporte técnico que construam, juntos, alguns exemplos fictícios de passagem de chamado. Definam o que cada resumo precisa preservar. Antes de buscar integração com qualquer sistema, teste se a ferramenta consegue entregar isso e quanto trabalho dá conferir.
O resultado dessa experiência já ajuda a decidir. Pode revelar uma tarefa adequada para IA, uma base de procedimentos que precisa melhorar ou uma revisão que custa mais do que o benefício. Cada uma dessas respostas evita ampliar um processo sem entender como ele funciona.
