Migrate from ChannelReply to Intercom

ChannelReply maps each incoming marketplace message into a helpdesk ticket with threaded replies. We export the ticket and its full message chain from the connected helpdesk and create a corresponding Intercom Conversation. The first customer message becomes the Conversation's opening message; subsequent customer and agent replies attach as Conversation Parts in chronological order. The original marketplace channel tag (Amazon, eBay, Walmart, etc.) is preserved as a Conversation tag.

Individual messages sourced from Amazon MWS/SP-API, eBay, Walmart, Etsy, Back Market, and Newegg are the atomic unit ChannelReply delivers. We map each message body, timestamp, author type (customer vs agent), and any attachments to Intercom Conversation Part records. The author is resolved to an Intercom Contact or Admin based on email match. Shopify messages are identified by email header and routed as a separate channel within Intercom.

ChannelReply pushes order-level data into helpdesk custom fields: Item Title, Order ID, Order Status, Order Total, Customer Name, Shipping Address, Buyer Location, SKU, Shipping Fee, Payment Method. We create an Intercom Custom Object schema (e.g., Order) with matching attribute types and link each Order record to the relevant Conversation and Contact via reference attributes. The customer chooses the object name and attribute structure during scoping.

ChannelReply enriches each ticket with buyer name, email, shipping address, and marketplace buyer ID. We map these to Intercom Contact fields: name, email, shipping_address, and custom attributes for marketplace-specific buyer identifiers. The Intercom Contact serves as the unified customer record across all marketplace channels.

ChannelReply applies marketplace-specific tags to tickets indicating channel source (e.g., Amazon, eBay, Walmart). We preserve these tags and apply them as Intercom Conversation tags during migration. Tags are preserved as string values and do not require any schema configuration in Intercom beyond the tagging permission for the migration user.

ChannelReply stores per-marketplace and per-account agent signatures. These are configuration data that lives in ChannelReply, not in the connected helpdesk. We export the signature configuration as a structured record set and provide a written reconfiguration guide for the customer to manually re-enter signatures in Intercom's Admin settings under Inbox > Settings > Personal Settings > Signature. This step is manual because Intercom signatures are tied to Admin identity, not to the conversation record.

ChannelReply relies on the connected helpdesk for agent identity. We export agent assignments from the helpdesk tickets and map them to Intercom Conversation assignments. Assignments are resolved by email match against Intercom Admins. Any ChannelReply agent without a matching Intercom Admin is held in a reconciliation queue for the customer's admin to provision before the migration phase that requires assignment.

Each connected marketplace account in ChannelReply stores API credentials (Amazon MWS/SP-API keys, eBay OAuth tokens, Walmart tokens) that cannot be exported. We provide a written marketplace reconnect checklist with the required permission scopes for each platform so the customer's admin can re-authenticate each marketplace channel in Intercom's channel settings. This step is mandatory and must be completed before or immediately after migration.

ChannelReply distinguishes between customer messages and system notifications (some free, some paid). We export active notification settings and map paid system notifications to Intercom Conversation tags indicating notification type (e.g., Amazon-Refund-Notification, eBay-Dispute-Opened). The customer reviews which notification types to surface as conversations versus silently discarding them in Intercom's routing rules.

ChannelReply action logs recording refund initiations, cancellations, and Resolution Center case actions appear in the ticket history. We migrate these as read-only Conversation Part notes attached to the relevant Intercom Conversation, with the action type, timestamp, and agent identifier preserved. The action itself (the actual refund or cancellation) is not re-executed — it must be performed in the marketplace platform directly. The migration provides an audit trail of what was done, not a functional replication of the action.