O sistema foi entregue numa terça. Tem cadastro de cliente, funil com arrastar e soltar, campos personalizados, um painel com três gráficos e um filtro que você levou meio dia para deixar redondo. O cliente elogiou, mexeu por uma hora e ficou satisfeito.

Na quinta ele manda a primeira mensagem de verdade. E a partir dali, por uma semana inteira, tudo o que ele pede é a mesma coisa vestida de cinco formas diferentes — e nenhuma delas é o CRM. São todas o canal. Este texto é a lista, na ordem em que ela chega, com o que cada pedido custa do outro lado.

Pedido 1: "a Maria também precisa responder"

Chega no segundo dia. O sistema foi feito para o dono, e o dono tem uma equipe. Ele quer que a Maria abra o mesmo painel e responda as mesmas conversas.

Parece pedido de login, e não é. Criar usuário você já sabe fazer; o problema é que duas pessoas passam a olhar a mesma fila e se atropelam — as duas respondem o mesmo cliente, com respostas diferentes, com dez segundos de intervalo. O que esse pedido implica, de verdade:

• Um estado por conversa. Pendente, em atendimento, encerrada. Sem isso não há como saber o que já tem dono.
• Uma atribuição atômica. Aceitar uma conversa precisa ser uma operação só no banco, condicionada a ela ainda não ter responsável. Ler, decidir em memória e gravar depois deixa uma janela — e dois cliques simultâneos caem exatamente nela. Quem perde a corrida tem que receber um erro claro, não um sucesso silencioso.
• Uma noção de setor ou equipe. Ele vai pedir na semana seguinte que financeiro não veja o que é do suporte.

Nada disso é WhatsApp, mas tudo isso nasce do WhatsApp: um número só, uma caixa só, várias pessoas. Como isso se resolve do lado da API está em Vários atendentes no mesmo número de WhatsApp: como fazer pela API, e vale ler antes de escolher o desenho, porque a parte difícil é o que acontece quando duas telas discordam.

Um detalhe que economiza um chamado: quando alguém aceita uma conversa, as outras telas precisam saber na hora. Se a lista da Maria só atualiza quando ela recarrega a página, ela vai clicar em aceitar algo que já é do João e receber um erro sobre algo que a tela dela afirmava estar livre.

Pedido 2: "eu preciso saber quem falou com quem"

Chega logo depois do primeiro, e costuma vir com um tom diferente — não é entusiasmo, é desconfiança. Alguém prometeu desconto a um cliente e ninguém sabe quem.

Tecnicamente é o pedido mais simples dos cinco e o mais fácil de fazer errado. Duas armadilhas:

A primeira é não gravar o autor na mensagem. Se o seu sistema grava só "mensagem enviada", a pergunta não tem resposta. O autor precisa ir na mensagem, no momento em que ela é gravada, e não ser deduzido depois de quem era o responsável pela conversa — porque o responsável muda.

A segunda é resolver o nome na leitura. Se você guarda só o id do usuário e busca o nome quando alguém abre o histórico, o painel mostra o nome atual daquela pessoa. Um atendente renomeado reescreve o próprio passado, e um atendente desativado some do registro. Guarde o nome junto do id, desnormalizado. É redundância de propósito: a pergunta que o histórico responde é quem a pessoa era naquele dia.

E existe um terceiro autor que quase ninguém prevê: o celular. Se o número também está num aparelho, alguém vai responder por lá, e essa resposta volta pelo webhook marcada como saída sem autor nenhum. Desenhada igual a uma mensagem do sistema, ela será lida como se um atendente tivesse escrito. Marque a diferença.

Pedido 3: "o histórico não pode sumir"

Este chega quando alguém encerra um atendimento e o cliente volta a escrever no dia seguinte.

A regra que quase todo sistema adota — e que está certa — é uma conversa aberta por contato e por conexão, e encerrar libera abrir outra. O que o cliente está pedindo não é que a conversa não feche; é que o histórico anterior continue alcançável. São coisas diferentes, e a confusão entre elas gera uma decisão ruim: manter a conversa aberta para sempre, o que faz a fila crescer sem fim e destrói qualquer métrica de atendimento.

O desenho que funciona é: a conversa encerra, uma nova nasce, e a tela do contato mostra as duas. O que tem que existir para isso é uma busca que alcance conversa encerrada — e é aí que aparece o pedido escondido. Quando o dono liga perguntando "o atendimento do sr. Carlos da semana passada", ninguém tem o nome exato nem a data. É o momento em que o número de protocolo deixa de ser burocracia e vira a única forma de achar alguma coisa.

Se você vai acrescentar protocolo, duas decisões:

• Sequencial por empresa, gerado numa operação só no banco. Ler o último e somar um não serve: duas conversas criadas no mesmo instante leem o mesmo valor e recebem o mesmo número.
• Da conversa, não da mensagem. Por mensagem seriam centenas por atendimento e não serviria para nada.

E não renumere o que já existe. Inventar uma ordem que não aconteceu é pior do que ter conversas antigas sem número.

Pedido 4: "tem uma resposta que a gente manda toda hora"

O quarto pedido é o mais barato de todos e o que mais muda a percepção do produto. A equipe digita a mesma frase trinta vezes por dia — o horário de funcionamento, os dados de pagamento, o link do catálogo — e quer um atalho.

Faça um catálogo de respostas por empresa, com categoria, e um gatilho dentro da barra de digitação. Três decisões que valem a pena ter pensado antes:

1. Texto escolhido concatena no campo, não envia. A pessoa quase sempre quer completar a frase antes de mandar. Enviar direto tira dela a chance de ajustar, e o que ela ia ajustar era justamente o nome do cliente.
2. Mídia cadastrada é diferente de mídia de conversa. O cardápio em PDF que a equipe manda toda hora precisa ficar guardado em algum lugar para poder ser reenviado. Isso não contradiz a regra de não armazenar mídia de atendimento: é conteúdo cadastrado por um administrador, com finalidade de reenvio.
3. Trocar o tipo de uma resposta pronta exige limpar o campo antigo. Se um texto vira imagem e você só sobrescreve o campo de mídia, a resposta continua carregando o texto velho junto. É o tipo de defeito que ninguém reproduz e todo mundo vê.

Na sequência ele pede para organizar as conversas por assunto. Antes de construir uma taxonomia inteira, olhe o que o canal já oferece — Labels na API do WhatsApp: organize conversas sem CRM descreve o mecanismo, e ele costuma resolver sem uma segunda estrutura para manter.

Pedido 5: "o robô não pode responder de madrugada?"

O quinto é o que parece mais ambicioso e é o que tem a maior chance de dar errado, porque o cliente está pedindo uma coisa e imaginando outra.

Ele imagina uma inteligência artificial que atende como a melhor atendente dele. O que ele precisa, na primeira semana, é muito menos que isso: uma resposta automática fora do horário, um menu de opções e uma forma de chamar gente. E o que ele não disse, mas vai cobrar no primeiro erro, é que o robô saiba a hora de calar a boca.

As regras que precisam existir antes de qualquer modelo de linguagem entrar na história:

• Conversa com atendente não é do robô. Assim que uma pessoa aceita a conversa, o automático para. Sem essa regra, o cliente reclama, o robô responde por cima do atendente, e o atendimento vira duas vozes discordando.
• Existe uma palavra de saída. "Atendente", "sair", "parar". Comparada como palavra inteira, senão "sairemos amanhã" derruba o fluxo. Sem porta de emergência, a única saída de quem está preso num bot que não entende é errar três vezes de propósito.
• Existe um teto de tentativas. Três respostas que o robô não entende e a conversa vai para um humano. Insistir para sempre com quem digita qualquer coisa é a forma mais rápida de perder um cliente.
• Existe um freio contra laço. Um fluxo mal desenhado que volta a um nó já executado manda a mesma mensagem repetidas vezes. Com um intervalo no meio, isso vira dezenas de mensagens por dia para o mesmo número — e número que faz isso perde qualidade e depois perde limite de envio.

Quando o modelo de linguagem entrar, a pergunta difícil não é como chamá-lo; é quando fazê-lo parar. Quando a IA deve parar de responder no WhatsApp: regras de escalonamento para humano trata exatamente disso, e é o texto para ler antes de ligar qualquer coisa em produção.

Um pedido adjacente que chega junto: áudio. Metade dos clientes do seu cliente manda mensagem de voz, e a equipe perde tempo ouvindo cinco áudios para descobrir um endereço. Transcrever resolve, e resolve barato — o caminho está em Transcrição de áudio no WhatsApp com IA. Só não transcreva tudo: transcrição de todo áudio de toda conversa é conta que ninguém pediu, e o atendente humano ouve.

O que esses cinco pedidos têm em comum

Releia a lista. Multiatendimento, autoria, histórico que não some, respostas prontas, automação com hora de parar. Nenhum deles é sobre funil, campo personalizado ou relatório de vendas — que é onde você passou a maior parte do tempo de desenvolvimento.

Isso não é azar nem cliente difícil. É a natureza do produto: o CRM é onde o dado mora, mas o canal é onde o trabalho acontece. A equipe passa o dia inteiro na tela de conversa e entra no funil duas vezes por semana. Tudo que atrapalha na tela onde se passa o dia vira pedido urgente; tudo que atrapalha na tela que se abre às terças vira observação educada.

A consequência prática para quem constrói com IA é uma inversão de prioridade. O assistente entrega funil, cadastro e painel em um fim de semana, e entrega bem — essa parte está resolvida antes de começar. O que sobra de trabalho de verdade é a camada de canal, e ela precisa ser desenhada com essas cinco perguntas na mesa desde o primeiro dia, não acrescentada depois de o cliente reclamar.

Vale antecipar o sexto pedido, que chega na segunda semana: o Direct do Instagram. Ele é mais barato do que parece — os três canais saem da mesma conta e do mesmo webhook —, mas exige uma decisão de modelagem que é cara de tomar tarde. O que muda quando o contato deixa de ser um telefone descreve essa decisão, e é melhor tomá-la agora, com uma base pequena.

Conclusão

Se você está para entregar um sistema feito com IA ao primeiro cliente, use esta lista como pauta antes da entrega, não depois. Cinco perguntas: mais de uma pessoa consegue atender sem se atropelar? O histórico diz quem falou? Conversa encerrada continua achável? Existe atalho para o que se repete? O automático sabe parar?

Se as cinco tiverem resposta, a primeira semana vai ser sobre o produto. Se não, vai ser sobre o canal — e você vai construir tudo isso de qualquer jeito, só que com o cliente esperando e dado real no banco, que é a pior hora para mudar a chave única de uma tabela.

O resto do caminho até virar produto vendável — multi-inquilino de verdade, contrato, trilha de auditoria, cobrança — está em De protótipo a produto: o que falta no CRM que você criou com IA.

Perguntas frequentes

Dá para entregar sem multiatendimento e acrescentar depois?+

Dá, se a conversa já tiver estado e responsável desde o começo, mesmo com um usuário só. O que custa caro não é a tela de atribuição; é descobrir que as mensagens foram gravadas sem autor e sem noção de dono, e ter que decidir retroativamente de quem era cada atendimento. Grave os campos desde o primeiro dia, ainda que nada na interface os use.

Preciso de um número de protocolo mesmo em sistema pequeno?+

Precisa no momento em que alguém ligar perguntando de um atendimento antigo, e isso acontece antes do que se imagina. Acrescentar é barato — um contador por empresa e um campo na conversa —, e não ter custa uma busca por nome e data que quase nunca encontra o que a pessoa quer.

O robô pode atender junto com os humanos no mesmo número?+

Pode, e é o arranjo normal. A regra que faz funcionar é uma só: assim que um atendente aceita a conversa, o automático para de agir nela. Sem isso o robô responde por cima do humano, e o cliente recebe duas versões da mesma resposta com poucos segundos de diferença.

Vale usar as labels do WhatsApp ou criar etiquetas próprias no meu sistema?+

Depende de onde a equipe trabalha. Se ela vive só no seu painel, etiqueta própria é mais simples e você controla o comportamento. Se ela ainda usa o aplicativo do WhatsApp em paralelo, usar o mecanismo do próprio canal evita duas classificações divergentes para a mesma conversa. Decida antes de construir, porque manter as duas em sincronia é trabalho contínuo.

Como eu evito que o robô mande a mesma mensagem várias vezes?+

Com um freio explícito: conte quantas vezes cada etapa do fluxo rodou naquela conversa e interrompa o automático ao passar do teto, deixando a conversa para um humano. O contador precisa ficar gravado no banco, não em memória: o caso que mais acontece é o laço que atravessa uma pausa, e cada retomada começa uma execução nova.

Continue lendo

Como criar um CRM do zero com IA

A IA entrega modelo de dados, funil e painel em dias. Ela não entrega canal, entrega de mensagem nem multi-inquilino. O que fazer com cada uma das três partes.

Fiz meu CRM num fim de semana com IA. Aí chegou o WhatsApp.

Sábado: CRUD, funil e login prontos. Domingo: o WhatsApp. A parede tem nomes — Business Manager, verificação, template, janela de 24 horas — e este é o mapa dela.

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.