How to prepare Intercom conversation exports for customer data onboarding

Intercom conversation history often becomes part of a customer data onboarding project when a SaaS company is moving support context, launching a customer success workspace, or replacing a chat-led support process with a new operating system.

The export can look familiar: conversations, contacts, companies, assignees, teams, tags, states, timestamps, ratings, and conversation parts. The risk is that the implementation team treats it like a simple transcript archive when it is actually relationship-heavy customer context.

For onboarding teams, an Intercom conversation export should become a reviewed handoff package: scoped conversations, mapped fields, preserved customer relationships, clear exclusions, and import-ready files for the next system.

Decide which conversations matter for launch

Start by separating “available in Intercom” from “needed for launch.” A complete archive may be useful for reference, but it may not be the right import scope for the first customer launch.

Some projects need only open conversations and recent support history. Others need escalations, VIP customer threads, product feedback, account-level context, or historical conversations attached to companies. If the scope is unclear, the export can become too large, too noisy, and too hard for customer success teams to trust.

Before export, align on:

• Which conversation date range is in scope.
• Whether open, closed, snoozed, or archived conversations should move.
• Whether inbound, outbound, bot, and human replies should be handled differently.
• Which teams, inboxes, tags, priorities, or topics matter for launch.
• Whether conversation ratings, internal notes, or assignment history should be preserved.
• Which old conversations can stay as an archive instead of being imported into the active workflow.

The goal is not to move every possible field. The goal is to prepare the support history that affects launch, customer context, and downstream customer success workflows.

Choose the export path based on the handoff

Intercom data can be pulled in different ways depending on the workspace, permissions, and technical approach. For current object structure and API terminology, check Intercom’s official conversation model documentation before planning a migration export.

For implementation planning, the important point is that different export paths answer different questions. A spreadsheet-style export may help customer-facing reviewers inspect conversation rows. An API-based export may preserve richer nested structure, such as participants, conversation parts, tags, assignees, and related objects, but it usually needs preparation before non-technical reviewers can approve it.

Document the expected file package before the customer exports anything:

• Conversation records for the scoped date range.
• Contact or user records tied to those conversations.
• Company or account records tied to those contacts.
• Conversation parts, replies, notes, or transcripts if the destination product needs history.
• Tag, team, inbox, or topic definitions where they drive routing or reporting.
• Custom attributes and example values, not only raw field names.
• Export date, filters, source workspace, and requester.

This prevents a common onboarding loop: the implementation team receives conversation rows, then later discovers that contacts, companies, tags, or transcript details were needed to make the import meaningful.

Preserve customer relationships before flattening

Conversation data is useful because it connects a customer question to the person, company, support owner, team, topic, and resolution context. If those relationships are flattened too early, the destination product may receive a message record without enough context to help the customer success manager.

Build a relationship checklist before mapping fields:

• Can every in-scope conversation be tied to a contact, user, customer, or external ID?
• Can contacts be matched to the right company, account, workspace, tenant, or organization?
• Are assignee, team, and inbox values still meaningful in the destination product?
• Do tags represent routing, topic, lifecycle stage, customer health, escalation, or temporary triage?
• Are there conversations with missing contacts, merged users, deleted users, or unclear company links?
• Should bot messages, system events, internal notes, and human replies remain separate?

This is where import readiness becomes more than a required-field check. The file is only useful if the customer relationships survive the move.

Map conversation fields to customer-facing meaning

Intercom field names may be obvious to a support admin and unclear to an implementation team that does not live in the source workspace. A value like closed, snoozed, priority, team_id, or tag_id needs plain-language meaning before it can be mapped into a new workflow.

A reviewable field map should include:

• Intercom object, such as conversation, contact, company, tag, team, or conversation part.
• Source field name.
• Plain-language meaning.
• Example values from the export.
• Import field in the destination product.
• Required or optional status.
• Cleanup rule, if values need to be standardized.
• Review owner.
• Approval status.

Example values are especially important for tags and custom attributes. A tag may represent a product area, support queue, customer segment, escalation reason, billing issue, temporary campaign, or historical process that no longer exists. The implementation team should not infer that meaning from the tag name alone.

Validate conversation history before import preparation

Once the export path and field map are clear, validate the records against the import requirements. Do this before spending time on low-value cleanup.

For Intercom conversation exports, the most useful readiness checks are practical:

• Required import fields are present for every conversation that should launch.
• Conversation IDs and external IDs are unique enough for the destination workflow.
• Contact email, user ID, or customer identifier can be matched.
• Company, account, workspace, or organization relationships are complete.
• State, priority, tag, team, inbox, and topic values match allowed import values.
• Date fields use consistent formats and time zones.
• Open, closed, snoozed, archived, bot-led, internal-only, or test conversations are handled intentionally.
• Conversation parts are included, excluded, summarized, or planned as a separate workstream.
• Custom attributes have definitions and example values, not only IDs or column names.
• Records excluded from launch have a reason.

The strongest validation rules are tied to launch behavior. If a missing field blocks customer context, routing, reporting, permissions, or account handoff, it deserves priority. If a field is only historical noise, it should not distract the team from the records that affect go-live.

Treat notes, bot events, and attachments as explicit decisions

Conversation history contains more than public replies. It may include internal notes, bot messages, assignment events, automated replies, satisfaction ratings, attachments, and metadata that should not all be handled the same way.

Make the decision explicit:

• Should internal notes move, stay out, or become a restricted reference?
• Should bot messages become transcript history, workflow events, or be excluded?
• Should attachments move for active conversations only, all conversations, or none?
• Should conversation ratings become fields, notes, or a separate reporting artifact?
• Will the destination product preserve author and timestamp context?
• Who approves excluding history that will not be imported?

This avoids a launch surprise where conversation rows import correctly but the customer expected the full support timeline to appear with them.

Package the export as an implementation handoff

A prepared Intercom export should be easy for the next person to trust. The handoff should explain what the files contain, how they were prepared, what changed, and what still needs a decision.

Include:

• Export date, source workspace, date range, filters, and export method.
• Files received and files used for import preparation.
• Field map with example values and approval status.
• Validation summary by issue type.
• Cleanup rules applied to states, tags, teams, dates, contacts, companies, and custom attributes.
• Relationship notes for conversations, contacts, companies, teams, and assignees.
• Records changed, excluded, deferred, or blocked.
• Open customer questions with owners.
• Import-ready file names and version notes.

This turns the export from a transcript dump into a customer data onboarding artifact. The customer success manager can understand the launch decision. The implementation team can see what is ready. The customer admin can review questions without decoding every field from scratch.

A simple readiness rule

Use this rule before calling an Intercom conversation export ready:

The export is ready when the conversation scope matches the launch plan, contact and company relationships are preserved, required import fields are present, values have been checked against allowed import values, notes and bot events have explicit decisions, exclusions are documented, and open questions have owners.

Aformity is built for this customer data onboarding work: inspecting messy customer files or exports, validating records against import requirements, mapping source fields to import fields, and preparing clean, import-ready data for implementation teams.

For Intercom exports, that workflow matters because conversation history is not only text. It is customer context. Preparing it well helps the new system launch with fewer surprises and gives customer success teams a cleaner handoff after migration.