Reunião de comitê de TI, briefing pronto, cliente pedindo chatbot WhatsApp com IA. A lista cabe num parágrafo: responder dúvidas frequentes, abrir chamado no sistema de tickets, registrar pedido, atualizar status no CRM, qualificar lead, consultar saldo via API, encerrar acionando um time humano quando precisar. Parece coerente — um projeto, um fornecedor, um escopo.
Não é. Tem ao menos três projetos diferentes empilhados nessa lista, com engenharias distintas, requisitos de segurança distintos e curvas de risco distintas. Tratar tudo como o mesmo escopo é o caminho mais curto pra trocar de fornecedor no meio — depois de pagar discovery, ver piloto bonito em demo e descobrir que a parte de execução em sistema interno nunca foi dimensionada.
Principais pontos
- Chatbot que conversa é uma engenharia, chatbot que executa em sistema interno é outra, e o briefing B2B costuma juntar as duas como se fossem uma só.
- Existem 4 níveis de integração úteis pra decidir o escopo antes do contrato: FAQ puro, consulta read-only, execução transacional e orquestração com handoff humano.
- Discovery técnico decide o sucesso do projeto, não o modelo de IA escolhido — escopo errado vira troca de fornecedor depois do piloto.
- Cada nível dispara decisões de governança próprias: contratos de API, idempotência, papéis LGPD, ownership do dado após a execução, fallback humano.
- A escolha entre Cloud API oficial Meta e parceiro via QR Code também depende do nível, e merece ser tomada no discovery, não como detalhe técnico no fim.
Pra empresa montando o RFP, a pergunta útil antes de listar features é: que nível de integração o caso exige hoje, e qual é o nível pra onde provavelmente vai migrar em 12 meses? É exatamente esse tipo de discovery — antes do contrato — que parceiros como a Vertis Tech entram em consideração, especialmente quando o projeto cruza WhatsApp, CRM, ERPs e sistemas internos legados.
Por que o briefing junta tudo na mesma lista
Os briefings B2B de chatbot WhatsApp viraram lista de capacidades por uma razão razoável: do lado do decisor, parece tudo "o que o cliente vai conseguir fazer pelo WhatsApp". A divisão entre "perguntar status do pedido" (pergunta) e "alterar endereço do pedido" (ação) some no enunciado de negócio — virou genericamente "vamos resolver pelo WhatsApp".
No backstage técnico, essas duas frases moram em universos diferentes. Responder "qual o status do meu pedido" exige, no máximo, uma chamada read-only a uma API ou consulta a uma base de conhecimento atualizada. Alterar o endereço do pedido exige escrita autenticada no ERP, validação de regra de negócio ("posso alterar endereço depois que saiu pra entrega?"), idempotência ("o cliente repetiu a mensagem, eu vou alterar duas vezes?") e tratamento de falha que não pode terminar em "deu erro, tenta de novo" — porque do lado do cliente isso vira reclamação formal.
Tratar perguntas e ações no mesmo balde de "chatbot com IA" funciona em demo. Em produção, o fornecedor escolhido pra um tipo costuma falhar no outro — e a empresa contratante descobre tarde, depois de comprometer cronograma e orçamento.
Os 4 níveis de integração — escopo, engenharia e governança são diferentes em cada um
Nível 1 — FAQ puro: o agente conversa, não toca em nada
Aqui o chatbot lê uma base de conhecimento (PDFs, FAQs, política interna) e responde com base nela. Pode usar RAG pra reduzir alucinação, classificar intenção e aplicar prompt engineering. O sistema interno do cliente não é tocado.
Engenharia mínima: webhook do WhatsApp, retriever, LLM. Risco operacional: resposta imprecisa ou desatualizada. Risco de segurança: vazamento de informação da base. Governança LGPD: simples — controlador definido, base curada, retenção de log de conversa.
Tempo de implementação: curto. Custo de erro: contornável. Boa porta de entrada quando o objetivo real é deflexão de atendimento (resolver uma parcela relevante das dúvidas comuns antes de chamar humano).
Quando faz sentido: central de dúvidas, política interna, perguntas pré-vendas, encaminhamento de informações públicas, redução de volume no time de atendimento.
Nível 2 — Consulta read-only: o agente lê seus sistemas, mas não escreve
Aqui o agente chama APIs internas pra ler: status do pedido, saldo de pontos, próxima fatura, horário do agendamento, endereço cadastrado. A conversa fica mais rica, mas o sistema do cliente fica intacto — o chatbot é leitor autenticado.
Engenharia adiciona: contratos de API (endpoint, schema de retorno, error handling), autenticação serviço-a-serviço, rate limiting, observabilidade nas chamadas. Risco operacional: o agente exibe um dado errado ou desatualizado. Risco de segurança: o token de leitura vaza ou tem escopo amplo demais (o que era pra ser "ler pedido" acaba lendo dado de qualquer pedido). Governança LGPD: define quem pode consultar o que do CPF de quem.
Tempo de implementação: depende da maturidade da API interna. Empresa que já tem APIs versionadas e documentadas absorve rápido; empresa que depende de SQL direto em produção descobre que parte do projeto é abrir e governar a primeira API interna — o que muitas vezes é projeto maior que o chatbot em si.
Quando faz sentido: auto-atendimento de status (delivery, ordem de serviço), consulta de saldo/fatura, agendamento read-only ("qual horário eu tenho?"), pré-qualificação de lead com lookup em CRM.
Nível 3 — Execução transacional: o agente escreve e dispara processos
Aqui o agente muda estado no sistema interno: abre chamado, registra pedido, agenda consulta, atualiza endereço, cancela assinatura, inicia ressarcimento. A conversa não é mais sobre informação — é sobre ação irreversível ou de difícil reversão.
Engenharia adiciona, em cascata:
- Idempotência: cliente manda mensagem duas vezes, agente não pode abrir dois chamados.
- Validação de regra de negócio externa ao LLM: "esse cliente pode alterar endereço agora?" é decisão de ERP, não de prompt.
- Tratamento de falha de domínio: API caiu, regra recusou, valor inválido — o agente precisa saber o que falar e o que escalar.
- Auditoria append-only: o que o agente fez, em nome de quem, em que conversa, em que timestamp.
- Consentimento explícito do cliente final antes de ações destrutivas ou financeiras.
Risco operacional: agente faz a ação errada (pedido criado pra produto errado, agendamento marcado no dia errado, ressarcimento iniciado por engano). Risco de segurança: token de escrita vaza, ou o agente é manipulado pra executar fora do escopo — categoria de ataques chamada "prompt injection com efeito colateral". Governança LGPD: a responsabilidade pelo dado fica embaralhada — o agente é "operador", quem o opera é o controlador, e os subprocessadores (LLM externo, plataforma WhatsApp) precisam estar contratualmente nomeados.
Tempo de implementação: longo. Esse é o nível onde "discovery técnico" deixa de ser cerimônia — é o que distingue projeto que entra em produção de projeto que vira piloto eterno.
Quando faz sentido: auto-atendimento que substitui ligação ou app (segunda via, alteração de cadastro, agendamento confirmado), captação de pedido B2B com SKU complexo, abertura de chamado com classificação automática, qualificação de lead que cria oportunidade no CRM com SLA atrelado.
Nível 4 — Orquestração com handoff humano: o agente sabe quando passar a bola
Aqui o agente faz Níveis 1-3 quando consegue, e passa pra humano quando não consegue — preservando histórico, contexto e classificação da conversa. Inbox híbrido: IA e atendente humano no mesmo painel, com transferência limpa.
Engenharia adiciona:
- Critérios de transferência declarados: por intenção (cliente pediu humano), por confiança baixa do agente (não sei responder), por gatilho de negócio (cliente VIP, reclamação detectada, valor acima de um limite).
- Fila humana com SLA: quem atende, em quanto tempo, no horário comercial de quem.
- Estado da conversa preservado: humano não recomeça do zero, lê o que aconteceu e onde a IA travou.
- Modo espião e supervisão: equipe de QA acompanha conversas em tempo real, sem interromper.
- Métricas conjuntas IA + humano: tempo de resposta, resolução no primeiro contato, NPS pós-atendimento — sem isso o cliente não consegue evoluir o agente.
Risco operacional: humano nunca recebe a conversa quando deveria, ou recebe sem contexto (recomeça atendimento e cliente abandona). Risco de segurança: atendente humano vê dado que não deveria ver. Governança LGPD: papéis de acesso por atendente, log de quem viu o quê.
Quando faz sentido: atendimento B2C com mix de pergunta simples e caso complexo, vendas consultivas, suporte técnico em escala, reclamação que precisa virar incidente com responsável humano.
O que decidir antes do contrato — mesmo que ainda não saiba o fornecedor
A pior conversa com fornecedor é a que começa em "manda uma proposta de chatbot com IA pro WhatsApp". A boa conversa começa em "estamos contratando um chatbot que opera no Nível 2 hoje e provavelmente vai pro Nível 3 em 6 meses; precisa de handoff humano desde o início porque temos time de atendimento e quem vai atender precisa receber as conversas que a IA não resolve". A segunda frase muda quem você está procurando.
Algumas decisões internas que valem fechar antes de abrir RFP:
Que tipo de erro custa mais caro?
Resposta errada à dúvida é diferente de pedido criado errado, que é diferente de transferência humana perdida. O nível de integração que você está contratando precisa estar dimensionado pra absorver o erro que dói no seu modelo de negócio. Cliente de saúde que tem chatbot fazendo agendamento (Nível 3) e erra dia? Caso operacional grave. Cliente de varejo que tem chatbot de FAQ (Nível 1) e diz "consulte sua política"? Inconveniente, sem dano material.
Quem é o controlador do dado depois que o agente atua?
A LGPD não terceiriza essa pergunta. Se o agente lê CPF, consulta pedido, abre chamado e dispara cobrança, o dado pessoal está sendo tratado em mais de um sistema: WhatsApp, plataforma de chatbot, LLM (eventualmente externo), CRM/ERP do cliente, plataforma de cobrança. Cada um precisa de papel contratual definido — controlador, operador, subprocessador. Se a empresa contratante não decidir isso antes do contrato, a discussão acontece depois do incidente, e o ônus normalmente cai em quem assinou sem clareza.
Como o humano entra na operação — não se ele entra
Em quase nenhuma operação real, IA roda sozinha por muito tempo. A pergunta útil não é "vamos ter humano?", é "que conversas o humano precisa receber, com qual SLA, em qual interface". Empresa que entra no projeto sem essa decisão costuma descobrir, no piloto, que o produto entregue não suporta a operação humana planejada — e termina com dois inboxes (um da IA, outro dos atendentes) e nenhum funil que conecta os dois.
Qual é o tempo de mudança nos sistemas internos integrados?
Chatbot que executa em sistema interno acopla. Se o ERP muda contrato de API a cada trimestre sem versionamento, o agente quebra. Se o CRM passa por reestruturação anual de campos, a automação some no dia. Avaliar quão estável é o sistema interno do qual o agente depende é parte do discovery — e às vezes muda o veredito (vale começar no Nível 1-2 enquanto o ERP estabiliza, em vez de tentar Nível 3 contra um alvo que se move).
Cloud API oficial Meta ou parceiro via QR Code?
Decisão WhatsApp que costuma vir cedo no Nível 3-4. Cloud API oficial Meta dá templates aprovados, business verification, número verificado e regras claras de janela de 24h — caminho natural quando há volume, formalidade ou requisito de marca. Parceiro via QR Code dá simplicidade de setup, custo menor de entrada e mais flexibilidade pra piloto — caminho natural pra começar exploratório. Não existe resposta padrão; existe decisão informada com base no nível de integração e no risco operacional do canal.
Como a Vertis Tech ajuda em integração de chatbot WhatsApp com sistemas internos
A Vertis Tech é fábrica de software brasileira focada em CRM, automação e IA aplicada, credenciada Meta Tech Provider 2025 para WhatsApp Business com IA e CRM. Cada projeto é dimensionado conforme nível de integração necessário, sensibilidade dos sistemas internos envolvidos, exigência regulatória do setor e maturidade operacional do cliente. A depender do escopo, a implantação pode contemplar:
- Discovery técnico orientado a outcome, pra mapear em qual nível (1 a 4) o caso real está hoje e pra onde tende a evoluir, antes de comprometer arquitetura.
- Contratos de API auditáveis com sistemas internos (CRM, ERP, helpdesk, gateways), incluindo idempotência, versionamento, observabilidade e plano de fallback declarado.
- Camada de execução transacional desenhada com aprovação humana em pontos críticos, especialmente quando a ação envolve dado financeiro, cadastro sensível ou regra de domínio complexa.
- Atendimento híbrido IA + humano quando o Nível 4 entra no escopo, com inbox unificado, preservação de contexto na transferência, modo espião e métricas operacionais conjuntas.
- WhatsApp via Cloud API oficial Meta ou via parceiro de QR Code, decidido com o cliente conforme volume, formalidade e tradeoffs específicos do caso — sem caminho fixo imposto.
- Governança LGPD desenhada desde o primeiro diagrama, com definição contratual de papéis (controlador, operador, subprocessadores), retenção e rastreabilidade de acesso a dado pessoal.
Perguntas frequentes
Posso começar no Nível 1 e ir crescendo até o Nível 3 com o mesmo fornecedor?
Em tese sim, na prática depende do fornecedor. Plataformas otimizadas pra FAQ tendem a ter governança transacional rudimentar, e plataformas montadas pra agente transacional muitas vezes ignoram a economia de FAQ por deflexão. A pergunta útil no RFP é se o fornecedor tem caso real em produção no nível pra onde você quer migrar — não só promessa de roadmap.
O chatbot precisa estar dentro do meu CRM ou pode ser ferramenta separada?
Os dois cenários funcionam, mas têm tradeoffs distintos. Chatbot dentro do CRM tende a herdar permissões, papéis e relatórios do CRM (bom pra Nível 4). Ferramenta separada com integração via API tende a evoluir mais rápido em capacidade de IA (bom pra começar). A decisão depende mais da maturidade do CRM atual do que do produto de chatbot.
LGPD: agente executando em sistema interno me coloca em risco extra?
Coloca exposição que precisa ser desenhada, não risco categórico. Se o desenho contratual está claro (papéis nomeados, retenção definida, log de acesso a dado pessoal disponível), a operação fica auditável. Se está implícito ("o fornecedor cuida"), a operação fica vulnerável a incidente sem cadeia de responsabilidade definida.
Como saber se o fornecedor entendeu meu Nível antes de assinar?
Peça ao fornecedor que descreva, com palavras dele, em qual nível ele entendeu o projeto e por quê. Se a resposta vier no formato "vamos fazer um chatbot com IA pro seu WhatsApp", o nível não foi compreendido. Se vier em formato "entendi que estamos no Nível 2 hoje com escopo X, e a evolução pro Nível 3 acontece quando Y, com decisões A, B e C", o fornecedor enxerga o projeto da mesma altura que você.
Qual canal WhatsApp escolher quando há execução transacional?
Costuma fazer mais sentido a Cloud API oficial Meta quando há ação financeira, dado regulado ou volume relevante — templates aprovados, business verification e governança de janela de 24h conferida pela própria Meta. Em pilotos exploratórios e operações com volume moderado, parceiro via QR Code costuma viabilizar mais rápido. A decisão merece ser tomada no discovery, não no fim do projeto.
Decidir o nível de integração antes do contrato não é exigência de método — é defesa contra o reaprendizado caro. A maior parte das trocas de fornecedor de chatbot WhatsApp empresarial nos primeiros 6 a 12 meses vem de escopo mal dimensionado: o cliente acreditou que estava contratando um projeto e descobriu que eram três empilhados, todos parcialmente cobertos pelo fornecedor escolhido. A boa notícia é que a conversa pode ser estruturada antes — e quem chega no RFP com os níveis mapeados tende a fazer escolhas que ainda fazem sentido depois do piloto.
