Modelo de RFP para suporte com IA: perguntas aos fornecedores, planilha de pontuação e teste com tickets

Por que a maioria das RFPs de suporte com IA escolhe o fornecedor errado?

Porque pontuam o que o fornecedor diz em vez do que a IA faz nos seus tickets. Uma RFP típica faz 80 perguntas, recebe 80 respostas confiantes e depois escolhe quem fez a melhor demo. A demo usou os cenários escolhidos pelo fornecedor, em uma base de conhecimento limpa, com um sales engineer no comando.

Eu construo integrações na eesel, então vejo o outro lado: as perguntas do comprador depois que o contrato é assinado. Quase nunca são sobre funcionalidades. São "por que ela respondeu assim a esse ticket?", "por que a minha fatura subiu em novembro?" e "por que ela diz sim a produtos que não suportamos?". Cada uma delas poderia ter sido uma pergunta da RFP.

A solução é uma ordem diferente de trabalho, não mais perguntas:

1. Critérios primeiro. Tudo o que pode matar o negócio (certificação de segurança, uso de dados, o seu helpdesk, HIPAA) é um sim/não, verificado antes que alguém pontue qualquer coisa.
2. Respostas escritas em segundo. O banco de perguntas abaixo, respondido por escrito, com evidências.
3. Os seus tickets em terceiro. Os dois ou três sobreviventes executam o mesmo conjunto de teste do seu histórico.
4. Preço por último, no seu volume. Cada fornecedor preenche a mesma linha de custo.

Nas chamadas de vendas da eesel, o pedido que mais aparece é treinar a IA com os tickets antigos do próprio comprador. Meu colega Amogh disse sem rodeios depois de uma série de demos: "past ticket training strikes again". Os compradores já sabem que o próprio histórico é o teste real. A maioria dos modelos de RFP simplesmente não pede isso.

O que entra em um modelo de RFP para suporte com IA?

Dez seções. Cada uma corresponde a uma decisão que você terá de defender depois, diante do seu CFO, da sua equipe de segurança ou dos seus agentes.

A seção 1 é a que as equipes pulam, e é a que torna as respostas dos fornecedores comparáveis. Dê a eles os seus números reais: tickets por mês por canal, os 10 principais motivos de contato, idiomas, helpdesk e quais tipos de ticket você nunca quer que a IA toque. Uma líder de suporte falou isso com clareza em uma chamada com a eesel: "There are certain tickets I don't want to go through AI." Coloque essa lista na RFP, não em uma chamada de acompanhamento.

Que perguntas você deve fazer aos fornecedores de suporte com IA?

Copie estas para a sua RFP como perguntas escritas. Para cada uma, acrescentei como é uma boa resposta, porque as respostas fracas soam todas parecidas e a diferença está no detalhe.

Qualidade de resolução e precisão

Esta seção recebe o maior peso, e é onde os fornecedores têm mais prática. Vá além do número de destaque.

1. O que a sua taxa de resolução conta? Boa resposta: uma definição exata, quem ou o que decide que um ticket foi resolvido, e se spam, tickets fechados automaticamente e clientes que simplesmente foram embora estão incluídos.
2. Qual é a sua taxa de resolução em tickets como os nossos? Boa resposta: resultados divididos por motivo de contato e canal, com o tamanho da amostra e o intervalo de datas. Um único número combinado de todos os clientes não diz nada.
3. O que ela faz quando a base de conhecimento não tem resposta? Boa resposta: diz que não sabe e transfere. Peça que mostrem isso.
4. Ela alguma vez responde a partir do conhecimento geral do modelo em vez do nosso conteúdo? Boa resposta: não, ou sim com uma configuração para desligar. Um avaliador técnico em uma chamada de vendas da eesel perguntou exatamente isto: se a IA recorre a algo como o ChatGPT quando não sabe, e se isso pode ser desligado.
5. Como vocês detectam uma resposta errada depois do lançamento? Boa resposta: um processo nomeado (amostragem, pontuação, alertas), além de onde você vê isso no produto.
6. O que acontece quando o provedor do modelo muda o modelo? Boa resposta: eles reexecutam testes no seu histórico antes que a mudança chegue até você, e avisam.

Aquela primeira pergunta importa mais do que parece:

Em um teste da eesel com tráfego real de Zendesk de e-commerce, 22% dos tickets recebidos eram spam. Um fornecedor que conta o fechamento de spam como "resolução" pode adicionar 22 pontos à sua taxa sem responder a um único cliente. O post sobre deflexão versus taxa de resolução mostra como nove helpdesks contam isso de formas diferentes.

Um operador no Reddit descreveu o que acontece quando ninguém verifica o que "resolvido" significa:

"So we audited a week's worth of auto tickets and found 3 separate cases where the bot made up a policy that doesn't exist. The scary part is the customers believed what it said and walked away feeling that WE were wrong. It even marked the ticket as "resolved" so we didn't notice until they dropped a negative review."

quietkernel_thoughts, Reddit

Então acrescente uma sétima pergunta: como vocês contam um ticket que o cliente reabre, ou sobre o qual volta a entrar em contato, em até 7 dias? Se o número do fornecedor não os subtrai, ele mede como as conversas terminam, não se os problemas foram resolvidos.

Transferência e controle

1. Quais tickets podemos excluir por completo, e como? Boa resposta: por tag, formulário, canal, segmento de cliente ou assunto, definido por você, não por um ticket para a equipe de suporte deles.
2. Ela pode começar redigindo respostas para os agentes antes de enviar qualquer coisa? Boa resposta: sim, com uma chave por assunto ou canal para passar de rascunho para envio.
3. O que a pessoa vê quando ocorre a transferência? Boa resposta: um resumo, o que ela já tentou e as fontes que usou, escritos no ticket.
4. Um cliente pode chegar a uma pessoa a qualquer momento? Boa resposta: sim, e você consegue ver com que frequência pedem.

A versão mais clara disso que já vi veio de um líder de CX de uma marca direto ao consumidor que lidava com cerca de 7.000 tickets por mês:

"The AI will never be able to answer 100% of the questions, but if it tries and just answers 'sorry I don't know this,' I cannot go and check all my 7,000 tickets to see if the AI actually made a good answer. Then the point is a little bit gone. I need an AI who is only handling the tickets that it's confident to handle and all the other ones, leave them alone."

Isso é um requisito, então escreva-o como tal: "A IA deve responder apenas a tickets que consiga responder a partir do nosso conteúdo, e deve deixar todos os outros intocados para uma pessoa". Depois, teste. Meu post sobre boas práticas de transferência de agentes de IA cobre como é uma transferência limpa.

Integração com o helpdesk e ações

Esse é o meu trabalho do dia a dia, então vou ser direto: "integra com o Zendesk" pode significar qualquer coisa, desde um agente completo que etiqueta, roteia e responde dentro dos tickets até um widget que lê a sua central de ajuda e nada mais.

1. Funciona dentro do nosso helpdesk como um agente, ou ao lado dele? Boa resposta: lê e escreve tickets, tags, campos e notas internas no seu helpdesk, com uma lista de exatamente quais.
2. Que ações ela pode executar, não apenas responder? Boa resposta: uma lista nomeada (consultar um pedido, atualizar um campo, emitir um reembolso abaixo de um limite), com como cada uma é autorizada e registrada.
3. Do que ela aprende? Boa resposta: central de ajuda, macros, tickets antigos, documentos internos, cada um opcional e filtrável. Pergunte se você pode escolher quais tickets antigos ela lê (intervalo de datas, tags).
4. O que acontece quando a API do nosso helpdesk está fora do ar ou lenta? Boa resposta: novas tentativas, sem respostas duplicadas e um registro que você consegue ler.
5. Com que rapidez ela responde? Boa resposta: tempos medidos para chat e e-mail em tráfego real. Um comprador fez uma avaliação de 67 testes, achou as respostas sólidas e depois foi embora porque o widget de chat era lento e travava. A velocidade pertence à planilha de pontuação.

Se você está em um helpdesk específico, peça como referência um cliente nesse mesmo helpdesk. Compare o que cada fornecedor diz com o que a IA do próprio helpdesk faz: as análises de preços do Zendesk AI, preços do Freshdesk Freddy AI e preços do Gorgias AI são boas referências.

Segurança, privacidade e uso de dados

A maior parte desta seção é eliminatória. Os negócios que vi travar nesta etapa fizeram isso por um único motivo cada: nenhum relatório SOC 2, uma revisão interna de ISO que o fornecedor não conseguiu passar, ou nenhum acordo de associado comercial (BAA) da HIPAA. Descubra isso na semana um, não na seis.

1. Quais certificações vocês têm hoje, e quais estão em andamento? Peça o relatório ou uma carta de transição, e o escopo. "SOC 2 Type II em andamento" e "relatório SOC 2 Type II disponível sob NDA" são respostas diferentes.
2. Os nossos dados são usados para treinar algum modelo, o de vocês ou o de um provedor? Boa resposta: um não claro, no contrato. Leia o detalhe: a central de confiança da Zendesk diz que sua IA generativa não é treinada com dados de clientes, mas dados de serviço higienizados treinam seus próprios modelos de aprendizado de máquina entre contas.
3. Onde os nossos dados são armazenados e processados, e por quais subprocessadores? Boa resposta: uma lista, com regiões.
4. Vocês conseguem ocultar números de cartão e outros dados pessoais antes de armazenar? Uma empresa de mídia que avaliava a eesel fez disso a sua principal objeção antes mesmo de começar um teste.
5. Vocês assinam um BAA da HIPAA, e em qual plano? Só se você lida com dados de saúde, mas se lida, é um critério eliminatório.
6. O que acontece com os nossos dados quando saímos? Boa resposta: exportação em um formato nomeado, exclusão com confirmação e um prazo.

Um questionário de segurança padrão não capta tudo isso sozinho. Um comprador de uma empresa B2B SaaS de 200 pessoas descreveu bem a lacuna:

"My company (200 people, B2B SaaS) is starting to use AI vendors for customer support and internal tools. Our procurement process is basically "fill out security questionnaire, get SOC 2, done." But I'm realizing SOC 2 doesn't cover AI-specific stuff. Like what happens when the vendor updates their model and it starts giving wrong answers? What if the training data had customer info in it?"

Alieezeee, Reddit

É por isso que a pergunta sobre mudança de modelo da seção de precisão pertence junto dos critérios de segurança, e não só na revisão do produto.

Para a versão completa, use a lista de verificação de segurança de fornecedores de suporte com IA como apêndice da RFP, e o guia de SOC 2 e LGPD/GDPR se a sua equipe de segurança é nova com fornecedores de IA.

Preços e unidades cobráveis

As respostas aqui parecem comparáveis e não são. Um fornecedor cobra por resolução, outro por conversa, outro por crédito, outro por assento, e três não publicam preço algum. Pergunte:

1. O que exatamente é uma unidade cobrável? Obtenha a definição por escrito.
2. Quem decide que uma conversa conta, e podemos ver e contestar?
3. O que acontece no nosso mês mais movimentado? Peça a fatura com 2 vezes o seu volume normal.
4. Há cobrança excedente, e ela vem ativada por padrão?
5. Os aumentos de preço têm teto durante o prazo do contrato? Uma equipe de suporte de hardware que avaliava a eesel tinha visto o preço de um fornecedor anterior mais que dobrar, e queria desta vez uma trava de preço por escrito.
6. Preencha esta linha: nosso volume de tickets por mês dos últimos 12 meses, precificado às suas tarifas.

A unidade de cobrança muda quem paga pela falha:

Aquela célula inferior esquerda é agora a pergunta mais importante da seção. Desde 18 de maio de 2026, a Zendesk classifica cada conversa de IA em três níveis, e apenas uma "verified resolution" consome a sua franquia. O próprio modelo da Zendesk toma essa decisão, 72 horas depois do primeiro e-mail ou 2 horas depois do início de um chat de mensagens. Isso é justo com você em um aspecto (você não paga por escalonamentos), mas ainda assim deve perguntar como auditar os veredictos.

A Decagon, que permite aos clientes escolher qualquer um dos modelos, defende contra a cobrança por resolução no seu próprio blog de preços: "You never want to be in a situation where you're arguing over what a 'resolution' is." A Sierra vai no sentido oposto com a precificação baseada em resultados, em que os resultados são acordados por cliente.

No Hacker News, respondendo a uma startup que vendia cobrança baseada em resultados, um engenheiro nomeou a pergunta que toda cotação por resultado deveria responder:

"can you clearly explain how you will measure and track the outcomes? That's the key detail that matters. Relying on customers to self-report is not sufficient, and an automated self-report-system is not a true improvement."

mushufasa, Hacker News

Veja como ficam as tabelas de preços públicas para o mesmo mês. Mova os controles deslizantes para os seus números:

Duas coisas chamam atenção quando você brinca com isso. O preço por resolução fica mais barato quando a IA resolve menos, então uma cotação baixa pode esconder um agente fraco. E a diferença entre fornecedores muda completamente com a sua taxa de resolução, por isso você precifica depois do teste com tickets, não antes. Para um aprofundamento, veja o custo real por resolução e a análise dos preços do Agentforce.

Implementação e suporte

1. O que vocês precisam de nós, em horas, por função? Boa resposta: uma estimativa para o tempo de operações de suporte, engenharia e segurança, não "esforço mínimo".
2. Quanto tempo até o primeiro tipo de ticket entrar no ar? Boa resposta: uma data atrelada a um escopo, com o que poderia atrasá-la.
3. Quem é responsável pelo ajuste depois do lançamento? Boa resposta: uma pessoa nomeada, com o que está incluído no preço.
4. Quais são os motivos mais comuns pelos quais as suas implantações travam? Um fornecedor com implantações reais tem uma resposta específica e honesta. Uma vaga é um sinal de alerta.
5. Podemos pagar menos enquanto fazemos a rampa de adoção? Um CFO em uma chamada de vendas da eesel pediu preço reduzido durante a implementação e disse "this is not just for you, but for any tech vendor." É um pedido normal.

O guia de implementação e a lista de erros de implementação são úteis para enviar ao responsável pelo seu projeto.

Contrato e saída

1. Podemos exportar as nossas conversas, configurações e resultados de testes? Em que formato?
2. Qual é o prazo de aviso prévio, e há multa por saída antecipada?
3. O que acontece se o primeiro caso de uso não atingir a meta acordada? Boa resposta: um remédio por escrito (piloto estendido, crédito ou o direito de sair).

Se você está substituindo um fornecedor de IA em vez de comprar o primeiro, acrescente às suas leituras o guia para trocar de fornecedor de suporte com IA.

Como pontuar fornecedores de suporte com IA?

Aplique primeiro os critérios eliminatórios. Quem falhar em um está fora, por melhor que tenha sido a demo. Depois pontue o restante de 1 a 5 em cada linha e multiplique pelo peso.

Critérios eliminatórios (passa/falha, antes de pontuar): certificação ou relatório exigido disponível, compromisso contratual de não treinar com os seus dados, o seu helpdesk suportado, residência de dados de que você precisa, BAA da HIPAA se você lida com dados de saúde, exportação de dados na saída.

Duas escolhas aqui são deliberadas. O teste com tickets tem mais peso do que as respostas escritas e a transferência juntas, porque é a única linha em que o fornecedor não consegue entrar escrevendo. E a velocidade tem a sua própria linha, porque um widget de chat lento perde negócios que respostas precisas ganharam. A planilha de pontuação de piloto de suporte com IA tem uma versão mais longa se você quiser subnotas.

Como testar fornecedores com os seus próprios tickets?

Esta é a seção 9 da RFP, e é a que eu defenderia com unhas e dentes. Veja como executá-la para que os resultados sejam comparáveis.

1. Extraia um conjunto de teste dos últimos 90 dias. De 100 a 200 tickets resolvidos, amostrados entre os seus principais motivos de contato em proporção ao volume. Retire tudo o que você não pode compartilhar.
2. Adicione os difíceis de propósito. De 10 a 20 tickets em que a resposta honesta é "não" ou "não suportamos isso", mais alguns clientes irritados e alguns que exigem uma ação (reembolso, alteração de pedido).
3. Dê a cada fornecedor o mesmo conjunto e o mesmo conhecimento. Mesma exportação da central de ajuda, mesmas macros. Sem cenários escolhidos pelo fornecedor.
4. Pontue cada resposta em relação ao que a sua equipe realmente enviou. Correta e utilizável como está, correta mas precisa de edição, errada, ou transferida corretamente.
5. Reporte vários números, não um. Precisão, taxa de envio sem alterações, taxa de respostas erradas, taxa de transferência e tempo de resposta.

É no passo 5 que a verdade aparece. Em um teste da eesel com tráfego real de Zendesk de e-commerce (284 chats mais uma verificação cruzada de 100 tickets), a IA atingiu 93% de precisão na triagem e pegou todos os tickets de spam. Mas os agentes enviaram os rascunhos dela sem alterações apenas 12% das vezes. Quando a equipe investigou, cerca de 65% das reescritas eram por extensão e tom (os agentes reduziam rascunhos de 8 a 15 frases para 1 a 3), e apenas cerca de 5% eram por erros factuais. Um número teria dito "ótimo" ou "inútil". Cinco números disseram "precisa, prolixa demais, ajuste o tom".

Os tickets de "não honesto" do passo 2 importam mais do que parecem. Uma equipe técnica B2B contou à eesel em uma chamada de vendas que um bot havia confirmado "sim, suportamos o seu modelo de carro" para marcas que não estavam na base de dados deles, porque a base de conhecimento dizia "we support all models". Esse é exatamente o tipo de resposta que uma demo de fornecedor nunca mostra.

Este é o passo em torno do qual a eesel foi construída. A habilidade de simulação de helpdesk pega 20 tickets que a sua equipe resolveu recentemente, redige a sua própria resposta para cada um, compara com o que a sua equipe enviou, agrupa os resultados por tema e não envia nada aos clientes:

Repare no que esse relatório diz ser a lacuna: não a redação, mas as ações. Cerca de metade dos tickets correspondentes ainda exigia que uma pessoa fizesse algo em um sistema interno. Esse é o tipo de descoberta que você quer antes de assinar, porque diz sobre quais integrações perguntar. Se um fornecedor não consegue executar algo assim no seu histórico, pergunte como mais você vai saber. O guia de testes de agentes de suporte com IA se aprofunda em como montar o conjunto de teste.

Mais um teste que vale a pena emprestar, de uma discussão no Reddit sobre o que uma demo ao vivo deveria provar:

"Make them do the demo with a knowledge base that's deliberately outdated by like 6 months, and see if the agent just confidently spits wrong info or admits it don't know. That's the real test for me"

Right_Smile_4412, Reddit

A sua base de conhecimento real já está um pouco desatualizada em algum ponto, então esta não é uma pergunta capciosa. É o caso normal.

O que os fornecedores de suporte com IA publicam antes de você enviar a RFP?

Você pode preencher parte da RFP sozinho a partir das páginas dos fornecedores. Eis o que encontrei no site de cada fornecedor em outubro de 2026:

Três de seis não publicam preço, o que é normal em vendas corporativas, mas significa que a sua RFP precisa pedir a mesma linha de custo de cada um. Meu panorama dos melhores agentes de atendimento ao cliente com IA cobre mais fornecedores se a sua lista longa for maior.

Que erros as equipes cometem com RFPs de suporte com IA?

• Enviar 200 perguntas. Fornecedores respondem a questionários longos com texto copiado do anterior. 40 perguntas afiadas obtêm respostas melhores do que 200 genéricas.
• Deixar os fornecedores escolherem os cenários da demo. Todo fornecedor vai bem nos próprios exemplos. Use os seus tickets.
• Comparar cotações com unidades diferentes. Por resolução e por conversa não podem ser comparadas até que ambas sejam precificadas sobre o seu mês.
• Tratar "em andamento" como "concluído". Uma certificação em andamento pode estar tudo bem para você, ou pode ser um critério eliminatório. Decida antes da demo, não depois.
• Pular o mês movimentado. Precifique o seu pico, não a sua média. O preço por unidade acompanha o seu volume para cima.
• Deixar os agentes de fora. As pessoas que vão editar os rascunhos da IA devem pontuar o teste com tickets. Elas vão notar problemas de tom que um gerente lendo resumos não vê.

O ponto do pior cliente merece ser repetido, porque é o mais fácil de pular:

"test it as your worst customer not your best one vague question, typo in it, missing half the context. if it handles that you're probably fine. most people only test the clean version and then wonder why it breaks on real customers"

ShotOil1398, Reddit

Como a eesel responderia a esta RFP?

Já que eu disse para você fazer perguntas difíceis, aqui estão as respostas da eesel para as que costumam decidir, inclusive as que podem desqualificá-la.

• O que é: um colega de IA para o helpdesk que trabalha dentro do seu helpdesk como mais um agente: redige ou envia respostas, etiqueta e roteia tickets, e aprende com a sua central de ajuda, macros e tickets antigos. Conecta-se a Zendesk, Freshdesk, Gorgias, Help Scout, HubSpot, Front e Salesforce, entre outros.
• Unidade de cobrança: um crédito por ticket ou chat que trata, não importa quantas respostas. Os planos vão de $299 por 500 créditos a $1,749 por 5.000, sem taxas por assento. O excedente é $0.80 por crédito e fica desligado a menos que você o ative, com um teto que você define. Um plano gratuito tem 100 créditos e não exige cartão.
• Segurança: auditoria SOC 2 Type II em andamento, com o período de observação iniciado em 1º de outubro de 2026. Se você precisa de um relatório finalizado hoje, esse é um critério eliminatório que a eesel ainda não passa. BAAs da HIPAA estão no Enterprise. A eesel não treina nem faz ajuste fino de modelos com os seus dados.
• Teste com tickets: embutido, nos seus próprios tickets resolvidos, antes que qualquer coisa chegue a um cliente.

Como isso fica em produção, a partir de histórias de clientes publicadas:

• Finanças reguladas, rascunho primeiro. A smava, uma empresa alemã de comparação de empréstimos, executa três agentes da eesel em um único Zendesk: um categoriza cada ticket, um redige a partir da biblioteca de macros e um prepara respostas prontas para o cliente. São 27.000 tickets tratados em um mês e 15.300 rascunhos de resposta, e a eesel nunca os envia por conta própria.
• Respostas somente a partir dos seus documentos. Uma empresa de automação industrial colocou sua biblioteca técnica atrás de um chat que responde apenas a partir dos documentos, linka sua fonte e admite quando não tem nenhuma. Cada ticket de suporte chega com um rascunho para um engenheiro editar.
• Volume em um plano fixo. A SamCart executa um agente em tickets do Freshdesk e um no chat do seu site, respondendo a partir de 280 artigos da central de ajuda em um plano de 8.000 interações por mês.

Experimente a eesel como um dos fornecedores da sua RFP

Se você está escrevendo uma RFP de suporte com IA neste trimestre, coloque a eesel na lista curta e faça-a executar primeiro a seção 9. Conecte o seu helpdesk, peça que simule nos seus tickets resolvidos recentemente e você terá um relatório pontuado por motivo de contato antes de qualquer chamada de vendas, sem nada enviado aos clientes. Depois exija dela os mesmos critérios e a mesma linha de custo que de todos os outros.

Experimente a eesel grátis, ou agende uma demo se a sua equipe de segurança quiser ver os controles primeiro.