IA para assistência técnica de celulares: entrada e avisos de retirada

Um agente de IA para assistência técnica de celulares pode cuidar do trabalho repetitivo do balcão: registrar cada aparelho na entrada, vincular os pedidos de peças às ordens abertas e avisar o cliente quando o reparo está pronto para retirada. Ele só funciona bem depois que a loja tem um checklist de entrada rigoroso, uma regra clara sobre quais dados do cliente o agente pode acessar e um registro de ordem por onde passa toda mudança de status. A automação agrega valor quando essas bases estão firmes, e falha em silêncio quando não estão.

Principais pontos

• Comece pela entrada. Todas as etapas seguintes dependem de um registro do aparelho completo e consistente.
• Dê ao agente acesso de leitura ao status das ordens e das peças primeiro, e permita que ele escreva apenas anotações e rascunhos até que o registro se prove confiável.
• Limite os dados do cliente ao que o reparo exige. Senhas de bloqueio e históricos pessoais completos não devem fazer parte da memória do agente.
• Envie avisos de retirada somente a partir de um status de ordem definido pela equipe, e registre cada envio para que nada seja disparado duas vezes.
• Revise os erros do agente toda semana na primeira fase da implantação, antes de ampliar o papel dele.

O que o balcão produz e onde a informação se perde

Uma ordem de reparo em assistência técnica passa por uma sequência previsível: entrada do aparelho, diagnóstico, aprovação do orçamento, pedido de peça, conserto, controle de qualidade, retirada e encerramento. A maior parte do tempo perdido acontece entre essas etapas. Uma peça chega e ninguém a vincula à ordem certa. Um diagnóstico fica escrito num papel que nunca chega ao sistema. O cliente liga para perguntar se o celular já está pronto, e a resposta honesta é que alguém precisa ir verificar, o que tira a atenção de quem está no balcão com outro cliente.

São essas lacunas que um agente deve resolver. O primeiro papel útil é estreito: um agente de atendimento e status que lê as ordens abertas, responde perguntas de status a partir do registro, redige mensagens de retirada para aprovação da equipe e sinaliza ordens em que o registro se contradiz. Lojas com um ritmo parecido de peças e retiradas, como as sapatarias, enfrentam o mesmo tipo de problema no balcão. O agente não diagnostica aparelhos, não define preços e não promete datas. Essas decisões continuam com os técnicos e com o dono.

Checklist de entrada a concluir antes de qualquer automação

A entrada é onde começa a maior parte dos erros seguintes, por isso o checklist deve estar fixo antes de qualquer ferramenta tocar nele. A equipe deve conseguir preenchê-lo em poucos minutos no balcão, e cada campo deve ter um significado único e definido.

• Modelo do aparelho, como aparece nas configurações ou na caixa, mais o identificador que a loja usa para rastreamento, registrado no balcão e não reconstruído depois.
• Condição na chegada: trincas, indicadores de contato com líquido, peças faltando, como bandeja de chip ou capinha, e danos visíveis. Fotos são tiradas somente se o cliente concordar e se a política da loja permitir.
• Defeito relatado, nas palavras do próprio cliente, mantido separado do diagnóstico do técnico.
• Escopo do reparo aprovado e se a aprovação foi dada por escrito, por mensagem ou presencialmente.
• Prazo prometido para conclusão e o que acontece com o cliente se esse prazo mudar.
• Forma preferida de contato e consentimento para receber mensagens de status.
• Nome ou iniciais do funcionário que recebeu o aparelho.
• Uma decisão deliberada sobre senhas: a loja declara se elas são pedidas e, se forem, onde ficam guardadas e quem pode vê-las. A maioria das lojas deve mantê-las fora de qualquer memória de agente.

Grave o checklist no modelo que o seu sistema usa e depois confira dez ou quinze ordens recentes contra ele. As lacunas que aparecerem são as primeiras regras que o agente vai precisar.

Status de peças precisa de uma única fonte de verdade

O status das peças é onde as ordens mais costumam dar errado. Uma tela pode ser pedida de um fornecedor, recomprada de outro e recebida num dia em que ninguém atualiza a ordem. Um agente que lê três caixas de entrada e uma planilha vai dar três respostas diferentes para a mesma pergunta.

Escolha um único lugar em que cada peça esteja vinculada a uma linha da ordem. Defina um conjunto pequeno de status, como pedido, em trânsito, recebida, instalada e devolvida, e exija que a equipe altere o valor quando a situação física mudar. Se as confirmações dos fornecedores chegarem por e-mail, o agente pode lê-las e propor uma mudança de status, mas a mudança deve aparecer como sugestão até que a equipe confirme. Uma divergência entre o registro do fornecedor e a ordem é um alerta para revisão, não um fato em que o agente deva agir.

Cenário ilustrativo: uma loja recebe um celular para troca de tela. A peça é pedida numa segunda-feira e marcada como em trânsito no dia seguinte. Na quarta, um e-mail do fornecedor informa que a peça foi substituída por outra revisão. O agente não avisa o cliente sobre a data de retirada. Ele sinaliza a ordem para o técnico, que confirma a compatibilidade antes de qualquer nova data ser dada.

Avisos de retirada devem sair uma vez, e somente quando o aparelho estiver pronto

O aviso de retirada é a ação mais visível do agente e a mais prejudicial quando está errada. Uma mensagem dizendo que o celular está pronto enquanto ele ainda aguarda o controle de qualidade gera uma viagem desperdiçada e uma reclamação. Uma mensagem duplicada causa confusão sobre se algo mudou.

Use uma regra que a equipe possa conferir olhando a ordem. Um aviso só fica elegível quando a equipe define o status como pronto para retirada, o controle de qualidade está registrado e a situação do pagamento na ordem permite a liberação. O agente envia um aviso por ordem e por mudança de status, e registra o envio nessa ordem. Plataformas de pagamento tratam o mesmo risco com chaves de idempotência, um identificador estável que faz com que uma requisição repetida seja executada apenas uma vez. Uma loja pode aplicar a mesma lógica sem software especial, carimbando cada aviso com o identificador da ordem e a versão do status, para que uma nova tentativa ou um segundo disparo seja reconhecido como a mesma mensagem. Balcões que entregam trabalhos sob encomenda enfrentam necessidade parecida, tema tratado em o guia para joalherias.

As regras abaixo funcionam como guia de decisão para o comportamento dos avisos:

• Se o status for pronto para retirada, o controle de qualidade estiver registrado e o cliente tiver consentido em receber mensagens, o agente envia o aviso uma única vez.
• Se o status for pronto para retirada, mas o controle de qualidade estiver faltando, o agente segura o aviso e notifica o técnico.
• Se o cliente responder pedindo outro horário, o agente redige uma resposta para a equipe e não altera a ordem.
• Se a resposta pedir mudança no escopo do reparo, o agente encaminha a conversa a uma pessoa e não altera o registro.

Regras de tratamento de dados e registros de ordens

Defina as regras de dados antes de conectar o agente a qualquer coisa. Colete o mínimo que o reparo exige, mantenha os dados somente pelo tempo que a legislação local e a política da própria loja exigirem e limite quem e o que pode ler cada campo. As obrigações de dados pessoais variam de país, e no Brasil a Autoridade Nacional de Proteção de Dados publica orientações que a loja deve revisar com um consultor qualificado. No mínimo, as regras devem dizer o que é coletado, por que, quem vê, por quanto tempo fica guardado e como o cliente pede correção ou exclusão.

Trate o texto dentro de ordens e mensagens como conteúdo, nunca como instrução. Uma observação do cliente, um e-mail de fornecedor ou um post copiado de um fórum podem conter frases que parecem comandos. A injeção de prompt é um risco conhecido para agentes que leem textos não confiáveis, então o agente deve ser desenhado de modo que esse tipo de texto não consiga alterar as próprias permissões nem enviar mensagens sem uma regra que o autorize. As orientações da OWASP sobre prevenção de injeção de prompt são uma referência útil para a equipe técnica, e o NIST AI Risk Management Framework oferece uma estrutura para decidir quem responde por cada risco e como ele é medido.

Os registros de ordens são a memória de trabalho do agente sobre o trabalho da loja. Cada mudança de status deve registrar quem ou o que a fez, quando e a partir de qual fonte. As correções devem ser registradas como correções, e não como sobrescritas silenciosas, para que uma revisão posterior possa ver o que o agente propôs e o que a equipe decidiu. A memória deve guardar procedimentos da loja, ordens abertas e o checklist. Não deve guardar detalhes pessoais além do que o reparo exige.

A abordagem gerenciada da Be Human segue essa ordem. Cada projeto define um papel, a memória e as ferramentas que esse papel precisa, os limites de aprovação e um critério de sucesso que a loja consiga observar, como quantos avisos de retirada a equipe precisou corrigir em um período de revisão. Monitoramento, avaliações periódicas, manutenção das integrações e revisão de permissões continuam depois do lançamento, e as mudanças controladas são feitas uma de cada vez. A loja mantém a propriedade de seus dados, de seu sistema de ordens e de seus relacionamentos com clientes.

Uma implantação em quatro etapas que a equipe consegue revisar

Amplie o papel do agente somente depois que cada etapa mostrar registros limpos. Avance pelas etapas em ordem e não pule a revisão entre elas.

• Etapa um: limpe o checklist de entrada e confira as ordens recentes contra ele. O agente ainda não age.
• Etapa dois: conecte o acesso de leitura às ordens e ao status das peças. O agente responde perguntas internas da equipe e sinaliza contradições.
• Etapa três: permita rascunhos de mensagens de status para o cliente, cada um revisado por uma pessoa antes do envio. Acompanhe cada correção feita nos rascunhos.
• Etapa quatro: ative os avisos automáticos de retirada para as ordens que atendam às regras de elegibilidade, com revisão semanal dos envios e das retenções.

Entre as etapas, revise os erros do agente com as pessoas que trabalham no balcão. Mantenha um conjunto pequeno de ordens antigas como base de teste e rode esse conjunto de novo sempre que as instruções ou as ferramentas mudarem. Revise as permissões em um calendário fixo e comece toda nova integração em modo somente leitura. Se você quer descobrir qual é a primeira tarefa do seu balcão que vale entregar a um agente, faça o diagnóstico gratuito de IA da Be Human.

Perguntas frequentes

Um agente de IA pode substituir a equipe do balcão? Não, e ele não deve ser desenhado para isso. O agente assume a consulta e a redação de rascunhos para que a equipe dedique o tempo ao cliente que está na frente, enquanto as decisões sobre escopo do reparo, preço e datas prometidas continuam com pessoas.

Precisamos trocar o sistema de ordens antes? Não necessariamente. Muitas lojas podem começar com o sistema que já usam, desde que ele consiga exportar registros e manter um histórico de status consistente. O primeiro passo é fixar o checklist e os valores de status, porque um agente não consegue interpretar um registro que a equipe preenche de forma diferente a cada vez.

Como tratar fotos e senhas dos clientes? Colete fotos somente quando o cliente concordar e o reparo precisar delas, e guarde-as com os mesmos controles de acesso dos demais registros de ordens. Decida se as senhas são pedidas e, se forem, mantenha-as fora de qualquer memória de agente e restrinja quem pode vê-las. Escreva a decisão para que todos os funcionários sigam a mesma regra.

Quanto tempo leva para confiar nos avisos automáticos de retirada? A confiança deve vir de resultados observados, não de um calendário. Mantenha os avisos em modo de rascunho até que as revisões mostrem que as regras de elegibilidade funcionam nas ordens recentes e que as retenções são pegas antes de chegar ao cliente. Passe para o envio automático somente quando as pessoas que trabalham no balcão concordarem que o registro é confiável o bastante para que o agente aja sobre ele.

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