---
title: "Intercom Integration: Context in the Chat | JustAutomate"
description: "An Intercom conversation that knows the plan, the last order and the payment status, so the bot hands over to a human with context. Live in 2 to 6 weeks."
url: "https://justautomate.ai/en/integrations/intercom/"
lang: en
---

Tasks, communication and customer service

# Intercom integration a conversation that knows the customer

A customer writes in the chat window in your product or on your site, and support sees their plan, their last order and their payment status beside the conversation. Contact and company attributes come from your CRM and your systems, the bot collects the basics and hands over to a human with the context, and the history goes to the warehouse. One thread, not a ticket closed after every reply.

 Book a free consultation [See how the workshop works](https://justautomate.ai/en/services/process-workshop/)

- 1 monthis all the time you get to answer a customer who asks what data you hold from their conversations, or asks you to erase it. GDPR, regulation 2016/679, Article 12(3)
- 5 to 10 secondsis how long an AI agent takes to build an answer out of your own data, counted from the question asked in the chat window
- 2 to 6 weeksfrom workshop to a working integration, depending on how many systems feed the contact and company attributes

The problem

## Why does every conversation with a customer start from nothing?

A customer writes in the chat window inside your app to say something is broken. The person on support does not know which plan they are on, how long they have been a customer, or whether they reported the same thing last week. So they ask for an order number and an email address, even though the customer is logged in and Intercom knows them by name. Three weeks later the same person comes back and tells the whole story again, because the previous conversation was closed and nobody reads it.

A conversation in Intercom is not a ticket that gets shut. The [Intercom developer documentation](https://developers.intercom.com/) shows it in the data structure: a conversation is one object that later parts are appended to, and contacts and companies carry their own attributes you are allowed to fill with data from your systems. Most companies never use them, so the context sits beside the conversation instead of inside it: the plan in the CRM, the order in the sales system, the invoice in accounting, the agreement in somebody's inbox.

There is also a cost nobody thinks about on the day the chat goes live. Conversations are personal data, and [GDPR Article 12(3)](https://eur-lex.europa.eu/eli/reg/2016/679/oj) gives you one month to answer a person who asks what you hold on them or asks you to erase it. When one customer's history is spread across the chat window, a shared inbox, the CRM and a spreadsheet, pulling it together inside the deadline takes days of somebody's time.

- A logged-in customer gets asked for an order number the system already has
- The same case comes back three weeks later as a brand new conversation
- Support opens three systems to check one pricing plan
- Nobody knows what customers ask about most, because conversations are never counted

Why now

## What changed, so that a chat window can know the customer?

Intercom sits in two places at once: inside the product, after login, and on the public site, in front of somebody who has bought nothing yet. The difference matters more than it looks. A logged-in contact arrives with an identifier from your own database, so the conversation can be tied to the customer, their plan and their order from the first sentence. A site visitor is anonymous, and only the conversation itself can identify them.

The second change is contact and company attributes. They are ordinary fields on the record, but you are allowed to keep data from your systems in them: plan, signup date, deal value, onboarding stage, status of the last order. Once they are there they do three jobs at once. They describe the conversation, they steer the flow in the chat window, and they build the segments that fire an outbound message at the right moment rather than a week after it.

The third change is on the AI agent side. A question asked in a plain sentence can now be turned into a query against the CRM, the order system and the warehouse, with the result handed back as one paragraph. BOND, our company AI agent, does that in 5 to 10 seconds. The bot in the chat window and its answers from your documents are covered in [AI chatbot for business](https://justautomate.ai/en/services/business-ai-chatbot/), the agent working next to a support person in [AI customer service](https://justautomate.ai/en/services/ai-customer-service/), and sorting the incoming queue in [automatic ticket categorization](https://justautomate.ai/en/automations/automatic-ticket-categorization/). This page is about something narrower: making the Intercom conversation know who it is talking to.

What changes

## What do the support team and the product team get?

- ### Customer context beside the conversation, with no CRM open
Next to the conversation you see the plan, the signup date, the account owner, the last order and the payment status. The data lands in contact and company attributes from the CRM and from your own systems, so nobody asks the customer for things the company already knows.
6 to 12 attributes agreed in the workshop, refreshed after every change in the source system
- ### One thread instead of starting over
The conversation stays a single object with the whole history, and the same support person comes back to it. A customer who raises a case three weeks later does not tell the story twice.
Conversation history visible in the chat window and on the customer record in the CRM
- ### The bot collects the basics, the human gets the context
The flow in the chat window asks for what somebody would have to ask for anyway, and checks the contact attributes. It hands the conversation to a human with a summary: who is writing, which plan they are on, what the case is about and what has already been checked.
A handover with a summary, instead of a thread somebody has to read from the top
- ### Repeat questions answered at 22:30
The AI agent answers in the conversation from your documents and your systems, and when the answer is not in them it says so and passes the case to a human. The morning queue is shorter by the questions that needed nobody.
An answer from company data in 5 to 10 seconds, in English or in Polish
- ### An outbound message to the right segment
A segment built from attributes fires a message in the product or by email: account created and unused for 7 days, onboarding stopped halfway, plan ending this month. One message per case, not a sequence.
Segment entry conditions and a frequency cap agreed before launch, not after the complaints
- ### Conversations as data, not as a feeling
We move the conversation history to the warehouse together with the case category, the time to first reply and whether the bot handed the conversation to a human. You can see what customers ask about most and which stage of the product generates the conversations.
A conversations table in BigQuery or in your own database, refreshed daily

Proof

## Do you handle conversations this way yourselves?

Yes, though not on Intercom. The AI agent in our founders' agency picks up incoming requests from clients and answers from company data, and that is the only proof we can show without asking a client for permission to publish their numbers. Below is the scale of that work, together with what the number does NOT prove.

Built for ourselves. These are not client deployments but implementations inside the founders' own companies. We say so plainly, because proof you cannot verify is not proof.

- ![JustIdea Agency](https://justautomate.ai/klienci/justidea.png)![JustBot](https://justautomate.ai/agenci/justbot-80.webp)JustBottheir agent
JustIdea Agency, a performance marketing agency of around 30 people
23
people from the company work with the agent
38
systems wired in permanently
112
processes run without a human
475
thousand lines of the agent’s code
The agent is wired into the CRM, the task system, the data warehouse, the forms on the website and the team messenger. First commit on 1 March 2026, and in August 23 people were using it.
8 of 38 systems it works in

  - Google Ads
  - Meta Ads
  - HubSpot
  - ActiveCollab
  - Ahrefs
  - GA4
  - Search Console
  - BigQuery
Before
A request was read by a person, who created the contact and the company in the CRM by hand and hunted for the history across several systems. Answering a question about client data meant logging into one of them and building a view.
After
The agent picks the request up, creates the records in the CRM, checks for a duplicate by domain and notifies the team. A question about client data gets a one-sentence answer, in the place where the team already talks.
64,903 operations in 30 days, 29,854 of them with no human involved, including 1,301 on requests coming from website forms

And in your company

## What if our Intercom looks different?

Four sentences we hear most often, and how we answer them.

- We have had Intercom for two years and nobody ever configured it.
That is a normal starting point, and far from the worst one. We begin with two things: identifying the logged-in customer, and the six to twelve attributes the support person genuinely needs beside the conversation. Bots and outbound messages come later, because without attributes they have nothing to work on.
- We run Zendesk for tickets and we do not want two systems.
You do not have to choose. The conversation in Intercom stays with the customer, and a case that needs longer handling goes to Zendesk with the full conversation history in the body of the ticket. Intercom is then the channel and Zendesk is the queue, and each tool does what it is good at. Ticket flow inside Zendesk is something we cover separately.
- We are worried the bot will tell customers nonsense.
That is why the pilot is compulsory and the bot starts with a narrow scope: a few kinds of question you actually have documents for. Outside that scope it does not improvise, it hands the conversation to a human with a summary. After 30 days we look at how many answers somebody corrected, and we narrow the scope wherever the documents are incomplete.
- We do not want customer data going to a language model.
We settle before the rollout which fields leave your systems and which never do: card numbers, sensitive data, whole attachments. What goes to the model is the text of the question plus the attributes needed to answer it. We also write down a retention period for conversations, because without one the history grows forever.

Support and communication

Intercom, Slack, Microsoft Teams, Google Workspace, Microsoft 365

CRM

HubSpot, Pipedrive, Salesforce, Zoho

Sales and shop

Shopify, WooCommerce, Magento, BigCommerce, Stripe

Finance and accounting

Xero, QuickBooks, Sage, sevDesk, Chargebee

Data and analytics

BigQuery, Google Sheets, GA4, SQL databases

Automation layer

Make, n8n, Zapier, custom API integrations

## Attributes in the conversation: where we get them and what they make possible

Each row shows one field on the contact or the company in Intercom, together with its two consequences: where it has to come from, and what changes in the conversation because of it. The third column matters most, because an attribute nothing follows from is just one more field to maintain.

| Contact or company attribute       | Where we get it from                               | What it changes in the conversation                                          |
| ---------------------------------- | -------------------------------------------------- | ---------------------------------------------------------------------------- |
| Customer plan or package           | the CRM and your product database                  | the bot knows who to answer at once and who to hand to an account owner      |
| The company the contact belongs to | company attributes from the CRM, matched by domain | three people from one company show as one account, not three separate cases  |
| Status of the last order           | Shopify, WooCommerce, Magento, BigCommerce         | a question about a delivery is answered without asking for an order number   |
| Payment and invoice status         | Xero, QuickBooks, Stripe, Chargebee                | support sees the overdue balance before promising a discount or an extension |
| Onboarding stage in the product    | events sent from your own application              | the started and never finished segment gets one message inside the product   |
| Signup date and plan end date      | your database or your billing system               | the outbound message goes out on the day it makes sense, not a week later    |
| Contact language and time zone     | the account profile and in-app settings            | the conversation reaches somebody working those hours and that language      |

A first rollout usually covers 6 to 12 attributes. The rest goes in once it turns out somebody actually looks at them, rather than up front.

How we work

## Five steps from a chat with no context to a conversation tied to the customer

Every step ends with something you can judge before you decide on the next one.

1. ### Workshop
We list what customers ask in the chat window and what the support person is missing to answer straight away. We measure how long it takes today to get the plan, the order and the payment status, and we check where that data actually lives. Separately we note the questions whose answer is always the same.
2. ### Attribute and segment design
A list of contact and company attributes with the source and the direction of sync for each, a list of segments that fire a message, and the conditions for handing a conversation to a human. We agree the scope of personal data, the retention period for conversations and the fields that never leave your systems.
3. ### Pilot on real conversations
We go live on one entry point, usually the in-product chat for logged-in users, with a narrow range of questions. We check every answer against the source system and every handover to a human, because a bot that gets one conversation in ten wrong is worse than no bot: the customer stops believing the correct answers too.
4. ### Production
A new conversation event and a reply event trigger a sync in both directions: attributes from the CRM and your systems into Intercom, the conversation and its outcome onto the customer record in the CRM. Conversation history goes to the warehouse. All of it with error monitoring and training for whoever maintains it on your side.
5. ### Measurement at 30 and 90 days
We look at four numbers: how many conversations the bot closed on its own, how many it handed over, how many answers somebody corrected and what customers ask about most. A kind of question nobody asks drops out of scope, and an outbound message nobody opens disappears.

Before and after

## How a day in customer support changes

### Before

- The conversation opens with a request for an order number and an email address
- Checking a customer plan means three tabs and two logins
- A customer from last month tells their story from the beginning
- What customers ask about most is known from the team's impression

### After

- The conversation starts with the name, the plan and the last order in context
- Plan and payment status sit beside the conversation, with no other system open
- The thread carries the whole history, and the same support person comes back to it
- Conversation categories are in the warehouse, tied to the product stage that caused them

The first conversations with context are visible on pilot day. We judge the bot's question scope and the segment list after 30 days against what customers actually asked, and again after 90 days.

For the person signing this off

## What the person accountable for customer support gets out of it

You stop guessing what happens in the chat window. You know how many conversations came in, how many the bot closed on its own, how many it handed over and what customers ask about most. A new person on the team enters a conversation with the context already there, so their first week is not a race for access to four systems.

The second thing matters more in front of the board. Repeat questions become a number rather than a feeling, and you can see which stage of the product generates them. That is the argument in a discussion about whether to hire one more support person or fix one place in the product, and today you do not have that number.

- The bot scope written down and narrow, and outside it the conversation goes to a human
- Attributes and their sources written down in the workshop, not buried in a tool's settings
- A pilot on one chat entry point, so backing out costs a single click
- Conversation history in the warehouse, ready for a data request from a customer

What it costs

## The workshop has a published price, the rollout is quoted after it

The process workshop costs **EUR 3,500 net per week**, and runs from one to seven weeks. Intercom work usually needs one week, because the scope is narrow: the list of questions, the list of attributes and the line between the bot and a human. We quote the rollout after the workshop, once it is clear how many systems feed the attributes and what state the data in them is in.

You settle Intercom directly with its vendor, on the price list of your own plan, and you pay the language model cost to the model provider, where a single query costs roughly EUR 0.005 to 0.07\. No margin from us. The same goes for n8n, Make or Zapier if they end up in the solution, or you pay nothing at all when n8n sits on your own infrastructure.

- ### Process workshop
EUR 3,500 net
per week, and Intercom work is usually one week
A self-contained piece of work. It ends with an attribute list, a bot scope and a conversation map you could execute without us.

  - The list of questions customers ask in the chat window today, with the source system for each
  - Contact and company attributes, with the source and the direction of sync for each
  - The bot scope, the handover conditions and the list of segments
  - The metrics to measure at 30 days, and the scope of personal data in conversations
 Start with the workshop
- Most popular
### Workshop and Intercom rollout
Quoted after the workshop
scope follows from the number of systems feeding the attributes
The option most companies choose. A working integration 2 to 6 weeks after the workshop, tested on your own real conversations.

  - Everything in the workshop
  - Contact and company attributes fed from CRM, sales and accounting through n8n, Make or the API
  - The conversation tied to the customer in the CRM, with their plan and last order
  - The bot and the flows in the chat window, with a handover to a human carrying the context
  - Conversation history in the warehouse, error monitoring, training for the support team
 Talk about a rollout
- ### Intercom and BOND, the company AI agent
Quoted after the workshop
a BOND rollout takes around 2 months
For companies where customer conversations run all day and an answer needs data from several systems at once.

  - Everything in the Intercom rollout
  - BOND wired into the CRM, sales, accounting and the data warehouse
  - An answer from company data in 5 to 10 seconds, in English or in Polish
  - A Personal AI Agent for somebody running their own book of clients
  - Conversation summaries and weekly digests written by the AI agent
 Ask about the agent

If the workshop shows that identifying the logged-in customer plus six attributes is all you need, we say so and show you how to set it up. The workshop ends with a document that stands on its own. And if it turns out there is nothing to automate, because you get a handful of conversations a week, we say that too, instead of hunting for a scope to roll out.

## Frequently asked questions

What is an Intercom integration in practice?

It is the chat window wired into your systems in both directions. Into Intercom go contact and company attributes: plan, account owner, last order, payment status, onboarding stage. Out of Intercom go the conversation and its outcome onto the customer record in the CRM, and the conversation history into the warehouse. Bots, chat flows and outbound messages to segments all sit on top of that.

How is an Intercom conversation different from a ticket in a helpdesk?

The unit of work. A ticket is created, moves through statuses and gets closed, and the same customer's next case is a new record. A conversation in Intercom is one thread that later parts are appended to, and it can live for months. That is why the context belongs on the contact and the company, rather than in the fields of a single ticket.

How does the conversation know who the customer is?

From identification at login. Your application passes the customer identifier from your own database into the chat window, and we add attributes from the CRM and your systems to that contact. A visitor on the public site is anonymous, so for them the chat flow first asks for an email address or a company name and only then links the conversation to a record.

Will the bot in the chat window answer everything?

No, and that is not what we put it there for. The bot starts with a narrow range of questions you have documents for, and outside that range it hands the conversation to a human with a summary: who is writing, which plan they are on, what the case is about and what has already been checked. The mechanism for answering from your documents is covered on our AI chatbot for business page.

How long does an Intercom integration take?

One week of workshop and 2 to 6 weeks of rollout, depending on how many systems feed the attributes and what state the data in them is in. Identifying the logged-in customer with six attributes from one CRM is the lower end. A full company AI agent, meaning BOND wired into the whole business, is a different scale and around 2 months of work.

How do we set up outbound messages so they are not spam?

Through segment entry conditions and a frequency cap, both agreed before launch. We build the segment from attributes and product events, for example an account unused for 7 days or onboarding stopped halfway. One case means one message, and a customer already in an open conversation with a human does not get it at all.

What about personal data in conversations?

We agree in the workshop which fields leave your systems and which never do, and how long you keep the conversation history. GDPR Article 12(3) gives you one month to answer a person who asks what data you hold on them or asks you to erase it, so the conversation history you move to the warehouse has to be searchable by customer, not only by date.

Why move conversations into a data warehouse?

To turn them into numbers. The warehouse gets the case category, the time to first reply, whether the bot handed the conversation to a human, and the link to the customer plan. Then you can see what customers ask about most and which stage of the product generates the conversations. Without it you are left with the team's impression, which is not something to base a decision on.

## Let us find out what is missing from your chat conversations

The free consultation takes 30 minutes and you write directly to Pawel, our founder. You tell us what customers ask in the chat window and what the support person is missing to answer straight away. We show you which attributes can be pulled into Intercom in the first week, and what needs the data in the CRM tidied up first. You do not have to share any systems at this stage.

We run at most two rollouts at a time, so that someone is genuinely sitting on each of them.

[Book a free consultation](https://justautomate.ai/en/contact/)

**PS.** If anyone in your company asked a logged-in customer for an order number this week, that is exactly the problem. The context sits in the system next door, so the conversation starts with data the company already has, and the customer repeats their story every time. Attributes on the contact cut that down to a single glance, and listing them is where the workshop starts.

## Related

- [AI chatbot for business](https://justautomate.ai/en/services/business-ai-chatbot/)
- [AI customer service](https://justautomate.ai/en/services/ai-customer-service/)
- [Automatic ticket categorization](https://justautomate.ai/en/automations/automatic-ticket-categorization/)
- [BOND, the business AI agent](https://justautomate.ai/en/services/bond-business-ai-agent/)
- [API integration](https://justautomate.ai/en/services/api-integration/)
- [Process workshop](https://justautomate.ai/en/services/process-workshop/)

---

**JustAutomate** · contact: contact@justautomate.ai · form: https://justautomate.ai/en/contact/