Support Volume & CSAT Threshold Alert: Intercom → Airtable → Microsoft Teams
Stop checking Intercom reactively — sync it to Airtable, compute the trends, and let Teams tell you when something's wrong.
The stack in the order it runs — data flows from the source through to where it lands.
Support is your earliest signal on product quality. Most early-stage teams only open Intercom when they're answering tickets. By the time you notice a spike manually, you're already behind. This workflow surfaces a volume surge or CSAT drop in the same channel where your ops team is making decisions — Microsoft Teams — before it turns into a crisis.
Intercom's REST API exposes conversation-level data: created_at, state (open/closed/snoozed), CSAT ratings, tags. Airtable sits in the middle because it gives you a running dataset, date-range filtering, and formula-based aggregates without standing up a database or writing backend code. Pipedream or Make would handle the sync step, but n8n gives you HTTP flexibility and a self-hosting option if you need it.
Teams over Slack here because this playbook targets Teams-first orgs — enterprise, SMB on Microsoft 365, or Windows-centric IT shops. The Teams webhook API is straightforward and supports Adaptive Cards for structured, color-coded alert formatting.
Two cases where you should skip this: if you're on Zendesk, the API shape differs but the logic is identical — swap the Intercom HTTP node for Zendesk's /api/v2/tickets.json endpoint. And if you're under 10 conversations/day, don't bother — just read every ticket. This is built for teams fielding 30+ conversations/day where manual triage stops being realistic.
The stack (4)
Chat + channels for Microsoft-365 shops.
If the company is on Outlook/365, Teams is where reports get read — push there, not a separate tool.
How it runs
- 1
Create the Airtable base for support metrics
Create a new Airtable base called 'Support Operations'. Add a table 'Daily Metrics' with these fields: Date (Date), Open Conversations (Number), New Conversations (Number), Closed Conversations (Number), Avg First Response Time Minutes (Number), CSAT Score (Number, 0-100), CSAT Response Count (Number), Flagged (Checkbox). Add a second table 'Raw Conversations' if you want row-level data — fields: Conversation ID, Created At, State, Tags, CSAT Rating, Assignee. The Daily Metrics table is what drives your alerts. The Raw Conversations table is optional but useful for debugging aggregation errors later.
- 2
Set up the n8n Schedule Trigger and Intercom HTTP Request
In n8n, create a workflow with a Schedule Trigger set to '0 9 * * *' (9 AM daily). Add an HTTP Request node pointing at 'https://api.intercom.io/conversations'. Auth: Bearer token from your Intercom app's access token. Set query param 'created_after' to yesterday's Unix timestamp. Set headers 'Accept: application/json' and 'Intercom-Version: 2.10'. The response is paginated — add a Loop node to handle pagination via the 'pages.next' cursor in the response body. Don't skip the Loop; Intercom won't return everything in one call once your volume climbs.
- 3
Extract and aggregate conversation stats in a Code node
Add a Code node receiving all paginated conversation data. Compute: new_count (conversations created yesterday), open_count (state == 'open'), closed_count (state == 'closed'), avg_first_response_time in minutes (pull from the 'statistics.first_response_time' field, average across all conversations), csat_scores (filter to conversations where 'conversation_rating' exists, average the 'rating' field on a 1-5 scale, normalize to 0-100). Output a single aggregated object. One specific rule: if csat_response_count is under 5, flag CSAT as statistically unreliable and exclude it from the alert. Five responses is the floor — below that it's noise.
- 4
Upsert the daily row into Airtable
Add an Airtable node with action 'Search Records', filtering where Date equals today's date formatted as YYYY-MM-DD. If a record already exists, use 'Update Record' to refresh it. If not, use 'Create Record'. Map all fields from the Code node output. This upsert pattern means you can re-run the workflow at 2 PM and 5 PM for intraday snapshots without creating duplicate rows. Skipping the search step and always creating is the most common mistake here — you'll end up with three rows for the same day and broken trend math.
- 5
Read the last 7 days from Airtable for trend calculation
Add an Airtable 'List Records' node filtered to the last 7 days using the formula: IS_AFTER({Date}, DATEADD(TODAY(), -7, 'days')). Sort ascending by Date. In a second Code node, compute 7-day averages for new_count and csat_score. Compare today's values against those averages. Breach conditions: new_conversations > 7-day avg * 1.5 (volume spike), OR csat_score < 65 when response count >= 5, OR open_count > 50 (backlog threshold). If any breach is true, set the Flagged field on the Airtable record to true.
- 6
Post the daily digest to Microsoft Teams
Add an HTTP Request node targeting your Teams Incoming Webhook URL — create it in Teams under a channel > Connectors > Incoming Webhook. POST a JSON payload in Adaptive Card format: a title card labeled 'Support Daily Digest — [date]', a fact set showing New Conversations, Open Backlog, CSAT Score, and Avg First Response Time. Keep it to one card, under 6 facts. Use the 'attention' color on any metric that's breached its threshold — Adaptive Cards support color-coded badge elements and it makes the card scannable in under three seconds.
- 7
Add a separate breach alert to a dedicated Teams channel
Add an IF node after the trend calculation. If any breach condition is true, POST to a second Teams webhook pointing at your #ops-alerts channel — separate from the digest channel. Message format: '🚨 Support alert: [specific condition]. Today: [value] vs 7-day avg: [value]. Assignees: @[support lead handle].' Teams mentions require the user's AAD Object ID in the format '<at>DisplayName</at>' — look it up once and hardcode it. Only fire this node when a breach is true. Alert fatigue from daily pings on healthy days is exactly what kills these systems within two weeks.
- 8
Test with a manual trigger before activating the schedule
Before activating the schedule, run the workflow manually in n8n's test mode using a hardcoded date range covering a past week where you know the Intercom data. Verify your aggregation math against Intercom's own reporting UI. Check that the Airtable upsert produces exactly one row per day — not two, not zero. Confirm the Teams webhook receives and renders the Adaptive Card correctly. Teams is finicky: malformed JSON gets silently dropped, no error message. If your card doesn't show up, the schema is wrong — validate it against Microsoft's Adaptive Card schema before you waste time debugging the n8n nodes.
Want me to build this for you instead?
Product Audit and CTO Mode run out of this same thinking. If you’re reading this thinking “I want this, but in my product” — let’s talk.
See servicesMore like this
Google Analytics 4 + HubSpot Lifecycle Stage: Weekly Acquisition-Quality Digest to Slack via Pipedream with Claude Narrative
Stop reporting traffic numbers. Report whether the traffic you paid for last week actually became pipeline — with a one-paragraph executive summary written by Claude.
Gmail Thread Aging + Stripe Invoice Overdue: Unified AR Follow-Up Digest to Slack via Zapier
Surface overdue Stripe invoices and the exact age of your last Gmail thread with that customer — every morning at 8:30, automatically — so AR follow-up stops living in someone's head.
Outlook Calendar Load + HubSpot Deal Velocity: Weekly Ops Digest to Microsoft Teams
Every Monday at 07:30, your revenue team gets one Teams card: last week's deal pipeline movement next to each rep's actual meeting load — so you stop guessing whether low close rates are a pipeline problem or a capacity problem.