--- title: "O CRM que você fez com IA vai para o cliente: o que ele pede na primeira semana" description: "Cinco pedidos, na ordem em que eles chegam. Nenhum é sobre CRM: todos são sobre o canal. O que cada um implica tecnicamente, sem rodeio." url: "https://wame.api.br/blog/crm-feito-com-ia-o-que-o-cliente-pede-na-primeira-semana" language: "pt-BR" og:type: "article" published_time: "2026-09-23" modified_time: "2026-09-23" author: "Raphael Serafim" keywords: "criar crm com ia, integrar whatsapp no crm, multiatendimento whatsapp, chatbot whatsapp, protocolo de atendimento, instagram direct api" reading_time: "11 min de leitura" --- # O CRM que você fez com IA vai para o cliente: o que ele pede na primeira semana > Cinco pedidos, na ordem em que eles chegam. Nenhum é sobre CRM: todos são sobre o canal. O que cada um implica tecnicamente, sem rodeio. 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](/blog/multiatendimento-mesmo-numero-whatsapp), 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](/blog/labels-api-whatsapp-organizar-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](/blog/quando-ia-deve-parar-responder-whatsapp) 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](/blog/transcricao-audio-whatsapp-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](/blog/instagram-e-messenger-no-seu-saas) 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](/blog/de-prototipo-a-produto-vender-o-crm-que-voce-criou). ## 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.