Este artigo é para colegas de suporte e qualquer pessoa responsável por configurar ou manter o Fin que queira usar Monitors como parte de um fluxo de garantia de qualidade (QA) para problemas de resposta do Fin. Cobre o que fazer depois que um monitor começa a trazer conversas: como interpretar resultados, aplicar julgamento humano e transformar descobertas em melhorias.

Se você procura instruções de configuração, veja o guia de configuração do Monitor.

A garantia de qualidade para o Fin costumava significar revisar uma pequena amostra de conversas, procurar qualquer coisa que parecesse fora do comum e esperar que você identificasse os padrões importantes. Essa abordagem funcionava quando o volume de conversas era gerenciável. Hoje, não escala.

O Fin mudou o que é possível. Em vez de revisar manualmente uma fração das conversas, você pode avaliar milhares. O desafio não é mais encontrar problemas — é saber quais realmente importam.

É por isso que os fluxos de QA mais eficazes não substituem colegas humanos por IA. Eles combinam a capacidade do Fin de expor padrões com o julgamento humano para interpretar esses padrões e transformá-los em melhorias significativas.

Um monitor avalia continuamente as conversas com base em critérios que você define — seja uma amostra aleatória para QA contínuo, ou conversas direcionadas com base em sinais como pontuações CX baixas (sua avaliação de experiência do cliente no Intercom), escalonamentos repetidos ou qualidade da resposta. Essas conversas podem então ser revisadas usando um scorecard pelo Fin, por um revisor humano ou por ambos.

O Intercom inclui modelos para fluxos de QA comuns, incluindo revisões semanais do Fin, baixa qualidade de resposta, tratamento de escalonamentos, problemas recorrentes e mais. Você também pode criar Monitors do zero para se adequar às necessidades da sua equipe.

Pense nos Monitors como a camada de filtragem. Eles pegam um número esmagador de conversas e as reduzem às que têm mais probabilidade de precisar da atenção de alguém.

Um monitor não apenas sinaliza que uma conversa teve baixa pontuação. Para critérios avaliados por IA, ele mostra exatamente o porquê — até o critério específico e o raciocínio do Fin por trás da pontuação.

O que ele não faz é conectar os pontos entre conversas.

Você pode ter dez conversas com baixa qualidade de resposta e dez explicações diferentes geradas pela IA. Mas se olhar um pouco mais de perto, sete dessas conversas podem na verdade remontar ao mesmo artigo desatualizado.

O Fin pode dizer por que cada conversa individual teve baixa pontuação. Ele não pode dizer que sete desses "porquês" são, na verdade, o mesmo problema subjacente aparecendo de maneiras diferentes.

Reconhecer essa diferença requer conhecimento do produto e contexto. É a diferença entre essas duas conclusões:

Sem essa etapa, o QA se torna uma lista de conversas sinalizadas. Com ela, o QA se torna uma lista de melhorias acionáveis. Essa é a diferença entre ruído e insight.

O fluxo tem quatro passos:

É aqui que os Monitors fazem o trabalho pesado. Em vez de amostrar manualmente conversas e esperar encontrar algo útil, os Monitors avaliam continuamente cada conversa que corresponde aos seus critérios e destacam as que têm mais probabilidade de precisar de atenção.

Esta é a etapa que o Fin não pode substituir. Monitors podem dizer que dez conversas tiveram baixa pontuação — mas não dirão se todas são sintomas do mesmo problema, se o problema é conteúdo desatualizado ou se o Fin está seguindo orientações que não refletem mais seu produto.

Seus especialistas de produto humanos são os que conectam esses pontos.

Uma conversa sinalizada não é uma ação. Compare estas duas conclusões:

A segunda dá à equipe algo concreto para corrigir. Sempre que possível, identifique o artigo, procedimento ou regra de orientação do Fin específico que está causando o problema, em vez de apenas descrever o sintoma.

Insights só criam valor se alguém agir sobre eles. Uma lacuna de conhecimento pode pertencer à equipe responsável pelo help center. Um problema de procedimento pode pertencer às pessoas que mantêm a orientação do Fin ou o design de conversação.

Nem toda organização tem equipes dedicadas de Gestão do Conhecimento ou Design de Conversação. Equipes menores podem ter uma pessoa desempenhando várias funções. A distinção importante não é quem possui o trabalho. É identificar se você está lidando com um problema de conteúdo ou de procedimento, para que a melhoria certa seja feita.

Quanto mais específica for sua recomendação, menos tempo outra pessoa gastará redescobrindo o problema e mais tempo ela gastará resolvendo-o ativamente.

Você pode fazer isso diretamente dentro do Monitor usando Issues.

Do painel lateral Review de qualquer conversa, você pode abrir um ticket Issue com um título, tipo (Content, Guidance, Procedure, Escalation, e mais) e responsável — sem sair da conversa. A mesma Issue pode ser vinculada a várias conversas onde o mesmo problema apareceu, para que sua equipe tenha um ticket por causa raiz em vez de um por conversa. Todas as Issues se reúnem em uma visualização central em Fin AI Agent > Analyze > Monitors, onde você pode acompanhar o status desde a submissão até a resolução.

Para detalhes completos de configuração, veja Rastrear e agir sobre issues encontradas em revisões QA do Monitor.

Quando um monitor continua trazendo o mesmo problema, geralmente é um sinal de que algo maior precisa de atenção — um artigo do help center, um procedimento do Fin ou uma orientação que precisa ser ajustada.

Monitors são ótimos em identificar padrões em milhares de conversas, mas não conseguem dizer quais padrões realmente valem a pena agir. É aí que entram os especialistas de produto humanos. Eles usam seu conhecimento do produto e contexto para identificar a causa raiz, transformar essas descobertas em recomendações acionáveis e garantir que elas cheguem à equipe responsável por corrigi-las.

À medida que o Fin melhora em encontrar padrões, o papel do especialista de produto evolui. Em vez de passar tempo procurando problemas, eles podem se concentrar em entender o que os dados estão dizendo, decidir o que é mais importante e conduzir melhorias significativas.