O registro da conversa é evidência, não fonte de verdade
Ligações, chats, emails, redes sociais, lojas e tickets revelam intenção e frustração, mas contêm erros de transcrição, explicações incompletas, scripts repetidos, dados pessoais e conclusões anteriores aos fatos atuais. Use-os para reconstruir a interação, não para substituir conta, billing, pedidos, rede e incidentes.
A IA precisa de snapshot temporal: cliente autenticado, produtos, plano, saldo, faturas, uso, device, pedidos, visitas, mudanças, cobertura, incidentes, tickets, contatos e promessas. Cada fato mantém fonte, horário e confiança.
Evidência da conversaTranscrição, canal, idioma, intenção, entidades, sentimento, compromissos, incerteza e redação.
Cliente e comercialIdentidade, produtos, plano, conta, uso, pagamentos, elegibilidade, consentimento e pedidos.
Serviço e redeInventário, device, ativação, qualidade, alarmes, outage, topologia, diagnóstico, campo e SLA.
Autoridade operacionalTools permitidas, limites, aprovações, compensação, owner, escalonamento, auditoria e rollback.
Normalize interações em uma timeline imutável
Ingerir mídia e metadados separadamente. Preserve gravação conforme retenção, gere transcrição com speakers, detecte idioma, remova valores sensíveis e registre versões e confiança. Correção humana cria revisão, não sobrescreve o original.
Una canais por conversation e case ID. Registre fala, fato consultado, recomendação, ação aprovada e promessa. O próximo atendente não deve pedir informação já verificada.
O pipeline deve otimizar resolução verificada
Pipeline de resolução do contact center01 CapturaColete a interaçãoVoz, chat, email, app, loja, ticket, auth, consentimento, canal e policy de gravação.
02 EntendimentoTranscreva e classifiqueSpeakers, intenção, entidades, idioma, urgência, promessas, churn e incerteza.
03 ContextoMonte fatos atuaisCliente, billing, produtos, inventário, rede, incidentes, pedidos, diagnósticos e contatos.
04 DiagnósticoTeste causas concorrentesChecks determinísticos e hipóteses com evidência; separe sintoma, causa, policy e elegibilidade.
05 DecisãoSelecione uma resolução permitidaResposta, diagnóstico, configuração, ticket, visita, crédito, plano, escalonamento ou sem ação segura.
06 ExecuçãoChame tools estreitasAutentique, autorize, preview, aprove, use idempotência, before/after e trate falha parcial.
07 VerificaçãoConfirme o outcomeLeia o estado, teste serviço, confirme entendimento, monitore e registre pendências.
08 AprendizadoFeche ou transfiraResumo estruturado, evidência, ações, owner, prazo, promessa, outcome e feedback.
Diagnóstico exige contexto OSS e BSS
Cobrança exige itens, descontos, impostos, pagamento, mudança e vigência. Ativação exige pedido, provisioning, inventário, SIM/eSIM, device e registro. Qualidade exige localização, tecnologia, sinal, congestionamento, outage, manutenção e equipamento do cliente.
TM Forum Open APIs criam contratos para cliente, produto, serviço, recurso, billing, trouble ticket e service problem. Não corrigem dados ruins, mas oferecem fronteira melhor que acesso direto ao banco ou screen scraping.
Tools devem ser comandos de negócio controlados
Separe reads de ações. Reads consultam fatura, status, pedido, elegibilidade ou diagnóstico. Ações criam ticket, reiniciam equipamento, reenviam configuração, marcam visita, aplicam crédito, alteram plano ou cancelam. Cada ação precisa de schema, scope, policy, limite, idempotência, aprovação, timeout e compensação.
O modelo propõe; o gateway autoriza. Ações relevantes exigem confirmação do cliente ou aprovação humana. A IA não pode inventar elegibilidade, conceder crédito fora da policy ou acessar outro assinante.
Handoff humano é estado de primeira classe
Transfira quando identidade está incompleta, fatos conflitam, pedido está fora da policy, tool falha, vulnerabilidade aparece, cliente pede pessoa ou confiança cai. Leve resumo, fatos, diagnósticos, resultados, motivo, preferência e próximo passo.
Roteie para quem é dono da resolução. Informe prazo e evite repetir autenticação ou coleta sem necessidade de policy.
Churn deve acionar recuperação do serviço
Contatos repetidos, falhas abertas, rede degradada, surpresa na conta e visitas perdidas indicam churn. A resposta correta é corrigir a causa. Oferta de retenção sem correção apenas adia cancelamento.
Versione features e avalie por segmento. Não infira atributos sensíveis nem priorize só clientes de alta receita. Registre motivo e outcome da intervenção.
Cada solicitação tem limite de automação
| Pedido | Evidência | Automação segura | Verificação | Escalar quando |
|---|
| Explicar cobrança | Conta autenticada, itens, plano, descontos, uso e datas. | Explicação vinculada às fontes e comparação histórica. | Cliente entende; item contestado vira caso. | Dados conflitam, disputa legal ou exceção. |
| Sem dados móveis | Plano, franquia, device, APN, registro, cobertura, outage e mudanças. | Diagnóstico, configuração aprovada ou ticket. | Teste de rede e confirmação. | Incidente amplo, device incerto ou repetição. |
| Banda larga fora | Inventário, CPE, sinal óptico, incidente, manutenção e visita. | Teste/restart remoto, aviso, ticket ou técnico. | CPE online e teste de qualidade. | Dano físico, instabilidade ou diagnóstico conflitante. |
| Mudar plano | Identidade, elegibilidade, preço, prazo, benefícios e consentimento. | Preview exato e execução após confirmação. | Pedido e billing atualizados. | Contrato ambíguo, bundle ou risco de cancelamento. |
| Crédito | Duração do incidente, impacto, policy, histórico e limite. | Aplicar dentro de regra e valor determinísticos. | Crédito visível com referência. | Valor excede autoridade ou evidência incompleta. |
| Cancelamento ou vulnerabilidade | Identidade, produtos, saldos, obrigações, acessibilidade e risco. | Explicar consequências e preservar escolha. | Confirmação, estado final e registros. | Coerção, luto, fraude, acessibilidade, dívida ou processo legal. |
Avalie o caso completo
Avalie transcrição por idioma, sotaque, ruído, canal e termos. Depois intenção, entidades, diagnóstico, evidência, policy, tool, argumentos, explicação, handoff e outcome. Resumo correto ainda pode gerar ação nociva.
Use casos desidentificados, cenários sintéticos, amostras de produção, simuladores de tools, judges calibrados e revisão de domínio. Segmente por produto, região, device, idioma, acessibilidade e falha. Faça red team de prompt injection em mensagens e notas.
Privacidade segue o lifecycle da interação
Gravações, transcrições, autenticação, localização, billing, diagnósticos e sentimento são sensíveis. Defina finalidade, base legal, aviso, acesso, retenção, deleção, redação e quem usa cada campo. Não transforme todo atendimento em dado permanente de treino.
Separe mídia bruta, transcrição revisada, fatos, outputs e auditoria por nível de acesso. Minimize logs e permita reconstrução sem liberar gravações a todos.
Meça resolução, não contenção
Deflection e AHT menor podem esconder contatos repetidos. Meça resolução no primeiro contato verificada por estado, repetição, reabertura, promessa cumprida, serviço restaurado, conta corrigida, visita concluída, transferência, abandono, esforço, reclamação, churn e falsa resolução.
Para IA, meça cobertura de evidência, afirmação sem suporte, sucesso de tools, violação, qualidade do handoff, latência, custo, override e divergência. Otimize custo por resolução verificada.
O que eu construiria
Eu construiria um control plane de resolução unindo eventos omnichannel, timeline, retrieval governado, adapters OSS/BSS, diagnósticos, tool gateway tipado, policy, evals, case management e monitoramento de outcome.
O workspace mostraria transcrição, fatos com fonte e idade, causas, testes, ações permitidas, promessas e owner da pendência. A automação aumentaria por tipo apenas após evidência de resolução segura.
O princípio de design
IA no atendimento vale quando fecha o ciclo: entende, busca fatos atuais, diagnostica, executa remédio autorizado, verifica e transfere com contexto quando não termina. Antes da verificação, é assistência, não resolução.