Quando o volume de tickets de um SaaS B2B passa de 800 para 3.000 por mês em dois trimestres, a operação tem duas saídas conhecidas, e as duas são ruins. A primeira é contratar: cada novo analista adiciona custo fixo, leva de seis a oito semanas para ficar produtivo num produto que envolve integrações, provisionamento, billing e regras de negócio próprias, e ainda assim resolve no máximo o que uma pessoa resolve por dia. A segunda é empurrar para a engenharia: o ticket de "integração parou de sincronizar há 4 dias" sobe para o time de produto, que para uma feature para abrir o painel interno, consultar o status no provedor e destravar manualmente. Nos dois casos o custo por ticket sobe junto com o volume. A operação não escala — ela engorda.

A terceira saída — terceirizar o suporte — historicamente significava trocar custo interno por custo de BPO, mantendo o mesmo modelo: gente lendo ticket e respondendo texto. Isso muda a planilha, não a curva. O que muda a curva é terceirizar para uma camada que executa a ação dentro dos seus sistemas, não que responde sobre ela. É sobre essa diferença — e sobre a matemática que ela destrava — que vale a pena conversar antes de aprovar mais um headcount.

A unit economics do suporte que não escala

Vale fazer a conta com números reais de um SaaS B2B em série A. Um analista de suporte técnico custa, com encargos, algo entre R$ 7.000 e R$ 11.000 por mês. Resolvendo de 25 a 40 tickets por dia em casos de média complexidade, o custo direto por ticket fica entre R$ 12 e R$ 22 — antes de somar ferramenta, gestão e o tempo de quem treina e revisa.

O número que ninguém coloca na planilha é o custo de escalonamento. Quando um ticket — uma integração que caiu, um provisionamento que falhou, um cadastro travado, uma conciliação que não bate — não pode ser resolvido pelo analista porque exige consultar uma API interna, cruzar dados entre sistemas ou executar uma ação privilegiada, ele sobe. E o destino do escalonamento normalmente é um engenheiro, cujo custo-hora é três a cinco vezes o do analista, e cujo custo real de oportunidade é a feature que deixou de ser entregue.

Numa operação típica desse porte, 15% a 25% dos tickets são desse tipo: não são difíceis de resolver, são difíceis de delegar, porque exigem acesso a sistema e contexto técnico. São esses 20% que consomem desproporcionalmente o tempo caro da casa. A conta fica assim:

3.000 tickets/mês
  ├─ 80% resolvíveis pelo nível 1   → 2.400 × R$ 15  = R$ 36.000
  └─ 20% que escalam para eng/produto → 600 × R$ 70  = R$ 42.000
                                                    -----------
                                  custo total/mês ≈ R$ 78.000
                                  custo médio/ticket ≈ R$ 26

O problema estrutural: contratar mais gente reduz o custo do primeiro bloco, mas não toca no segundo — que é o mais caro. Você pode ter o melhor nível 1 do mercado e ainda assim sangrar nos 20% que dependem de execução técnica. É exatamente esse bloco que define se a operação escala ou não.

Por que terceirizar para chatbot não resolve o bloco caro

A primeira reação de muito CTO é jogar IA no problema. Intercom Fin, Decagon, Sierra — todos prometem deflexão. E entregam, no primeiro bloco. Um bom resolution bot resolve "como altero meu plano" ou "onde vejo minha fatura" lendo a base de conhecimento e respondendo com texto. Isso é real e tem valor.

Mas o segundo bloco — o caro — é justamente onde esses produtos param. Um chatbot generalista, por melhor que seja o modelo de linguagem por trás, encontra o limite na mesma frase: ele responde, não executa. Diante de "meu cliente diz que a sincronização com o sistema dele parou ontem", o bot bem treinado devolve algo como "verifique se as credenciais da integração estão corretas no painel". Está certo e é inútil, porque o problema não era informacional — era operacional. A sincronização não rodou porque o refresh token de OAuth expirou, ou porque o webhook do provedor falhou, ou porque a conta entrou em rate limit. Nenhuma dessas causas é resolvível com uma resposta de texto — e o mesmo vale para uma NF que não saiu numa fintech ou um usuário que não foi provisionado num SaaS de RH.

O contraste honesto é esse: chatbots de suporte foram desenhados para o primeiro bloco, e o primeiro bloco já estava barato. Eles deflexionam o que era fácil e te devolvem, intacto, o que era caro. A curva de custo dos 20% continua exatamente onde estava — e esses produtos cobram por resolução ou por contato resolvido, o que significa que você paga justamente pelo trabalho que eles não conseguem terminar.

O que muda quando o agente executa a ação

A diferença não é o modelo de linguagem — é a camada de integração por baixo. Um agente operacional não termina no texto: ele tem acesso, via MCP e APIs, aos sistemas onde a ação acontece. O mesmo ticket de sincronização deixa de ser uma pergunta a ser respondida e vira um workflow a ser executado:

ticket: "cliente X diz que a sincronização com o sistema dele parou ontem"

workflow do agente operacional:
  1. identifica a conexão        → API interna: busca integração por cliente
  2. checa o status              → serviço de sync: status = "falha_sync"
  3. cruza a causa raiz          → log do provedor: refresh token expirou
  4. AÇÃO: reconecta + reprocessa → POST /integrations/{id}/reauth + retry
  5. confirma                    → sync retomado, backlog processado
  6. responde o cliente com o resultado, não com instrução
  7. abre tarefa no Linear       → "refresh token expirando silenciosamente" (com payload)

Repare nos passos 4 e 7. O passo 4 é o que nenhum chatbot faz: uma ação de escrita, autenticada, num sistema de produção. O passo 7 é o que nenhum BPO faz: o agente percebeu que a causa raiz é sistêmica e abriu um bug no Linear já com o payload da conexão e o trecho de log — exatamente o contexto que normalmente se perde entre o cliente, o analista e o engenheiro.

Na prática, a chamada de tool use que destrava o ticket se parece com isto:

{
  "tool": "integrations_service.retry_sync",
  "input": {
    "connection_id": "conn_3Kd92h",
    "reason": "refresh_token_expired",
    "requested_by": "agent",
    "requires_review": false
  }
}

O requires_review: false é importante: reprocessar uma sincronização que caiu por token expirado é uma ação reversível e de baixo risco, então o agente executa direto. Já uma exclusão de dados, uma alteração de plano com impacto de billing, ou — numa fintech — um refund acima de um limite ou o desbloqueio de uma conta sinalizada em KYC carregam requires_review: true — e aí entra o Conductor, que veremos adiante. O ponto é que o roteamento entre "executa" e "revisa" é uma decisão de produto, configurável por tipo de ação e por risco, não uma limitação do modelo.

O efeito na unit economics é direto: o bloco de 20% que escalava para engenharia, a R$ 70 cada, passa a ser resolvido pela camada de agentes a uma fração do custo e sem consumir tempo de produto. É o bloco caro que finalmente entra na curva de deflexão — não o barato, que já estava resolvido.

A nova matemática: o que efetivamente entra na conta

Voltando ao mesmo volume de 3.000 tickets, o redesenho da operação muda os dois blocos, mas o ganho concentrado está no segundo:

                         antes              com agentes operacionais
nível 1 (80%)            R$ 36.000          deflexão parcial + agente
escalonamento (20%)      R$ 42.000          executado pelo agente
eng/produto consumidos    sim                liberados p/ roadmap
custo médio/ticket       ~R$ 26             redução > 30% em 90 dias

A meta concreta — e o jeito de cobrar essa promessa — é redução de mais de 30% no custo por ticket em 90 dias, com devolução do setup fee se não acontecer. Mas o número que costuma pesar mais na decisão do CTO não é o custo por ticket: é o de FTEs de engenharia que deixam de ser consumidos. Tirar 600 escalonamentos/mês da fila do time de produto não é uma economia de R$ 42.000 — é a feature que volta para o roadmap. Esse é o item que raramente aparece na comparação com chatbot, porque chatbot não toca nesse bloco.

O contraste com as alternativas, sem vender, fica assim. Equipe interna: escala linear, custo fixo crescente, ainda escalona o bloco caro. Chatbot generalista (Fin, Decagon, Sierra): deflexiona o bloco barato, cobra por resolução, devolve o bloco caro intacto. Agente operacional vertical: ataca o bloco caro porque executa a ação, e cobra com ROI amarrado a custo por ticket. São propostas para problemas diferentes — e a maioria das empresas descobre tarde que comprou a solução do bloco que já estava barato.

Especialização vertical é o que torna a execução confiável

Executar ação em sistema de produção não é o mesmo em qualquer SaaS — e muda de uma vertical para outra. Um agente que vai reprocessar uma sincronização, destravar um provisionamento ou corrigir um cadastro precisa entender a semântica do domínio do cliente. Num produto com billing por seats, é saber que rebaixar um plano no meio do ciclo gera proration que precisa bater com o contrato. Num SaaS de RH, é a diferença entre um colaborador "desligado" e "afastado" no fluxo de folha. Numa fintech, é a diferença entre uma transação PIX devolvida e uma estornada, ou o que pode e o que não pode ser alterado numa NF já transmitida.

É aqui que o generalista perde para o especialista no domínio do cliente. Um agente treinado num knowledge graph horizontal sabe abrir um ticket; ele não sabe que reverter um upgrade exige recalcular a fatura proporcional, nem que reemitir uma NF transmitida exige cancelamento e nova emissão dentro de uma janela fiscal — e que fazer isso errado gera passivo. A especialização no domínio não é marketing — é o que separa um agente que você autoriza a executar de um que você só autoriza a responder. E a confiança para deixar o agente executar é justamente o que destrava o bloco caro da unit economics.

O Conductor: orquestração sênior, não call center

Deixar um agente executar ações em produção sem supervisão seria irresponsável — e não é o modelo. Sobre a camada de agentes opera um Conductor humano sênior, e a função dele não tem nada a ver com call center. Ele não atende ticket. Ele orquestra: define quais tipos de ação o agente executa direto e quais exigem revisão, aprova as ações de alto impacto que chegam com requires_review: true, monitora padrões entre contas e ajusta os workflows quando o comportamento dos sistemas do cliente muda.

Na prática, o Conductor é quem olha para a fila de ações sinalizadas — a exclusão de dados de um cliente, a alteração de plano com impacto de billing, ou o refund acima do limite numa fintech — e decide com contexto. É uma função de poucos humanos para muitos tickets, o oposto da régua de um call center, onde a relação é de um humano para uma fila. É por isso que a curva de custo não acompanha o volume: você adiciona volume sem adicionar gente na mesma proporção, porque a execução é do agente e a supervisão é concentrada.

É também o que torna o modelo seguro o suficiente para um SaaS aprovar. As ações reversíveis e de baixo risco fluem; as irreversíveis ou sensíveis passam por um sênior antes de tocar o sistema. Você não está escolhendo entre velocidade e controle — está separando uma coisa da outra por tipo de risco.

Antes de aprovar o próximo headcount

O argumento para terceirizar suporte deixou de ser sobre custo de mão de obra e passou a ser sobre qual bloco da sua operação você está, de fato, atacando. Contratar e usar chatbot resolvem o bloco barato. O que define se a operação escala — ou só engorda — é o bloco caro: os 15% a 25% de tickets que exigem execução técnica e hoje consomem o tempo mais caro da casa.

Se você quiser testar a tese sem reescrever sua stack, o caminho mais honesto é olhar para os seus próprios dados primeiro: pegue os escalonamentos do último mês, separe os que viraram ação manual de alguém de produto, e calcule quanto custou — em reais e em features adiadas. Esse número, e não o custo por ticket do nível 1, é o que diz se vale a conversa. A operação roda em 14 dias, sobre os sistemas que você já tem, sem você precisar construir a camada de integração. O resto é a matemática que você já fez ao ler até aqui.