Migrate from Yuma AI to Intercom

Yuma reads Tickets from the host helpdesk (Gorgias, Zendesk) and writes AI-generated replies and resolution status into the ticket thread. We extract the full ticket body, metadata, and status from the host platform API and import each as an Intercom Conversation. Yuma's auto-replies and resolution status flags migrate as Conversation parts tagged with source attribution so that Fin can use the historical AI corpus as a training signal during the shadow period. Closed, open, and pending status maps directly to Intercom's conversation_state field.

Customer profiles (name, email, phone, order history, contact records) live entirely in the host helpdesk. We extract all customer fields via the host platform API and import as Intercom Users. Custom attributes from the host helpdesk (order ID, subscription tier, return reason) migrate as Intercom custom attributes. Email addresses serve as the dedupe key; duplicate records are reconciled before insert.

Company-level data from the host helpdesk (if used — e.g., Zendesk Organizations or Gorgias Organizations) migrates to Intercom Companies. Company name and domain map to Intercom's name and website fields. Intercom Companies allow linking multiple Users to a single organization, which supports B2B support workflows where multiple contacts from one account are handled in a shared context.

Yuma's human agents are users in the host helpdesk. We extract all agent profiles (name, email, role, availability status) and provision them as Intercom Admins or Agents based on the role hierarchy in the host platform. Agent email serves as the matching key. Any agent present in Yuma ticket assignments but absent from the host platform is flagged for reconciliation.

Yuma routes edge-case tickets to specific human teams via rules configured in Flows. We extract team definitions from the host helpdesk and the Yuma Flow routing logic, then map them to Intercom Teams. Each Intercom Team gets assigned a conversation routing rule for inbox distribution. Teams that exist only in Yuma's Auto-Pilot config and not in the host helpdesk are flagged as requiring manual recreation in Intercom.

Yuma respects and populates custom fields defined in the host helpdesk (order ID, return reason, subscription tier, product variant, WISMO tracking number). We extract all custom field values at migration time and create equivalent Intercom custom attributes of the matching type (text, number, date, boolean, single-select). Custom attributes are attached to the relevant Conversation or User record at insert time.

Every message in a ticket thread migrates as an Intercom Conversation Part. We flag which parts were authored by a Yuma Auto-Pilot versus a human agent using a source attribution attribute. This flag is the primary training signal for Fin during the shadow period — it tells Fin which historical replies were AI-authored and which were human, so the AI can learn from the resolution patterns without blindly replaying them. Attachment URLs on message parts migrate as Intercom attachment references.

Inline attachments on tickets — images, PDFs, order screenshots — are pulled from the host helpdesk's attachment API and uploaded to Intercom as Conversation Part attachments. Yuma does not store its own attachment blob; we pull directly from the host platform as normal. File size limits follow Intercom's 10 MB per attachment cap.

Yuma applies internal tags during processing (resolution type, automation status, channel attribution, AI confidence flag). We export all tags applied by Yuma alongside the ticket and create equivalent Intercom Labels on each Conversation. Labels are preserved so the destination support team can use Yuma's classification taxonomy to set Fin routing rules and escalation thresholds during the Fin configuration phase.

Guidelines are Yuma's brand policy rules that constrain AI behaviour during ticket resolution. Exported as structured JSON with full condition logic, allowed channels, and action guardrails. Intercom has no native Guidelines equivalent; Fin controls behaviour through the Fin AI Prompt and Help Center article grounding. We deliver Guidelines as a structured JSON document plus a written mapping to recommended Fin Prompt sections and Help Center article structure. The customer or an Intercom partner rebuilds these inside Fin during the configuration phase.

Flows are Yuma's visual automation builder for ticket routing, trigger conditions, and escalation sequences. Exported as structured JSON with trigger definitions, condition branches, and escalation actions. Intercom Workflows serve a similar routing and inbox-assignment purpose but are structured differently. We export Flow definitions as JSON and deliver a written inventory mapping each Flow's trigger conditions to the equivalent Intercom Workflow rule. The customer or an Intercom partner rebuilds routing logic in Intercom's Workflow builder.

Yuma's Auto-Pilot agents are a separate logical layer configured by an account manager. Each Auto-Pilot has a scope (which ticket types it handles), escalation routing, and resolution confidence thresholds. Exported as structured JSON. Intercom's Fin Agent does not have a direct Auto-Pilot equivalent — Fin is a single AI agent whose behaviour is configured via the Fin AI Prompt and Help Center article selection. We deliver Auto-Pilot configs as JSON and a written recommendation for how to replicate the routing logic inside Intercom's Fin routing rules and inbox assignment settings.