Migrate from Yuma AI to Freshdesk

Yuma AI reads Tickets from the host helpdesk (which may be Freshdesk, Gorgias, Zendesk, or another supported platform) and writes AI-generated replies and resolution status into the ticket thread. We preserve the full ticket body, metadata, and every message — including those authored by a Yuma Auto-Pilot versus a human agent. We flag each Yuma-authored message in a custom Freshdesk conversation note or tag so that Freddy AI can reference the AI-authored corpus during retraining without treating it as human-agent output. If the host helpdesk is not Freshdesk, we first export all tickets from that platform in dependency order (Contacts, then Conversations), then append the Yuma-specific reply and resolution data.

Customer profiles in Yuma AI exist entirely in the host helpdesk. We carry all standard Contact fields — name, email, phone, company, language, and timezone — through to Freshdesk Contacts. Custom fields on the Contact record (order ID, subscription tier, return reason) migrate as Freshdesk custom contact fields with type preserved (string, number, dropdown, checkbox). Yuma's internal customer-level tags (resolution type, customer tier) transfer as Freshdesk Contact tags.

Company-level data from the host helpdesk (e.g., if using Zendesk Organizations or a CRM-linked company record) maps to Freshdesk Organization. The company domain and name become the Organization's Name and Website fields. We use the domain as a dedupe key during import to prevent duplicate Organizations. If the source helpdesk does not use a separate company object, this step is skipped and Contacts are created without an Organization link.

Yuma Auto-Pilots are SOP-driven automation configs that execute specific ticket-resolution workflows (refunds, returns, subscription changes, VIP care) triggered by keywords or ticket tags. We export each Auto-Pilot as structured JSON documenting its trigger conditions, condition logic, multi-step action sequence, and escalation routing. Freshdesk Automations support event-based triggers (ticket created, ticket updated, criteria matched) but do not natively execute the same deterministic multi-step action sequences. The Auto-Pilot JSON is delivered as a written automation map for the customer's Freshdesk admin to rebuild as Freshdesk Automations or Freddy Copilot agent instructions.

Yuma Flows (visual workflow builder introduced November 2025) define structured if/then branching logic within conversational experiences. We export Flow definitions as structured JSON covering all nodes, edges, condition branches, and action steps. Freshdesk Bot supports conditional conversation flows but the node-and-edge model differs. We document each Yuma Flow as a condition map with recommended Freshdesk Automations equivalents (Freshdesk Automations for background rule-based actions, Freshdesk Bot for conversation-fragment flows) and deliver it as a written handoff for the customer's admin or a Freshdesk implementation partner.

Yuma respects and populates custom fields defined in the host helpdesk — for example, order ID, return reason, subscription tier, or refund amount. We preserve all custom field values at migration time and map them to identically named Freshdesk custom ticket fields. Field types are matched: dropdown to dropdown, date to date, number to number. If a custom field in the source helpdesk has no Freshdesk equivalent, we create it before migration begins. Custom fields used by Yuma Auto-Pilots for routing decisions are flagged in the scope document so they can be incorporated into Freshdesk Automations.

Every message in a ticket thread is preserved, including Yuma auto-replies. We flag each message authored by a Yuma Auto-Pilot with a Freshdesk internal note tag (e.g., '[Yuma-Auto-Pilot]') so the migration record distinguishes AI-authored replies from human agent messages. This flagging is important for Freddy AI retraining: the destination AI can use Yuma's AI-authored corpus as positive training examples while recognizing which interactions involved human review. Conversation timestamps, message order, and sender attribution (agent vs customer vs Yuma) are all preserved.

Inline attachments on tickets — images, PDFs, order screenshots — transfer via the helpdesk API. Yuma does not store its own attachment blob; we pull attachments directly from the host platform's API at migration time. If the host helpdesk is not Freshdesk, we export attachments alongside the ticket export and re-attach them to the corresponding Freshdesk conversation during import. All attachments are verified post-migration against a source-side checksum.

Yuma applies its own internal processing tags during automation — for example, tags indicating resolution type, automation status, or escalation outcome. We export all Yuma-applied tags alongside the ticket so they can be applied to the Freshdesk conversation as Tags. These tags can be used for Freshdesk's built-in analytics segmentation, SLA grouping, or Automations triggers post-migration. Tags that reference Yuma-specific concepts (e.g., 'yuma-auto-resolved') are renamed to Freshdesk-appropriate equivalents during the tag mapping phase.

Yuma Guidelines are brand-policy rules that constrain AI behavior and prevent hallucinations — specifying allowed reply tones, prohibited actions, escalation thresholds, and channel-specific policies. We export Guidelines as structured JSON with full condition logic and action constraints. Freshdesk has no native equivalent named 'Guidelines.' We map Guidelines to Freshdesk's closest analog: brand voice rules are documented as text in Freshdesk's 'Canned Responses' library, escalation conditions are rebuilt as Freshdesk Automations, and the full JSON is delivered as a written brand policy document for the admin to reference when configuring Freddy Copilot guardrails.