Migrate from Yuma AI to Zendesk

Yuma reads Tickets from the host helpdesk and writes AI-generated replies and resolution status into the ticket thread. We export the full ticket body, metadata, and conversation thread from the host platform API, then import into Zendesk as native Ticket records. Yuma's auto-replies are preserved as comments in the thread and tagged with a custom attribute (yuma_auto_reply: true) so the Zendesk admin or destination AI can identify and optionally review them. Resolution status from Yuma maps to a custom ticket field yuma_resolution_status__c for audit continuity.

Customer profiles exist entirely in the host helpdesk. Yuma reads customer name, email, order history, and contact records to ground AI replies. All standard customer fields migrate to Zendesk End User records via the Zendesk Users API. Custom fields populated by Yuma (e.g., subscription tier, order count) migrate as custom user fields in Zendesk.

Company-level data from the host helpdesk (e.g., Zendesk Organizations if the source is Gorgias) maps directly to Zendesk Organizations. The domain or company name becomes the Organization's name field and is used as a dedupe key during import. Organization membership on tickets migrates as a standard Zendesk Organization field.

Yuma's Auto-Pilot agents are a logical layer above human agents, not a direct 1:1 map. We export Auto-Pilot agent configurations as structured JSON with their escalation routing rules and channel assignments. During Zendesk migration, we map the escalation routing to Zendesk's Agent role and group structure. Any Auto-Pilot agents without a human agent equivalent are exported separately as documentation for the admin to implement in Zendesk's routing rules.

Yuma routes edge-case tickets to specific human teams based on rules configured in Flows. We map these team assignments to Zendesk Groups and, where applicable, to Zendesk Business Rules for routing. Teams that exist only within Yuma (e.g., a tier-3 escalation queue defined in Yuma Flows) are flagged as requiring manual Group creation in Zendesk.

Yuma respects and populates custom fields defined in the host helpdesk, such as order ID, return reason, subscription tier, or product category. We preserve all custom field values at migration time using the host platform's custom field export and map them to Zendesk custom ticket fields by field ID. Zendesk's custom_fields array uses numeric IDs rather than display names — we resolve by ID during import to prevent misalignment if field names were duplicated in the source.

Every message in a ticket thread is preserved, including Yuma auto-replies. We flag which messages were authored by a Yuma Auto-Pilot versus a human agent using a custom comment attribute (author_type: yuma_autopilot | human_agent). This attribution is critical for the destination AI or admin to understand which resolutions were autonomous and to train future routing models on Yuma's automation corpus.

Inline attachments on tickets (images, PDFs, order screenshots) carry over via the host helpdesk API. Yuma does not store its own attachment blob — we pull attachments from the host platform as normal and insert them into Zendesk Ticket Comments via the Zendesk Attachments API. Attachments associated with Yuma auto-replies are linked to the same comment record in Zendesk to preserve the original message context.

Yuma applies its own internal tags during processing — e.g., resolution_type, automation_status, channel_origin, or language. We export all tags applied by Yuma alongside the ticket record and import them into Zendesk as native Tags. Tags that Yuma used for AI routing logic (e.g., needs_human_review, wismo_resolved) are preserved so the destination platform can use them as training signals or for future automation buildout.

Guidelines are Yuma's brand policy rules that constrain AI behavior and prevent hallucinations — they define conditions, actions, allowed channels, and guardrails for Auto-Pilot responses. Exported as structured JSON with full condition logic and action sets. Zendesk has no native equivalent construct. We export Guidelines as a documented JSON artifact and provide a written mapping to Zendesk Triggers, Macros, and Automations for the admin to manually reimplement. This work is out-of-scope for standard migration and is scoped as a separate automation rebuild engagement.

Flows are Yuma's visual workflow builder for automating ticket routing, triggers, and escalation sequences. We export Flow definitions as JSON including trigger conditions, branch logic, wait steps, and escalation paths. Zendesk's routing engine (Triggers, Macros, and Automations) uses a different model. We deliver the Flows as documented JSON with a written mapping to Zendesk equivalents. The admin rebuilds routing logic in Zendesk based on this inventory.

Yuma Auto-Pilot configurations (escalation thresholds, response tone settings, brand voice parameters, and channel-specific behavior) export as structured JSON. Zendesk has no equivalent to these per-channel AI behavior settings. We export the configuration and deliver it as a reference document the admin uses to configure Zendesk Agent Copilot settings and channel-specific routing rules post-migration.

Yuma's direct integrations with Shopify, Recharge, and Klaviyo are outbound API connections that exist only within Yuma. They do not carry over to Zendesk. We document each active integration, its API endpoints and trigger conditions, and provide a connection guide for re-establishing the same data flows in Zendesk. Shopify metafields, order lookups, and refund actions in Zendesk use the Zendesk Shopify integration or the Zendesk Sunshine API — these are new connections, not migrated ones.