Chat com dados: como perguntar ao ERP e receber resposta útil

Foi numa reunião de resultado, terça de manhã. Eu abri o chat com dados, digitei "como estão as vendas", peguei o número que apareceu e levei para a mesa com a maior segurança do mundo. O comercial olhou e disse que não batia. Ele tinha razão. O sistema respondeu direitinho — só que a uma pergunta que eu não tinha feito, porque não disse período, não disse métrica e não disse agrupamento.

No começo a gente escrevia as perguntas como escreve para um colega que já conhece o contexto. E o contexto é justamente o que falta. Demorei pra entender que a máquina não adivinha o que eu chamo de "vendas". Pode ser valor faturado. Pode ser pedido emitido. Pode ser dinheiro que entrou na conta. Três números diferentes, os três corretos, e nenhum deles era o que eu queria naquele dia.

Vou te contar o que mudei no jeito de perguntar, o que o recurso faz por baixo e onde ele trava de propósito. Quando a pergunta vira rotina, o destino dela é o Reports IDE — e eu explico esse caminho mais adiante.

O que o chat com dados realmente faz

Ele guarda conversas e sessões de análise, com histórico, favoritos e arquivamento. Parece detalhe. Não é. Análise quase nunca termina na primeira pergunta: você pergunta, estranha o número, muda o recorte, pergunta de novo. Ter esse encadeamento salvo é o que separa uma consulta solta de uma investigação que outra pessoa consegue refazer depois.

• Perguntas em português comum sobre os dados reais da sua empresa, sem exportar planilha antes.
• Dicionário montado a partir do schema real do banco, com cache: ele conhece as tabelas que existem de fato.
• Respostas em texto, KPIs, tabelas e gráficos, conforme o tipo de resultado.
• Sugestões de perguntas, barra lateral e histórico completo da conversa.
• Exportação de um resultado só ou da conversa inteira em TXT, CSV, SQL, HTML e PDF.
• Geração e abertura de um projeto no Reports IDE a partir da análise que ficou boa.

Toda pergunta boa responde a quatro coisas

A regra que eu uso hoje cabe numa linha: o quê, de quem, quando e agrupado como. Se faltar um desses quatro, o sistema assume um padrão razoável. O problema é que o padrão razoável dele pode não ser o seu. Escrever a pergunta inteira custa dez segundos. A confusão que ela evita custa meia hora de reunião.

1. Escreva a decisão, não o dado"Quais clientes compraram menos no último trimestre" leva a uma decisão. "Listar vendas" leva a um despejo de linhas que ninguém vai ler.
2. Diga o período com dataEntre 01/03 e 31/03. Sem intervalo explícito, qualquer resposta vira discutível e a comparação com o mês anterior fica impossível.
3. Nomeie a métricaValor, quantidade, ticket médio, contagem. Métrica implícita é a maior fonte de briga entre duas áreas que juram estar certas.
4. Leia com desconfiançaAntes de mostrar para alguém, confira o total contra um relatório tradicional que você já conhece. Essa conferência leva dois minutos.
5. Refine e guardeAjuste o recorte na mesma conversa, favorite a versão que ficou boa e exporte ou gere o projeto de relatório a partir dela.

Perguntas que eu já escrevi errado

Essa tabela saiu do meu próprio histórico. Todas as da coluna da esquerda eu digitei, achando que estavam claras.

Da conversa para o relatório publicado

Análise que fica presa dentro de uma conversa vira retrabalho no mês seguinte. Já vi isso dar errado de um jeito bobo: o recorte era ótimo, só que só existia no histórico de uma pessoa, e ela saiu de férias justo na semana do fechamento. Quando a pergunta se repete, gere o projeto no Reports IDE e publique internamente. O critério de decisão está em quando usar cada ferramenta.

Para uso pontual, exportar resolve. Você escolhe o formato conforme o destino: CSV quando alguém vai continuar o trabalho em planilha, PDF quando o número vai anexado a uma ata, SQL quando a área técnica quer revisar a consulta gerada. As diferenças estão em formatos de exportação e seus usos.

O que ele não faz, nem se você insistir

A execução é estritamente somente leitura, limitada a SELECT, com escopo obrigatório por empresa. Mutações, múltiplas instruções na mesma execução, construções inseguras e acesso a dados fora da empresa da sessão ficam bloqueados. O SQL gerado não concede capacidade de escrita no banco. Traduzindo: o pior caso é um número errado. E número errado a gente detecta conferindo.

O combinado antes de soltar para o time

• Definir quem abre o chat e quem só consome relatório já publicado.
• Validar o isolamento por empresa em ambiente com mais de uma empresa ativa.
• Escrever as métricas oficiais, para que a mesma palavra signifique a mesma conta em todas as áreas.
• Combinar que exportação com dado pessoal segue a política interna de tratamento.
• Revisar de tempos em tempos as conversas favoritadas e aposentar recorte que envelheceu.

Isso não é burocracia. É o que impede que dois diretores cheguem na mesma reunião com números diferentes, que foi exatamente o que aconteceu comigo. O ponto de partida está em governança de dados em relatórios e o detalhe técnico das travas em text-to-SQL somente leitura.

A resposta nunca é mais precisa que a pergunta. Aprendi isso do jeito difícil.

Equipe Webajato

Por onde eu começaria

Pegue três perguntas que a diretoria repete todo mês e reescreva cada uma com período, métrica e agrupamento explícitos. Rode. Confira contra o relatório tradicional equivalente. Quando bater, publique o recorte e avise quem precisa ler. Se você tem CRM ativo, o mesmo raciocínio vale para os indicadores de atendimento, que alimentam a visão consolidada.