Gestão de mudanças nas políticas de suporte: como lançar uma política nova em todo lugar

O que é gestão de mudanças nas políticas de suporte?

É o processo de mudar uma regra voltada ao cliente e garantir que cada canal, pessoa e ferramenta que repete essa regra passe para a versão nova no mesmo dia. Pense em um prazo de devolução de 30 dias que vira 14, uma taxa de reposição que aparece, um reembolso que agora exige uma foto, ou uma promessa de tempo de resposta (um SLA) que passa de 4 horas para 1 dia útil.

Eu atendo a fila de suporte da eesel todos os dias, e o padrão é sempre o mesmo. O dono da política (financeiro, jurídico, operações) atualiza a página da política e avisa a líder de suporte. A líder atualiza o artigo principal da central de ajuda. Aí, nas três semanas seguintes, continuam chegando tickets em que o cliente cita de volta a regra antiga, porque a leu em uma resposta salva, em uma tradução para o francês, em um e-mail de confirmação de pedido ou em uma resposta do chatbot.

Essa é a ideia central deste guia: uma política não é um documento, são seis ou sete cópias de um documento, e a gestão de mudanças é o trabalho de encontrar todas elas.

Onde as cópias antigas da política se escondem

Antes de mudar qualquer coisa, você precisa de um inventário. Estes são os lugares que eu confiro sempre, mais ou menos em ordem de quão frequentemente dão problema.

1. O artigo principal da central de ajuda. Todo mundo lembra deste.
2. Outros artigos que mencionam a regra de passagem. A FAQ de envio que diz "devoluções são grátis em até 30 dias". O artigo de cartão-presente. A página de pedidos internacionais. Esses são os que ninguém lembra.
3. Traduções. Cada versão de idioma é uma cópia própria e não é atualizada quando a inglesa é.
4. Macros e respostas salvas. Geralmente a maior pilha e a mais difícil de pesquisar (mais sobre isso abaixo).
5. Conhecimento do agente de IA. Artigos da central de ajuda, PDFs enviados, Google Docs, páginas de site rastreadas e qualquer regra ou "guidance" que você digitou direto na ferramenta de IA.
6. Fluxos de chatbot e modelos de e-mail. Confirmações de pedido, textos do portal de devolução, respostas automáticas disparadas por tags.
7. A cabeça dos seus agentes. A regra que eles digitaram de memória 400 vezes.

O problema de busca de que ninguém avisa

Esta parte me surpreendeu quando li a documentação dos fornecedores. A maioria dos helpdesks só documenta a busca de macros e respostas salvas pelo nome, não pelo texto dentro delas. A busca de macros do Zendesk funciona pelo nome ou parte do nome. Os snippets do HubSpot são pesquisados por nome. Help Scout e Zoho Desk também buscam respostas salvas e snippets por nome. Então você não consegue digitar "30 dias" e obter todas as respostas que prometem 30 dias.

O jeito é exportar. O Freshdesk permite exportar respostas prontas para CSV, editar a coluna Content HTML e reimportar, desde que você não mexa no Canned Response ID. O Gorgias faz o mesmo com CSVs de macros identificados por id. No Zendesk, exportar macros dá um arquivo que você pode pesquisar com Ctrl+F. Com o texto em uma planilha, achar cada cópia da regra antiga leva minutos em vez de uma tarde de cliques.

O Help Scout tem uma armadilha extra. As respostas salvas ficam por caixa de entrada, e o botão Copiar cria uma resposta separada na outra caixa. Cinco caixas significam cinco edições.

É também por isso que bibliotecas de macros bagunçadas doem mais do que parecem. Em uma ligação de vendas da eesel, uma marca DTC no Gorgias com cerca de 7.000 tickets por mês descreveu seu conhecimento como espalhado entre ferramentas de SOP, vídeos do Loom sem transcrição e macros desatualizadas. Toda mudança de política em um cenário assim vira um projeto de arqueologia. Se o seu é parecido, meu guia sobre gerenciar macros é uma boa primeira limpeza.

Quão rápido seu agente de IA percebe a mudança?

Esta é a seção que eu mandaria todo líder de suporte ler duas vezes. Quando você edita um artigo, um agente humano vê a versão nova na próxima vez que o abrir. Seu agente de IA talvez não.

A regra prática segundo a documentação dos fornecedores: edições em artigos dentro do seu helpdesk chegam rápido à IA, enquanto edições em qualquer coisa fora dele (uma página de site, um Google Doc, uma página de política rastreada) podem ficar defasadas até alguém ressincronizar.

Aqui está o detalhe, tudo da central de ajuda de cada fornecedor:

A linha do Gorgias merece uma olhada mais de perto, porque lojas Shopify mantêm a política de devolução e envio no site da loja. O Gorgias puxa essas páginas para snippets de perguntas e respostas que você não pode editar, e ressincronizar é permitido uma vez a cada 24 horas. Se você mudar a página de devoluções às 9h, seu agente de IA pode estar citando o prazo antigo naquela tarde. A alternativa do próprio Gorgias, quando você não pode esperar, é desativar o snippet com o conteúdo desatualizado.

Duas cópias que se contradizem são piores que uma cópia desatualizada

O Gorgias também publicou o aviso mais claro que encontrei sobre cópias conflitantes. A documentação de conhecimento deles diz "guidance carries the most weight" e dá este exemplo exato: se um artigo da central de ajuda diz que o prazo de devolução é de 30 dias mas uma guidance diz 14, o agente de IA "might not respond the same way every time". Esse é o modo de falha realista de uma mudança de política pela metade. Não uma resposta errada toda vez, mas um cara ou coroa. O recurso Opportunities do Gorgias (em beta) pode sinalizar esses casos como "Resolve knowledge conflict" e mostrar os dois conteúdos lado a lado.

O Help Scout tem uma versão da mesma armadilha. Seu AI Answers permite adicionar pequenas "Improvements" para ajustar respostas. Se você corrige o artigo do Docs e esquece a Improvement antiga, a IA pode continuar repetindo a regra antiga. Se você roda IA em qualquer helpdesk, o hábito de gestão da base de conhecimento que mais importa durante uma mudança de política é apagar a versão antiga, não só adicionar a nova.

Por que isso importa mais do que antes

Em fevereiro de 2024, o Civil Resolution Tribunal da Colúmbia Britânica decidiu Moffatt v. Air Canada. O chatbot do site da Air Canada disse a um cliente em luto que ele podia solicitar uma tarifa reduzida de luto em até 90 dias após comprar a passagem, mesmo depois de viajar. A página de luto para a qual o chatbot apontava dizia que a política não se aplicava após a viagem. A Air Canada argumentou, nas palavras do tribunal, que não podia ser responsabilizada por informações de seus representantes, "including a chatbot". O tribunal chamou isso de "a remarkable submission" e escreveu: "It makes no difference whether the information comes from a static page or a chatbot." Também disse que os clientes não deveriam ter de conferir uma parte de um site com outra. A companhia aérea pagou US$ 812,02 em danos, juros e custas.

O valor é pequeno. O princípio não é. Quando duas das suas cópias se contradizem, o cliente pode confiar na que leu. Um comentarista do Hacker News apontou a causa mais provável com clareza:

"I wonder whether the bot hallucinated the wrong information or whether the policy changed and the bot simply wasn't updated / retrained. The latter seems more likely but less interesting, akin to information on a boring HTML page getting overlooked during a site update."

danepowell, Hacker News

Não é só com companhias aéreas. Em abril de 2025, o bot de suporte com IA da Cursor disse a um usuário que os logins eram restritos a um dispositivo. O cofundador da Cursor respondeu no Reddit que "we have no such policy", e a discussão no Hacker News passou de 600 comentários. Um agente de IA com uma política desatualizada ou ausente não fica quieto. Ele preenche a lacuna.

Um lançamento de mudança de política passo a passo

Este é o cronograma que eu usaria para qualquer mudança voltada ao cliente, de um ajuste de redação a uma nova política de reembolso. Para uma mudança grande, estique a primeira metade. Para uma pequena, comprima em dois dias. A ordem continua a mesma.

1. Escreva uma nota de mudança de uma página (dia -7)

Antes de qualquer pessoa editar qualquer coisa, anote cinco itens em uma página:

• A regra antiga e a regra nova, palavra por palavra.
• A data e a hora de início, com fuso horário.
• A quem se aplica. Esta é a pergunta da proteção a clientes antigos: um pedido feito no dia 3 recebe os 30 dias antigos ou os 14 novos? Escolha um corte (a data do pedido é a mais comum) e anote.
• As exceções e quem pode aprová-las, com números. "O líder do time pode aprovar devoluções de até 30 dias para pedidos abaixo de US$ 200" dá para seguir. "Use seu bom senso" não.
• O motivo em uma frase que você pode dar aos clientes.

Esta última linha importa mais do que parece. Agentes que sabem explicar por que uma regra mudou lidam com a reação com calma. Agentes que não sabem acabam pedindo desculpas por ela, e os clientes entendem isso como "essa regra é negociável". Se você já mantém um SOP de atendimento ao cliente para reembolsos, a nota de mudança vira o diff que você aplica a ele.

2. Faça o inventário de cada cópia (dia -7 a dia -5)

Percorra os sete lugares listados acima. Exporte as macros para uma planilha e procure os números e frases antigos, não só o nome da política. Pesquise na central de ajuda os mesmos termos. Confira cada idioma.

Depois use dados de uso para priorizar. O Zendesk pode ordenar macros por uso nos últimos 30 dias no Suite Growth e acima. O Freshdesk tem um relatório de uso de respostas prontas, o Front tem um relatório de modelos de mensagem, e o Gorgias permite monitorar o uso de macros na lista de macros. A resposta que seu time envia 50 vezes por dia é corrigida primeiro.

3. Prepare as edições para que virem juntas (dia -5 a dia -3)

O objetivo é que todas as cópias mudem no mesmo instante. Quanto o helpdesk ajuda depende muito do seu plano.

Zendesk tem as melhores ferramentas e tranca a maioria delas no Enterprise. Os content blocks permitem escrever o parágrafo da política uma vez e reutilizá-lo em vários artigos. Edite o bloco e todo artigo que o usa é atualizado, sem republicar. Se você está em um plano menor, meu guia de gestão de conhecimento no Zendesk cobre as alternativas manuais. A publicação e a despublicação agendadas são só Enterprise, em intervalos de uma hora, e você pode aplicar o agendamento a todas as traduções de uma vez.

Uma pegadinha do Zendesk: se você depois restaurar uma versão antiga de um artigo que continha um content block, o Zendesk desvincula o bloco e cola o texto dele no artigo. Esse artigo para de receber atualizações do bloco, então a próxima mudança de política o deixa passar em silêncio. Meu post sobre o histórico de versões de artigos do Zendesk cobre o resto das ferramentas de revisão.

HubSpot (Service Hub Pro e acima, onde fica a base de conhecimento) tem um recurso útil aqui: Schedule update, que prepara uma edição de um artigo já publicado e a publica na sua data de início.

Freshdesk mostra um diff "Show changes" em cada versão salva e, depois que você edita o artigo principal, oferece marcar outras traduções como desatualizadas. Uma etapa formal de aprovação (Draft, In Review, Approved) é só Enterprise.

Gorgias mantém as edições de um artigo ou guidance publicados como rascunhos, e a documentação é clara: "AI Agent does not use drafts in real customer conversations." Ao publicar uma mudança na base de conhecimento, você pode adicionar um resumo da mudança. O exemplo do próprio Gorgias é "updated return window from 15 to 30 days" (fonte).

Front e Help Scout têm rascunhos e histórico de versões, mas nenhuma publicação agendada na documentação que consultei, então neles você edita ao vivo no dia. O Zoho Desk tem um recurso que nenhum outro tem para políticas com prazo: uma data de expiração de artigo que retira o artigo da central de ajuda automaticamente, com e-mails ao responsável 7 dias antes, na véspera e no dia. Perfeito para uma extensão de devoluções de fim de ano.

4. Oriente os agentes (dia -3)

Aqui há uma lacuna que eu não esperava: nenhum dos três grandes helpdesks que pesquisei mais de perto (Zendesk, HubSpot, Help Scout) documenta um recurso de comunicados embutido para agentes. As atualizações de política saem pelo Slack, e-mail ou pela reunião do time, e o helpdesk só ajuda no ponto de uso. O painel de conhecimento do Zendesk mostra artigos dentro do ticket, e os playbooks do HubSpot podem incorporar um artigo no registro do ticket.

Então a orientação fica por sua conta. O que funciona:

• Compartilhe a nota de mudança de uma página na sua base de conhecimento interna, não só um link para o artigo novo.
• Passe pelos três tickets que você mais espera: o cliente que comprou antes do corte, o cliente que comprou depois e está irritado, e o caso limite.
• Dê aos agentes a redação exata para "por que isso mudou" e o limite exato de exceção que podem aprovar sem perguntar.
• Diga onde está a macro nova e que a antiga vai sair.

O modo de falha quando isso é pulado é dolorosamente familiar para quem já trabalhou em uma fila. Uma discussão no r/callcentres perguntando como os times ficam sabendo de mudanças de política estava cheia de respostas como esta:

"Emails get buried so fast man I swear I will find a important update like 3 days later after already giving wrong info to 10 customers. The knowledge base is good when they actually update it but half the time someone forgot to change the article and then supervisor says oh yeah they sent email about that last week"

u/RaspyStoppage, Reddit r/callcentres

O único canal que as pessoas nessa discussão disseram que chegava de forma confiável foi uma reunião diária rápida antes do turno. Use uma no primeiro dia de uma mudança grande, mesmo que seu time nunca faça reuniões.

Se você dá feedback regular aos agentes, adicione a regra nova à ficha de avaliação de QA no primeiro mês. Um cenário de treinamento montado a partir do tipo de ticket complicado é o jeito mais rápido de dar confiança aos agentes mais novos.

5. Publique tudo no dia 0

Na data de início, vire tudo de uma vez:

1. Publique o artigo novo (ou deixe o agendamento fazer isso) e despublique ou redirecione o antigo.
2. Atualize ou substitua cada macro do seu inventário (macros do Gorgias e respostas prontas do Freshdesk aceitam reimportação por CSV). Arquive as macros antigas em vez de apagá-las se puder precisar do histórico. No Gorgias, arquivar é recuperável e apagar é permanente (fonte).
3. Atualize a IA. Edite ou remova a regra antiga na sua ferramenta de IA e ressincronize cada fonte externa que contenha a política. No Gorgias, ressincronize o site da loja. No Front, Freshdesk e Help Scout, ressincronize qualquer fonte de site ou documento.
4. Desligue o que você não consegue corrigir hoje. Desative o snippet desatualizado, despublique o PDF antigo, desligue a fonte.
5. Atualize os fluxos de chatbot e os modelos de e-mail automáticos.

No Zendesk Enterprise, há mais um truque que vale copiar. O próprio Zendesk sugere remover a verificação de artigos em massa depois de uma mudança grande (o exemplo dele é uma troca de nome de marca). Todo artigo que você deixa sem verificação cai em uma lista "Needs verification", e os responsáveis recebem e-mails a cada duas semanas até confirmarem. Para uma mudança de política, desverifique todo artigo que apareceu na sua busca por palavras-chave e deixe a lista cobrar as pessoas por você.

6. Teste a IA antes dos clientes (dia 0 a dia 1)

Escreva dez perguntas de teste do jeito que os clientes realmente perguntam: "ainda posso devolver isto, comprei no dia 2", "por que agora tem uma taxa", "o site de vocês dizia 30 dias". Faça cada pergunta à IA e leia a resposta e a fonte.

A maioria dos helpdesks hoje tem um lugar para fazer isso com segurança. O AI Agent Studio do Freshdesk tem uma aba Test que roda até 100 consultas de uma vez, e um modo sombra do agente de IA de e-mail que redige respostas como notas privadas. O Gorgias permite testar um rascunho no Playground antes de publicar, usando todas as suas configurações ao vivo com o rascunho no lugar. O Autopilot do Front tem uma simulação que roda cenários que você escreve.

Preste atenção especial ao caso da proteção a clientes antigos. Agentes de IA são bons em citar uma regra e menos bons em "depende da data do seu pedido", a menos que você diga como conferir. Se a IA não consegue consultar a data do pedido, a instrução certa é escalar esses tickets, não adivinhar.

7. Procure a redação antiga (dia 14)

Duas semanas depois, pesquise nas suas respostas enviadas os números e frases antigos. Cada resultado é uma cópia que você deixou passar. Retardatários comuns: a macro pessoal de um agente, um modelo dentro de uma automação, um artigo traduzido, um PDF que a IA ainda tem.

O Front documenta um jeito esperto de pegar cópias enviadas automaticamente: criar uma regra que marque mensagens enviadas cujo corpo contenha um trecho único do modelo, já que o relatório de modelos não conta respostas automáticas. A mesma ideia funciona em qualquer lugar onde você possa marcar pelo conteúdo da mensagem.

Depois coloque a revisão em um calendário, do mesmo jeito que você trataria conteúdo desatualizado da central de ajuda em geral. As revisões agendadas de artigos do Front (plano Professional e acima) enviam aos revisores um lembrete diário dos artigos vencidos, e as regras de verificação do Zendesk podem remarcar artigos de política a cada poucos meses.

Guia rápido de mudança de política para o seu helpdesk

Cada helpdesk trata de um jeito as quatro tarefas de um lançamento: preparar o artigo, achar respostas antigas, fazer a IA perceber e testar antes dos clientes. Escolha o seu.

Lidando com os clientes durante a transição

Os tickets das duas primeiras semanas vêm, na maioria, de pessoas que leram a regra antiga em algum lugar. Algumas coisas deixam tudo muito mais fácil.

Honre a versão que eles viram, dentro do razoável. Se um cliente consegue mostrar a redação antiga no seu próprio site ou no seu próprio e-mail, o jeito mais barato quase sempre é honrá-la uma vez e corrigir a cópia. Isso é, mais ou menos, o que a decisão do caso Air Canada diz que você acabaria fazendo de qualquer forma.

Escreva uma macro de transição. Se precisar de um ponto de partida, adapte um destes modelos de macro para reembolsos e devoluções. Uma resposta que diga: a política mudou nesta data, este é o motivo, isto é o que vale para o seu pedido e isto é o que posso fazer por você. Os agentes não deveriam improvisar isso 40 vezes por dia.

Dê aos agentes um limite de exceção de verdade. Se um agente precisa escalar toda pergunta sobre proteção a clientes antigos, sua fila dobra por duas semanas. Um limite claro em valor ou dias que eles possam aprovar sozinhos mantém os tickets andando.

Exceções inconsistentes são o que transforma uma mudança de política em uma briga longa. Quem trabalha no varejo sabe bem:

"Yup, customers have definitely played the "but the other guy did it for me!" card and it sucks because now there's precedent"

u/ralphcorleone, Reddit r/retailhell

Uma solução da mesma discussão: os gerentes digitam o próprio código para devoluções fora da política, de modo que toda exceção tem um nome. Em um helpdesk, o equivalente é uma nota interna e uma tag em todo ticket de exceção.

Marque os tickets com tags. Adicione uma tag como policy-change-returns a todo ticket sobre a mudança. Depois de um mês você saberá quantos clientes foram afetados, do que reclamaram e se a mudança precisa de uma explicação melhor na página da política. Se você usa marcação de tickets com IA, isso acontece sem que ninguém precise lembrar.

Erros comuns

• Atualizar o artigo principal e dar por encerrado. É uma cópia de seis ou sete.
• Deixar a versão antiga ativada ao lado da nova. Duas cópias conflitantes dão à IA um cara ou coroa, como mostra o exemplo de 30 contra 14 dias do Gorgias.
• Esquecer as fontes externas. Um PDF de política enviado à ferramenta de IA, um Google Doc, uma página de política rastreada. Essas são as cópias mais lentas de atualizar.
• Não decidir de antemão a regra para clientes antigos. Cada agente vai inventar a sua, e os clientes vão comparar. Um comentarista do Hacker News, reagindo a um provedor que cancelou planos anuais pré-pagos para aumentar preços, escreveu que "actually stick with them" se os planos pré-pagos tivessem sido preservados.
• Treinar a IA com tickets antigos. Se sua IA aprende com respostas passadas, os tickets dos últimos seis meses ensinam todos a regra antiga. Filtre a fonte de tickets para depois da data da mudança quando sua ferramenta permitir.

Como a eesel lida com uma mudança de política

Vou ser transparente sobre por que esse tema me importa tanto: ajudar times a lançar mudanças de regra para o colega de IA é uma boa parte do que faço na fila de suporte da eesel. E o time tem suas cicatrizes aqui. No começo, a eesel tinha clientes reensinando ao agente regras que achavam já ter salvo em uma conversa anterior. Por isso o produto atual mostra todas as regras salvas em uma única página de Instructions que você pode ler e editar, e por isso eu digo a todo mundo para conferir essa página depois de qualquer mudança.

Veja como uma mudança de política funciona com o colega de IA para helpdesk da eesel, passo a passo.

Fatos vão em documentos, regras vão em instruções. A documentação da eesel é direta nisso: não coloque preços ou políticas nas instruções do agente. Seu agente responde perguntas factuais pesquisando o conhecimento conectado, e as instruções governam "tone, policy and escalation". É o mesmo motivo pelo qual a recuperação vence o fine-tuning em centrais de ajuda: você muda um documento, não um modelo. Na prática, o texto da nova política de devolução fica no artigo da central de ajuda ou em um documento, e a regra de comportamento ("pergunte antes de aprovar qualquer devolução acima de 14 dias") fica nas instruções.

Mudar uma regra edita a regra antiga. Quando você corrige o agente no chat ("mudamos o prazo de devolução para 14 dias, pedidos antes do dia 1 ainda têm 30"), ele lê primeiro suas instruções atuais. Se uma regra já cobre o ponto, ele edita essa regra em vez de adicionar uma linha nova. É exatamente o problema das cópias conflitantes de antes, resolvido na origem.

Veja como isso fica em uma configuração real. Um administrador de suporte no Zendesk ensinou ao agente sua regra de cancelamento em palavras simples:

"I have a rule in CS where we do not address a cancel or refund request when there is an issue attached to it."

É um administrador de suporte codificando uma política de "resolva o problema antes de cancelar", e quando o agente depois redigiu uma resposta de cancelamento cedo demais, a correção do administrador foi uma linha: "This is incorrect. You have not provided troubleshooting steps yet." Essa é toda a interface: diga o que estava errado, diga sim quando ele oferecer guardar a mudança, e a correção vira uma regra na página de Instructions.

Saiba como cada fonte é atualizada. É aqui que eu iria mais devagar, porque é o mesmo problema de documentos externos de todo helpdesk:

Tudo isso vem da documentação de conhecimento da eesel. A linha do Google Drive é a que merece atenção. Se sua nova política é um Google Doc novo em vez de uma edição do antigo, uma ressincronização não vai encontrá-lo, e o documento antigo continua indexado até você removê-lo. Edite o documento existente ou escolha a pasta de novo. Mais um detalhe do Zendesk: rascunhos da central de ajuda são excluídos a menos que você os inclua, então um rascunho do artigo novo não vai vazar para as respostas antes da hora.

Teste contra tickets reais antes de entrar no ar. O skill de simulação da eesel reproduz seus tickets reais do passado (ou casos de teste que ele escreve para você) sem enviar nada, e dá nota a cada resposta comparando com o que seu time realmente enviou. Uma ressalva para mudanças de política: a referência são as respostas do seu time sob a política antiga, então uma "divergência" no tema alterado pode ser a resposta correta. Eu pediria que ele gerasse casos de teste especificamente para a nova regra e leria os resultados de todo o resto para confirmar que nada mais mudou.

Segure o tema de risco para aprovação durante a transição. Cada ação pode ser definida como Auto, Needs approval ou Disabled, e você pode reter um tema mesmo com as respostas em Auto usando uma instrução como "pergunte antes de responder qualquer coisa sobre reembolsos" (documentação de aprovações). Na primeira semana após uma mudança de política de reembolso, é isso que eu faria, e é como eu configuraria IA para pedidos de reembolso em geral. Além disso, cada rascunho nomeia o artigo da central de ajuda que usou, então você vê de relance se ele leu a versão nova.

Preço. O plano Free da eesel inclui 100 créditos sem cartão. Os planos Teammate começam em US$ 299 por mês por 500 créditos, e um ticket ou chat conta como um crédito, não importa quanto dure. Perguntas que você faz no painel (como testar suas dez perguntas de política) são, em sua maioria, gratuitas.

O que a eesel não faz: ela não substitui as ferramentas de artigos do seu helpdesk. Content blocks, publicação agendada e listas de verificação continuam no Zendesk ou onde estiver sua central de ajuda. A eesel é o colega que lê o resultado e responde a partir dele.

Experimente a eesel na sua próxima mudança de política

Se a sua próxima mudança de política te preocupa mais pela IA do que pela central de ajuda, experimente a eesel. Ela entra no seu helpdesk atual como um colega de IA, lê sua central de ajuda, macros e documentos e aceita mudanças de regra em frases simples. Você pode reproduzir tickets reais do passado contra a nova regra antes que os clientes vejam uma única resposta. O plano gratuito inclui 100 créditos e todas as integrações.

Experimentar a eesel