Migrate from LeadDesk to Intercom

LeadDesk Contacts migrate 1:1 to Intercom Contacts. Every Contact property (name, phone, email, custom fields) maps to the corresponding Intercom Contact attribute. The Intercom Contact.id is used as the parent reference for all subsequent conversation imports. If a LeadDesk Contact has no email and no phone, it is held in a reconciliation queue because Intercom requires at least one identifier to create a Contact.

LeadDesk Leads represent unqualified prospects assigned to campaigns. We split on LeadDesk lifecycle status: leads with no associated account map to Intercom Contact records (created with no company link), and leads with an associated sponsor or office assignment map to Intercom Users for internal routing. The original LeadDesk lead status and outcome codes are preserved as custom attributes on the migrated record. Any LeadDesk campaign assignment is stored as a tag rather than a native parent-child relationship since Intercom does not have an equivalent campaign object.

LeadDesk Campaigns organize outbound initiatives with sponsor assignment, round settings, and agent rosters. Intercom has no native campaign object. We capture the full campaign configuration as structured JSON in the migration inventory document, tag each Contact and Lead affected by a given campaign with a tag formatted as ld_campaign_<name>, and document the dialer settings (preview, power, predictive, AI) for the customer's admin to redesign in Intercom's routing and inbox rules.

LeadDesk Projects are parent containers for campaigns and agents. They map to Intercom Teams with a 1:1 relationship. Project status, sponsor association, and timezone information migrate as Team metadata. The Project's agent roster maps to the Intercom Team's member list, resolving each LeadDesk Agent to an Intercom User by email match.

LeadDesk call records carry duration, disposition, agent assignment, and campaign linkage. We extract the full call record history and create an Intercom Conversation per call, with the contact and agent linked. LeadDesk's Results (disposition codes) and Outcome values migrate as custom attributes on the conversation (ld_disposition__c, ld_outcome__c) and as tags so the customer's admin can build Intercom inbox rules or reports around the original disposition taxonomy. Call recording URLs are stored as a custom attribute; the recording files themselves require separate S3 or blob storage transfer if the customer requires replay.

LeadDesk chatbot (JennyBot) exports are time-bounded ZIP files from Chatbot Studio containing four CSV files: conversations, outcomes, timing, and agent. We decompress and parse all four files, then create an Intercom Conversation per chatbot session with message threading preserved. Intent labels and outcome values from the chatbot analysis file map to custom attributes (ld_intent__c, ld_chatbot_outcome__c). The export date range must be set to the full historical scope before extraction; we confirm this with the customer during the export setup phase.

LeadDesk Results and Outcomes are the platform's native call disposition codes, stored per campaign and per call attempt. Intercom has no equivalent first-class disposition taxonomy. We extract the complete Results and Outcomes taxonomy from LeadDesk and create a corresponding set of custom attributes on Intercom Contacts or Conversation records, and a set of tags matching the disposition values. The disposition taxonomy JSON is delivered as part of the migration inventory so the customer's Intercom admin can build inbox rules, SLAs, and reports against the migrated codes.

LeadDesk Agents map to Intercom Users by email address. Each Agent's team membership, office assignment, and role (Agent, Teamleader, Manager) migrate as Team membership in Intercom. Agent status (active or inactive) maps to the Intercom User active state. Any LeadDesk Agent without a matching Intercom User is placed in a reconciliation queue for the customer's admin to provision before the user-dependent object import begins.

LeadDesk Offices represent multi-site deployment nodes with their own timezone, VoIP routing, and agent roster. We map each Office to an Intercom Team, preserving the timezone as a custom attribute (ld_office_timezone__c) since Intercom Teams do not have a native timezone field. The Office's VoIP routing configuration has no Intercom equivalent and is documented separately for the customer's admin to reconfigure with Intercom's phone or VoIP partner integration.

LeadDesk custom fields on Contacts and Leads (the Contact Properties object) migrate as Intercom custom attributes on the Contact. We match field type: LeadDesk text fields map to Intercom text attributes, numeric fields to number attributes, date fields to date attributes, and multi-select or checkbox fields to string list attributes. Any LeadDesk custom field with an unsupported complex nested type is flagged for manual review and a custom resolution approach before migration begins.

LeadDesk stores dialer mode (preview, power, predictive, AI) and round settings per campaign. These configurations have no direct equivalent in Intercom's conversational support model. We document every active dialer configuration as structured JSON (mode, dial ratio, retry rules, wrap-up time) in the migration inventory and flag that the customer's admin must redesign the outbound calling workflow in Intercom's Outbound Messages, routing rules, or a third-party dialing integration. This object is excluded from data migration but fully inventoried.

LeadApps are add-on applications within LeadDesk. We export their configuration as JSON where the platform exposes it, but we do not migrate their runtime state. LeadApps require reconfiguration in Intercom or an equivalent third-party tool. We deliver the exported JSON and a written summary of each LeadApp's purpose and dependencies for the customer's admin to evaluate and re-implement.