Intercom and CodeWords: automating around the inbox

Intercom is a capable platform with its own automation, its own AI agent in Fin, and its own workflow builder. So the honest question is not whether to automate around it but where its boundary sits, because building outside that boundary when you did not need to is wasted effort.

The boundary is roughly this: Intercom handles what happens inside Intercom very well. It handles poorly anything that depends on data it does not hold, or that has to end up in a system it does not own. That is where the useful automation lives.

What we'll cover

• Where Intercom's own automation stops
• What the Intercom API reaches
• Connecting it to CodeWords
• Eight automations worth building
• Fin, and what should reach it
• Building it so it survives
• Limits worth knowing about
• Frequently asked questions

Where Intercom's own automation stops

Workflows are strong inside the product. Routing by team, assignment rules, triggered messages, and Fin answering from your help content are all well handled natively and should be used natively.

Custom attributes have to get there somehow. Intercom can route on any attribute it holds. The work is keeping those attributes true, and that means writing them from your billing system, your product database, and your warehouse.

Outcomes do not leave on their own. A conversation that ends in a bug, a refund, or a feature request needs those recorded elsewhere, and Intercom will not do that unprompted.

Aggregate judgement is missing. Individually handled conversations hide patterns. Nothing in the product tells you that eleven people asked about the same thing this week.

What the Intercom API reaches

Conversations can be listed, searched, read, replied to, assigned, tagged, and closed. The search endpoint is the useful one for anything analytical.

Contacts — users and leads — can be created, read, updated, and searched, including custom attributes. This is where enrichment belongs.

Companies can be read and updated and associated with contacts, which matters for anything account-based.

Tickets exist as their own object with state and attributes, for work that outlives a conversation.

Tags can be applied to conversations and contacts, which is how classification gets recorded in a form the native workflows can then route on.

Notes can be added to contacts, and internal notes to conversations, which is the right place for context that should be visible to your team but never to the customer.

Webhooks fire on conversation and contact events, which is what makes reactive automation possible.

The pattern worth noticing: write your judgement back as tags and attributes, then let Intercom's native workflows route on them. That combination is usually better than doing the routing externally, because it keeps the routing rules where your team can see and change them.

Connecting it to CodeWords

CodeWords connects to more than 3,000 integrations, and the connection is made once and reused.

1. Open CodeWords and start a new automation.
2. Describe what should happen in plain language to Cody, the automation builder, naming Intercom and the other systems involved.
3. Authorize the connection when prompted. Intercom uses OAuth with scoped permissions, so grant only what the automation needs.
4. Describe the exceptions as well as the happy path: a contact with no matching customer record, a conversation already closed, a downstream system unavailable.
5. Test against a small set of real conversations before scheduling anything.

You describe the outcome; Cody builds it, connects it, and deploys it. When the process changes you describe the change. 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.

Eight automations worth building

Attribute enrichment. Keep plan, spend, account age, usage level, and renewal date current on the contact and company records, written from whichever system owns each. Everything else in Intercom becomes more capable once these are reliable, including Fin.

Context notes on conversation open. When a conversation starts, post an internal note summarising who this is, what they pay for, what they have raised before, and anything open elsewhere. The person answering starts informed rather than starting with three tabs.

Classification into tags. Read the message, decide what it is about and how urgent, tag accordingly, and let your existing native workflows route on those tags. This adds judgement without moving your routing logic out of Intercom.

Outcome capture. On close, extract what was agreed and create the record: an issue in the tracker with the relevant transcript, a row in a refunds log, a note against the account.

Escalation on signal. Value, repetition, or deteriorating tone raised where a human will see it promptly rather than in queue order.

Weekly theme digest. The week's conversations grouped by topic, with what is new and what is rising. This is the one that changes what gets built, because it makes patterns visible that individual handling hides.

Help content gap detection. Find the questions Fin could not answer and report them as candidate articles. Fin improves with your help centre, so the loop that finds the gaps is what makes it better over time.

Renewal and risk surfacing. Combine support signals with billing data to flag accounts worth a proactive conversation before the renewal date.

Fin, and what should reach it

Fin answers from your help content, so the questions worth sending it are the ones your documentation genuinely answers.

Feed it better content rather than more. The gap-detection pattern above is the highest-value thing you can do for Fin, because its ceiling is your help centre.

Give it accurate attributes. Fin behaves differently for a trial user and an enterprise customer only if it knows which it is talking to, which brings you back to enrichment.

Decide the boundary explicitly. Anything that commits you — refunds, discounts, promises about the roadmap — belongs with a person regardless of how confident an automated answer sounds.

Watch the handoff carefully. Distinguish giving a customer contact instructions, notifying an owner with a summary, and transferring to a verified operator. These get lumped together as "handoff" and they have very different costs when they go wrong.

Measure resolution honestly. A conversation closed by an automated answer and reopened two hours later was not resolved. Reopen rate is the number that tells you the truth here.

Building it so it survives

Make it safe to run twice. Webhooks retry. Posting a note or a reply twice is visible to the customer or confusing to your team, so guard the write.

Decide what an unknown contact means. Proceed without enrichment, create a record, or flag it. Having no answer means failing in whichever way the platform chooses.

Report the outcome. A daily line with counts is what makes silence meaningful.

Keep the routing rules in Intercom. Write tags and attributes from outside, and let the native workflows act on them. Moving routing out means your support team can no longer see or change how work is distributed.

Log the classification and its reasoning. When somebody disputes a routing decision weeks later, that log is the difference between an answer and a guess.

Limits worth knowing about

Rate limits apply and vary by endpoint, so bulk operations over conversation history need pacing. The search endpoint in particular repays being used with a tight filter rather than walking everything.

Custom attributes must be defined before they can be written, which catches people whose automation works in testing and fails on a fresh workspace.

Conversation search is not instantaneous for very recent items, so an automation that acts then immediately searches for its own effect can race itself.

Personal data is abundant here. Support conversations contain things customers did not intend to share. Copy only what the process needs, and remember every field written elsewhere is subject to deletion requests.

Contacts can merge, which changes identifiers. An automation holding a contact ID for a long period should handle the possibility that it now points somewhere unexpected.

Frequently asked questions

Does this replace Intercom Workflows?

No, and it should not. Use Workflows for routing, assignment, and triggered messages inside Intercom. Reach outside when the decision depends on data Intercom does not hold, or when the outcome belongs in another system. The best arrangement usually has both, with the external automation writing attributes and tags that the native workflows then act on.

Can an automation reply to customers?

It can, and the question is which messages should. Recurring factual questions with a settled answer are reasonable. Anything committing you, involving money, or coming from an unhappy customer should be prepared for review rather than sent.

How do I get data from our product into Intercom?

Write it as custom attributes on the contact and company records, on a schedule or on the events that change it. This is the single highest-return integration, because it makes routing, Fin, and every report more capable at once.

What is the best first automation to build?

Attribute enrichment. It is invisible, it improves everything else in the platform, and it is easy to verify because you can simply look at a contact record and see whether it is right.

Can I detect which questions Fin is failing on?

Yes, and it is worth doing regularly. Find conversations where Fin could not answer or where the customer immediately asked for a person, group them by topic, and report the themes as candidate help articles. That loop is what makes Fin better rather than static.

How should conversation data be retained?

Deliberately, and less than you think. Decide what your automation genuinely needs to keep, keep that, and let the rest stay in Intercom under its own retention. Copying conversation content into a warehouse because it might be useful creates an obligation you will have to honour later.

Will automation make support feel impersonal?

Only if you point it at the conversation. Aimed at the work around the conversation — context, routing, outcome capture — it is invisible to the customer and makes the human reply faster and better informed, which is the opposite of impersonal.

How do I measure whether this helped?

Reopen rate rather than resolution time. Routing faster moves the clock without improving the answer, and a conversation resolved then reopened was not resolved. Also watch what your team stops doing: if context notes are working, people stop opening the billing dashboard before replying, and if they have not, the note is missing what they actually need.

Can I use this across multiple workspaces?

Yes, and scope the credentials per workspace rather than sharing one. Multi-workspace setups usually also want the classification rules held centrally, since the alternative is three copies of the same logic drifting apart over a year.

What should never be automated here?

Anything that commits you, anything involving money or access, and anything from a customer who is already unhappy. Those are the cases where being wrong costs far more than the minutes saved, and where a machine-generated reply makes a recoverable situation worse.

What to build first

Start with attribute enrichment. It is invisible to customers, it makes routing and Fin better at the same time, and you can verify it simply by opening a contact record and looking.

Two things make the difference between a first automation that sticks and one that gets abandoned. Run it alongside whatever happens now for a cycle or two and compare the outputs, since the differences are nearly always genuine discoveries rather than bugs. And have it report that it ran even when it found nothing, because an automation whose only output is silence is one nobody can distinguish from a broken one.

How long should I run it alongside the manual process?

Two weeks covers most weekly rhythms and is long enough to meet the awkward cases. Compare what the automation decided against what people decided, and look specifically at the disagreements rather than the accuracy percentage, since the disagreements are where you learn whether your rules match how your team actually thinks.

Related reading

• Crisp and CodeWords
• Freshdesk and CodeWords
• CodeWords integrations and templates