Construir um Fin Procedure que lida bem com um tema tecnicamente complexo requer iteração. Este artigo explica como um procedimento real, o Data Connectors Setup and Troubleshooting procedure, foi projetado do zero, refinado em iterações sucessivas e moldado por seis princípios que o tornaram consistentemente melhor. Use-o para aplicar o mesmo raciocínio aos seus próprios procedimentos.

Este artigo é para colegas que constroem e iteram Fin Procedures. Assume que você está trabalhando no editor de procedimentos e já publicou pelo menos um procedimento.

O procedimento lida com toda a gama de perguntas sobre Data Connector: configuração inicial, falhas de autenticação, erros de chamadas API, timeouts, problemas de mapeamento de resposta e regressões. Cobre muito terreno técnico e usa um Data Connector próprio, construído especificamente para buscar dados diagnósticos ao vivo sobre o conector do cliente antes que o Fin faça uma única pergunta. Essa decisão de design sozinha mudou como todo o procedimento funciona.

Na superfície, "ajuda com Data Connectors" soa como um único tema. Na prática, cobre uma série de situações distintas: uma configuração pela primeira vez, uma falha de autenticação, uma chamada API quebrada, um timeout, um problema de mapeamento de dados, uma regressão (algo que funcionava e não funciona mais), um protocolo não suportado e um cliente que ainda não sabe o que precisa. Lidar bem com todas essas situações em um único procedimento só é possível se o Fin souber, cedo na conversa, em qual situação está.

A decisão de design mais significativa no procedimento é um Data Connector dedicado, construído especificamente para puxar dados de saúde ao vivo sobre o próprio conector do cliente.

Quando um cliente compartilha a URL do conector, o Fin usa o ID do conector para fazer uma requisição GET. Ele recebe de volta:

O Fin usa esses dados para conduzir sua primeira resposta significativa com algo específico, não algo genérico. Essa é a diferença entre um procedimento que parece um formulário de suporte e um que parece falar com alguém que já investigou seu problema antes de atender o telefone.

O procedimento roteia em duas etapas. A primeira é automática — o Fin lê os dados diagnósticos e roteia antes de perguntar qualquer coisa ao cliente. A segunda é baseada em intenção — se a primeira etapa não determinar o caminho, o Fin lê o que o cliente descreve e roteia para o subprocedimento correspondente.

A tabela abaixo mostra as 13 situações distintas que o procedimento Data Connectors Setup and Troubleshooting lida, como o Fin detecta cada uma e para qual subprocedimento ele roteia.

Os seis princípios abaixo explicam como o procedimento chegou lá e como aplicar o mesmo raciocínio no seu próprio.

Cada princípio inclui:

Antes que Fin diga uma única palavra ao cliente, ele deve entender sobre o que o cliente está realmente perguntando.

Intenções diferentes merecem caminhos diferentes, e um procedimento que faz as mesmas perguntas iniciais para todos os clientes perde tempo para a maioria deles.

Fin também não executa procedimentos como um roteiro fixo de cima para baixo. Ele usa uma abordagem de planejamento não linear: pode revisitar etapas anteriores, pular à frente ou mudar de rumo conforme a conversa se desenvolve. Em alguns casos, pode até mudar para outro procedimento no meio da conversa se outro for mais adequado.

Isso significa que a ordem dos passos nem sempre controla a ordem da conversa. Projete procedimentos em torno da intenção que Fin precisa tratar, não em torno de um caminho estrito passo a passo.

Um procedimento que trata de perguntas sobre Data Connectors ilustra isso bem.

"Pergunta sobre Data Connector" cobre na verdade pelo menos cinco conversas diferentes:

A etapa inicial de Instrução diz para Fin ler a primeira mensagem do cliente e determinar qual situação se aplica.

Etapas de condição mais abaixo então enviam a conversa pelo caminho correspondente.

O direcionamento acontece no gatilho, então é isso que você precisa testar — e a ferramenta certa é o teste ao vivo, não simulações. Simulações ignoram completamente a correspondência de intenção; elas executam um procedimento diretamente sem passar pelo gatilho, então não podem dizer se Fin seleciona o procedimento correto desde o início.

Para testar o direcionamento, configure o procedimento ao vivo com o público limitado a você mesmo — por exemplo, uma regra onde o email contenha seu domain da empresa. Envie dez mensagens iniciais realistas e verifique duas coisas: que este procedimento começa quando deve, e que não começa quando não deve. Inclua mensagens ambíguas; esses são os casos mais propensos a direcionamento incorreto. Quando uma mensagem é direcionada incorretamente, ajuste a descrição do gatilho para ser mais específica sobre quando Fin deve e não deve usar o procedimento.

Liste os tipos distintos de conversas que seu procedimento receberá. Então pergunte: são o mesmo trabalho com pequenas variações, ou trabalhos genuinamente diferentes? Se forem genuinamente diferentes, você tem duas opções: dividi-los em procedimentos separados com gatilhos distintos, ou tratá-los como ramificações dentro de um procedimento. Use procedimentos separados quando os trabalhos forem distintos o suficiente para que você queira ver o desempenho relatado separadamente. Use ramificações quando os trabalhos forem relacionados e você quiser manter a lógica em um só lugar.

Escreva seu gatilho para que fique claro sobre ambos os lados: quando Fin deve usar este procedimento, e quando não deve. Gatilhos vagos são a fonte mais comum de direcionamento incorreto. Dentro do procedimento, nunca peça aos clientes para categorizarem seu próprio problema — Fin lê a mensagem deles e direciona a partir disso. O trabalho do cliente é descrever o problema, não rotulá-lo.

Use a etapa de Condição para caminhos principais mutuamente exclusivos — situações onde o que Fin faz a seguir é completamente diferente dependendo da resposta. Para diferenças menores, mantenha a lógica em uma etapa de Instrução como linguagem natural. Isso mantém os procedimentos mais simples e fáceis para Fin seguir.

Os seguintes fatores ajudam você a escolher entre dividir trabalhos em procedimentos separados ou tratá-los como ramificações dentro de um procedimento:

Se seu procedimento tem acesso a um Data Connector que pode responder parte da pergunta do cliente, chame-o antes de começar a entrevistar o cliente.

Os clientes percebem isso como competência. Procedimentos que entrevistam primeiro parecem formulários.

Quando a pergunta do cliente é sobre um conector específico, o procedimento Data Connectors Setup and Troubleshooting pergunta uma vez o nome do conector. Em seguida, chama um Data Connector diagnóstico dedicado e obtém os seguintes campos:

A primeira resposta significativa do Fin usa esses dados. Veja a diferença na prática (valores abaixo são ilustrativos):

Após a execução do Data Connector, leia a primeira mensagem do Fin em voz alta. Se ele fizer perguntas que você poderia ter respondido com os dados já buscados, você não está usando os dados de forma agressiva o suficiente.

Empurre mais decisões para etapas de Condição que leem os dados em vez de empurrá-las para o cliente.

Faça um inventário dos Data Connectors disponíveis para seu procedimento. Para cada um, pergunte: "Posso chamar isso antes da primeira pergunta do cliente em vez de depois?" Se a resposta for sim, reestruture para que a busca de dados aconteça primeiro. O cliente deve sentir que o Fin já fez o dever de casa.

Depois de buscar dados diagnósticos, ramifique diretamente com base nesses dados. Não faça o cliente descrever um estado que você já pode detectar.

Após a execução do Data Connector, sua resposta fica disponível como contexto temporário. Leia campos individuais usando a ação de atributo de leitura, depois use etapas de Condição que ramificam diretamente com base nesses valores.

A tabela abaixo mostra como valores específicos dos campos do Data Connector mapeiam para ramificações de etapas de Condição e a ação correspondente que o Fin deve tomar:

Cada ramificação produz uma mensagem de abertura diferente escrita especificamente para aquele estado.

Para cada ramificação, pergunte: "A resposta do Fin nesta ramificação faria sentido se um cliente real nesse exato estado a lesse?"

A ramificação do conector saudável é frequentemente a mais difícil de acertar porque o instinto é continuar diagnosticando. Resista a isso. Se o conector parecer saudável, diga isso e avance na conversa.

Observe cada dado que você obtém e pergunte se ele deve conduzir um passo de Condição.

Mantenha a lógica enxuta e escreva cada ramo como se fosse a única resposta que o cliente verá.

O modo de falha mais comum em um procedimento orientado a dados não é um erro do Data Connector. É uma chamada bem-sucedida que não retorna resultados.

Normalmente isso acontece porque a entrada do cliente não corresponde a nada.

URLs do Data Connector devem ser exatas. Quando os clientes fornecem URLs que não correspondem ao connector que pretendem, seja por erros de digitação, barras finais ou outras variações, o Data Connector frequentemente retorna campos vazios em vez de um erro.

Sem um tratamento explícito, Fin pode continuar e gerar respostas baseadas em dados que nunca encontrou de fato.

A solução é um passo de Condição que verifica se campos-chave estão vazios ou nulos. Se estiverem, Fin pede ao cliente para verificar a URL do data connector nas configurações de Data Connectors e fornecê-la exatamente como aparece. O Data Connector então executa novamente usando a URL corrigida.

Tente entradas que quase correspondem, mas não:

Se o procedimento não detectar e recuperar desses casos, o caminho de fallback não é forte o suficiente.

Cada vez que você chamar um Data Connector, adicione um passo de Condição imediatamente depois para "sem resultados."

Nesse ramo:

Um procedimento se torna confiável por meio de testes. O Intercom oferece três ferramentas que capturam problemas progressivamente diferentes — use-as em ordem, pois cada uma encontra problemas que a anterior não consegue.

Clique em Revisão no editor de procedimentos (canto superior direito, ao lado de Testar).

A Revisão executa uma análise estática da configuração do seu procedimento e retorna uma lista de problemas sinalizados com correções específicas. Ela captura problemas na construção, como:

A Revisão não executa uma conversa nem mostra como Fin realmente se comportaria em tempo de execução — ela apenas inspeciona a configuração. Execute-a primeiro para corrigir problemas estruturais antes de gastar tempo em simulações.

Simulações executam o procedimento de ponta a ponta contra uma mensagem inicial, sem saída para o cliente. A transcrição mostra mais do que a resposta final: o raciocínio do Fin em cada passo, qual ramo foi escolhido, atualizações de atributos e chamadas ao Data Connector. Você pode anexar critérios de sucesso para afirmar a resposta, valores de atributos, chamadas ao connector e resultado, transformando um cenário em um teste repetível de aprovação/reprovação.

Simulações ignoram completamente o reconhecimento de intenção — executam o procedimento diretamente e não testam se seu gatilho dispara corretamente. Para testar o roteamento de intenção, use testes ao vivo limitados a você (explicado abaixo).

Uma vez que a Revisão esteja limpa e suas simulações passem, teste a experiência genuína de ponta a ponta. Defina o procedimento ao vivo com o público limitado a você — por exemplo, uma regra onde o email contenha seu company domain. Isso permite testar a experiência completa em uma conversa real sem expô-la aos clientes. Quando estiver satisfeito, atualize a regra do público para incluir todos os clientes. Salvar a alteração da regra cria um novo rascunho, então clique em Definir ao vivo novamente para que a mudança tenha efeito.

Testes ao vivo capturam coisas que simulações não conseguem — o acionamento correto do gatilho, o fluxo real da conversa e a sensação de cada resposta quando chega no contexto.

Acompanhe a porcentagem de conversas de teste onde a primeira resposta do Fin teria parecido correta para o cliente. Não pergunte apenas "Foi roteado corretamente?" — pergunte "Um humano atento acharia essa primeira resposta útil?"

Com o tempo, conecte isso a sinais objetivos já disponíveis no Intercom: taxa de resolução, CSAT e tempo de atendimento da conversa. Se uma melhoria no procedimento estiver funcionando, você deve ver esses indicadores se moverem.

Siga as camadas na ordem:

Toda vez que você publica um procedimento, o Intercom pede para você escrever uma nota ‘O que mudou?’. Trate esse campo como um changelog real, não uma formalidade. Parece uma tarefa no momento, mas é o registro que permite conectar uma mudança de métrica a uma alteração específica semanas depois, em vez de adivinhar.

Um procedimento nunca está concluído — você continuará refinando-o, e cada mudança é uma pequena aposta de que o procedimento melhora. O histórico de versões é o registro dessas apostas. Se a taxa de resolução, CSAT ou tempo de atendimento mudar após uma alteração, uma nota clara informa o que mudou e quando, para que você possa rastrear a mudança até uma edição específica em vez de adivinhar.

Escreva o que a mudança faz e por quê, não apenas onde ela está:

A segunda versão é uma nota que você pode agir seis semanas depois. A primeira não é.

Se uma mudança degrada o desempenho, reverta pelo Histórico de versões:

Você também pode editar uma nota existente (ícone de lápis no Histórico de versões) para esclarecer o que uma mudança passada realmente fez.

Quando uma métrica cai, abra primeiro o Histórico de versões. Alinhe a data da queda com suas notas de mudança. A causa geralmente é a mudança que foi publicada logo antes.

A primeira versão do procedimento Data Connectors Setup and Troubleshooting entrevistava os clientes antes de procurar qualquer coisa. Fin fazia três ou quatro perguntas antes de dizer algo útil. Era tecnicamente funcional, mas parecia um formulário.

O Data Connector diagnóstico veio na próxima iteração. Essa única adição mudou o caráter de todo o procedimento. Em vez de começar com perguntas, Fin podia começar com observações específicas — "Seu conector tem uma taxa de sucesso de 64% nos últimos 7 dias e o erro mais recente foi um 401" — e então passar diretamente para resolver o problema.

Depois disso, o roteamento de intenção foi separado do fluxo diagnóstico. Clientes perguntando o que os Data Connectors podem fazer seguiam um caminho diferente dos clientes com um conector quebrado. Isso eliminou muitas perguntas diagnósticas irrelevantes para pessoas que só precisavam de uma resposta rápida sobre capacidades.

Cada iteração foi guiada por um padrão específico de falha identificado em conversas reais: um cliente que caiu na ramificação errada, um caso que o roteamento não antecipou, uma resposta tecnicamente correta mas inútil no contexto. Nenhuma iteração veio de suposições. Todas vieram de evidências.

O sinal mais claro de que um procedimento está funcionando é a qualidade da primeira resposta do Fin. Antes desse procedimento existir, um cliente perguntando sobre um conector com falha respondia várias perguntas antes de receber qualquer orientação. Com o procedimento, a primeira resposta significativa do Fin começa com o que realmente encontrou: o estado do conector, sua taxa de sucesso na última semana e seu código de erro mais recente. O diagnóstico começa com dados, não com uma entrevista.

A profundidade do roteamento também importa. 13 caminhos distintos significam que cada situação recebe uma orientação que realmente se encaixa. Um cliente perguntando sobre integração SOAP recebe uma resposta direta e honesta sobre o que é suportado — não um fluxo de solução de problemas que não leva a lugar nenhum. Um cliente cujo conector está saudável, mas cujos dados não estão mapeando corretamente, não é enviado primeiro para solução de problemas de autenticação.

E quando uma conversa precisa de um agente humano, a nota de transferência já contém o nome do conector, a URL do conector e a categoria do problema. O colega tem contexto antes de ler uma única mensagem do cliente. Isso é algo pequeno do ponto de vista do design — uma etapa de nota no final do procedimento — mas muda a transferência de um reinício para uma continuação.

Quando esses seis princípios são combinados, um procedimento como o exemplo dos Data Connectors tende a seguir uma estrutura previsível:

Princípio 6 — manter um changelog honesto — não é uma etapa na estrutura, mas é o que torna tudo melhorável ao longo do tempo. Sem um registro claro do que mudou e quando, cada iteração é um palpite.

Os melhores Fin Procedures não se tornam eficazes por causa de um primeiro rascunho inteligente. Eles se tornam eficazes porque cada iteração é guiada por evidências de conversas reais.

Comece com seu procedimento de maior volume. Aplique o Princípio 1 primeiro: mapeie todas as intenções que ele pode receber e verifique se o roteamento está funcionando. Depois, construa a partir daí.

A primeira versão é o ponto de partida. A boa versão é aquela que você refinou repetidamente.