Este artigo aborda exemplos práticos de como estruturar suas etapas, condições e chamadas de conector de dados em Procedimentos Fin.

A etapa Instrução é a etapa padrão e mais poderosa.

Menos etapas, bem projetadas e que combinam ações relacionadas de forma coerente são melhores do que muitas etapas pequenas e separadas.

❌ Menos eficaz:

✅ Mais eficaz:

@read email. Se não for conhecido, peça ao usuário seu email antes de continuar. Então @use get_subscription_details e responda perguntando com o que o usuário precisa de ajuda. Inclua o plano atual do usuário, status do plano e próxima data de renovação na sua resposta.

Pense no Fin como um novo colega de equipe sem contexto prévio. Se um humano não entender facilmente suas instruções, provavelmente o Fin também não entenderá.

❌ Menos eficaz:

Colete o número do pedido do cliente e certifique-se de que é válido e não um número de rastreamento

✅ Mais eficaz:

Colete o número do pedido do cliente. Se ele forneceu um número, mas ele tem mais de 11 caracteres excluindo o # no início, informe que pode ser um número de rastreamento e peça o número do pedido novamente. Se o cliente não puder fornecer o número do pedido, não continue @Escalate:Support team.

Use @Add note dentro de uma etapa de instrução para deixar contexto interno na conversa. Isso é especialmente útil antes de escalonamentos ou transferências, dando aos colegas o contexto necessário.

❌ Menos eficaz:

✅ Mais eficaz:

@use Get_Order_Details e informe ao cliente o status. Se o pedido estiver perdido ou não entregue após a data prevista, @Add note com o número do pedido, fornecedor de envio, data prevista de entrega e status atual do rastreamento. Então @Escalate para Support team.

Condições dizem ao Fin como se comportar em diferentes situações. Você pode usá-las para grandes e distintas ramificações na sua lógica.

Este exemplo usa uma condição Código para verificar a saída de um conector de dados.

SE: data["Check refund eligibility"].decision == "eligible"

SENÃO:

Este exemplo usa Linguagem Natural para verificar um atributo.

SE: @Read Fulfillment status é 'fulfilled'

A partir daqui, você pode clicar no ícone + para Adicionar condição else if ou Adicionar else.

Você pode usar conectores de dados e atributos para obter ou atualizar informações.

Você pode instruir o Fin a usar um conector de dados para obter ou atualizar informações de um sistema externo.

Exemplo: @Use: Get order status e informe ao cliente qual é o status do pedido.

Você não precisa dizer explicitamente ao Fin para coletar os dados que um conector precisa. O Fin infere as entradas que precisa coletar com base na configuração do conector.

❌ Errado (desnecessariamente complexo):

Primeiro peça ao cliente o e-mail dele, depois chame @get_order_details com esse e-mail

✅ Simples e claro:

Chame @get_order_details

Quando você usa um conector de dados, os dados retornados estão disponíveis durante todo o Procedimento. Use @read attribute para acessar esses dados em etapas posteriores, em vez de chamar o mesmo conector novamente.

❌ Menos eficaz (mais lento):

Simples e mais rápido:

Você também pode ler dados do Intercom como atributos de Pessoas, Empresa ou Conversa.

Exemplo: Diga ao cliente o @Read People.Plan dele

Seções permitem que você organize um Procedimento em blocos nomeados e lógicos. Por padrão, o Fin executa as etapas de cima para baixo, independentemente dos limites das seções — as seções não mudam o comportamento de execução a menos que você direcione o Fin para pular para uma delas.

Divida um procedimento longo em seções nomeadas para melhorar a legibilidade e facilitar a navegação com Ir para seção.

Seção: Verificar pedido

Seção: Determinar tipo de devolução

SE: o cliente quiser um reembolso

SENÃO:

Seção: Processar reembolso

Seção: Processar troca

Use seções para organizar o fluxo dentro de um único procedimento. Use sub-procedures quando a mesma lógica for reutilizada em vários procedimentos ou quando quiser encapsular uma parte complexa da lógica que tenha suas próprias entradas e saídas.

Sub-procedures são conjuntos reutilizáveis de etapas que podem ser chamados de outro Procedimento. Isso é recomendado para lógica complexa ou repetida.

Você pode executar um sub-procedimento como parte de um ramo condicional.

SE: a escolha do cliente for devolver o item e receber um reembolso total

SENÃO:

Use nomes claros e orientados para ação que comuniquem o que o sub-procedimento faz.

✅ Bons nomes:

❌ Nomes ruins:

A etapa Perguntar ao Colega permite que Fin pause no meio do procedimento e solicite a opinião de um colega humano — sem transferir toda a conversa. Use isso para decisões de alto risco, sensíveis ou complexas, onde você quer automação na maior parte do tempo, mas ainda precisa de um humano em pontos-chave.

Passo 1: @use Check_Refund_Eligibility. Se elegível, @read refund amount.

SE: data["Check_Refund_Eligibility"].refund_amount > 500

SENÃO:

Quando Fin chega na etapa Perguntar ao Colega:

Você pode direcionar Fin para mudar de um procedimento para outro quando as necessidades do cliente mudam no meio da conversa.

Use o comando @Switch dentro de uma etapa de instrução para mover explicitamente para outro procedimento.

Exemplo:

Se o cliente disser que deseja cancelar a assinatura em vez de atualizar o método de pagamento, @Switch para o procedimento de Cancelamento.

Quando o Agentic Switch está ativado, Fin pode mudar autonomamente do procedimento atual para outro procedimento ativo se determinar que a intenção do cliente mudou. Fin toma essa decisão com base na conversa e nas descrições dos gatilhos do procedimento, e pode fazer perguntas para esclarecer.

Agentic Switch é opcional e pode ser ativado nas configurações do procedimento. Você ainda pode usar @Switch para controle determinístico junto com o Agentic Switch.

Use Orientação para regras gerais e etapas de Fim para dizer ao Fin o que fazer a seguir.

Use a seção Orientação para regras globais sobre como Fin deve interagir durante este Procedimento.

As etapas de Fim dizem ao Fin que o Procedimento terminou e o que fazer a seguir.