Connecting Intercom to HubSpot: conversations are not contacts

The usual request is to see support conversations in the CRM. It sounds obvious and it is the wrong shape, because copying every conversation into HubSpot produces contact records buried under transcripts that no salesperson will read, while the questions people actually have — is this account in trouble, has this prospect asked something that matters — still go unanswered.

The two systems hold different things. Intercom holds what was said; HubSpot holds who somebody is to your business. Deciding what crosses between them is the whole design, and it is mostly a decision about what not to copy.

What we'll cover

• Two different records of a person
• Identity, which does not line up
• What should cross, and what should not
• Building it with CodeWords
• Signals worth sending to the CRM
• Context worth sending to support
• Where the account level matters
• Who is allowed to see what
• Making it survive
• Limits worth knowing about
• What to build first
• Frequently asked questions

Two different records of a person

Intercom is conversation-shaped. Its unit is a thread, with a state, an assignee and a history.

HubSpot is relationship-shaped. Its unit is a contact within a company, with properties, deals and lifecycle.

Support cares about the open thread; sales cares about the account over a year.

Copying threads into the CRM serves neither. The transcript is unreadable in HubSpot and the relationship context is unavailable in Intercom.

The useful exchange is small in both directions: a handful of signals one way, a handful of facts the other.

Volume is the tell. If the integration is moving thousands of records, it is copying rather than connecting.

Identity, which does not line up

Intercom identifies by user id for logged-in users and by an anonymous lead record otherwise.

HubSpot identifies by email, primarily, which is the same identifier only sometimes.

Leads become users in Intercom when they sign in, and the merge of their history is not always clean.

One person can have several Intercom records — a lead from the website and a user in the product — and both may match one HubSpot contact.

Several people share one account in business software, so the person asking is not always the person who bought.

Decide the matching rule explicitly, and flag ambiguity rather than merging on weak evidence, since a wrong merge in a CRM is difficult to reverse.

What should cross, and what should not

Not full transcripts, which nobody reads in a CRM and which may contain things that should not spread.

Not every conversation as an activity, which buries the timeline.

Yes to a summary of the relationship: how many conversations, when the last one was, and their general character.

Yes to specific events that change what sales or success should do.

Yes to a link back to the conversation for anybody who wants the detail, which is what makes not copying it acceptable.

Nothing that duplicates a field both systems maintain, which will diverge and then neither can be trusted.

Building it with CodeWords

CodeWords connects to more than 3,000 integrations, so Intercom, HubSpot and your alerting can meet in one automation.

1. Open CodeWords and start a new automation.
2. Describe what should happen in plain language to Cody, the automation builder: the matching rules, which signals cross, and who is alerted.
3. Authorize the connections — Intercom and HubSpot.
4. Describe the exceptions: an anonymous visitor, an ambiguous identity match, a conversation on a named account, a sensitive topic.
5. Run it over last month's conversations and check what would have reached the CRM.

You describe the outcome; Cody builds it, connects it, and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.

Signals worth sending to the CRM

A pricing or plan question, which is a buying signal arriving in the support queue rather than the sales one.

A cancellation or downgrade enquiry, immediately, to the account owner.

A complaint or escalation, since a rep walking into a renewal conversation unaware of last week's escalation is the failure this integration exists to prevent.

Conversation volume rising on an account, which is frequently the earliest churn signal available.

A feature request from a named account, tied to the opportunity or renewal it might affect.

Satisfaction scores, as a property rather than as individual events, so they are reportable.

Context worth sending to support

Plan, value and renewal date, so an agent knows who they are talking to.

Open opportunities, since a support conversation during an active sale is a different conversation.

The account owner's name, so the agent can loop them in rather than guessing who to ask.

Recent account events — an upgrade, a renewal, a failed payment — which frequently explain the question being asked.

Not the whole CRM record, which is as unreadable in Intercom as a transcript is in HubSpot.

Keep it current. Stale account context is worse than none, because the agent acts on it.

Where the account level matters

Business software is bought by companies and used by individuals, and most useful questions are about the company.

Aggregate conversations to the account, since three people from one customer each asking about the same problem is a pattern no per-contact view shows.

Map Intercom companies to HubSpot companies properly, which is the association most often left unconfigured.

Domain is usually the join, with the same caveat about generic mailbox providers.

Report at account level — conversation volume, satisfaction, escalations — which is the view success and sales actually use.

Watch for the silent account. A customer who has stopped contacting you is not necessarily happy, and account-level view is the only place that shows.

Who is allowed to see what

Connecting a support tool to a CRM widens the audience for everything in it, which is a decision worth making rather than inheriting from whichever integration was easiest to enable.

Support conversations are not sales material. Customers say things to support they would not say to an account manager, and moving that content changes the relationship they thought they had.

Access differs between the systems. A field restricted in Intercom is not restricted once it is a HubSpot property, and the permission model does not travel with the data.

Health and personal circumstances appear in support threads more often than people expect, particularly around cancellations and billing.

Decide the categories that never cross — a complaint about a named employee, anything a customer marked confidential, anything a regulator would treat as special.

Deletion has to work in both. A deletion request honoured only where it arrived leaves the data in the other system, which is the obligation people miss.

Review what is actually crossing, quarterly, by reading a sample rather than by reading the configuration.

Making it survive

Make writes idempotent so a retried webhook does not duplicate an activity.

Respect rate limits on both, particularly during a backfill.

Handle the identity change when a lead becomes a user, without creating a second CRM contact.

Keep personal data out of anything that does not need it, and remember that support conversations contain more than support topics.

Report the outcome: conversations processed, signals raised, matches made, and ambiguous identities flagged.

Limits worth knowing about

Historical backfills are heavy and both APIs will throttle them.

Intercom's data model changes with its product, and integrations built against older shapes break.

HubSpot property limits and types constrain what can be written and how.

Deletion obligations apply to both, and a deletion request must be honoured in each rather than only where it arrived.

Support conversations can contain sensitive information that the customer did not expect to reach a sales system, which is a reason to send signals rather than content.

What to build first

The alert: a pricing, cancellation or escalation conversation on a named account, sent immediately to the account owner with a link to the thread. It copies nothing, it is small, and it prevents the specific failure where somebody walks into a customer conversation unaware of what happened in the support queue last week.

Two habits make the difference. Send signals and links rather than content, since a CRM full of transcripts is unreadable and carries information the customer did not expect to share there. And aggregate to the account as well as the contact, because business software questions are about companies and a per-contact view hides the pattern that matters.

Frequently asked questions

Should support conversations be copied into the CRM?

No. Transcripts are unreadable in a CRM, they bury the timeline, and they carry information the customer did not expect to reach a sales system. Send a summary, specific signals, and a link to the thread.

How do identities differ between the two systems?

Intercom identifies by user id for logged-in users and by anonymous lead records otherwise; HubSpot identifies primarily by email. One person can hold several Intercom records that match a single HubSpot contact.

What should happen when identity matching is ambiguous?

Flag it rather than merging on weak evidence. A wrong merge in a CRM is difficult to reverse, and an unresolved flag is a task somebody can handle.

Which support events matter to sales?

Pricing and plan questions, cancellation or downgrade enquiries, complaints and escalations, rising conversation volume on an account, and feature requests from named accounts.

What context does a support agent need from the CRM?

Plan, value, renewal date, open opportunities, the account owner's name, and recent account events — not the whole record, which is as unreadable there as a transcript is in the CRM.

Why does the account level matter?

Because business software is bought by companies and used by individuals. Three people from one customer asking about the same problem is a pattern no per-contact view will ever show.

What is the earliest churn signal in this data?

Rising conversation volume on an account, and its opposite — an account that has gone quiet, which is not the same as an account that is happy.

How do I know the integration is copying too much?

By volume. If it is moving thousands of records, it is copying rather than connecting. The useful exchange between these two systems is small in both directions.

Does connecting support to the CRM create a privacy problem?

It can. Customers say things to support they would not say to an account manager, field-level restrictions do not travel with the data, and deletion requests must be honoured in both systems rather than only where they arrived.

How do I check what is actually crossing between them?

Read a sample of what landed in the CRM last month. Reviewing the configuration tells you what you intended; reading the records tells you what happened.

Should I copy Intercom satisfaction scores into HubSpot?

As a property rather than as individual events, so it is reportable and does not bury the timeline. The per-conversation detail belongs in Intercom with a link.

What does a quiet account mean?

Not that they are happy. An account that has stopped contacting support is one of the patterns only an account-level view surfaces, and it is worth treating as a question rather than as good news.

Related reading

• Automating product feedback categorisation
• HubSpot and CodeWords
• Automating sales pipeline updates