Migrate from Channel Talk to Intercom

Channel Talk Contacts (Managed Users) map directly to Intercom Contacts. We extract all standard fields (name, email, phone, created_at, updated_at) and map Channel Talk custom contact properties to Intercom contact attributes, handling type differences (text, number, date, multi-select) during the transform. Because Channel Talk MUs drive billing on the source side, we flag the MU count during scoping and advise on whether dormant contacts should be archived before export to reduce destination cost.

Channel Talk conversation history migrates to Intercom Conversations with each message as a part. We sequence conversation import after all contacts are created in Intercom so that the contact_id reference resolves at insert time. Long conversation threads are chunked to stay within Intercom API batch limits. Read/unread status, timestamps, and conversation metadata (channel, assignee) preserve from Channel Talk. Notes attached to conversations migrate as Intercom notes on the conversation.

Tags applied to Channel Talk Contacts and Conversations migrate as flat label arrays to Intercom Tags. We preserve the tag vocabulary exactly and reassign them to matching Intercom tags. If a tag name conflicts with a reserved Intercom term, we flag it during scoping and the customer chooses a rename before migration.

Channel Talk Documents (knowledge-base articles) migrate to Intercom Help Center articles with content, categorization, and metadata preserved. We export each document's full body text and structured sections, then import as Intercom articles within the target collection. Article authors, publication dates, and edit history migrate as article metadata fields.

Channel Talk operator accounts map to Intercom Admins and Operators. We extract name, email, and role (admin, operator) from Channel Talk and map them to Intercom's agent role model. Seat assignment logic on Channel Talk does not carry over and must be reconfigured in Intercom based on the target plan tier. We deliver a role mapping table for the customer's admin to configure post-migration.

Channel Talk custom contact properties are supported via the API and map to Intercom contact attributes. We handle field-by-field mapping across type differences (text, number, date, multi-select). Intercom requires that attributes be created in the destination workspace before data import, so we run a schema pre-creation phase before any records load. Multi-select properties from Channel Talk map to Intercom tag arrays or custom text fields depending on the customer's preferred segmentation approach.

Channel Talk chatbots built on workflow triggers and document sources map to Intercom Fin AI agent configuration. We do not migrate chatbot logic as code because Channel Talk's bot builder and Intercom's Fin use different intent models and resolution flows. Instead, we document each Channel Talk chatbot's trigger conditions, document sources, and escalation rules as a step-by-step sequence for the customer to replicate in Intercom's Fin setup.

Channel Talk Workflows are event-condition-action automation rules that do not map directly to Intercom's Rules or Workflows engine. We document each Channel Talk Workflow as a sequence diagram with its trigger event, conditions, and actions, then map each step to the equivalent Intercom Rule or Workflow construct. Complex multi-branch workflows may require simplification in Intercom or manual rebuild by the customer's admin.

Channel Talk Team Chats are internal collaboration threads separate from customer Conversations. Intercom does not have a native Team Chat equivalent; internal team messaging lives outside the platform. We export team chat channels and message history as a flat log artifact delivered to the customer, who can archive it externally or import it into a separate internal tool. Team Chat is not imported into Intercom as a standard object.

The Channel Talk chat widget is a configuration artifact tied to Channel Talk's infrastructure and script injection. We document the active widget settings (widget color, position, greeting message, online/offline behavior) as a configuration reference for the customer to reapply in Intercom's messenger installation. The actual widget script must be replaced on the customer's website as a manual step post-migration.