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 workflow de garantia de qualidade (QA) para problemas de resposta do Fin. Ele cobre o que fazer depois que um monitor começa a exibir conversas: como interpretar resultados, aplicar julgamento humano e transformar descobertas em melhorias.

Se você está procurando instruções de configuração, veja o Guia de configuração do Monitor.

Garantia de qualidade para o Fin costumava significar revisar uma pequena amostra de conversas, procurando qualquer coisa que parecesse fora do normal, e esperando identificar 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 workflows de QA mais eficazes não substituem colegas humanos por IA. Eles combinam a capacidade do Fin de identificar 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 baseadas em sinais como pontuações baixas de CX (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, um revisor humano, ou ambos.

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

Pense nos Monitors como a camada de filtragem. Eles pegam um número esmagador de conversas e reduzem para aquelas que provavelmente precisam de atenção.

Um monitor não apenas sinaliza que uma conversa teve uma pontuação baixa. Para critérios avaliados por IA, ele mostra exatamente o motivo — 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 as conversas.

Você pode ter dez conversas com baixa qualidade de resposta e dez explicações diferentes geradas por IA. Mas se olhar mais de perto, sete dessas conversas podem realmente estar relacionadas ao mesmo artigo desatualizado.

O Fin pode dizer por que cada conversa individual teve uma pontuação baixa. Ele não pode dizer que sete desses “porquês” são realmente o mesmo problema subjacente aparecendo de formas diferentes.

Reconhecer essa diferença requer conhecimento do produto e contexto. É a diferença entre estas 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 workflow tem quatro etapas:

É aqui que os Monitors fazem o trabalho pesado. Em vez de amostrar manualmente conversas e esperar encontrar algo útil, os Monitors avaliam continuamente todas as conversas que correspondem aos seus critérios e exibem aquelas que provavelmente precisam de atenção.

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

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

Uma conversa sinalizada não é um item de 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 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 conteúdo do help center. Um problema de procedimento pode pertencer às pessoas que mantêm a orientação ou o design de conversa do Fin.

Nem toda organização tem equipes dedicadas de Gestão do Conhecimento ou Design de Conversa. Equipes menores podem ter uma pessoa acumulando várias funções. A distinção importante não é quem é o dono do trabalho. É identificar se você está olhando para 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.

Na barra lateral Review de qualquer conversa, você pode abrir um ticket Issue com um título, tipo (Conteúdo, Orientação, Procedimento, Escalonamento e mais) e responsável — sem sair da conversa. O mesmo Issue pode ser vinculado 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. Todos os Issues se reúnem em uma visã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 encontrados em revisões de QA do Monitor.

Quando um monitor continua exibindo 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 para identificar padrões em milhares de conversas, mas não podem dizer quais padrões realmente valem a pena agir. É aí que entram os especialistas humanos em produto. 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 na identificação de padrões, o papel do especialista em produto evolui. Em vez de gastar tempo procurando problemas, eles podem se concentrar em entender o que os dados estão dizendo, decidir o que importa mais e impulsionar melhorias significativas.