Como trocar de fornecedor de IA de suporte sem prejudicar os clientes

Por que trocar de fornecedor de IA é um problema de transferência

Eu construo agentes de IA na eesel e sou chamado para muitas conversas do tipo "queremos migrar para outra IA". Quase nenhuma começa com "a IA é ruim". Nas ligações de vendas da eesel neste ano, um operador de e-commerce no Zendesk tinha testado a IA nativa, achado cara demais e não boa o bastante, e queria trocar "ontem". Uma equipe de suporte de hardware (cerca de 250 tickets por mês, quatro idiomas, também no Zendesk) estava sendo forçada a sair da ferramenta de IA porque o fornecedor mudava a forma de fazer negócio. Nenhum dos dois escolheu a data. Outra pessoa escolheu.

É nesse momento que as pessoas pulam a parte cuidadosa. Quando o prazo era ontem ou o fornecedor o definiu, uma migração brusca parece a opção rápida. Em geral não é, porque o que quebra não são as respostas da nova IA. É a transferência entre dois sistemas que acreditam ser donos da conversa. A eesel passou anos colocando agentes de IA em filas de suporte reais, e nós simulamos cada implantação contra tickets históricos antes de ir ao ar porque já vimos um bot de tom confiante dar respostas erradas a clientes reais. Ainda assim, a maior parte do que dá errado em uma troca é encanamento: dois bots respondendo ao mesmo chat, tickets criados duas vezes, histórico que não veio junto.

Então este é o reenquadramento que eu manteria na cabeça. Você não está movendo uma IA. Você está movendo uma decisão de roteamento, e pode movê-la uma fatia por vez, para a frente e para trás, enquanto a configuração antiga ainda existir. Este guia percorre isso na ordem em que eu faria, com os controles próprios de cada helpdesk conferidos na documentação de cada fornecedor em 20 de outubro de 2026: inventário, construir e testar à parte, sombra, piloto, aumento gradual, com chats em andamento, sua equipe, gatilhos de rollback e datas de contrato tratados em paralelo.

Dois posts vizinhos cobrem peças que não vou repetir. Se você ainda está decidindo se coloca uma IA de terceiros sobre a IA integrada do seu helpdesk, leia camada de IA vs IA integrada. Se você quer a mecânica semana a semana de um piloto, como rodar um piloto de IA de suporte a traz.

Etapa 1: faça o inventário do que a IA antiga faz e do que migra

Comece anotando tudo o que a IA antiga faz, inclusive o que ninguém lembra de ter configurado. Depois separe a lista em duas pilhas: o que vive no seu helpdesk (e migra com uma exportação, ou simplesmente fica) e o que vive dentro do fornecedor de IA (e precisa ser reconstruído). O resumo honesto dessa segunda pilha é que seu conhecimento é portátil e sua configuração não é.

Esta é a classificação com a qual eu começaria, com o que a documentação de cada helpdesk diz sobre tirar as coisas de lá.

A última linha é a que se esquece. Se você não captura os números da IA antiga antes de qualquer mudança, acaba julgando a nova contra uma lembrança. Puxe as últimas 8 a 12 semanas dos tipos de ticket que pretende mover: taxa de resolução (contada do jeito que seu fornecedor antigo conta), taxa de transferência, recontato em até sete dias, tempo de primeira resposta e CSAT. Os fornecedores definem "resolvido" de formas diferentes, por isso eu leria o guia de taxa de resolução da IA e a lista de KPIs de atendimento ao cliente antes de escolher as definições.

Mais um hábito de inventário que compensa: escreva o comportamento da IA antiga como regras simples: o que ela recusa, quando transfere, que tom usa, que assuntos nunca toca. Essas frases viram as instruções da nova IA e são a parte de uma configuração que realmente migra. Se sua base de conhecimento também precisa de uma arrumação antes de alimentar uma nova IA, uma auditoria da base de conhecimento é a semana mais barata que você vai gastar.

Etapa 2: construa e teste a nova IA sem tocar na produção

Construa a nova IA à parte e teste onde ela não possa alcançar um cliente. Todo helpdesk grande oferece um lugar para isso, e a maioria não cobra por ele.

• Zendesk: testar em um sandbox não consome resoluções automatizadas, e o widget de teste e o simulador de conversas também não, embora testar em produção possa consumir. O Zendesk também sugere testadores que não construíram os fluxos. O guia de sandbox vs produção cobre a configuração.
• Freshdesk: o Email AI Agent tem uma aba Evaluate em que você pode montar um conjunto de testes à mão, gerar e-mails de exemplo ou importar tickets históricos resolvidos. O Freshdesk recomenda pelo menos 20 consultas representativas antes de implantar, e sua prévia não toca conversas ao vivo. Veja também configuração do sandbox do Freshdesk.
• Gorgias: conversas de teste no Playground não são cobradas e não enviam mensagens reais aos compradores.
• HubSpot: o agente de clientes tem testes em lote, em que você avalia cada resposta como boa ou ruim.

Essas ferramentas testam a IA própria de cada fornecedor, então a IA do novo fornecedor é testada na ferramenta do novo fornecedor. O que eu acrescentaria é um conjunto de testes compartilhado que as duas IAs respondam: cerca de 50 tickets reais da faixa que você pretende mover primeiro, rotulados por tipo, incluindo os difíceis (o cliente irritado, a pergunta que sua documentação responde errado, o pedido que deveria ir para uma pessoa). Quando a nova IA e a antiga respondem os mesmos 50, as diferenças deixam de ser opiniões. O guia de testes de agentes de IA de suporte tem uma sequência completa de testes, e os testes adversariais trazem tickets cabeludos para emprestar.

É aqui também que a simulação da eesel ganha seu lugar. Você pede no chat que ela rode uma simulação nos seus tickets recentes, e ela os reproduz e pontua suas respostas contra o que sua equipe realmente enviou, depois lista as lacunas e sugere mudanças nas instruções. Ela não prevê uma taxa de resolução nem um custo, e eu não confiaria em uma ferramenta que previsse antes de um único cliente ter visto uma resposta. Ela diz, em uma tarde, quais tipos de ticket estão prontos.

Etapa 3: migre em fases, primeiro sombra, depois piloto, depois aumento gradual

Agora a parte em que quase todo manual de implantação concorda: migre em fases em vez de escolher uma data. A IA antiga continua respondendo tudo o que a nova ainda não conquistou, e a fatia sobe em degraus.

Uma fatia de 5 a 10% de um tipo de ticket é o tamanho que eu escolheria por um motivo: grande o bastante para mostrar padrões, pequena o bastante para que uma resposta errada chegue a um punhado de clientes e não à metade da sua fila. E uma regra mantém os números legíveis: mude uma coisa por vez e registre a data, porque uma fatia maior e uma instrução nova na mesma tarde significam que você não sabe qual movimentou o resultado.

Como enviar uma fatia depende do helpdesk. Veja o que a documentação de cada fornecedor oferece.

A caixa de diálogo do Zendesk acima mostra a restrição que molda tudo: um agente de IA por canal. Se a IA antiga é a própria do Zendesk e a nova é uma camada de terceiros, você dividirá por canal ou por uma tag ou fila pela qual a camada de terceiros filtre, porque os controles do Zendesk só governam a IA do próprio Zendesk. Escolha uma regra de divisão que os dois lados enxerguem (um canal, uma tag, uma fila, uma lista de clientes) e escreva-a no plano.

O calendário da Luxedo é o que eu copiaria, mesmo que ela não estivesse substituindo outra IA. A fabricante de projetores Luxedo conectou o Gorgias à eesel em julho de 2026, passou agosto construindo o conhecimento e as instruções e ligou o gatilho de tickets na última semana de agosto. A eesel deixa uma nota interna com um rascunho de resposta e um resumo, e uma pessoa o envia. Entre 8 de agosto e 8 de setembro ela preparou 21 tickets. Ninguém se surpreendeu com nada, que é justamente o objetivo de um aumento gradual.

Aqui vai um planejador para a sua própria versão. Informe sua data de início e a duração das fases, e a data de renovação e o aviso prévio do contrato antigo. Ele monta o calendário e mostra se o prazo do seu aviso cai antes ou depois da decisão do piloto, que é a parte que surpreende as pessoas.

Etapa 4: pare os tickets duplicados quando há um bot de terceiros

Se a IA antiga ou a nova for um bot de terceiros no Zendesk, há uma mudança de regra que você não pode pular. O próprio aviso do Zendesk diz que, a partir de 4 de maio de 2026, ele impõe tickets de agente de IA para todas as conversas tratadas por bots, não apenas as escaladas, e que os tickets de agente de IA se tornam o mecanismo exclusivo de criação de tickets para conversas tratadas por agentes de IA e bots de terceiros. Se seu bot também estiver configurado para criar seus próprios tickets em chats só do bot, agora você recebe dois tickets para uma conversa.

O aviso pede três coisas, e eu as trataria como lista de verificação tanto para o bot antigo quanto para o novo:

1. Audite a criação de tickets. Procure ações de "criar ticket" na plataforma do bot e webhooks personalizados que criam tickets a partir de eventos do bot. O Zendesk sugere a ação releaseControl se você quiser anexar metadados a tickets resolvidos.
2. Teste e avise. Experimente a integração em um sandbox antes de a mudança chegar à produção e mostre à sua equipe o formato de ticket de agente de IA.
3. Desative o caminho legado. Desligue qualquer criação manual de tickets que duplique isso.

O Zendesk acrescenta um alívio: interações com bots de terceiros não geram cobrança de resolução automatizada, então esses tickets dão visibilidade, não uma fatura. Eles ocupam espaço, porém. Tickets de agente de IA contam para os limites de armazenamento, são somente leitura para a maioria dos usuários, e triggers e automações não disparam neles até que uma conversa seja escalada para uma pessoa. Veja como isso aparece da cadeira do administrador, em um tópico publicado poucos dias antes de eu escrever isto:

"The main issue is that there appears to be no way to disable Zendesk from creating an AI Agent ticket for EVERY SINGLE interaction an end user has with the bot, not just handoffs."

u/VestedCrayon, r/Zendesk

Uma resposta no mesmo tópico resume bem a vantagem prática:

"Luckily they’re easy to exclude from reports and views, but definitely annoying to parse through when you need to find something."

u/yogahippie, r/Zendesk

O mecanismo por baixo é o switchboard do Zendesk, e entendê-lo evita a maioria dos bugs de sobreposição. Cada conversa tem exatamente uma integração de switchboard ativa por vez, e as outras ficam em espera. Então, durante uma execução em paralelo, "os dois bots ao vivo no mesmo canal" significa que um bot é dono de cada conversa, e o respondente padrão decide quem recebe as novas. Há uma aresta afiada para conhecer: se você excluir uma integração de switchboard que estava ativa em uma conversa, as novas mensagens são reatribuídas à integração padrão sem um webhook passControl. Remova o bot antigo depois que suas conversas abertas tiverem fechado, não antes. O guia de orquestração de switchboard aprofunda o tema.

Em outros helpdesks o mesmo princípio aparece com outras palavras. O Freshdesk permite que cada origem de ticket tenha um agente de IA ativo e sinaliza um conflito se você tentar mapear um segundo. A solução é a mesma em todo lugar: um dono por conversa, decidido por uma regra que você escreveu. E duplicatas não são só tickets. O Gorgias, por exemplo, desativa o Article Recommendations automaticamente quando o AI Agent entra no ar no chat e sugere rever qualquer regra de resposta automática personalizada para que os compradores não recebam duas mensagens. Liste suas antigas mensagens de boas-vindas e respostas automáticas na Etapa 1 para poder desligá-las de propósito.

Etapa 5: rode as duas lado a lado e compare em igualdade de condições

Durante o piloto e o início do aumento, você terá as duas IAs ao vivo em fatias diferentes. Aproveite. A comparação mais útil não é a nova IA contra o trimestre passado, e sim a nova IA contra a IA antiga nos mesmos tipos de ticket nas mesmas semanas, porque a sazonalidade, um lançamento de produto ou uma mudança de preço atingem as duas fatias igualmente.

Mantenha um grupo de controle na IA antiga enquanto sobe, do mesmo modo que um piloto mantém uma fila de controle só humana. A documentação de A/B do Zendesk define o primeiro grupo como grupo de controle, e o guia do piloto explica como dimensioná-lo. Depois compare quatro coisas, definidas de forma idêntica para os dois lados:

• Resolução: conversas que a IA encerrou sem recontato em sete dias, não o indicador de resolvido do próprio fornecedor.
• Taxa e qualidade da transferência: com que frequência ela transfere e se quem recebe precisa perguntar tudo de novo.
• Recontato e CSAT: clientes voltando pelo mesmo problema e como avaliam a conversa.
• Custo por conversa tratada: cada fornecedor cobra uma unidade diferente, então converta as duas em custo por conversa que sua equipe teria respondido de outra forma.

Esse último é fácil de errar porque as unidades de cobrança diferem muito: o Zendesk cobra por resoluções automatizadas, o agente do HubSpot roda com créditos do HubSpot, e o Freddy do Freshdesk tem seu próprio preço por sessão. Eu conferiria a página de preços atual de cada fornecedor antes de montar a comparação e usaria o guia de métricas de IA para CX para manter as definições alinhadas.

Etapa 6: proteja as conversas já em andamento

Esta é a seção que eu leria duas vezes. Um cliente que começou um chat com a IA antiga às 14h55 não deveria ser entregue a outra IA às 15h porque você mudou uma configuração. A regra: direcione as novas conversas para a nova IA e deixe as abertas terminarem onde começaram.

O comportamento dos próprios fornecedores na maior parte concorda com essa regra, o que ajuda:

• HubSpot: se você desligar o agente de clientes, ele continua tratando as conversas existentes até a conversa ser resolvida, mas não recebe novas.
• Freshdesk: a implantação é imediata e cobre apenas tickets novos. Tickets que chegaram antes não são respondidos retroativamente.
• Zendesk: um ticket de agente de IA de mensagens conta como em andamento até passarem quatro dias sem resposta, a IA liberar o controle ou (para bots de terceiros) o bot decidir que está resolvido.

Depois vem a transferência e a devolução entre uma IA e suas pessoas, que se comporta de forma diferente do que a maioria das equipes supõe. Na mensageria do Zendesk, um agente continua como primeiro respondente até o ticket ser fechado. A devolução só acontece quando o ticket passa de Resolvido para Fechado, e por padrão isso leva quatro dias, então um cliente que volta nessa janela ainda cai na conversa antiga com a pessoa, não com a IA. Você pode encurtar a automação "fechar ticket 4 dias após resolvido" para uma hora ou estendê-la a 28 dias, mas mantenha uma pequena folga se usar CSAT, pois a pesquisa dispara no momento em que um ticket é marcado como Resolvido. Durante uma migração isso importa de um jeito específico: o comportamento de "quem responde clientes que voltam" é governado por esse temporizador, não pela sua configuração de IA.

O Gorgias oferece outro conjunto de controles de transferência: tópicos que sempre escalam, uma chave para definir se a IA avisa os clientes por e-mail ou SMS que está transferindo e, no chat, uma etapa de confirmação antes de transferir. Qualquer que seja o helpdesk, garanta que a transferência da nova IA leve o contexto de que uma pessoa precisa, para que o cliente não se repita. A lista de boas práticas de transferência de agentes de IA e o guia de transferência no Zendesk cobrem o que uma boa transferência contém.

Quanto dura a cauda? Veja seus próprios dados: quanto tempo os chats tratados por IA ficam abertos antes de fechar e qual é o seu maior tempo aberto realista? Esse número é por quanto tempo a IA antiga precisa ficar ligada para os chats existentes depois que a nova assume todos os novos.

Etapa 7: informe sua equipe antes do primeiro dia ao vivo

Seus agentes são quem vai notar os problemas primeiro, e os mais propensos a descobrir a troca por um cliente irritado se você não avisar. Dê a eles um manual de uma página antes de a sombra começar. O meu tem seis linhas:

1. O que muda e quando. O calendário de fases, em palavras simples, com a data em que cada tipo de ticket migra.
2. O papel deles. Eles são os revisores. Quinze minutos por dia lendo as conversas da IA de ontem e marcando as erradas com uma tag.
3. O que verão de diferente. No Zendesk, tickets de agente de IA são somente leitura para a maioria dos usuários e os escalados voltam como Novos; nos outros helpdesks, o rótulo ou nota que a nova IA deixar.
4. O que fazer numa transferência. Quem assume, onde está o contexto e o que dizer a um cliente que pergunta "eu estava falando com um bot?".
5. Como relatar uma resposta ruim. Uma tag, um canal, respondido no mesmo dia. Uma convenção de tags como ai_old e ai_new torna possível a comparação da Etapa 5; tags de suporte com IA tem ideias de nomes.
6. Quem pode pausar e quando. Nomeie uma pessoa em cada turno.

O padrão que mais ouço nas ligações de vendas é que as equipes querem primeiro um copiloto e depois a automação total: a IA redige respostas para os agentes e é promovida quando a confiança existe. Isso se encaixa perfeitamente numa troca, porque o modo sombra é exatamente isso. Escrever a rotina de revisão no seu SOP de suporte e manter o processo de mudança de políticas ligado a ela evita que um novo prazo de devolução vire, sem ninguém notar, uma resposta errada da nova IA na terceira semana.

Gatilhos de rollback, escritos antes de começar

Decida o que conta como falha enquanto ninguém está chateado. Quem escreve o gatilho no meio de um incidente tende a se convencer a não usá-lo. Esta é a tabela com a qual eu começaria; os limites são pontos de partida meus, então ajuste-os ao seu volume.

"Rollback" deve significar virar uma configuração, não reconstruir algo. Por isso a IA antiga continua configurada durante a janela de rollback: sua alavanca de pausa é um único botão, como desmarcar o canal no Zendesk, o limite diário de conversas no Freshdesk, a chave do canal no Gorgias ou desligar o agente de clientes no HubSpot. O HubSpot tem uma peculiaridade que vale conhecer: um agente de clientes não pode ser excluído depois de criado, só pausado, então o antigo ainda estará lá se você precisar. Registre cada pausa com data e motivo. Uma pausa não é uma troca fracassada, é o sistema funcionando.

Sobreposição de contratos e janela de cancelamento

O jeito mais barato de trocar é pagar duas IAs por algumas semanas. Parece desperdício e ainda assim é mais barato do que a alternativa, que é cancelar a antiga no início do piloto e descobrir na terceira semana que não dá para voltar.

Eu manteria três regras no lado financeiro:

• Mantenha o plano antigo durante a janela de rollback. Se seu contrato termina antes, peça contrato mensal para a sobreposição. O planejador acima mostra exatamente quantos dias faltariam.
• Leia seu próprio formulário de pedido sobre o aviso prévio. Renovação automática e prazos de aviso são termos contratuais, não documentação de produto, então não posso dizer quais são os do seu fornecedor. Posso dizer que um aviso de 60 dias pode cair antes da decisão do seu piloto, e esse é o caso que vale a pena negociar.
• Conheça cada unidade de cobrança durante a sobreposição. O Zendesk diz que conversas de bots de terceiros não geram cobrança de resolução automatizada, então sobrepor um bot de terceiros custa o plano desse bot, não a tarifa por resolução do Zendesk. O agente do HubSpot deixa de ser atribuído a novas conversas se seus créditos acabarem, um evento de cobrança que parece uma queda.

Antes de cancelar qualquer coisa, exporte o que quiser guardar. Pergunte por escrito ao fornecedor antigo quais dados ele pode entregar (logs de conversas, análises, configuração) e por quanto tempo após o cancelamento. Depois feche o ciclo no planejador: sua data de aviso deve cair depois da decisão do piloto, dentro ou depois da janela de rollback.

Erros que eu evitaria

• Trocar nas suas semanas mais movimentadas. Escolha um período calmo: a Norden-Frisia, uma linha de balsas cuja agenda enche a partir de maio, testou a eesel em fevereiro e depois dimensionou seu plano ao volume sazonal.
• Mover uma conversa no meio do chat.
• Mudar duas coisas ao mesmo tempo e depois discutir qual quebrou os números.
• Comparar a nova IA com o trimestre passado em vez de com a fatia simultânea da IA antiga.
• Cancelar no início do piloto porque ele "parece bom".

Como a eesel lida com uma troca

Sou parcial, então aqui vai a versão direta de onde a eesel se encaixa e onde não. A eesel é uma colega de IA para helpdesk que se conecta ao helpdesk que você já tem, então uma troca não exige mover seus tickets para lugar nenhum. Ela lê sua central de ajuda, suas macros e tickets passados direto do helpdesk, por isso não precisa de nada exportado da IA antiga. Estas são as integrações que mais se ativam:

• Zendesk
• Freshdesk
• Gorgias
• HubSpot

Isso corresponde às etapas acima:

• Portabilidade: macros são o ativo mais portátil que você tem. A Koffer.ch, uma loja suíça de malas no Freshdesk, lê primeiro suas macros e usa uma correspondente palavra por palavra, em qualquer dos quatro idiomas em que o cliente escreveu. Toda resposta é um rascunho que uma pessoa envia.
• Treinamento e testes: a Norden-Frisia, uma linha de balsas alemã, conectou o Zendesk durante um teste de uma semana em fevereiro de 2025, trouxe suas macros e os tickets dos últimos três meses e assinou em poucos dias. Antes de qualquer entrada no ar, a simulação reproduz seus tickets passados para você ver as lacunas primeiro.
• Fases: você pode começar com a eesel acordando apenas com uma menção @eesel em uma nota interna, depois passar para cada mensagem de ticket de cliente e mantê-la em rascunhos enquanto revisa. Essa é a sua semana de sombra embutida.
• Preço durante a sobreposição: a eesel tem planos fixos mensais de créditos, não uma tarifa por resolução. Um ticket ou um chat é um crédito, não importa quanto dure, há um plano gratuito com 100 créditos e sem cartão, e o Teammate começa em US$ 299 por mês com 500 créditos, com todas as integrações, agentes e usuários incluídos.

Vale dizer os limites com clareza. A eesel não importa fluxos, intents nem logs de conversas de outro fornecedor que nunca viraram tickets, então você os reconstrói como instruções, o que para a maioria das equipes leva menos tempo que a construção original. E se você só quer a IA que seu helpdesk já inclui, não precisa de uma camada; as páginas de comparação com o Freddy, o Gorgias AI Agent e o HubSpot Breeze mostram onde estão os prós e contras.

Experimente a eesel

Se você está saindo do Zendesk AI agents, do Freddy, do Gorgias AI Agent, do HubSpot Breeze ou de um bot de terceiros, experimente a eesel primeiro na sua própria fila. Conecte seu helpdesk, deixe-a aprender com seus tickets passados, rode uma simulação e comece em rascunhos enquanto sua IA atual continua respondendo. É a semana de sombra deste guia, e o plano gratuito a cobre.