---
title: "De protótipo a produto: o que falta no CRM que você criou com IA para poder vendê-lo"
description: "A lista honesta entre o sistema que funciona para um cliente e o produto que você vende para trinta: multi-inquilino, contrato, auditoria, cobrança e o canal."
url: "https://wame.api.br/blog/de-prototipo-a-produto-vender-o-crm-que-voce-criou"
language: "pt-BR"
og:type: "article"
published_time: "2026-09-23"
modified_time: "2026-09-23"
author: "Raphael Serafim"
keywords: "criar crm com ia, multi-inquilino saas, vender saas, trilha de auditoria, micro saas, integrar whatsapp no crm, primeiro cliente saas"
reading_time: "11 min de leitura"
---

# De protótipo a produto: o que falta no CRM que você criou com IA para poder vendê-lo

> A lista honesta entre o sistema que funciona para um cliente e o produto que você vende para trinta: multi-inquilino, contrato, auditoria, cobrança e o canal.

Existe um momento em que o projeto muda de natureza, e ele quase nunca é percebido no dia em que acontece: o segundo cliente. Com um só, quase tudo se resolve na unha — uma variável de ambiente, uma consulta rodada à mão, um ajuste de madrugada que ninguém vê. A partir do segundo, cada uma dessas coisas vira processo, e processo que não existe em código existe no seu domingo.

Este texto é a lista do que separa as duas situações. Não é uma lista de recursos do CRM — o funil e o cadastro já estão prontos. É o que o sistema precisa ter para ser **vendido**, cobrado e mantido sem consumir você. São seis itens, e três deles são de canal.

## 1. Multi-inquilino de verdade, e não um filtro no `where`

É o mais caro e o mais urgente. A pergunta não é "dá para cadastrar mais de uma empresa?" — é "existe algum caminho no sistema pelo qual o dado de uma empresa aparece para outra?".

A diferença entre as duas perguntas é que a primeira se responde acrescentando uma coluna, e a segunda se responde garantindo que **nenhum** acesso ao banco esqueça dessa coluna. O caminho que funciona:

- **O identificador da empresa não viaja como parâmetro de função.** Se ele for parâmetro, uma chamada nova em algum canto do sistema vai esquecer de passá-lo, e esquecer não quebra nada: a consulta simplesmente devolve a base inteira. Faça-o chegar por contexto de requisição, de modo que esquecer de abrir o contexto derrube a requisição em vez de vazar dado.
- **Nenhum repositório recebe a coleção ou a tabela crua.** Ele recebe um invólucro que injeta o filtro da empresa por último em toda consulta e o crava em toda escrita. Injetar por último importa: se quem chama mandar o campo, o escopo sobrescreve.
- **Escreva um teste que lê os seus arquivos** e falha se algum repositório usar o acesso cru. O compilador não vai reclamar — o acesso cru tem os mesmos métodos que a versão segura —, e o defeito não quebra teste nenhum: ele só passa a mostrar demais. É o único erro desta lista que, em produção, pode encerrar o seu negócio.

Duas coisas passam batidas depois que o banco está escopado: **a sala de tempo real** e **a chave única**. Se a sala de eventos se chama `admins`, o administrador de uma empresa recebe notificação da conversa de outra — o escopo de banco não pega esse caminho. E toda chave única precisa incluir a empresa, com as exceções justificadas uma a uma no código, senão o segundo cliente não consegue cadastrar um setor com o nome que o primeiro usou.

## 2. LGPD e contrato, que não é papelada opcional

Você vai processar conversa de terceiro. O conteúdo é do cliente do seu cliente, e a lei tem opinião sobre isso. Quatro pontos precisam estar escritos antes da assinatura:

- **O papel de cada parte.** Em geral o seu cliente é o controlador dos dados dos clientes dele, e você é operador. Isso muda quem responde pelo quê.
- **Prazo de retenção.** Conversa guardada para sempre é passivo, não recurso. Não ter escolhido prazo nenhum também é uma escolha, só que sem ninguém responsável.
- **O que acontece no fim do contrato.** Exportação, devolução, eliminação. Se não estiver escrito, vai ser negociado no pior momento possível.
- **Subprocessadores.** O provedor de canal e o provedor de modelo de linguagem, se houver, entram nessa lista.

O detalhe de mensageria está em [API de WhatsApp e LGPD: o que a sua software house precisa garantir no contrato do cliente](/blog/whatsapp-api-lgpd-contrato-cliente) — leia antes da primeira proposta, não depois da primeira objeção. O [checklist de compliance para WhatsApp API](/blog/checklist-compliance-whatsapp-api-2026) cobre as regras da própria Meta, que são outro conjunto e igualmente contratuais.

## 3. Trilha de auditoria: quem fez o quê

Primeiro item cobrado em qualquer venda para empresa com departamento de TI, e impossível de reconstituir retroativamente. Ou você registrou, ou o passado não existe. Três decisões definem se a trilha serve para alguma coisa:

**Registre dentro do caso de uso, não num middleware.** Um middleware escreve "POST /conversations/abc123", que não é "Fulano transferiu o atendimento de Maria para o Financeiro". O significado só existe onde a ação acontece. O furo é esquecer de chamar o registro num caminho novo — e o remédio é o do item 1: um teste que lê os arquivos.

**Grave o nome do autor junto do id.** A trilha diz quem a pessoa era no momento do ato. Resolver o nome na leitura mostra o nome de hoje, e um renomeado reescreve o próprio passado.

**Nenhum segredo entra na trilha.** Numa edição, registre qual campo mudou, nunca o valor — senão a auditoria vira um segundo banco com o conteúdo de todo mundo, e agora são dois lugares para proteger.

E decida a retenção: a trilha só cresce, e não escolher prazo é escolher "para sempre" sem avisar ninguém.

## 4. Cobrança, e o teto que vem junto

Cobrar parece o item mais simples e costuma ser adiado até doer. O que ele exige do sistema, além do gateway:

- **Um teto por empresa em cada coisa que ocupa vaga** — usuários, conexões, setores. Cobrado onde o registro é criado, não num middleware: há criações fora de rota, como o cadastro inicial de uma empresa, que cria usuário e setor de uma vez.
- **Teto ausente significa ilimitado; teto zero significa "não cadastra isto".** A comparação tem que ser explícita contra "não definido". Numa comparação preguiçosa, o zero vira ilimitado — o oposto exato do que ele diz.
- **Baixar o teto abaixo do uso trava o cadastro novo e não mexe em quem já está lá.** É porta de entrada, não faxina. Não há como recuperar o que for removido.
- **O contador na tela é conveniência; a recusa é do servidor.** Se a regra só existe no front, ela não existe.

Sobre quanto cobrar, este texto não vai chutar número para você — a conta depende do seu custo, e uma parte dela é o canal, que tem preço público. O raciocínio de precificação e de recorrência está em [Ganhar dinheiro criando CRM com IA](/blog/ganhar-dinheiro-criando-crm-com-ia), que trata da montagem da oferta.

## 5. Suporte, que é um recurso do sistema e não um número de telefone

O item que mais consome fundador e o que menos aparece em roadmap. Suporte escalável não é atendimento rápido; é o sistema responder sozinho as perguntas que geram chamado. As quatro que mais geram, em mensageria:

| Chamado | O que evita |
|---|---|
| "As mensagens pararam de chegar" | Um indicador de saúde da conexão visível na tela, e um aviso quando o endereço de webhook cadastrado não bate com o da instalação |
| "Mandei e não chegou" | Status de entrega visível na bolha, com o erro escrito quando falhou |
| "Não consigo responder esse cliente" | Uma mensagem explicando a janela de 24 horas, no lugar onde ela impede, e não um botão desabilitado sem motivo |
| "Sumiu uma conversa" | Uma tela que mostre também as conversas que estão com outros atendentes |

Nenhum desses quatro é difícil. Todos são invisíveis enquanto você é o único usuário, porque você sabe o que está acontecendo. O segundo cliente não sabe, e liga.

## 6. O canal no nome do cliente, e não no seu

Este é o item que costuma ser descoberto tarde, e é específico de quem vende sistema com WhatsApp dentro.

Enquanto é um cliente, você conecta o número dele na sua conta e funciona. Com trinta, esse arranjo desmonta por quatro motivos, e cada um deles já derrubou o negócio de alguém:

1. **O custo das mensagens é do seu cliente, mas a fatura chega para você** — e agora você é banco, com inadimplência e conciliação.
2. **A qualidade do número de um afeta a reputação sob a qual todos estão.** Um cliente que dispara para lista comprada arrasta os outros.
3. **A saída é dolorosa.** Se um cliente sai, o número precisa migrar. Se o número está na sua estrutura, a saída dele vira um projeto seu.
4. **Você não consegue crescer sem provisionar.** Criar, ativar, suspender e cortar instância tem que ser chamada de API, não formulário preenchido à mão. Como isso se faz está em [Provisionar WhatsApp para 100 clientes por API](/blog/provisionar-whatsapp-multiplos-clientes-api).

Daí a decisão final desta lista, que é sobre a camada de canal: construir ou contratar.

**Construir** significa manter a integração com a plataforma da Meta, o ciclo de vida das instâncias, a fila de envio, o tratamento de erro, a reentrega de webhook e a evolução de tudo isso quando a Meta muda a regra — e ela muda. A estimativa honesta de tempo para a primeira versão, sem manutenção, está em [Quanto tempo leva integrar WhatsApp num sistema? A estimativa honesta](/blog/quanto-tempo-integrar-whatsapp-build-vs-buy).

**Contratar** significa uma API gerenciada com programa de revenda, onde cada cliente seu é uma instância no nome dele, com provisionamento por API e preço por instância que cai conforme o volume. Na WAME, o programa de marca branca tem mínimo de 20 instâncias e a faixa começa em R$ 28,00 por instância entre 20 e 99, cai para R$ 24,00 entre 100 e 299, R$ 20,00 entre 300 e 799, e acima disso é negociado. Se você vai revender canal como parte do seu produto, essa é a conta que entra no seu custo por cliente.

Não há resposta certa para todo mundo, mas há uma pergunta que resolve: a camada de canal é o seu diferencial? Se o que você vende é o CRM, o funil e o atendimento, o canal é infraestrutura — e infraestrutura mantida sozinho é custo fixo disfarçado de independência. Se o que você vende **é** o canal, construa, e construa bem.

## Onde a IA continua ajudando nisto

A leitura fácil deste artigo é "a IA fez a parte fácil e agora começa o trabalho humano". Não é bem assim: escopo por empresa, trilha de auditoria, tetos por plano e testes que leem arquivos são padrões estabelecidos, e um assistente escreve todos rápido quando você descreve a regra com precisão.

Onde ele erra é na camada de canal, e sempre pelo mesmo motivo: ele não conhece a API que você usa e preenche a lacuna com o que parece plausível — endpoints que não existem, um modelo de dados sem janela de 24 horas, um webhook tratado como se chegasse uma vez só. O conserto é barato: dê a ele o mapa da documentação em [`https://wame.api.br/llms.txt`](https://wame.api.br/llms.txt) antes de pedir qualquer coisa de canal, e a especificação OpenAPI em `https://server.wame.api.br/docs/swagger.json` quando ele precisar acertar nomes de campo.

A lista completa do que a IA resolve sozinha e do que ela não resolve está em [Como criar um CRM do zero com IA (e as três partes que ela não resolve)](/blog/criar-crm-com-ia-o-que-a-ia-nao-resolve).

## Conclusão

Entre o sistema que funciona para um cliente e o produto que se vende para trinta há seis itens: escopo por empresa que não vaza, contrato e LGPD, trilha de auditoria, cobrança com teto, suporte embutido no produto e o canal no nome de quem usa. Três são de canal, e é por isso que a decisão de construir ou contratar essa camada define o resto do cronograma.

O erro caro não é escolher errado. É adiar a escolha até o quinto cliente, quando já há dado de gente real no banco, uma fatura consolidada no seu nome e um número com reputação compartilhada entre empresas que não se conhecem. Nessa altura cada item custa o dobro, e nenhum pode ser feito com o sistema parado.

Faça a lista agora. Marque o que existe, o que falta e o que você decidiu conscientemente não fazer — essa terceira coluna é a mais importante, porque é a única que você consegue defender numa reunião.

## Perguntas frequentes

### Dá para vender para o segundo cliente sem multi-inquilino, subindo uma instalação separada?

Dá, e para dois ou três clientes é até razoável. O que quebra é a manutenção: cada correção vira um deploy por cliente, cada banco fica com um esquema ligeiramente diferente, e a primeira migração que falhar vai passar despercebida. A partir de cinco, operar instalações separadas custa mais do que teria custado o escopo por empresa desde o começo.

### Preciso de trilha de auditoria mesmo vendendo para empresa pequena?

Precisa se quiser vender para empresa grande depois, porque ela não se reconstrói retroativamente. Uma versão mínima — quem, quando, que ação, sobre qual registro — cabe numa tarde e resolve a maior parte das exigências. O que não cabe depois é o ano de operação que passou sem registro nenhum.

### Vale mesmo revender o canal em vez de o cliente contratar direto?

Depende do que você quer vender. Revender simplifica a vida do cliente e vira receita recorrente sua, mas você passa a ser o primeiro chamado quando o canal falha. O cliente contratando direto tira esse peso e tira também a margem. As duas funcionam — o que não funciona é revender sem provisionamento por API, porque aí cada cliente novo é trabalho manual seu.

### Como eu evito que um cliente estrague a reputação do número de outro?

Com uma instância por cliente, no nome dele. A qualidade e o limite de envio são propriedades do número, então números separados isolam o problema. Onde todos compartilham a mesma estrutura, um cliente que dispara para lista comprada reduz o limite dos outros, e não há o que você faça do lado do software.

### Qual desses seis itens eu faço primeiro?

O escopo por empresa, sem discussão. É o único cujo defeito em produção não é incômodo, e sim incidente de dados — e o mais caro de acrescentar depois, porque toca toda consulta do sistema. Os outros cinco entram em versões sucessivas sem drama; esse não.