Agente de IA para assistência técnica de eletrodomésticos

Um agente de IA para assistência técnica de eletrodomésticos é mais útil quando consegue ler o que os técnicos já registram: códigos de diagnóstico, sintomas, testes, peças instaladas e o resultado de cada visita. O primeiro passo prático é tornar esse registro consistente agora, para que um agente mais capaz, no futuro, possa sugerir os próximos passos prováveis e sinalizar peças já tentadas, enquanto um técnico confirma cada decisão de reparo.

Principais pontos

• Registre códigos de diagnóstico, sintomas e histórico de peças em um formato único e consistente antes que qualquer agente toque no fluxo de trabalho.
• Trate o agente como uma camada de sugestão que ranqueia causas prováveis e redige mensagens, e não como quem decide o reparo.
• Mantenha pedidos de peças acima de um valor combinado, reembolsos e decisões de garantia atrás de aprovação humana explícita.
• Escolha um fluxo de reparo e uma medida de sucesso observável, e revise tudo mensalmente com o responsável pela operação.

Por que o registro do reparo importa mais que o modelo

A maioria das assistências técnicas de eletrodomésticos já tem o conhecimento de que um agente precisaria. Ele está nas anotações dos técnicos, nas fotos enviadas pelos clientes, nos recibos de peças, nas cartas de garantia e na memória de quem atende o telefone. Um agente mais capaz só é útil na medida em que consegue ler o registro. Se o registro diz que apareceu um código de falha, qual teste foi feito, qual peça foi instalada e se a falha voltou, o agente pode raciocinar a partir de fatos. Se o registro diz apenas 'consertado, provavelmente a placa', o agente só consegue adivinhar, e uma adivinhação confiante construída sobre dados fracos é pior do que nenhuma sugestão.

A recuperação de informação é o mecanismo que conecta os dois lados. Em vez de depender apenas do treinamento geral do modelo, o sistema consulta visitas anteriores para a mesma marca, o mesmo modelo e o mesmo sintoma, e responde com esses registros à vista. A orientação de arquitetura do Google Cloud descreve esse padrão para geração aumentada por recuperação (RAG), e a mesma lógica vale para o histórico de reparos: uma sugestão só é tão confiável quanto as anotações de visita que ela cita. Uma boa recuperação também significa que o agente deve mostrar qual visita sustenta cada sugestão, para que o técnico possa conferir em segundos.

O que registrar em cada visita

Registre estes campos para cada visita, na mesma ordem sempre:

• Tipo do aparelho, marca, modelo e número de série, lidos na plaqueta de identificação e não de memória.
• A descrição do sintoma pelo próprio cliente, com as palavras dele, antes de qualquer diagnóstico.
• Códigos de erro ou de diagnóstico exatamente como exibidos, inclusive os que o técnico acredita não serem relevantes.
• Testes realizados e as leituras ou observações de cada teste.
• Peças substituídas ou reparadas, com referência da peça, fornecedor e indicação se a peça era nova, usada ou recondicionada.
• Situação da garantia ou do contrato de assistência no momento da visita.
• A conclusão do técnico, marcada claramente como conclusão e não como fato.
• O resultado, acrescentado depois, quando o cliente confirma se o reparo se manteve.

O último campo é o que a maioria das empresas deixa de lado, e é justamente ele que torna o histórico útil para aprender. A mesma disciplina vale em outros serviços. Agentes de IA para concessionárias de veículos: leads e oficina mostra como registros de peças e orçamentos geram problemas parecidos quando são mantidos de forma informal.

Um plano passo a passo para começar a registrar agora

Comece pequeno, com as categorias de aparelhos que mais geram retrabalho nos seus próprios registros.

• Escolha uma ou duas categorias, como máquinas de lavar ou geladeiras, nas quais as mesmas falhas se repetem.
• Substitua as anotações em texto livre pelos campos acima, usando listas de seleção para códigos e peças quando o seu sistema permitir.
• Exija o código exato, e não uma paráfrase, porque qualquer correspondência futura dependerá dele.
• Vincule cada peça à visita em que foi instalada, para que o histórico de assistência de cada unidade seja lido em ordem.
• Torne o campo de resultado parte do fechamento de cada serviço e de toda revisão de retorno de cliente.
• Toda semana, peça a um técnico líder que revise uma amostra dos registros, procurando lacunas e corrigindo-as.
• Exporte o histórico limpo de uma categoria e teste se uma pessoa consegue responder a uma pergunta comum a partir dele em poucos minutos.

Esse último teste é o mais útil. Se uma pessoa não encontra a resposta no registro, um agente também não vai encontrar, e o problema está no registro, não no modelo.

Onde o agente sugere e onde ele para

Defina o limite antes de configurar qualquer coisa. Uma divisão viável tem esta forma:

• Sugerir: causas prováveis ranqueadas com base em códigos, sintomas e resultados anteriores correspondentes, com as visitas de apoio citadas.
• Preparar: uma lista de peças para o técnico revisar, incluindo a situação de estoque quando o sistema de inventário estiver conectado.
• Redigir: atualizações para o cliente, confirmações de agendamento e perguntas de acompanhamento, que um membro da equipe envia.
• Sinalizar: defeitos repetidos na mesma unidade, peças instaladas que não resolveram o sintoma e registros sem o campo de resultado.
• Escalar: qualquer caso que envolva gás, segurança elétrica, reclamações de danos por água ou um cliente que conteste um diagnóstico.
• Nunca decidir sozinho: aprovação final de reparo, negativas de garantia, reembolsos e qualquer mudança que afete a operação segura do aparelho.

A linha entre sugerir e decidir é o que mais importa. Uma sugestão é barata de errar, porque um técnico a revisa antes que qualquer coisa aconteça. Uma decisão que gasta dinheiro, nega uma reclamação ou encerra um serviço sem inspeção é diferente, e deve permanecer com uma pessoa até que o registro tenha conquistado mais confiança por meio de resultados medidos.

Cenário ilustrativo: um defeito recorrente em uma máquina de lavar

Este cenário é ilustrativo e não descreve um cliente real. Uma máquina de lavar volta poucas semanas depois de uma visita com o mesmo erro de drenagem. O técnico anterior substituiu a bomba de drenagem e escreveu que a unidade estava consertada. O registro não mostra nenhum teste da mangueira de drenagem ou do filtro, e o campo de resultado nunca foi preenchido.

O agente lê o histórico de visitas daquele número de série e do mesmo código em modelos semelhantes. Ele sinaliza a lacuna, sugere verificar a mangueira e o filtro antes de uma segunda bomba e lista as duas peças com a situação de estoque. Redige uma mensagem ao cliente sobre a janela de atendimento e pede a um membro da equipe que verifique se a visita anterior está coberta pela garantia. O técnico decide no local, registra a constatação e completa o campo de resultado do serviço anterior. A próxima pessoa que abrir essa unidade verá a sequência completa.

O valor aqui não está em o agente saber mais que o técnico. Está em o registro anterior ser incompleto, e o agente tornar essa lacuna visível no momento em que isso importava.

Permissões, dados de clientes e anotações não confiáveis

Um agente que lê registros de visitas deve ter apenas o acesso que sua função exige. Dê a ele leitura do histórico relevante, escrita apenas em rascunhos e sinalizações, e nenhuma capacidade de fazer pedidos de peças acima de um limite combinado ou de alterar a situação de garantia. O acesso deve passar por credenciais com escopo definido, e não por logins compartilhados, e deve ser revisado periodicamente. A orientação de autorização da OWASP descreve esse princípio de limitar cada ator ao que sua tarefa exige.

As anotações de clientes também são um risco de entrada. Uma nota digitada por um cliente ou por um técnico pode conter um texto que parece uma instrução para o agente. Trate todo texto livre como dado a ser lido, e não como comando a ser seguido, e mantenha os limites da função na configuração do sistema, e não nas anotações. A folha de referência da OWASP sobre prevenção de injeção de prompt cobre esse risco com mais detalhes.

Quando o agente solicitar um pedido de peça, a solicitação deve ser segura para repetir. APIs de pagamento e comércio costumam documentar chaves de idempotência por esse motivo, para que uma solicitação repetida não gere dois pedidos. Dados pessoais exigem regras próprias: defina por quanto tempo os registros de visitas são guardados, quem pode ver os dados de contato dos clientes e como os pedidos de exclusão são tratados. No Brasil, a Autoridade Nacional de Proteção de Dados (ANPD) publica orientações que as empresas devem ler antes de armazenar dados de clientes em novos sistemas.

Como medir se o agente está ajudando

Meça o fluxo de trabalho, não o modelo. Para cada sugestão, registre o que o agente propôs, quais registros citou, se o técnico aceitou e qual foi o resultado final. Conceitos de rastreamento do OpenTelemetry, como acompanhar uma única solicitação por cada etapa que ela toca, permitem ver onde uma sugestão deu errado.

Medidas úteis para uma assistência técnica incluem retornos para o mesmo defeito, peças instaladas que não resolveram o sintoma e o tempo entre a ligação do cliente e o agendamento da visita. Acompanhe cada uma por categoria de aparelho, para que um bom resultado em uma área não esconda um problema em outra. Mantenha um conjunto fixo de visitas passadas com resultados conhecidos e refaça os testes sempre que o prompt, as ferramentas ou o formato do registro mudarem. O guia de avaliações da OpenAI descreve esse tipo de teste repetível, e a mesma abordagem funciona para o fluxo de reparos. Para operações com muita manutenção e problemas semelhantes de histórico, IA para gestão de frotas: manutenção, motoristas e compliance é uma comparação útil.

O custo também merece atenção. Meça o custo do agente por visita concluída, e não por mensagem, para que um período de muita demanda não pareça progresso. A orientação da FinOps Foundation sobre economia unitária descreve esse tipo de medida em termos gerais.

Como a Be Human trabalha nisso

A Be Human projeta e opera esse tipo de agente como serviço gerenciado. O trabalho começa com uma função útil, a memória e as ferramentas de que ela precisa, os limites de aprovação e um critério de sucesso observável. Para uma assistência técnica, isso costuma ser um único fluxo, como a revisão de defeitos recorrentes, com leitura do histórico de visitas e escrita apenas em rascunhos e sinalizações. A operação gerenciada inclui depois monitoramento, avaliações recorrentes com visitas passadas, revisões de permissões, manutenção das integrações e resposta a incidentes quando um formato de registro muda ou uma ferramenta conectada falha. As melhorias são feitas em etapas controladas, e o responsável pela operação aprova cada mudança. O serviço é entregue remotamente, em português e em inglês.

Se você não tem certeza de qual tarefa de reparo vale a pena entregar primeiro a um agente, o diagnóstico gratuito de IA da Be Human pode ajudar a identificá-la.

Perguntas frequentes

Precisamos substituir nosso software de gestão de serviços antes que um agente possa ajudar? Não. Muitas empresas começam com os registros que já têm, acrescentando uma estrutura consistente às novas visitas e exportando um histórico limpo de uma categoria de aparelho. Trocar de software é uma decisão separada, que deve seguir o fluxo de trabalho e não vir antes dele. A estrutura que você criar agora também tornará qualquer migração futura mais fácil.

Um agente consegue diagnosticar sozinho um defeito de aparelho? Não deveria. O agente pode ranquear causas prováveis a partir de códigos correspondentes e resultados anteriores, e pode mostrar os registros por trás de cada sugestão. Um técnico ainda inspeciona a unidade, faz os testes que importam e decide o reparo, porque o estado físico do aparelho e a segurança do conserto estão além do que o registro consegue mostrar.

A que um agente não deveria ter acesso em uma assistência técnica? Evite dar a ele a capacidade de fazer pedidos grandes de peças sem aprovação, alterar a situação de garantia, emitir reembolsos ou encerrar serviços sem um resultado registrado. Limite-o à leitura do histórico relevante e à escrita de rascunhos e sinalizações. Revise essas permissões periodicamente e remova qualquer acesso que o fluxo de trabalho não precise mais.

Como saber se vale a pena manter o agente? Compare as sugestões dele com o que os técnicos fizeram e com o que aconteceu depois, usando um conjunto fixo de visitas passadas com resultados conhecidos. Observe, por categoria de aparelho, os retornos para o mesmo defeito, as peças que não resolveram o sintoma e o custo por visita concluída. Se as medidas não melhorarem após um período definido, reduza a função do agente ou interrompa o projeto, e mantenha os registros mais limpos em qualquer caso.

Orientação editorial Be Human. Exemplos são ilustrativos, salvo atribuição explícita. Fontes oferecem contexto; a implementação depende do seu processo.