We’re currently exploring how to automate our carrier loss/damage claims workflow using Fin AI and would really value input from anyone who has implemented something similar.
Context We manage parcel claims (e.g. Royal Mail and other carriers) on behalf of merchants. Today, this process involves significant manual review, validation, routing, and follow-ups. Our goal is to reduce manual workload while maintaining a strong audit trail and strict compliance with carrier policies.
What we’d like to automate:
Collect structured claim data (tracking number, order number, carrier, reason, invoice, proof of sale, damage photos, etc.)
Route complete claims to the right internal team or BPO
Automatically follow up if information is missing
Provide SLA-based status updates
Support appeal flows if claims are rejected
We’ve seen examples (like this LinkedIn post) suggesting Fin could:
Guide customers through structured workflows
Enforce policy logic
Reduce manual CS triage
Automate tagging and routing
Our questions:
What’s the best way to architect this in Intercom? (Workflows + Fin + Custom Objects?)
Can Fin dynamically enforce carrier-specific logic in a scalable way?
What’s the best practice for validating required documents/attachments?
How would you structure QA, audit trails, and compliance reporting?
Has anyone implemented a similar insurance-style or claims automation flow?
We’re aiming for a production-grade setup — not just automation for speed, but something structured, auditable, and scalable.
Would really appreciate examples, architecture suggestions, or lessons learned 🙏
Best answer by Christopher Boerger
Hey @Alex Petroiu, I haven't built this exact flow, but here's how I'd approach the architecture based on what Procedures and Custom Objects can do:
Core architecture:
Fin Procedures for the intake flow — multi-step data collection, branching logic per carrier, validation checkpoints, handoff to human when needed. You can define carrier-specific paths using conditions.
Custom Objects to model Claims as their own data type (claim ID, carrier, status, evidence list, timestamps). This gives you structure beyond conversation attributes and makes reporting easier.
Data Connectors if you need to hit carrier APIs for real-time validation (claim window checks, tracking status).
Workflows for the routing, SLA reminders, and follow-up sequences — Procedures trigger on customer intent, so time-based automation (e.g., "no response in 48h") needs Workflows.
Things to watch:
Document validation — Fin Vision can help here. It extracts text (OCR), identifies damage in photos, pulls reference numbers from receipts/invoices. Combine with Guidance to tell Fin what to look for and how to respond based on what it sees. (More here: https://www.intercom.com/help/en/articles/10696494-how-fin-vision-understands-images)
Audit trail — Conversation logs + Custom Object history give you some trail. For compliance-grade audit, you might need to push events to an external system via webhooks.
Carrier-specific logic at scale — You can use Guidance + Audience rules, or branch within Procedures. But if you have 10+ carriers with different rules, maintenance gets heavy. Consider a lookup table approach via Data Connector to an external config.
Suggested starting point:
Build one carrier flow end-to-end in Procedures first (Royal Mail seems like your primary). Validate the pattern works, then extend. Procedures has Simulations for testing before go-live — use it heavily.
Honestly, this is sophisticated enough that a direct conversation with Intercom's team on Procedures (still in managed availability) would be worth it. They may have seen similar implementations.
Hey @Alex Petroiu, I haven't built this exact flow, but here's how I'd approach the architecture based on what Procedures and Custom Objects can do:
Core architecture:
Fin Procedures for the intake flow — multi-step data collection, branching logic per carrier, validation checkpoints, handoff to human when needed. You can define carrier-specific paths using conditions.
Custom Objects to model Claims as their own data type (claim ID, carrier, status, evidence list, timestamps). This gives you structure beyond conversation attributes and makes reporting easier.
Data Connectors if you need to hit carrier APIs for real-time validation (claim window checks, tracking status).
Workflows for the routing, SLA reminders, and follow-up sequences — Procedures trigger on customer intent, so time-based automation (e.g., "no response in 48h") needs Workflows.
Things to watch:
Document validation — Fin Vision can help here. It extracts text (OCR), identifies damage in photos, pulls reference numbers from receipts/invoices. Combine with Guidance to tell Fin what to look for and how to respond based on what it sees. (More here: https://www.intercom.com/help/en/articles/10696494-how-fin-vision-understands-images)
Audit trail — Conversation logs + Custom Object history give you some trail. For compliance-grade audit, you might need to push events to an external system via webhooks.
Carrier-specific logic at scale — You can use Guidance + Audience rules, or branch within Procedures. But if you have 10+ carriers with different rules, maintenance gets heavy. Consider a lookup table approach via Data Connector to an external config.
Suggested starting point:
Build one carrier flow end-to-end in Procedures first (Royal Mail seems like your primary). Validate the pattern works, then extend. Procedures has Simulations for testing before go-live — use it heavily.
Honestly, this is sophisticated enough that a direct conversation with Intercom's team on Procedures (still in managed availability) would be worth it. They may have seen similar implementations.
