beehiivIt’s 9am and you haven’t opened Intercom yet. Somewhere in there, a customer has been waiting since last night for an answer that takes thirty seconds.
When support is one of your six jobs, the inbox only gets opened when you remember it. The board puts it in front of you.
What the board shows
Open conversations: who’s waiting, on a list on your board. You see it the moment you look up, next to everything else, without opening the inbox.
Customers: Intercom reads contacts and companies too, so the people who wrote in this week can sit on the board beside the conversations.
Beside it: today’s signups from Supabase or PostHog, MRR from Stripe, errors from Sentry, and the to-do list where “reply before noon” lives. When five messages arrive about the same broken invite email, the Sentry issue beside them is usually where you start.
Where the data comes from
Intercom runs its own MCP server, the one AI apps sign in to when they read your workspace. The board signs in to it through Intercom’s own consent and sign-in pages. That sign-in is sealed on the board’s server and never sent back to your browser.
Then the board runs the reads you chose, on a schedule, while the board is open. Only reads. Intercom’s server can write internal notes, and the board never does. Answering stays in Intercom, where your replies, macros and history already live.
You pick what to show in Connect. Choose one of Intercom’s reads, try it, and the form shows what the widget will say before anything lands on the board. Or ask your agent in a sentence. “Show open Intercom conversations on the board” works from Claude, Codex, Cursor or any app that speaks MCP.
If a read fails, the widget keeps the last rows it got and says what went wrong and when. It won’t pretend the inbox is empty.