This article is for support teammates and anyone responsible for configuring or maintaining Fin who want to use Monitors as part of a quality assurance (QA) workflow for Fin answer issues. It covers what to do after a monitor starts surfacing conversations: how to interpret results, apply human judgment, and turn findings into improvements.

If you're looking for setup instructions, see the Monitor setup guide.

Quality assurance for Fin used to mean reviewing a small sample of conversations, looking for anything that seemed off, and hoping you'd spot the patterns that mattered. That approach worked when conversation volume was manageable. Today, it doesn't scale.

Fin has changed what's possible. Instead of manually reviewing a fraction of conversations, you can evaluate thousands. The challenge isn't finding issues anymore — it's knowing which ones actually matter.

That's why the most effective QA workflows don't replace human teammates with AI. They combine Fin's ability to surface patterns with human judgment to interpret those patterns and turn them into meaningful improvements.

A monitor continuously evaluates conversations against criteria you define — whether that's a random sample for ongoing QA, or targeted conversations based on signals like low CX scores (your customer experience rating in Intercom), repeated escalations, or answer quality. Those conversations can then be reviewed using a scorecard by Fin, a human reviewer, or both.

Intercom includes templates for common QA workflows, including weekly Fin reviews, low answer quality, escalation handling, looping issues, and more. You can also create Monitors from scratch to fit your team's needs.

Think of Monitors as the filtering layer. They take an overwhelming number of conversations and narrow them down to the ones most likely to need someone's attention.

A monitor doesn't just flag that a conversation scored poorly. For AI-graded criteria, it shows you exactly why — down to the specific criterion and Fin's reasoning behind the score.

What it doesn't do is connect the dots across conversations.

You might have ten conversations with low answer quality and ten different AI-generated explanations. But if you look a little closer, seven of those conversations could actually trace back to the same outdated article.

Fin can tell you why each individual conversation scored poorly. It can't tell you that seven of those "whys" are really the same underlying issue showing up in different ways.

Recognizing that difference requires product knowledge and context. It's the difference between these two conclusions:

Without that step, QA becomes a list of flagged conversations. With it, QA becomes a list of actionable improvements. That's the difference between noise and insight.

The workflow has four steps:

This is where Monitors do the heavy lifting. Instead of manually sampling conversations and hoping you find something useful, Monitors continuously evaluate every conversation that matches your criteria and surface the ones most likely to need attention.

This is the step Fin can't replace. Monitors might tell you ten conversations scored poorly — but they won't tell you whether they're all symptoms of the same issue, whether the problem is outdated content, or whether Fin is following guidance that no longer reflects your product.

Your human product experts are the ones who connect those dots.

A flagged conversation isn't an action item. Compare these two conclusions:

The second gives a team something concrete to fix. Whenever possible, identify the specific article, procedure, or Fin guidance rule that's driving the issue, rather than just describing the symptom.

Insights only create value if someone acts on them. A knowledge gap might belong with the team responsible for help center content. A procedure issue might belong with the people who maintain Fin's guidance or conversation design.

Not every org has dedicated Knowledge Management or Conversation Design teams. Smaller teams might have one person wearing many hats. The important distinction isn't who owns the work. It's identifying whether you're looking at a content problem or a procedure problem, so the right improvement gets made.

The more specific your recommendation is, the less time someone else spends rediscovering the problem, and the more time they spend actively solving it.

You can do this directly inside the Monitor using Issues.

From the Review sidebar of any conversation, you can raise an Issue ticket with a title, type (Content, Guidance, Procedure, Escalation, and more), and assignee — without leaving the conversation. The same Issue can be linked to multiple conversations where the same problem appeared, so your team gets one ticket per root cause rather than one per conversation. All Issues collect in a central view in Fin AI Agent > Analyze > Monitors, where you can track status from submission through to resolution.

For full setup details, see Track and action issues found in Monitor QA reviews.

When a monitor keeps surfacing the same issue, it's usually a sign that something bigger needs attention — a help center article, a Fin procedure, or guidance that needs to be adjusted.

Monitors are great at identifying patterns across thousands of conversations, but they can't tell you which patterns are actually worth acting on. That's where human product experts come in. They use their product knowledge and context to identify the root cause, turn those findings into actionable recommendations, and make sure they reach the team responsible for fixing them.

As Fin gets better at finding patterns, the role of the product expert evolves. Instead of spending time searching for issues, they can focus on understanding what the data is telling them, deciding what matters most, and driving meaningful improvements.