São 17h40. O comercial está numa loja de ferragens em Viseu. O cliente quer 40 unidades de uma referência e pergunta duas coisas: "Têm isso em stock?" e "A quanto ma vendeste da última vez?". As respostas existem. Estão no Sage 50, num servidor na sala do fundo do escritório, a 90 quilómetros dali.
O comercial liga para o escritório. A colega que sabe abrir aquele ecrã já saiu, ou está ao telefone com um fornecedor. "Eu vejo isso e depois digo-lhe." O cliente acena com a cabeça. Muitas vezes, esse "depois digo-lhe" é o momento em que a venda arrefece.
Isto não é falta de jeito de ninguém. É a forma como o Sage 50 foi pensado: os dados vivem num servidor ou num posto do escritório, e o acesso é local.
Os dados estão onde o ERP foi instalado
Num fórum oficial da Sage, um utilizador escreveu: "Preciso de integrar o Sage50 Cloud com outro sistema. Existe alguma API que me permita obter a lista de clientes, fornecedores, moradas, contactos… e artigos?" A resposta foi uma "API local" publicada no GitHub ou uma WebAPI comercial de terceiros. Em resumo, chegar aos dados por fora exige trabalho. O "Cloud" do nome não quer dizer que os dados estejam acessíveis a partir de qualquer sítio.
O Sage 50 não é caso único. O PHC CS corre num SQL Server instalado na empresa e é atualizado por versões. O Primavera V10 assenta em .NET e SQL Server. Muitas PME portuguesas têm o ERP onde sempre o tiveram: na caixa preta com a luz verde, debaixo de uma secretária.
Quando toda a gente trabalhava no escritório, isto não incomodava ninguém. Hoje há pelo menos três pessoas que precisam desses números e quase nunca estão sentadas em frente ao monitor:
- o comercial, que está no cliente;
- o técnico, que está numa obra;
- o dono, que está numa reunião, num fornecedor ou simplesmente em casa ao domingo à noite.
O que se faz hoje, e porque não chega
Há três soluções habituais. Funcionam todas, mas mal.
Ligar para o escritório. Depende de alguém estar livre, de saber onde procurar e de não haver engano a ditar o número. É também a forma mais cara de fazer uma consulta de três segundos, porque interrompe duas pessoas.
A VPN ou o acesso remoto ao posto. Resolve para quem tem um portátil e meia hora. Num telemóvel, ao balcão de um cliente, abrir o ecrã completo do ERP com os dedos é um exercício de paciência. Há também uma questão menos falada: o acesso remoto dá, por norma, o ERP inteiro, com permissão para alterar. Para saber um stock, isso é poder a mais.
O Excel que se tira à segunda-feira. Na quarta já está desatualizado. E nunca tem a coluna de que precisa.
Em nenhum dos três casos o problema é o Sage 50. O problema é a distância entre a pergunta e o sítio onde os dados estão.
A ferramenta que o comercial já tem aberta
Essa distância fecha-se com uma ferramenta que já está no bolso de toda a equipa: o WhatsApp. Mas há uma condição, e não é pequena. Não serve qualquer bot.
O WhatsApp proíbe nos seus Termos os clientes não oficiais. Muitos "bots de WhatsApp" baratos correm em bibliotecas que simulam uma sessão do WhatsApp Web, e o número que usam pode ser banido, muitas vezes sem aviso. O caminho sério é a WhatsApp Business API oficial.
Depois há a regra da Meta. A partir de 15 de janeiro de 2026, a Meta passou a restringir na Business API os assistentes de IA de propósito geral: os que conversam sobre qualquer tema e não estão presos a um processo de negócio. Na União Europeia o processo tem dado voltas. Em junho de 2026, a Comissão Europeia adotou medidas provisórias que obrigam a Meta a repor o acesso, e a Meta recorreu. Ainda não se sabe como isto acaba, e não vamos fingir que sabemos.
O que se sabe é que, em nenhuma fase desta história, esteve em causa um agente vertical: ligado aos dados de uma empresa, a responder a perguntas do negócio dessa empresa, através da API oficial. Isto vale com ou sem a proibição. É esse o espaço defensável, e não um chatbot genérico colado por cima do ERP.
E é aqui que está a lacuna. A Cegid Pulse, apresentada em agosto de 2026, leva IA ao Cegid Primavera Evolution e ao Cegid PHC Evolution/GO. Segundo o que foi divulgado publicamente, funciona dentro da aplicação e do sistema. Não há menção a WhatsApp, nem ao Sage 50, nem às versões instaladas no servidor do escritório. Para quem tem o ERP na sala do fundo, a ligação WhatsApp↔ERP continua por fazer.
O mesmo fim de tarde em Viseu, outra vez
Voltemos à loja de ferragens. Desta vez, o comercial escreve no WhatsApp, na mesma conversa onde fala com a equipa:
Comercial: Stock da referência PRF-M8-40?
Nemea: 38 unidades no armazém principal. Há uma encomenda a fornecedor de 100 unidades, sem data de entrega registada.Comercial: Última venda deste artigo à Ferragens Lopes, e a que preço?
Nemea: Fatura de 12 de agosto, 25 unidades a 0,84 € cada, sem desconto de linha.
O exemplo é ilustrativo e os números são inventados para o artigo. Mas repare no que a resposta faz e no que não faz. Diz 38, e não "cerca de 40". Avisa que a encomenda a fornecedor existe mas que não tem data, em vez de arriscar um prazo. Se o dado não estiver no ERP, a resposta é "não tenho essa informação", e não um palpite com ar seguro. É isto que quer dizer dados reais, sem inventar.
O comercial responde ao cliente: "Tenho 38 já e o resto vem de fornecedor. O preço é o da última vez." O tempo de espera foi o de escrever duas mensagens.
"Então os dados da empresa vão parar ao WhatsApp?"
É a objeção certa. Responde-se pelo desenho da integração, e não com promessas:
- Só leitura. A ligação à base de dados usa um utilizador sem permissão para escrever. Ninguém altera um preço, apaga uma fatura ou mexe num stock a partir do telemóvel.
- Viaja a resposta, e não a base de dados. O que chega ao WhatsApp é "38 unidades", e não uma cópia do Sage 50.
- Isolamento por tenant ao nível da base de dados. Os dados de uma empresa não se cruzam com os de outra.
- Auditado. Cada pergunta, cada consulta feita e cada resposta ficam registadas, com o custo por mensagem. Se alguém perguntar "quem consultou os saldos de clientes este mês?", há resposta.
- Business API oficial. O número da empresa não fica dependente de uma biblioteca que a Meta pode bloquear amanhã.
Há também uma pergunta prática a que convém responder com honestidade: como é que um servidor no escritório fica ligado sem se abrir a porta ao mundo? Depende da instalação: a versão do Sage 50, onde corre a base de dados e a rede que existe. É a primeira coisa que se analisa numa demonstração. Se a sua configuração não o permitir de forma segura, dizemos-lhe isso antes de mais nada.
Porque "horas e não semanas" depende do ERP
Ligar à base de dados é a parte fácil. A parte difícil é saber que "stock disponível" não é uma coluna, mas uma conta entre tabelas, armazéns e documentos pendentes. Quem já tentou tirar um mapa à mão de um ERP português sabe do que estamos a falar. A essa tradução entre a pergunta do dia a dia e a estrutura real do ERP chamamos camada semântica.
No PHC, a Nemea já traz essa camada pré-construída, e é isso que põe o arranque em horas. Para os restantes ERP, incluindo o Sage 50, o princípio é o mesmo. O ponto de partida concreto, ou seja, o que já vem feito e o que é preciso mapear, confirma-se caso a caso. Preferimos dizer isto agora a descobri-lo a meio do projeto.
Quem pergunta o quê
- Dono ou gestor: "Quanto faturámos este mês até hoje, comparado com o mesmo período do ano passado?" Sem esperar pelo relatório de segunda-feira.
- Comercial: "Que encomendas tem em aberto o cliente X?" ou "Qual é o saldo em dívida da Ferragens Lopes?" Antes de entrar na loja, e não depois de sair.
- Armazém: "Há a peça Y em algum armazém?" Sem ir ao posto do escritório, de luvas, a meio de uma separação.
- Técnico: "Quantas horas tenho registadas este mês?" Desde que esse dado exista no ERP. Se não existir, a resposta diz isso mesmo.
O ERP fica onde está
Não é preciso migrar o Sage 50 para a cloud, mudar de ERP ou instalar uma app nova na equipa. Os dados ficam no servidor do escritório. O que muda é que deixam de estar presos lá.
Se quiser ver isto ligado aos seus próprios números, e perceber com franqueza o que a sua instalação permite, marque uma demonstração em nemea.pt.