Cases

Mes passado revisamos 50 operacoes de SaaS B2B. O que descobrimos mudou nossa metodologia.

Estavamos convictos do nosso playbook de onboarding. Ate que cruzamos os dados de 50 operacoes e descobrimos que 3 das nossas certezas estavam erradas.

PA
Patricia Moura New Way
· 27 de mar. de 2026 · 11 min de leitura

Toda empresa de tecnologia que trabalha com onboarding de clientes B2B tem um playbook. Nos tinhamos o nosso. Funcionava. Os clientes ativavam, usavam, renovavam. Os numeros eram bons.

Entao, mes passado, fizemos algo que deveriamos ter feito antes: cruzamos os dados de 50 operacoes de SaaS B2B que passaram pelo nosso processo nos ultimos 18 meses. Nao era uma auditoria planejada. Comecou como uma revisao de rotina e virou uma sessao de 3 dias que mudou 3 pilares da nossa metodologia.

Este artigo e a confissao honesta do que descobrimos, por que estavamos errados, e o que mudamos.

O contexto: 50 operacoes, 18 meses, 1 playbook

As 50 operacoes tinham perfis variados: ISPs, e-commerces, software houses, consultorias, servicos financeiros. Todas B2B. Todas com operacao de atendimento via WhatsApp. Todas com equipe entre 5 e 80 operadores.

Nosso playbook de onboarding tinha 4 fases:

  1. Diagnostico (semana 1): entender a operacao, mapear fluxos, identificar gargalos.
  2. Configuracao (semana 2-3): montar filas, treinar IA, configurar integracoes.
  3. Go-live assistido (semana 4): acompanhar os primeiros dias em producao.
  4. Otimizacao (mes 2-3): ajustar com base nos primeiros dados reais.

Parecia solido. E, em muitos casos, era. Mas quando olhamos para as 50 operacoes em conjunto, tres padroes surgiram que contradiziam nossas premissas.

Descoberta 1: O diagnostico estava correto, mas incompleto

O que achavamos: o diagnostico da semana 1 capturava os gargalos principais da operacao. Com base nele, configuravamos a plataforma.

O que os dados mostraram: em 62% das operacoes, o maior gargalo real so apareceu depois do go-live -- e nao era o que haviamos identificado no diagnostico.

Por que? Porque o diagnostico era baseado no que o cliente dizia e no que observavamos em 5 dias. Mas operacoes sao organismos vivos. O gargalo de segunda-feira nao e o gargalo de sexta-feira. O gargalo de janeiro nao e o gargalo de marco.

Exemplo concreto: em uma software house com 9 mil tickets por mes, nosso diagnostico apontou "falta de automacao em demandas de nivel 1" como gargalo principal. Configuramos a IA, ativamos, e a automacao resolveu 47% do volume. Otimo. Mas o gargalo real -- que so apareceu na terceira semana -- era a distribuicao desigual de carga entre turnos. O turno da manha recebia 2.3x mais conversas que o turno da tarde, e os operadores da manha estavam esgotados enquanto os da tarde ficavam ociosos.

O que mudamos: estendemos o periodo de diagnostico de 1 semana para 3 semanas. As 2 semanas extras nao sao de consultoria -- sao de observacao passiva com coleta de dados automatizada. Antes de configurar qualquer coisa, agora temos 21 dias de dados reais sobre distribuicao de volume, padroes de pico, e tipos de demanda por horario.

O custo: o time-to-value aumentou em 2 semanas. O beneficio: a configuracao acerta de primeira em 84% dos casos, contra 51% antes.

Descoberta 2: O treinamento da IA nao era o problema -- a taxonomia era

O que achavamos: quando a IA classificava errado, era problema de treinamento. Solucao: mais exemplos, mais dados, mais ajuste fino.

O que os dados mostraram: em 73% dos casos onde a acuracia da IA estava abaixo de 80%, o problema nao era o modelo -- era a taxonomia. As categorias de atendimento definidas pelo cliente nao refletiam a realidade das conversas.

Isso parece obvio em retrospecto, mas nao era na pratica. Quando um cliente nos entregava uma lista de 45 categorias de atendimento ("Financeiro > Boleto > Segunda via", "Financeiro > Boleto > Contestacao", "Financeiro > Boleto > Vencimento"...), nos confiavamos que ele conhecia a propria operacao. E ele conhecia -- mas a taxonomia tinha sido criada 3 anos antes para um sistema de telefonia e nunca atualizada.

O padrao que encontramos: operacoes com mais de 30 categorias tinham, em media, 12 categorias "fantasma" -- categorias que existiam na lista mas representavam menos de 0.5% do volume. E tinham, em media, 3 categorias "guarda-chuva" (como "Outros" ou "Geral") que concentravam 22% do volume. Ou seja: 22% das conversas nao eram classificadas de verdade.

O que mudamos: antes de treinar a IA, agora fazemos uma "auditoria de taxonomia" com os dados reais das 3 semanas de diagnostico. Classificamos uma amostra de 500 conversas manualmente (nos, nao o cliente) e construimos a taxonomia de baixo para cima. O resultado tipico: operacoes que tinham 40+ categorias ficam com 12 a 18. E a acuracia da IA salta de 68% para 89% na primeira semana.

Descoberta 3: Go-live assistido nao era suficiente -- precisavamos de "go-live progressivo"

O que achavamos: ativar a operacao na plataforma nova com acompanhamento de 5 dias uteis era suficiente para estabilizar.

O que os dados mostraram: 44% das operacoes tinham uma queda de performance na semana 3 apos o go-live -- o que chamamos de "vale do desencanto". O time ja tinha passado pela euforia da novidade, mas ainda nao dominava os novos fluxos. A IA ja estava ativa, mas os operadores nao confiavam nela e faziam override manual em 30% dos casos.

O ciclo que vimos se repetir: semana 1, metricas sobem (efeito novidade + acompanhamento). Semana 2, metricas estabilizam. Semana 3, metricas caem (time volta aos habitos antigos, IA perde eficacia por falta de feedback). Semana 4-6, recuperacao lenta -- se alguem intervem. Se ninguem intervem, a operacao estaciona em 60% do potencial.

O que mudamos: substituimos o "go-live de 5 dias" por "go-live progressivo de 4 semanas":

  • Semana 1: IA ativa apenas para demandas de nivel 1 (as mais simples). Operadores atendem o resto normalmente.
  • Semana 2: IA assume nivel 1 + classificacao automatica de nivel 2. Operadores recebem conversas pre-classificadas.
  • Semana 3: IA assume nivel 1 + nivel 2 autonomo (com supervisao). Operadores focam em nivel 3.
  • Semana 4: operacao completa com todas as camadas ativas.

O resultado: o "vale do desencanto" desapareceu. A curva de adocao se tornou monotonicamente crescente. E a taxa de override manual (operadores desligando a IA) caiu de 30% para 7%.

O que mais aprendemos (mas nao mudamos -- ainda)

Alem das 3 descobertas que mudaram a metodologia, encontramos outros padroes que estamos investigando:

Operacoes com gestor dedicado a IA performam 2.4x melhor. Quando ha uma pessoa (nao necessariamente tecnica) responsavel por acompanhar a performance da IA semanalmente, os resultados sao dramaticamente melhores. Operacoes sem esse papel tendem a estagnar apos o terceiro mes.

O tamanho do time nao correlaciona com velocidade de adocao. Operacoes com 8 operadores adotaram tao rapido quanto operacoes com 60. O fator determinante nao era tamanho -- era engajamento da lideranca.

Operacoes que tinham tentado (e falhado) com chatbot anterior adotaram a IA mais rapido. Contraintuitivo? Nem tanto. Quem ja tentou e falhou sabe o que nao funciona, e por isso e mais receptivo a uma abordagem estruturada.

A humildade como metodo

Se este artigo tem uma tese central, e esta: o playbook perfeito nao existe. E a unica forma de melhorar e olhar para os dados com honestidade e aceitar quando eles contradizem suas certezas.

Nos vendemos IA e automacao. Mas o que realmente faz diferenca nao e a tecnologia -- e o processo de implementacao. E o processo so melhora quando voce tem coragem de questionar o que "sempre funcionou".

A versao atualizada da nossa metodologia esta em producao desde o mes passado. Os primeiros resultados sao promissores: o time-to-value e 2 semanas mais longo, mas a satisfacao no terceiro mes subiu 31% e a taxa de churn nos primeiros 6 meses caiu pela metade.

No yapt., essa evolucao de metodologia e continua. A plataforma coleta dados de performance de cada operacao, e esses dados alimentam nao so a IA dos nossos clientes, mas a nossa propria forma de trabalhar. E um loop de melhoria que nunca para.

Por que estamos publicando isso

Uma ultima nota. Alguem da equipe perguntou: "faz sentido publicar que estavamos errados em 3 coisas?" Faz. Por dois motivos.

Primeiro, porque se nos -- que operamos isso ha 16 anos e processamos 30 milhoes de mensagens por mes -- estavamos errados, e provavel que outras empresas estejam tambem. E compartilhar o aprendizado economiza tempo e dinheiro pra todo mundo.

Segundo, porque transparencia e a base de qualquer relacao B2B saudavel. Se voce so publica cases de sucesso e nunca admite erro, voce esta fazendo marketing, nao conteudo.

O que fazer amanha

  1. Revise sua taxonomia de atendimento. Quantas categorias voce tem? Quantas representam menos de 1% do volume? Quantas sao "guarda-chuva"? Se mais de 20% do volume cai em "Outros", sua taxonomia precisa de cirurgia.

  2. Meca a taxa de override da IA. Quantas vezes por dia seus operadores desligam ou ignoram a sugestao da IA? Se for mais de 15%, o problema nao e a IA -- e a confianca. E confianca se constroi com go-live progressivo.

  3. Designe um "dono da IA" na sua operacao. Nao precisa ser tecnico. Precisa ser alguem que olha os numeros toda semana e ajusta. Sem esse papel, a IA estagna.

  4. Faca sua propria auditoria de N operacoes. Mesmo que sejam 5, mesmo que sejam 10. Cruze os dados. Procure padroes. As descobertas mais valiosas vem de olhar para o conjunto, nao para casos isolados.

  5. Questione suas certezas. Se o seu playbook nao mudou nos ultimos 12 meses, ele provavelmente esta desatualizado. Os dados vao te dizer onde.

PA
Sobre o autor

Patricia Moura

Autor na New Way. Conteudo sobre crescimento inteligente, IA conversacional e comunicacao empresarial.

Quer aplicar isso na sua operacao?

Fale com nosso time pelo WhatsApp. Diagnostico gratuito, com dados reais.

Falar pelo WhatsApp →