Simulações permitem validar Procedimentos Fin, aumentar a confiança na sua automação e identificar problemas antes que afetem seus clientes. Modelando conversas completas, as simulações ajudam sua equipe a lidar com cenários complexos ou de alto volume, como cancelamentos e reembolsos, com certeza.

Projetadas para substituir verificações manuais demoradas, as simulações ajudam a identificar problemas ou mudanças graduais no comportamento do Fin conforme a lógica do seu negócio evolui.

Acessando simulações

As simulações estão localizadas no painel de testes de um Procedimento. Para acessá-las:

Abra o Procedimento que deseja testar.
Clique em Test no canto superior direito da tela.
Selecione a aba Simulations no painel à direita

Nota: Acessar Simulações requer a permissão "Can manage workspace data". Se o botão Simulations não responder, verifique se essa permissão está habilitada para seu papel em Configurações > Workspace > Teammates.

Simulações ignoram o reconhecimento de intenção. Diferente do Preview ou conversas ao vivo, simulações não verificam suas instruções 'When to use this Procedure', assumem que o Procedimento já foi acionado e o executam diretamente. Isso torna as simulações ideais para testar a lógica de execução isoladamente.

Importante:

Preview mostra a experiência completa para o cliente; usá-lo enquanto seu procedimento está ativo pode expor mensagens a clientes reais.
Simulations executam o procedimento em segundo plano sem saída para o cliente, sendo a forma mais segura de validar a lógica antes de publicar. Use Preview para verificações rápidas; use Simulations antes de cada publicação.

Criando uma simulação

Você pode criar uma simulação de duas formas: usando sugestões geradas por AI para um início rápido, ou definindo manualmente o cenário para controle total.

Simulações geradas por AI: Use-as para cobrir rapidamente cenários comuns ou esperados de clientes com base em suas instruções. Fin AI gera testes "prontos" para economizar seu tempo.

Simulações manuais: Use-as quando precisar de controle preciso sobre dados, casos específicos ou ramos particulares na sua lógica.

Simulações geradas por AI

Com base em suas instruções, Fin AI gera testes iniciais para ajudar a criar simulações "prontas" rapidamente.

Abra a aba Simulations no painel direito do seu Procedimento.
Em Suggested for these instructions, revise a lista de cenários propostos (ex.: "Full cancellation request").
Clique no ícone de Play ao lado de uma sugestão para executá-la instantaneamente.
Uma vez criada ou aceita uma simulação das sugestões, ela aparecerá na sua lista. Você pode então clicar em Run all para executar todas as simulações salvas de uma vez.

Simulações criadas manualmente

Você também pode construir uma simulação do zero para testar casos específicos com base nas instruções do Procedimento.

Na aba Simulations, clique em + New.
Nome da simulação: Dê um título claro para sua simulação.
Simular como: Escolha um usuário ou marca específica para testar a personalização. Você pode selecionar na lista suspensa de users reais no seu workspace.
Mensagem inicial do cliente: Insira a primeira mensagem enviada pelo cliente (ex.: "Preciso de ajuda com meu pedido"). Você também pode anexar uma imagem, como uma captura de tela de um erro, para testar como o Fin lida com contexto visual.
Detalhes adicionais: Forneça orientações sobre a situação do cliente ou ações específicas que ele tenha tomado.

Selecione um canal

Simulações permitem selecionar o canal que o Fin usará para esta simulação, para testar como o Fin se comporta. Use o menu suspenso para alternar entre Messenger e Email antes de executar sua simulação.

Nota: O Fin se comporta de forma diferente dependendo do canal. No Email, o Fin agrega várias informações em uma única resposta em vez de enviar várias mensagens. Orientações e Conteúdo também podem ser configurados por canal — por exemplo, respostas por Email podem usar um tom mais formal ou incluir uma introdução específica.

Definir dados disponíveis

A seção Customer data available to Fin permite definir os dados que o Fin terá acesso durante o teste. Isso garante que você teste com valores precisos em vez de descrições vagas.

Hora da simulação: Use para definir "quando" o cenário está acontecendo. Definir data e hora específicas permite testar lógica sensível ao tempo, como verificar se o cliente está dentro do prazo de reembolso de 30 dias.
Atributos e Conectores de Dados: Esta seção é preenchida com os atributos referenciados no seu Procedimento. Atualize esses valores (ex.: defina People.Plan como "Pro") para testar diferentes resultados de ramificação.

Nota: Para garantir que sua simulação funcione corretamente, posicione os dados conforme o momento em que o Fin deve "saber" deles:

Usar Atributos: Se o Fin deve já conhecer a informação no início da conversa (ex.: o Plano atual do cliente ou data de cadastro).
Usar Detalhes adicionais: Se a informação deve ser fornecida pelo cliente durante a conversa (ex.: o cliente fornece o "Order ID" em uma resposta posterior). Isso permite testar se o Fin captura e armazena corretamente esse dado em um atributo.

Nota: Conectores de Dados não usam dados reais de users em simulações. Em vez de chamar seu sistema externo, o Fin usa os valores de teste que você define na seção Customer data available to Fin. Certifique-se de preencher os campos do Conector de Dados com os valores que deseja que o Fin use durante o teste — caso contrário, o conector retornará resultados vazios.

Avaliar o comportamento do Fin

Defina os critérios que devem ser verdadeiros para o teste passar. Clique em + Add criteria e selecione:

Resposta do Fin: Especifique o que o Fin deve (ou não deve) dizer durante a conversa.
Atributos: Verifique se um atributo foi definido, não foi definido, foi igual ou não foi igual a um valor específico.
Conector de dados: Verifique se um conector foi acionado, não foi acionado ou foi acionado exatamente X vezes.
Resultado da instrução: Verifique se a conversa chegou a uma conclusão específica, como finalização, transferência para um teammate ou outros resultados, como mudança para um Procedimento diferente.

Uma vez configurado, clique em Save.

Nota: Ao clicar em Save, o Fin usa AI para revisar seu formulário de simulação. Se as instruções estiverem confusas ou os critérios de sucesso inconsistentes, você verá recomendações para melhorar o teste e obter resultados mais precisos.

Melhores práticas para cobertura de simulação

Para aproveitar ao máximo as simulações, estruture seu conjunto de testes com base nestes princípios:

Teste um ramo por simulação. Se seu Procedure tiver Conditions ou subprocedimentos com múltiplos caminhos, crie uma simulação separada para cada ramo. Isso cria uma rede de segurança contra regressões — se uma edição futura quebrar um caminho específico, você vai detectar imediatamente.
Cubra tanto os caminhos de sucesso quanto de falha para Data Connectors. Execute uma simulação onde seu connector retorna dados válidos, e outra onde não retorna nada ou falha. Isso verifica se sua lógica de fallback (por exemplo, um passo @Condition que trata uma resposta vazia) funciona corretamente.
Execute todas as simulações antes de publicar alterações. Após editar um Procedure, clique em Run all para reexecutar todo o seu conjunto antes de entrar no ar. Qualquer simulação que falhar sinaliza uma regressão introduzida pela sua edição.
Use nomes descritivos para as simulações. Nomeie cada simulação de acordo com o cenário que representa (por exemplo, "Reembolso total — dentro de 30 dias" ou "Cancelamento — pedido não encontrado"). Isso facilita identificar qual teste cobre qual caminho ao revisar os resultados.

Estratégia de teste: caminho feliz, caminho de risco e casos extremos

Um conjunto de simulações bem equilibrado cobre três tipos de cenários. Juntos, eles dão confiança de que seu Procedure funciona corretamente em condições normais, lida com falhas de forma elegante e não quebra quando os customers se comportam de forma inesperada.

Caminho feliz
O caminho feliz representa o fluxo ideal e ininterrupto — um customer que fornece exatamente as informações corretas e atende a todas as condições para que Fin complete o Procedure com sucesso. Sempre comece por aqui. Se o caminho feliz falhar, depurar caminhos mais complexos fica muito mais difícil.
Exemplo: Um customer solicita um reembolso dentro do prazo de 30 dias, tem um ID de pedido válido, e o Data Connector retorna os detalhes do pedido. Fin processa o reembolso e confirma em uma única passagem.
Caminho de risco
Os caminhos de risco testam os cenários mais propensos a falhas em produção — tipicamente onde dados externos estão ausentes, conditions não são atendidas, ou um ramo de fallback deve ser acionado. Esses são os testes que protegem seus customers de respostas incorretas ou incompletas.
Exemplos: O Data Connector não retorna pedido algum (teste que Fin peça ao customer o ID do pedido). O customer está fora do prazo de reembolso (teste que Fin comunique a política correta e ofereça o repasse adequado). Um atributo está vazio quando um passo Condition o avalia (teste que o caminho de fallback do Fin seja acionado corretamente).
Casos extremos
Casos extremos cobrem entradas incomuns ou em condições-limite que são tecnicamente válidas, mas incomuns. Esses testes são especialmente importantes para Procedures com lógica sensível ao tempo, limites numéricos ou entradas de texto livre dos customers.
Exemplos: Um customer solicita um reembolso exatamente no dia 30 (o limite da janela). Um customer envia uma mensagem inicial ambígua que pode corresponder a múltiplas intenções. Um customer fornece seu ID de pedido em um formato inesperado ou inclui texto extra junto com ele.

Dica: Use nomes descritivos para as simulações para indicar a qual categoria cada teste pertence — por exemplo, "Reembolso — caminho feliz", "Reembolso — pedido não encontrado (risco)" ou "Reembolso — dia limite 30 (extremo)". Isso facilita identificar lacunas na sua cobertura de relance.

Executando e revisando resultados

Depois de executar um teste, ele aparece no painel Tests no lado direito com um indicador de status:

Executando: O teste está sendo executado ativamente.
Aprovado: O teste foi executado e atendeu com sucesso a todos os critérios de sucesso definidos.
Falhou: O teste foi executado, mas não atendeu aos critérios de sucesso definidos.
Na fila: O teste foi iniciado, mas está aguardando a simulação anterior terminar antes de executar.

Para investigar um resultado, clique em See conversation. Isso abre a transcrição completa da conversa entre o customer simulado e o Fin, facilitando ver exatamente como o fluxo ocorreu e por que um teste passou ou falhou.

Depurando uma simulação que falhou

Quando uma simulação é marcada como Failed, a transcrição disponível via See conversation contém tudo que você precisa para identificar a causa raiz. Veja como lê-la efetivamente:

Pensamentos do Fin
Em cada passo da conversa, expanda o raciocínio do Fin para ver como ele interpretou a mensagem do customer, qual passo do Procedure estava executando e qual decisão tomou. Se o Fin seguiu um caminho inesperado, os pensamentos do Fin geralmente mostram exatamente onde sua interpretação divergiu da sua intenção. Procure passos onde a interpretação do Fin de um atributo ou condition não corresponde ao esperado.
Eventos da conversa
Eventos da conversa aparecem inline na transcrição e mostram ações de baixo nível como atualizações de atributos, chamadas de Data Connector e gatilhos de repasse. Use-os para verificar se os connectors certos foram acionados no momento certo e se os atributos foram definidos com os valores esperados antes de cada passo de ramificação.
Identificando a falha
Cruze o que você vê nos pensamentos do Fin e nos eventos da conversa com seus critérios de sucesso definidos. Um padrão comum é um passo Condition avaliando para o ramo errado — tipicamente porque um atributo estava vazio ou tinha um valor inesperado. Verifique sua configuração Customer data available to Fin para garantir que todos os atributos necessários foram preenchidos antes da simulação ser executada.

Dica: Após identificar a causa, ajuste seu Procedure ou configuração da simulação e clique em Run na mesma simulação para re-testar imediatamente. Não é necessário criar uma nova simulação — a existente mantém sua configuração.

Limites de uso de simulação

Há um limite para o número de simulações que você pode executar a cada mês. Esse limite é aplicado no nível do workspace e é reiniciado no primeiro dia de cada mês do calendário.

Cada workspace recebe uma cota mensal de execuções de Simulation. A cota é baseada no segmento de volume de conversas do seu workspace, com customers maiores recebendo cotas maiores.

A cota de Simulation é baseada no volume de conversas do seu workspace no Intercom.

Atribuímos seu workspace a um segmento usando o número de conversas no último mês do calendário.
Seu segmento é reavaliado mensalmente e sua cota refletirá o volume de conversas do seu mês mais recente.
Se o volume de conversas aumentar ou diminuir, sua cota de Simulation pode mudar no próximo ciclo mensal.

Segmento de Volume de Conversas	Limite de Simulation por mês
Menos de 1K	50
1K–15K	200
15K–100K	350
100K–1M	1000
1M+	2500

Monitorando seu uso

Para ajudar você a gerenciar seus testes, Fin fornece indicadores visuais na aba Simulations:

Aviso de uso

Quando seu workspace atingir 80% do limite mensal, um banner amarelo de aviso aparecerá. Ele mostra seu uso atual (ex.: "85/100") e lembra quando o limite será reiniciado.

Limite atingido

Quando você atingir 100% do limite mensal, uma mensagem de erro vermelha aparecerá. Você não poderá executar mais simulações até o início do próximo mês.

Nota: Se você atingir seu limite, ainda poderá revisar resultados e transcrições de simulações anteriores clicando em See conversation, mas os botões Run e Run all ficarão desativados.

FAQs

As simulações interagem com minhas APIs ao vivo ou dados externos?

Não. Diferente da ferramenta Preview, as simulações não acessam APIs reais ou sistemas externos (como Shopify ou Stripe). Não é possível ler ou alterar dados em uma API externa durante uma simulação. Isso garante que você possa testar a lógica com segurança sem impactar dados reais.

Por que usar Simulations em vez de testes manuais?

Simulations permitem validar Procedures em escala e garantir que Fin funcione de forma confiável em cenários complexos e de alto risco — diferente dos testes manuais, que são melhores para verificações rápidas ou revisões de configuração. Executar Simulations antes de cada lançamento ajuda a detectar comportamentos inesperados cedo.

O que acontece se uma Simulation falhar?

Uma Simulation que falhou pode ser revisada completamente — abra a conversa simulada para entender por que Fin não se comportou como esperado, ajuste seu Procedure e execute a Simulation novamente sem impactar os clientes.

Por que minha simulação está marcada como "Failed" mesmo que Fin tenha resolvido o problema com sucesso?

Uma Simulation marcada como "Failed" apesar de Fin ter resolvido o problema geralmente significa que seus Success Criteria são muito rígidos. Por exemplo, se você exige que Fin "Peça um Order ID", mas Fin é inteligente o suficiente para encontrar o ID automaticamente, o teste falhará porque Fin pulou a pergunta. Atualize seus critérios para focar no resultado final (ex.: "Procedure finalizado") em vez de exigir etapas intermediárias específicas.

Fin para no meio da simulação. Por que está travando?

Fin frequentemente para se encontrar um "beco sem saída" em suas instruções, como verificar uma variável que está vazia (ex.: People.signed_up). Se você não disse ao Fin o que fazer quando os dados estiverem faltando, ele vai parar. Garanta que suas instruções tenham um plano de "fallback", como: "Verifique se a variável tem valor. Se estiver vazia, pergunte ao cliente a data."

Onde devo inserir dados de teste como "Sign up dates" ou "Order history"?

Dados de teste como datas de inscrição ou histórico de pedidos devem ser inseridos na seção Customer data available to Fin da configuração da simulação — não na mensagem inicial do Customer ou nos campos Additional details, pois Fin pode não percebê-los. Insira valores exatos (ex.: 2024-06-01) nos Atributos ou Variáveis específicas que você está testando.

Minha ferramenta funciona na vida real, mas falha na simulação. Por quê?

Simulations não buscam dados reais de sistemas externos, então seu Data Connector não retornará resultados ao vivo como em uma conversa real. Se seu connector funciona em conversas ao vivo mas falha na simulação, provavelmente é porque os valores esperados não foram definidos na seção Customer data available to Fin. Adicione os dados que seu connector normalmente retornaria como valores de teste lá e execute a simulação novamente.

Simulations são cobradas separadamente dos Procedures?

Simulations estão incluídas com Procedures e não são cobradas como item separado. Você não terá cobranças adicionais por executar simulações.

Por que devo testar meu Procedure por Email?

Testar seu Procedure por Email valida comportamentos específicos do canal que diferem do Messenger. No Email, Fin agrega várias informações em um único email em vez de enviar várias mensagens. Guidance e Content também podem ser direcionados a canais específicos — por exemplo, respostas por Email podem ser configuradas para usar um tom mais formal ou incluir uma introdução específica. Simular conversas por Email permite validar esse comportamento e implantar com confiança.

Por que há um limite para execuções de Simulation?

Cada execução de simulation requer recursos para gerar previsões precisas de IA. Fornecemos uma cota mensal para garantir que você possa testar seus Procedures livremente para casos de uso padrão, evitando que uso extremo gere custos excessivos.

Posso simular um sub-procedure independentemente?

Não. Sub-procedures não têm seu próprio painel de simulação e não podem ser executados isoladamente. Para testar um sub-procedure, execute uma simulação no Procedure pai e configure o cenário para que o caminho de execução alcance o sub-procedure — definindo a mensagem do customer, atributos e detalhes adicionais para acionar o ramo específico que o chama.

Se você tiver múltiplos sub-procedures dentro do mesmo pai, crie uma simulação separada para cada um, com cada simulação cobrindo o cenário que leva à chamada daquele sub-procedure.

Meu Data Connector retorna resultados vazios na simulação. O que devo fazer?

Resultados vazios do Data Connector em uma simulação geralmente são causados por dados de teste ausentes. Simulations não buscam dados ao vivo de sistemas externos — você precisa definir os valores que seu Data Connector deve retornar na seção Customer data available to Fin da configuração da simulação. Verifique se você preencheu os campos relevantes do Data Connector com os valores de teste que deseja que Fin use.

Se você está testando intencionalmente o caminho 'connector returns nothing', esse é o comportamento esperado — e exatamente o que você deve testar. Certifique-se de que seu Procedure tenha um passo de fallback @Condition que lide com respostas vazias do connector:

Se o connector retornar vazio mesmo para um user com dados reais, verifique se seu contato de teste tem um external_id válido que corresponda ao identificador do customer no seu sistema externo.

Execute Simulações para Procedimentos Fin