Contexto, não chatbot
A NIA consulta o equipamento, o estado, o pagamento e os alertas da cliente antes de responder. Quando a Maria diz que a luz não acendeu, encontra o alerta das 08:15 e diz que a causa não está confirmada.
Não pomos IA no projeto para dizer que usamos IA. Usamos onde resolve um problema da operação: entender o contexto da cliente, atender, organizar problemas técnicos, apoiar a manutenção e chegar por texto e voz.
A NIA consulta o equipamento, o estado, o pagamento e os alertas da cliente antes de responder. Quando a Maria diz que a luz não acendeu, encontra o alerta das 08:15 e diz que a causa não está confirmada.
Perguntas simples: funcionou ontem? quando começou? há alerta? Orienta só verificações visíveis. Cheiro de queimado, faísca ou cabo solto: para e chama um técnico. A IA não substitui o eletricista.
Ao abrir um pedido, a NIA transforma a conversa em oito linhas em português para a equipa: cliente, sistema, estado, bateria, pagamento, relato, verificações feitas e o que é necessário. O técnico chega informado.
No painel, a leitura "Inteligência NumIA" resume sistemas em atenção, pedidos já resumidos e baterias baixas. Sai do estado da demonstração, não de clientes reais.
A mesma NIA por voz, em português, crioulo e francês, com o reconhecimento do navegador. É a base do que queremos levar para chamadas com a Orange.
A cliente descreve o que tem; a NIA lê e aponta o que costuma faltar nesse tipo de negócio. A conta é feita por fórmula, com margem de projeto, e a equipa recebe o kit estimado. Depois, se o consumo passar do contratado, a NIA avisa a cliente e abre revisão de contrato.
Com sistemas reais e histórico, a IA poderá apontar quedas de desempenho, baterias fora do padrão e regiões com mais manutenção. Hoje é conceito, não resultado.
Peça "Minha luz não funciona" e depois "Chamar técnico". O resumo para a equipa aparece no chat e em /admin.
"Minha luz não funciona."
Cliente: Maria Gomes, Bissau Sistema: NUMIA-GB-0012 (NumIA Casa) Estado: ATENÇÃO, alerta 08:15, causa não confirmada Bateria: 38% (demonstrativo) Pagamento: em dia Relato da cliente: a luz não acendeu ontem Verificações feitas: indicadores visíveis, sem abrir o equipamento Necessário: diagnóstico no local. Prioridade média.
Já se viu em Bissau: dias de chuva, baterias vazias, torres sem rede. A resposta começa no dimensionamento e no material, não no dia da chuva. E quando chove, o sistema sabe o que fazer.
Ver a previsão de sol na área da clienteCada alerta passa por quatro etapas com responsáveis diferentes. O modelo de linguagem só entra na terceira, com o resultado das regras, e a última é sempre de uma pessoa.
Exemplo real da demonstração: a regra guarda "carga base aumentou ~80 W durante períodos prolongados"; só depois a NIA acrescenta "possível frigorífico ou arca, a confirmar". Em /admin o ticket mostra as duas linhas separadas.
Poucas famílias em Bissau têm internet em casa. Por isso os dados nunca dependem da ligação da cliente: o controlador do sistema leva a sua própria via, e o aviso volta por SMS, chamada ou USSD.
Não há parceria assinada. Há fluxos preparados, marcados como DEMO, prontos para ligar com credenciamento.
Perguntas, pagamentos, falhas, manutenções e dados repetem-se. Sem automação, mais clientes exige mais equipa na mesma proporção. Com IA, parte da operação organiza-se sozinha e as pessoas ficam para o que exige presença.
Funcional.
Interessados reais gravados; nada inventado no painel.
Modelo externo (DeepSeek) sobre contexto DEMO; sem rede cai para o cenário demonstrativo.
Gerado pela NIA a partir da conversa, sempre em português.
Cálculo por fórmula com margem; a NIA lê a descrição com o modelo. Constantes a validar pelo técnico.
Regra dos 7 dias sobre telemetria simulada; SMS e revisão de contrato.
Previsão real de 3 dias (Open-Meteo, Bissau); projeção da bateria e aviso na véspera. O corte do circuito de conforto depende do controlador instalado.
Conectividade móvel empresarial/M2M a validar com a Orange; o controlador guarda 30 dias para sincronizar na visita.
Reconhecimento e síntese do navegador, com fallback guiado.
Dados fictícios, fluxo completo navegável.
Quatro etapas transparentes, sem endpoint inventado.
Simuladores para telefones básicos (*245#).
Proposta de integração.
Próxima fase, com os primeiros sistemas instalados.
Futura, dependente de dados reais.
Hoje mostramos um MVP. O próximo passo é testá-lo com clientes reais, equipamentos reais e um parceiro de telecomunicações.