Nossa leitura
Defina quatro pontos antes de o Fin responder a um cliente real: o conteúdo que ele lê, os dados de cliente que pode consultar, as ações que pode executar e os assuntos que deve passar a uma pessoa. Essa ordem é recomendação nossa, não da Kalshi. A implantação publicada pela Kalshi documenta apenas importação com testes em lote, depois regras e assuntos de escalonamento testados pelas equipes jurídica e de conformidade, e então a entrada em produção. Taxas de resolução de fornecedores são alegações, não a sua meta.
Comece pelo conteúdo com que o Fin vai responder
A Intercom diz que o Fin parte do conhecimento que você já tem e depois é treinado com seus processos e políticas. O Knowledge Hub pode reunir artigos de uma central de ajuda, Zendesk, Confluence, Notion e Guru, e a importação de uma central de ajuda do Zendesk mantém categorias e links. O mesmo conteúdo atende o Fin, o Copilot e a central de ajuda pública.
A tarefa é mais editorial do que técnica: decidir quais artigos são a referência, eliminar contradições e políticas defasadas e escrever as regras que hoje existem só na cabeça dos atendentes. A Intercom afirma que o Fin treina apenas com o conhecimento e os Procedures que você aprovou. A Kalshi começou importando sua central de ajuda e rodando testes em lote, antes de definir qualquer regra.
Decida quais dados de cliente o Fin pode consultar
Uma resposta sobre uma conta específica exige acesso aos dados dessa conta, então vale decidir isso de forma deliberada. A Intercom lista conectores pelos quais o Fin lê registros do Salesforce e do HubSpot, dados de loja do Shopify, cobrança e assinaturas do Stripe, incidentes do Statuspage e o status de tarefas no Jira ou no Linear. Para o resto, há um conector REST, webhooks e MCP.
Parta dos seus dez tipos de pergunta mais frequentes e nomeie, para cada um, o sistema que guarda a resposta e o acesso de leitura mais restrito que baste. No caso da Kalshi, descrito após a migração para a Intercom, diante de uma pergunta como onde está meu dinheiro, o Fin consulta a conta, verifica se um mercado está aberto, pendente ou liquidado, distingue bloqueio de depósito de processamento de saque e responde com datas e valores. Isso só funciona porque os dados da conta estão acessíveis.
Limite as ações e coloque as aprovações onde importam
A Intercom descreve os Procedures como o meio pelo qual o Fin conduz fluxos de várias etapas, aplica regras de negócio e aciona aprovações dentro dos limites que você define. Segundo a Intercom, quando o Fin precisa de uma aprovação ou de uma informação, ele pergunta a um colega e depois conclui a conversa. A página de preços inclui entre os recursos a ação em sistemas externos.
Nossa recomendação, e não uma capacidade declarada pelo fornecedor: classifique as ações candidatas por reversibilidade. Primeiro as consultas somente de leitura, depois as alterações reversíveis; tudo o que envolve dinheiro ou o status da conta fica sob aprovação humana até que as conversas justifiquem afrouxar. Escreva essa lista antes de construir o primeiro Procedure.
Escreva as regras de escalonamento e os assuntos excluídos
A Intercom informa que as conversas são monitoradas conforme seus critérios e que o Fin escala para uma pessoa quando os limites de confiança não são atingidos. Há também as Simulations, que ensaiam conversas completas com casos extremos, inclusive clientes vulneráveis e cenários de conformidade, antes do lançamento. Segundo a página de preços, o Fin repassa para os atendentes na caixa de entrada que você já usa.
Três decisões ficam com você: os assuntos que o Fin não trata no início, quem recebe a transferência e que contexto vai junto. A Kalshi deixou de fora do Fin, no lançamento, investigações de fraude, casos de conformidade e restrições de conta, e definiu regras sobre os termos permitidos, os assuntos a escalar de imediato e as perguntas financeiras, para evitar qualquer deriva para aconselhamento. As equipes jurídica e de conformidade testaram essas barreiras antes da entrada em produção.
O que a implantação da Kalshi mostra e onde ela termina
Pelo relato da própria empresa, a Kalshi colocou o Fin em todo o tráfego de produção cerca de dez dias após a primeira conversa, sobre o helpdesk que já usava. Quando os limites de API desse helpdesk bloquearam atendentes e o Fin no pico do Super Bowl, a Kalshi migrou todo o helpdesk para a Intercom em menos de três semanas. A equipe informa que o Fin resolve cerca de 80 % das conversas de chat de ponta a ponta e que o tempo mediano de resolução caiu de cerca de 23 horas para minutos.
Os papéis também mudaram: uma pessoa virou engenheira ou engenheiro do Fin em tempo integral, outra se concentrou em métricas e lacunas de conteúdo, e cinco pessoas continuaram na linha de frente. Os fluxos de fraude e conformidade foram acrescentados depois, por meio de um sistema interno da Kalshi que o Fin chama. São números publicados pelo fornecedor, de uma única empresa regulada: mostram como uma equipe procedeu, não uma taxa que você deva esperar.
Planeje o orçamento por resultado e defina o que medir
O preço publicado pela Intercom é de US$ 19 por assento ao mês mais US$ 0,99 por resultado (outcome), com limites de gasto que você configura. O Fin sozinho, sobre um helpdesk existente como Zendesk ou Salesforce, começa em US$ 0,99 por resultado, sem assentos. Há teste gratuito. Confirme a definição exata de um resultado cobrável antes de projetar o custo, porque a fatura segue essa definição.
A Intercom anuncia uma taxa média de resolução de 76 % entre seus clientes, e estes citam números de 50 % a 80 %. As populações e as definições diferem, então nenhum desses números é referência para você. Meça sua própria taxa por assunto e mostre à parte a fatia escalada.
Método e limites
2026-11-01
Este instantâneo datado conta empresas distintas com evidências públicas de clientes. CONFIRMED indica um estudo de caso, uma citação nominal ou uma fonte de imprensa; DECLARED, uma declaração da própria empresa; OBSERVED, uma lista de clientes do fornecedor; SIGNAL, um anúncio de vaga. Os quatro níveis contam, com solidez diferente. Linhas removidas ou sem nível ficam de fora. Os exemplos são uma seleção limitada, verificada nos últimos 90 dias. Os dados do fornecedor vêm de fontes verificadas nos últimos 60 dias. A cobertura é desigual, e a ausência de evidências significa que o dado é desconhecido. Estes números não medem participação de mercado nem desempenho; datas de captura não são datas de adoção.