Como defender os Procedimentos Fin internamente

Conseguir que o Fin responda perguntas é um primeiro passo importante. Os Procedimentos vão além, ajudando o Fin a resolver problemas repetitivos e de múltiplas etapas — não apenas explicando um processo, mas realmente concluindo-o.

Para isso, o Fin geralmente precisa de acesso a informações ou ações em seus sistemas internos, o que significa que você pode precisar de ajuda da engenharia ou da equipe que gerencia esses sistemas internamente.

Este guia é para líderes de suporte e operações que estão promovendo os Procedimentos internamente. Ele ajudará você a delimitar o pedido, falar com stakeholders técnicos com confiança e manter o primeiro projeto pequeno o suficiente para ser aprovado.

Por que isso importa

O Fin já lida bem com perguntas informativas. Os Procedimentos desbloqueiam um tipo diferente de valor: resolver problemas que dependem de dados em tempo real ou ações do sistema, como verificar o status de um pedido, consultar uma assinatura ou processar uma devolução.

É aí que começa o trabalho de advocacy interno. Se um problema do cliente depende de dados ao vivo ou de uma ação do sistema, sua equipe precisará de Data Connectors e acesso à API para tornar essa experiência possível.

A oportunidade não é apenas evitar contatos. É resolução mais rápida, menos trabalho manual repetitivo e uma experiência do cliente mais fluida para suas tarefas de maior volume.

Sem Procedimentos vs. com Procedimentos

Sem Procedimentos	Com Procedimentos
O Fin informa ao cliente como enviar uma reclamação por pedido danificado.	O Fin processa a reclamação, verifica o status do pedido no seu banco de dados e confirma a substituição — tudo em uma única conversa.
O Fin informa ao cliente para fazer login e verificar a data de renovação da assinatura.	O Fin consulta a data de renovação e o status da assinatura em tempo real e fornece uma resposta imediata ao cliente — sem necessidade de login.

De acordo com o Relatório de Transformação do Atendimento ao Cliente 2026 da Intercom, equipes que integram IA em workflows reais, em vez de parar em FAQs superficiais, relatam ROI significativamente maior e métricas aprimoradas. A maioria das equipes investe em IA, mas apenas uma pequena minoria alcançou implantação madura.

Comece antes da engenharia: o que você pode fazer agora

Nem todo Procedimento requer trabalho de engenharia. Antes de envolver stakeholders técnicos, explore o que você pode construir com o que já tem.

Procedimentos que não precisam de Data Connectors:

Fluxos de solução guiada usando conteúdo da knowledge base
Passo a passo que coleta informações e direciona para a equipe certa
Procedimentos de triagem que fazem perguntas qualificatórias antes de escalar
Fluxos de aplicação de políticas (ex.: verificações de elegibilidade de garantia com base na data da compra)

Procedimentos usando a etapa Ask Teammate:

Se um Procedimento precisa de informações de outro sistema, mas a engenharia ainda não está disponível, você pode usar a etapa Ask Teammate como substituto. Um colega completa manualmente essa etapa enquanto o Data Connector está sendo construído, para que você possa testar o fluxo completo do procedimento e coletar dados sobre seu impacto.

Começar aqui oferece duas vantagens: você aprende a construir Procedimentos e gera resultados mensuráveis que justificam o investimento em engenharia quando necessário.

Dica: As equipes agora podem construir e gerenciar Procedimentos usando linguagem natural, aplicar os controles e dados necessários para precisão e testar todos os cenários antes que cheguem ao cliente. Muitos dos blocos de construção, como descrições, gatilhos, condições e orientações, não exigem habilidades técnicas.

Novo em APIs e Data Connectors?

Se você é novo nesses termos, esta seção cobre o que você precisa saber para delimitar o pedido e explicá-lo internamente.

Uma API (Interface de Programação de Aplicações) é uma forma estruturada para sistemas de software trocarem informações. Quando um sistema precisa de um dado de outro, ele envia uma solicitação via API e recebe uma resposta.

Um Data Connector usa uma chamada API para que o Fin possa recuperar ou enviar com segurança uma informação específica, como o status de um pedido ou a data de renovação de uma assinatura. Cada connector geralmente é projetado para uma tarefa específica. Saiba mais sobre Data Connectors.

Um Procedimento usa esses connectors dentro de um processo de múltiplas etapas, para que o Fin possa fazer mais do que responder uma pergunta, ele pode ajudar a resolver o problema. Saiba mais sobre Procedimentos.

Para seu primeiro projeto, comece pequeno: um processo repetível, um sistema e apenas os poucos campos de dados que o Fin realmente precisa. Quanto mais focado o pedido, mais rápido ele avança.

Exemplo: como as peças se conectam

Objetivo do cliente: “Verificar a data de renovação da minha assinatura”
Procedimento: Fin confirma a identidade, chama o sistema de cobrança e retorna a data de renovação, tudo em uma conversa
Data Connector: Uma chamada API somente leitura para a plataforma de cobrança, retornando três campos: data de renovação, nome do plano, status da assinatura
Resultado: Fin responde em segundos. Nenhum colega necessário

O Fin não precisa de acesso ao seu sistema inteiro. Geralmente, ele precisa de uma forma segura para recuperar ou enviar um pequeno conjunto de dados aprovados. A engenharia ou o proprietário do sistema define exatamente quais campos o Fin pode acessar, nada mais.

Para a configuração técnica completa, consulte o artigo designing and using your APIs with Data connectors.

Como escolher seu primeiro Procedimento

O melhor caso interno começa com um processo concreto, não com uma proposta de recurso. Antes de envolver a engenharia, escreva o processo exato que deseja automatizar e os dados mínimos que o Fin precisa para executá-lo bem.

Um bom primeiro Procedimento geralmente é estreito, repetitivo e já bem compreendido pela sua equipe de suporte.

Dica profissional: Escolha o processo mais valioso que você pode automatizar com o menor número de endpoints e o menor conjunto de campos. Um Procedimento que lê alguns campos de um sistema é muito mais fácil de aprovar, construir e lançar do que um que toca múltiplos sistemas. Comece estreito — a complexidade pode vir depois, uma vez que a primeira vitória esteja garantida.

Critérios de seleção

Use os critérios abaixo para identificar seu melhor candidato:

Critérios	O que observar
Volume	Um problema de alta frequência que sua equipe lida repetidamente
Repetibilidade	Um processo com etapas consistentes que não requer julgamento humano a cada vez
API availability	Uma API bem documentada já existe (por exemplo, Stripe, Shopify) ou pode ser definida rapidamente
Propriedade do sistema	Você sabe qual equipe interna ou ferramenta possui os dados ou ação (por exemplo, "isso está no Salesforce" ou "nossa equipe de faturamento cuida disso")
Clareza no pedido de engenharia	Você pode descrever o que Fin precisa em uma frase sem usar termos técnicos. Fin só precisa de um pequeno número de campos de um sistema
Mensurabilidade	Você pode definir uma métrica clara de sucesso antes de construir (por exemplo, taxa de resolução)

Exemplo: um bom primeiro Procedimento

Use case: Verificar data de renovação da assinatura
System: Plataforma de faturamento
What Fin needs: Data de renovação, nome do plano, status da assinatura — três campos de um endpoint
First ask: "Precisamos de um endpoint somente leitura que retorne esses três campos para um cliente autenticado."
Why it works: Alto volume, repetitivo, baixo risco e fácil de medir. Não requer acesso de escrita e um esforço mínimo da engenharia ou do proprietário do sistema.

Pense em fases, não tudo de uma vez

As equipes mais bem-sucedidas adotam Procedimentos em etapas:

1. Sem integração necessária: Automatize fluxos estilo FAQ, guias de solução de problemas e lógica de roteamento usando apenas conteúdo da knowledge base.

2. Acesso somente leitura: Conecte Fin a um sistema para consultar informações (por exemplo, status do pedido, detalhes da conta, datas de assinatura). É aqui que entra o primeiro Data Connector.

3. Ações de escrita: Permita que Fin tome ações em outro sistema (por exemplo, processar um reembolso, cancelar uma assinatura, atualizar um registro). Isso requer envolvimento mais profundo da engenharia e geralmente ocorre após a confiança ser estabelecida.

Começar com a Fase 1 ou 2 significa que você pode mostrar resultados rapidamente e usar esses resultados para construir o caso para a Fase 3.

Dica: O painel de Recomendações Fin AI Agent > Analyze > Recommendations é a maneira mais rápida de encontrar seus melhores candidatos a Procedimentos.

Filtre por Lacunas de dados do cliente: onde Fin precisava de informações de um sistema externo como status do pedido ou detalhes da conta
Filtre por Lacunas de ação: onde Fin precisava tomar uma ação em outro sistema como cancelar um pedido ou atualizar um registro.

Cada recomendação inclui um guia que descreve a API e os dados necessários, tornando-o um resumo pronto para sua conversa com a engenharia. Extraia uma amostra de conversas do painel de Recomendações, identifique intenções específicas do cliente que podem se tornar Procedimentos e estime a melhoria na taxa de resolução com base na frequência dessas solicitações. Isso transforma uma ideia geral em um plano concreto e definido.

Mapeie o processo antes da reunião

Antes de abordar a engenharia ou a equipe que possui o sistema relevante, mapeie exatamente o que você quer automatizar. Este é o passo mais importante — um processo bem mapeado torna a conversa técnica mais rápida e o pedido mais difícil de ser recusado.

Como mapear

1. Escreva o processo passo a passo em linguagem simples. O que o desencadeia? O que acontece em cada etapa? O que o cliente recebe no final?

2. Destaque exatamente onde Fin precisa de dados de outro sistema ou precisa tomar uma ação. Esses são seus pontos de contato do Data Connector.

3. Para cada ponto de contato, liste os campos de dados específicos que Fin precisa. Não o banco de dados inteiro — apenas os campos mínimos para este processo.

4. Identifique qual equipe possui cada sistema. Nem sempre é a engenharia. Pode ser a equipe que administra Salesforce, Jira, sua plataforma de faturamento ou outra ferramenta interna.

O que levar para a reunião

O processo mapeado com pontos de contato claros do Data Connector
Os campos específicos que Fin precisa em cada etapa (por exemplo, "status do pedido, número de rastreamento, data estimada de entrega")
Uma métrica de sucesso que você pode medir antes e depois (por exemplo, "taxa de resolução para consultas de status de pedido")
Dados de volume mostrando com que frequência esse problema ocorre (extraia isso do painel de Recomendações ou do seu relatório)

Dica profissional: Considere mapear o processo visualmente em uma ferramenta como Miro ou um fluxograma simples. Isso ajuda todos, incluindo partes interessadas não técnicas, a ver o quadro completo e identificar onde está o trabalho da engenharia.

Quem está envolvido e o que fazem

Construir um Procedimento requer dois tipos de alinhamento: clareza sobre quem possui o que no dia a dia e saber quais stakeholders precisam ser envolvidos para obter aprovação.

Propriedade do dia a dia

Equipe de CX / Suporte	Equipe de engenharia
Escreva e atualize o Procedimento em linguagem natural usando etapas, ferramentas e orientações dentro do Intercom	Exponha o acesso ao sistema via Data Connectors (chamadas API autenticadas)
Defina a lógica do Procedimento, cenários de teste e métricas de sucesso	Defina o endpoint, tipo de requisição (por exemplo, GET, POST) e campos específicos que Fin tem permissão para usar
Seja responsável pela iteração após o lançamento	Defina cabeçalhos de autenticação ou tokens e confirme as restrições de segurança

Quem precisa estar na sala

Função	Quem eles normalmente são	O que eles contribuem
Campeão	Líder de suporte ou operações que conduz a iniciativa	Mapeia o processo de ponta a ponta e define o que Fin precisa para fazê-lo bem
Patrocinador direto	Chefe de suporte, CX ou operações	Aprova o Procedimento como prioridade e dá ao campeão o mandato para avançar
Proprietário do sistema	A equipe ou indivíduo responsável pela ferramenta interna relevante (por exemplo, administrador do Salesforce, líder da equipe de faturamento, proprietário do Jira)	Confirma quais dados existem, quem pode acessá-los e quais restrições se aplicam
Líder técnico	Desenvolvedor, arquiteto ou líder de engenharia para o sistema que está sendo conectado	Alinha a viabilidade, define o endpoint e os campos permitidos, e confirma o cronograma

Esta nem sempre é uma conversa de engenharia. Se os dados que Fin precisa estão no Salesforce, Jira, sua plataforma de faturamento ou outra ferramenta interna, o principal interessado pode ser a equipe que possui esse sistema, não um engenheiro de software. Identifique o proprietário do sistema primeiro, depois determine se é necessária a participação da engenharia.

O caso de negócio por parte do interessado

O mesmo Procedimento pode ser apresentado de forma muito diferente dependendo de quem está na sala. Antes de preparar a apresentação, descubra quais prioridades sua liderança já é responsável e enquadre o Procedimento como uma contribuição direta para um desses objetivos.

Para líderes de engenharia, é melhor manter o pedido limitado

"Não estamos pedindo que a engenharia assuma um workflow de AI. Estamos pedindo ajuda para expor um endpoint seguro para que a equipe de suporte possa automatizar um processo repetitivo e de alto volume por conta própria. Uma vez que o endpoint esteja no lugar, a equipe de CX constrói e mantém o Procedimento de forma independente, sem envolvimento contínuo da engenharia"
O que compartilhar: O endpoint específico, os campos necessários, o tipo de requisição (GET ou POST) e o método de autenticação. Quanto mais preciso for o pedido, mais fácil será para um engenheiro estimar e agendar.
Abordando o investimento de tempo: Para equipes com APIs bem documentadas, a configuração do Data Connector é tipicamente um trabalho contido. Já vimos a equipe de desenvolvimento de um cliente colocar um conector somente leitura em funcionamento em menos de uma hora. O escopo é semelhante ao de construir qualquer outra integração de API, não um sistema novo.

Para liderança de suporte e CX, é melhor focar na resolução

"Sem essa integração, Fin só pode explicar o processo. Com ela, Fin pode completar o processo. Isso elimina esforço humano evitável e faz a experiência do cliente parecer instantânea."
O que compartilhar: O volume de conversas que este Procedimento lidaria, o tempo médio atual de atendimento e a melhoria esperada na taxa de resolução.

Para liderança executiva, é melhor alinhar a uma prioridade existente

"Diga-nos a meta pela qual você já está sendo medido — seja CSAT, tempo de atendimento ou redução da carga manual — e nós dimensionaremos este Procedimento para mostrar um resultado direto contra isso. Isso não precisa de um caso de negócio próprio. É uma contribuição direta para algo que você já está acompanhando."
Uma nota sobre o enquadramento: Para algumas organizações, o valor financeiro da automação é significativo. Para outras, a economia financeira de um único Procedimento pode não fazer diferença na escala delas. Nesses casos, comece pelo impacto qualitativo: melhores pontuações de experiência do cliente, resolução mais rápida e redução de atrito em workflows de alto volume. Conheça seu público e comece pelo que mais importa para eles.

Lidando com objeções comuns

Eles dizem...	Você diz...
"Não temos capacidade."	"Por isso este é um piloto restrito. Ao remover essa carga manual recorrente da equipe, na verdade criamos capacidade para sprints futuros."
"Não queremos acesso amplo ao sistema."	"Data Connectors são limitados a endpoints específicos e campos de resposta. Podemos começar com acesso somente leitura para garantir a segurança."
"Precisamos que a API esteja totalmente construída primeiro."	"Podemos começar a projetar agora. O Intercom suporta respostas JSON de exemplo na configuração, e podemos validar a lógica usando Simulações antes da API estar ativa." Você também pode usar a etapa Ask teammate como um substituto temporário, que permite que um colega complete manualmente essa etapa enquanto o conector está sendo construído, para que você possa testar o fluxo completo do procedimento de ponta a ponta.
"Não está no nosso roadmap deste trimestre."	"Entendido. Podemos incluir no próximo ciclo de planejamento? Enquanto isso, teremos o processo mapeado, os campos documentados e a métrica de sucesso definida — assim, quando a capacidade abrir, o pedido estará pronto."

Depois de alinhar com a engenharia, compartilhe o guia Create data connectors for Fin com seu desenvolvedor ou proprietário do sistema. Ele cobre todo o processo de configuração, incluindo conexão API, autenticação, transformação de dados e testes.

Se os recursos internos forem limitados

Às vezes, o verdadeiro bloqueio é o timing do roadmap. A engenharia pode ser favorável em princípio, mas não estar disponível até o próximo ciclo de planejamento. Isso é um resultado razoável, não uma falha.

O que fazer enquanto espera

1. Mapeie o processo de ponta a ponta em linguagem simples. Documente cada passo, cada campo de dados e cada ponto de contato do sistema.

2. Construa Procedimentos que não precisem de Data Connectors. Soluções guiadas, fluxos de triagem e automação baseada em knowledge base já criam valor agora.

3. Use a etapa Ask Teammate como uma ponte para etapas que eventualmente usarão um Data Connector.

4. Reúna dados de volume e acompanhe os resultados dos Procedimentos que você já construiu — isso se torna a evidência para seu próximo pedido.

5. Reduza o escopo o máximo possível para que o pedido de engenharia esteja pronto para ser encaixado quando a capacidade abrir.

Obtenha ajuda externa

Participe do Intercom semanal Community Meetup Office Hours para perguntas e respostas e suporte com mentores

Para obter ajuda com escopo, discutir bloqueios e ouvir como outras equipes navegaram por conversas internas semelhantes. Útil de forma ampla e gratuito para participar

Contrate um Expert para Suporte Personalizado 1:1

Para suporte mais prático e dedicado, o programa verified Experts conecta você a consultores independentes e desenvolvedores que se especializam em Fin e Data Connectors. Uma boa opção se você quer orientação 1:1 e está disposto a investir em um caminho mais personalizado

Dica: O Início rápido: Crie um Fin Procedure guia você passo a passo na construção do seu primeiro Procedure, incluindo um exemplo prático usando um Data Connector.

Recursos relacionados

Perguntas Frequentes

Precisamos criar uma nova API para usar Procedures?

Não necessariamente, se uma API bem documentada já existir (por exemplo, Stripe ou Shopify), normalmente é uma integração contida e de baixo esforço. A engenharia só precisa expor o endpoint específico e os campos que Fin tem permissão para usar.

Podemos testar um Procedure antes da API estar pronta?

Sim, o Intercom suporta respostas JSON de exemplo na configuração, para que você possa construir e validar a lógica usando Simulações antes da API ao vivo ser conectada.

A engenharia precisa construir o Procedure em si?

Normalmente não, a equipe de suporte ou operações é responsável pela lógica do Procedure — escrevendo os passos, testando e iterando após o lançamento. A engenharia ou o proprietário do sistema habilita a camada de dados: expondo o endpoint correto, definindo quais campos Fin pode acessar e configurando o método de autenticação. Uma vez que isso esteja em vigor, a equipe de CX pode construir e atualizar o Procedure de forma independente.

E se só pudermos ter acesso à API em modo somente leitura no início?

Esse é um ponto de partida perfeitamente válido. Um Procedure somente leitura, por exemplo, consultando o status de uma assinatura ou detalhes de um pedido, ainda elimina um esforço manual significativo e oferece um resultado mensurável para construir a partir dele.

Quanto tempo normalmente leva para a engenharia configurar um Data Connector?

Depende da complexidade, mas para equipes com APIs bem documentadas, um Data Connector somente leitura pode ser configurado relativamente rápido — às vezes em menos de uma hora. O escopo é semelhante ao de construir qualquer integração padrão de API: definir o endpoint, configurar a autenticação, mapear os campos da resposta. A equipe de CX cuida de todo o resto.

Podemos construir Procedures sem qualquer envolvimento da engenharia?

Sim. Procedures que usam conteúdo da knowledge base, fluxos guiados de solução de problemas, lógica de triagem ou o passo Ask Teammate não requerem Data Connectors nem trabalho de engenharia. Estes são um ótimo ponto de partida para ganhar confiança antes de expandir para Procedures conectados.