Migrate from LeadDesk to Zendesk

LeadDesk Contacts map directly to Zendesk End Users via the Zendesk Users API. The Contact's phone number, name, email, and any custom fields transfer as typed user fields or custom user fields in Zendesk. We use the email address as the dedupe key. If a LeadDesk Contact has no email (outbound-only number records), we create the Zendesk user with a placeholder email constructed from the LeadDesk contact ID to preserve the record, flagging it for the customer's admin to supplement with real contact data post-migration.

LeadDesk Agents map to Zendesk Agent records. We extract agent email, name, and team assignment from LeadDesk's user export and provision matching Zendesk users. The Agent's role (Teamleader, Manager, Agent) maps to Zendesk's Agent or Admin role. We resolve Agent to Zendesk User by email match and hold any Agent without a matching Zendesk user in a reconciliation queue.

LeadDesk Campaigns and Projects are parent containers for outbound initiatives with no direct Zendesk equivalent because Zendesk does not have a campaign object. We document the full Campaign and Project hierarchy and map each one to a Zendesk Tag prefix (e.g., campaign_winter-2025) so that the customer's admin can filter tickets by original campaign in Zendesk views. Dialer mode settings per campaign (preview, power, predictive, AI) have no Zendesk equivalent and are noted for workflow review.

LeadDesk Call Records map to Zendesk Tickets via the Zendesk Tickets API or Bulk API depending on volume. Each Call Record's duration, disposition (Result and Outcome codes), agent assignment, campaign linkage, and timestamp become a Zendesk Ticket with the subject set to the campaign name, description carrying the call summary, and custom fields capturing disposition code, call duration, and original LeadDesk campaign tag. We preserve the full call disposition taxonomy as custom ticket fields rather than collapsing to Zendesk's default status values so that reporting fidelity is maintained.

LeadDesk Results and Outcomes are the specific call-end codes that represent how a call concluded (e.g., Answered, No Answer, Busy, Voicemail, DNC). These codes have no native Zendesk equivalent because Zendesk ticket statuses (New, Open, Pending, Solved, Closed) are ticket lifecycle states rather than call-outcome taxonomies. We create Zendesk custom drop-down fields mapped to each LeadDesk disposition code and store the original disposition as a tag on the ticket for reporting continuity.

LeadDesk chatbot analytics export as a time-bounded ZIP from Chatbot Studio containing four CSV files (conversations, outcomes, timing, agent). We decompress and parse the files, mapping conversation timestamps, detected intents, and outcomes to Zendesk Tickets. Each chatbot exchange becomes a ticket comment. We confirm the date range with the customer during export setup because LeadDesk exports only the explicitly selected range — older conversation data not included in the export is unrecoverable after migration.

LeadDesk Offices represent multi-site deployment nodes with associated timezone, VoIP routing, and agent rosters. These map to Zendesk Groups, which represent team-level groupings of agents. The Office timezone maps to Zendesk Business Hours configuration on the Group. VoIP routing settings have no Zendesk equivalent and are documented as IT configuration tasks.

LeadDesk Teams group Agents under Teamleaders and Managers. Zendesk Groups handle agent grouping but do not have a Teamleader concept — Zendesk uses the Agent role hierarchy and Group assignment instead. We map Team membership to Zendesk Group membership, preserving the Teamleader role as a Zendesk light Agent role or Admin role based on the customer's reporting structure.

LeadDesk Leads carry a status, owner, and associated outcome codes. These map to Zendesk End Users with the Lead status preserved as a custom user field and the original LeadDesk Lead ID stored as a tag for audit traceability. The Lead owner resolves via email match against Zendesk User records.

LeadDesk custom fields on Contacts and Leads map to Zendesk custom user fields with type matching (text to text, number to integer, date to date, checkbox to boolean, dropdown to dropdown). Any LeadDesk custom fields with unsupported data types such as nested objects or complex multi-level structures are flagged for manual review and mapping before migration proceeds.

LeadApps are add-on modules within LeadDesk with runtime state that is not exposed via the REST API. We export any LeadApp configuration JSON that the LeadDesk API exposes, but we do not migrate their active state. The customer's admin must reconfigure LeadApps in LeadDesk (if continuing to use it alongside Zendesk) or find Zendesk equivalents in the Zendesk Marketplace. This is documented as a manual rebuild task.

LeadDesk dialer modes (preview, power, predictive, AI) and round settings are stored per campaign and have no direct equivalent in Zendesk because Zendesk is not a dialer platform. We document the full dialer configuration per campaign as a written record, and the customer plans a replacement outbound dialing strategy (e.g., a dedicated CCaaS tool like Five9, Talkdesk, or a Zendesk Sell integration) post-migration.