Everyone is just getting onto AI and starting to understand Fin and what it can do. But the reality is: most teams are sitting on a mountain of dirty, unstructured historical data. That blocks us from using our own history for trend analysis, routing, automation, and learning loops in any meaningful way.
Intercom already shows the pattern works: Topics Explorer retroactively assigns topics/subtopics via a “backfilling” step (currently described as the last 90 days) and then does daily inference on recently closed items.
That’s the right idea — now we need it beyond topics, and we need it for tickets and conversations as a first-class capability.
What I’m asking for
Give us the ability to run a durable, resumable backfill job on existing tickets and conversations that re-runs Fin AI classification/enrichment and writes results back to our chosen fields/attributes — without requiring us to open/close every ticket.
This should feel like a real platform primitive:
-
“Re-run Fin classification on dataset X”
-
“Apply current labeling logic to historical items”
-
“Populate ticket + conversation attributes consistently”
Why product leadership should care
This isn’t a “nice-to-have automation.” It’s foundational for making Fin real at scale:
-
Data integrity & reporting
If only net-new items are enriched, every metric you show to customers is biased toward “post-AI era” data and hides the baseline. That makes it harder to prove impact, especially as you expand Fin AI Agent reporting metrics/attributes and reporting labels.
(And yes — this ties directly to the discussion I already raised in my Fin thread replying to the upcoming reporting-labels/metrics work.)
-
Customer journey intelligence
Teams want to map the full journey: pre-sales → onboarding → incidents → renewals. If history is unstructured, journey analytics stays cosmetic.
-
Fin gets smarter when customers can iterate
Intercom is actively enabling customers to improve Fin with “content from conversations.”
Backfilling is the missing partner to that: as customers refine knowledge and classification, we should be able to re-run enrichment over history to validate improvements against real volume.
-
Outbound + automation is about to create even more data
You’re already pushing Fin deeper into outbound follow-ups. Great.
But if we can’t retroactively structure historical data, outbound-driven automation will widen the “old data vs new data” gap and make reporting/segmentation messier over time.
“This already exists… just not where it needs to”
Intercom has job-style infrastructure for exporting data (including date-range export jobs, with concurrency limits).
So this request is straightforward conceptually: a managed backfill job, except it writes back Fin-derived fields rather than just exporting raw records.
Also: Intercom notes bulk exports for conversation content are API-driven and time-bounded (and UI bulk export isn’t available).
That’s exactly why this should be a first-class back-end job with safe controls, not a hacky “open/close everything” workflow.
Trust, privacy, and “don’t make me create a compliance incident”
If you ship backfill, it should be designed like a serious platform feature with guardrails:
-
Scoped access controls (who can run it, which inboxes, which time ranges).
-
Audit logs (who ran what, when, what changed).
-
No customer re-notifications (analysis + field updates only).
-
Data minimization (store only needed derived labels; don’t replicate raw content).
-
Resumable, idempotent processing (safe restarts; deterministic outputs).
And this is where it gets bigger than “support ops”: backfill can become a trust & safety accelerator if it supports sensitive information classification and remediation workflows. Intercom already has security features like PAN redaction.
A backfill pipeline could optionally scan historical conversations/tickets for sensitive categories and support governance controls (e.g., classify → restrict → redact → retain evidence).
This matters because customers are dealing with real legal obligations, including:
-
GDPR DSAR / portability / erasure workflows (exports + deletion expectations).
-
DMCA / legal takedown style requests (content traceability + audit).
-
CSAM and other illegal-content reporting requirements (classification, quarantine, strict access, audit trails).
If you want to be the AI-first customer comms platform, you can’t ignore that “AI over historic data” intersects with compliance and safety — and doing it deliberately is a competitive advantage.
Minimum viable requirements
-
Background job + progress + completion summary (counts, failures).
-
Scope filters: inbox/team, date range, open/closed, tags/attributes, ticket types.
-
Choose outputs: conversation attributes, ticket attributes, selected fields.
-
Idempotent + resumable + rate-limited.
-
Clear “no customer impact” guarantee (no state changes, no outbound triggers).
-
Optional: dry-run sampling + estimated impact.
User interview
I want to talk to the team building this. I’m in Dublin, Ireland, and happy to do a user interview (also happy to meet anyone in Dublin).
If helpful, I can share the volume we’re dealing with, the exact attributes/labels we want to backfill, and the reporting gaps this would close.