A farmácia que vende pelo WhatsApp

Não, em nenhuma hipótese. O produto é um painel de governança e um atendimento automatizado: ele lê uma imagem, casa itens com o catálogo e organiza o pedido.

Ele não avalia prescrição, não indica tratamento, não confere adequação terapêutica e não decide dispensação. Essas são responsabilidades de profissional habilitado e continuam fora do software.

Depende inteiramente da legibilidade da foto. O prompt manda o modelo devolver lista vazia quando a imagem não é legível, em vez de adivinhar — e o fluxo trata a lista vazia com uma mensagem pedindo outra foto.

Ainda assim, leitura de imagem erra. Por isso a lista lida é apresentada para conferência, com o nome exatamente como apareceu na receita ao lado do item casado no catálogo.

Ela não é gravada em disco pelo sistema: é recebida, enviada ao provedor do modelo para leitura e descartada ao fim da requisição. No histórico da conversa fica apenas a marcação de que uma imagem foi enviada. O que permanece é o pedido resultante — os medicamentos, associados ao contato e ao endereço do cliente.

Não. Não há classificação de tipo de receituário, retenção, escrituração, controle de validade da receita nem bloqueio de item. Um antimicrobiano é tratado exatamente como um analgésico comum. Se a sua operação depende disso, o produto não atende hoje — e forçar o uso seria contornar um controle, não automatizá-lo.

Sim, essa é a proposta do construtor de fluxo. Você arruma etapas dos oito tipos disponíveis, escreve os textos com variáveis, define os gatilhos e testa no simulador — que roda o mesmo motor do atendimento real. Nenhuma linha de código, e nada precisa ser publicado para valer.

Com a credencial da transportadora configurada, é uma cotação de verdade para o CEP informado. Sem ela, o sistema cai numa estimativa por faixa de CEP, sempre rotulada com a palavra “estimado” e com aviso visível no painel.

Em ambos os casos há uma simplificação assumida: o pacote enviado para cotação tem dimensões e peso fixos, então o valor não varia com o tamanho do pedido.

Por uma instância da Evolution API apontando o webhook para o backend. O sistema trata o evento de mensagem nova, ignora as mensagens enviadas pela própria loja e busca a mídia sob demanda quando o cliente manda uma foto. Trocar de número é trocar a instância — o roteiro do bot continua o mesmo.

Existem três papéis: administrador, operador e leitura. As telas de gestão de usuários e de chaves de API são exclusivas do administrador, com bloqueio no servidor. A separação entre operador e leitura, hoje, ainda é mais de rótulo do que de permissão — está listada nos limites por isso.

Num arquivo JSON dentro de um volume do contêiner, com produtos, pedidos, conversas, usuários, trilha, configuração do fluxo e chaves. Não há banco de dados. É fácil de inspecionar e de mover, e tem as limitações descritas na seção de limites — sem transação, sem expurgo e sem criptografia em repouso.

Não como está. Falta cobrança dentro do sistema, falta endurecimento de segurança, falta política de retenção e falta a revisão regulatória e do responsável técnico. O que existe hoje é uma demonstração funcional completa do fluxo — boa para decidir se o desenho serve, não para atender cliente real.