DocsSign inInstall Kastel
All connectors

An AI plugged into Intercom reads your conversations by team, and leaves aside the ones no team is handling.

With Kastel

An Intercom conversation comes into your Kastel when a team is handling it, and that team is what decides who may read it back. The subject, the customer's opening message and every reply come in, internal notes included. A conversation assigned to one person, or to nobody, is filed in no department and waits for an administrator's decision.

A customer pastes whatever is to hand into the messenger

An Intercom conversation starts in a messenger, and a messenger asks nobody for anything. The customer pastes whatever is to hand, an order number, a delivery address, a screenshot of the error with half their screen around it. Nobody filled in a form, so nobody decided what came in.

It is the most alive material support produces, and it is also the least structured. Your admins add their internal notes on top, invisible to the customer, where what they actually think of the case can be read.

What comes into your Kastel is the text of those messages, and nothing from the customer's record. Not their name, not their address, not the attributes your team has accumulated on them over the months. What the customer wrote themselves in a message comes in with the message, because it is the message.

The whole conversation, internal note included

The connector covers conversations, and nothing else in your workspace.

What your Kastel reads in Intercom

  • The subject and the opening message of a conversation
  • Every reply that follows, public answers included
  • Your admins' internal notes, labelled as such
  • The assigned team and its members, to decide who may read

What it never reads

  • Attachments on a conversation
  • The name, address and record of your contacts
  • The custom attributes you accumulate on a customer
  • Your help centre articles, which are not conversations

A contact's record is excluded because that is where Intercom accumulates everything you know about a person, their last visit included. The connector does not read it. It reads the text of the messages, which is enough to know what was asked and what was answered.

A team, or nobody

Intercom assigns a conversation to a team, to an admin, or to nobody. The connector recognises only one of those three as an original permission. The assigned team is expanded into admins, each admin is identified in your organisation, and the conversation is filed in the department all of them belong to.

A conversation assigned to one person stays on hold, even when their department is beyond doubt. The choice is deliberate and it is written into the connector. In a messenger a conversation goes to whichever admin is online, and being online designates no department. That admin's identity is kept for traceability, never as a right to read.

The other cases follow the same caution. A team that is empty, or unknown to the workspace, leaves the conversation on hold. An admin whose address cannot be identified in your organisation leaves every conversation of their team on hold, and the same holds when the members of a team belong to more than one department.

An administrator can of course file a waiting conversation explicitly. That decision is recorded like the rest of what your company decides about its own knowledge, and it can be read back.

One directory decides everything, so its uncertainty stops everything

To know who sits behind an admin identifier, the connector reads the workspace's admin directory. It reads it once per pass, in full, and that directory is what lets a team be attached to a department.

That single list has a consequence worth knowing in advance. When it comes back without telling us whether a page was missing, no team is resolved during that pass and every conversation waits. That is the difference with the Zendesk connector, which reads each group's membership separately. There, a doubt stays local to the group concerned.

On the reconciliation pass, the same uncertainty produces the opposite effect. When the directory is incomplete, the connector recomputes no scope at all and leaves every conversation in the department it was already in. Narrowing a correct filing on the strength of a doubtful list would cost more than waiting for the next pass. The principle holds across the other sources your Kastel can read, and it does not vary from one connector to the next.

What support teams ask us before they connect

A customer asks for their data to be erased. What happens?

Deleting the conversation in Intercom stops it being read, and the copy already read is marked in your Kastel as gone at the source, then kept. It stays readable by the same people as before until an administrator triggers the erasure, which is an explicit and recorded act. We would rather write that here than let you discover it on the day the request arrives.

Can an AI reply to a customer on my behalf?

No, not through this connector. No method to send, close or reassign exists in the transport it uses. The only call that is not a read is the search for modified conversations, and a search changes nothing in your workspace.

Our conversations live in Intercom's European region. Does it work?

Not in this version. The connector accepts only Intercom's US host and refuses the others loudly, rather than dialling a host it has not pinned. The European and Australian regional hosts are provided for in the code and switched off. If your workspace is one of those, tell us before you try.

Do my customers' names come into your Kastel?

No identity field is read from the contact's record. What comes in is the text of the messages, and if a customer wrote their name, their address or their order number in there, that text comes in with the message. It is what the customer chose to write, and stripping it would make the conversation unintelligible.

What this connector does not do

It does not guess the department of a conversation assigned to a person. If your conversations are assigned to admins rather than to teams, all of them stay on hold, and a plugged-in AI will see none of them until an administrator files what they want made readable. The refusal is a design choice we can open up later, and not a technical limit.

It talks only to Intercom's US host. A workspace served by the European or Australian regional hosts is refused, rather than dialling a host the connector has not pinned and verified. That is a limit of the current version, and it is lifted by work rather than by a setting.

It does not protect your admins' internal notes. They come in with the conversation, labelled internal, and the department of the team handling that conversation can read them back exactly like a public reply. The team decides for the whole conversation, never reply by reply.

It rereads a whole window after a failure. The reading position advances only at the end of a pass, and only when no conversation failed. One failed conversation therefore makes the next pass reread everything that moved since the previous position. We pay that cost rather than risk skipping a conversation by trusting the order the search returns them in.

Tell us where your conversations live before you connect anything.

A support archive carries your customers' words and your teams' notes. Tell us what you want an AI to know of it and which region your workspace lives in. We will tell you what comes in, what stays out, and what the connector cannot do yet.

Get in touch
Other connectors in detail
Zendesk
The internal note comes in with the ticket, and stays inside its group.
Crisp
The text of the thread comes in, the visitor's identity stays out.
Front
The members of each shared inbox decide who rereads its conversations.

See the full connector catalogue