Designing a tag-based labeling system for fintech support — examples wanted | Community
Skip to main content
Answered

Designing a tag-based labeling system for fintech support — examples wanted

  • September 15, 2026
  • 2 replies
  • 19 views

Hi all,

I'm building a labeling/tagging system for a fintech support team in Intercom and want to start simple, then expand.

Context:

  • Small support team handling inbound fintech queries (payments mostly)
  • Using tags only for now (no custom attributes yet)
  • Eventual goal: pipe tagged conversation data into a data warehouse for reporting/analysis

What I'm looking for:

  1. Examples of tag taxonomies others have used for support (fintech)
  2. Is it ok to use inly tags and automated topics? 
  3. Pitfalls to avoid — tag sprawl, inconsistent application by agents, etc.

Happy to share what I land on once it's live, in case it helps others in the same boat. Thanks in advance!

Best answer by melzayat

Hi ​@camil132 ! 
Great idea to design this ahead, it’ll save you nightmares later 😅. 

Topics, attributes, and tags each serve different purposes. Intercom generally recommends using a combination of all three. 
But, the important caveat for your data warehouse goal is this: Topics work retroactively (Intercom re-scans your whole conversation history when you set one up), but if you ever change a topic's definition, your historical reporting can become inconsistent.That's a real problem if you're trying to build trend lines in a warehouse.
I would use tags for granular reporting and topics for organizing/routing workflows, since a stable conversation attribute (or tag) is what holds up for reporting purposes, while shifting topic definitions can throw off historical numbers. So basically use Topics to discover what's trending and to route/prioritize in the inbox, but let tags (applied consistently, either manually or via Workflow) be the thing you actually pipe downstream. 


In terms of taxonomy. I haven’t worked specifically with Fintech but a few ideas here: 

  • payment-failed, payment-declined, payment-duplicate, payment-delayed
  • transfer-delayed, transfer-limit, transfer-failed
  • card-lost, card-activation, card-decline
  • kyc-pending, account-access, account-verification
  • dispute-chargeback, dispute-unauthorized-txn
  • fraud-suspected, fraud-confirmed
  • fee-question, fee-dispute
  • compliance-request


The category-reason naming convention (not free text, not emoji, not "misc") is what saves you later (truste me).
It’ll be what lets a warehouse query group by category prefix without regex gymnastics.

I'd also keep a separate orthogonal tag or two for things like escalated / vip, rather than baking severity into every category tag. That's exactly the kind of thing that turns into 40 near-duplicate tags in six months.
 

Pitfalls:

  • Sprawl: limit tag creation to a couple of admins/leads, keep a one-page tag dictionary. Free-for-all creation is how payment_failed / Payment Failed / pmt-fail all end up coexisting.
  • Inconsistent application: spot-check monthly via the Most used conversation tags chart drill-in, not just when something looks off.
  • Reporting lag: tag reporting runs 24–36h behind. Don't build a near-real-time dashboard on it.
  • Tag vs attribute: if a conversation can only be one thing (e.g. root cause), that's a single-select attribute, not a tag.

Getting it into the warehouse

Don't rely on the manual CSV route long-term.
 Intercom has a dedicated Reporting Data Export API (enqueue a job, poll status, then download) that covers the Tags dataset alongside Conversations, Contacts, etc., which is the right tool for a recurring pipe into Snowflake/BigQuery rather than the browser-based Dataset export (which caps at 10,000 rows for instant download and emails you larger files). Just double check that’s available on your plan.


Docs worth checking out:


Hope this helps!

2 replies

melzayat
Innovator ✨
Forum|alt.badge.img+2
  • Innovator ✨
  • Answer
  • September 15, 2026

Hi ​@camil132 ! 
Great idea to design this ahead, it’ll save you nightmares later 😅. 

Topics, attributes, and tags each serve different purposes. Intercom generally recommends using a combination of all three. 
But, the important caveat for your data warehouse goal is this: Topics work retroactively (Intercom re-scans your whole conversation history when you set one up), but if you ever change a topic's definition, your historical reporting can become inconsistent.That's a real problem if you're trying to build trend lines in a warehouse.
I would use tags for granular reporting and topics for organizing/routing workflows, since a stable conversation attribute (or tag) is what holds up for reporting purposes, while shifting topic definitions can throw off historical numbers. So basically use Topics to discover what's trending and to route/prioritize in the inbox, but let tags (applied consistently, either manually or via Workflow) be the thing you actually pipe downstream. 


In terms of taxonomy. I haven’t worked specifically with Fintech but a few ideas here: 

  • payment-failed, payment-declined, payment-duplicate, payment-delayed
  • transfer-delayed, transfer-limit, transfer-failed
  • card-lost, card-activation, card-decline
  • kyc-pending, account-access, account-verification
  • dispute-chargeback, dispute-unauthorized-txn
  • fraud-suspected, fraud-confirmed
  • fee-question, fee-dispute
  • compliance-request


The category-reason naming convention (not free text, not emoji, not "misc") is what saves you later (truste me).
It’ll be what lets a warehouse query group by category prefix without regex gymnastics.

I'd also keep a separate orthogonal tag or two for things like escalated / vip, rather than baking severity into every category tag. That's exactly the kind of thing that turns into 40 near-duplicate tags in six months.
 

Pitfalls:

  • Sprawl: limit tag creation to a couple of admins/leads, keep a one-page tag dictionary. Free-for-all creation is how payment_failed / Payment Failed / pmt-fail all end up coexisting.
  • Inconsistent application: spot-check monthly via the Most used conversation tags chart drill-in, not just when something looks off.
  • Reporting lag: tag reporting runs 24–36h behind. Don't build a near-real-time dashboard on it.
  • Tag vs attribute: if a conversation can only be one thing (e.g. root cause), that's a single-select attribute, not a tag.

Getting it into the warehouse

Don't rely on the manual CSV route long-term.
 Intercom has a dedicated Reporting Data Export API (enqueue a job, poll status, then download) that covers the Tags dataset alongside Conversations, Contacts, etc., which is the right tool for a recurring pipe into Snowflake/BigQuery rather than the browser-based Dataset export (which caps at 10,000 rows for instant download and emails you larger files). Just double check that’s available on your plan.


Docs worth checking out:


Hope this helps!


  • Author
  • New Participant
  • September 15, 2026

Thanks for the detailed response.