Calendly Booking Surge + Stripe Trial Conversion Lag: Sales Capacity Alert to Microsoft Teams via n8n
Know the exact moment your demo backlog is outpacing your trial conversion rate — before you've booked three weeks of calls you can't convert.
The stack in the order it runs — data flows from the source through to where it lands.
The failure mode is invisible until it's expensive. You run a campaign, Calendly fills up, you're booked solid for three weeks — and by the time those demos happen, the leads are cold and your Stripe trial-to-paid conversion tanks. Nobody notices the conversion degradation because everyone is heads-down on calls.
This playbook surfaces both signals together. n8n runs two parallel HTTP Request branches — one to Calendly's API, one to Stripe — merges the results, and only then fires the alert. That merge step is the whole point: either signal alone is noise; together they tell you whether you have a capacity problem or a conversion problem or both.
The native Microsoft Teams node in n8n sends Adaptive Cards directly. That matters because Adaptive Cards render tables cleanly in Teams without any extra formatting work on your end. Calendly's v2 API (`/scheduled_events`) gives you event counts by date range and event type. Stripe's `/v1/subscriptions` endpoint with `status=trialing` and `trial_end` date filters lets you compute trials expiring in the next 7 days and trials converted in the past 7 days. The conversion rate is `converted_last_7d / (converted_last_7d + churned_at_trial_end_last_7d)` — you need both `canceled` and `active` subscription data to compute it correctly.
One scope note: this is built for sales-assisted trial motions where demos are booked via Calendly and trials are created in Stripe afterward. If you're PLG with no sales calls, the Calendly signal is irrelevant. If you're running enterprise deals with multi-month cycles, the 7-day lag window is too short — extend it to 30 days.
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 n8n workflow with a daily Schedule trigger
In n8n, create a new workflow and name it `Sales Capacity Alert`. Add a 'Schedule Trigger' node set to run daily at 8:30 AM. Add your Calendly Personal Access Token and Stripe Secret Key as n8n credentials. For Calendly, use 'Header Auth' with the header `Authorization: Bearer YOUR_TOKEN`. For Stripe, use n8n's built-in Stripe credential type.
- 2
Fetch Calendly bookings for the past 7 days and next 7 days
Add an HTTP Request node. GET `https://api.calendly.com/scheduled_events?organization={ORG_URI}&min_start_time={7_days_ago_iso}&max_start_time={now_iso}&status=active&count=100` — this gives you last week's completed demos. Add a second HTTP Request node fetching `min_start_time={now_iso}&max_start_time={7_days_forward_iso}` to get upcoming booked demos. Handle Calendly's pagination via the `next_page_token` in the response. Extract two counts: `completed_demos_last_7d` and `booked_demos_next_7d`.
- 3
Fetch Stripe trial conversion data for the past 7 days
Add an HTTP Request node. GET `https://api.stripe.com/v1/subscriptions?status=active&created[gte]={7_days_ago_unix}&limit=100` — these are trials that converted to active in the past week. Also GET `https://api.stripe.com/v1/subscriptions?status=canceled&canceled_at[gte]={7_days_ago_unix}&limit=100` and filter client-side for records where `cancel_at_period_end = false` and `trial_end` falls within the past 7 days — those are trials that churned at trial end. Feed both counts into a Code node and compute `trial_conversion_rate = converted / (converted + churned)`.
- 4
Fetch upcoming trial expirations from Stripe
Add an HTTP Request node. GET `https://api.stripe.com/v1/subscriptions?status=trialing&trial_end[gte]={now_unix}&trial_end[lte]={7_days_forward_unix}&limit=100`. Count the results as `trials_expiring_next_7d`. Comparing this number to `booked_demos_next_7d` tells you how much of the upcoming trial expiry cohort has a demo scheduled versus is heading toward expiry with zero touchpoint.
- 5
Compute the capacity risk score
Add a Code node in JavaScript. Define three flags: OVERLOADED if `booked_demos_next_7d > completed_demos_last_7d * 1.5` (50% more demos booked than last week's actual capacity); CONVERSION_LAG if `trial_conversion_rate < 0.25` (below 25% trial-to-paid); COVERAGE_GAP if `trials_expiring_next_7d > booked_demos_next_7d * 2` (more than 2x trials expiring versus demos scheduled, meaning most trials will expire without a call). Output all three boolean flags plus the raw numbers behind them.
- 6
Post an Adaptive Card to Microsoft Teams
Add a Microsoft Teams 'Send a Message' node and target your sales or ops channel. Build an Adaptive Card with: a title block reading 'Sales Capacity Report — {today}'; a FactSet showing Demos Completed (last 7d), Demos Booked (next 7d), Trial Conversion Rate (last 7d), and Trials Expiring (next 7d); and a TextBlock for each active risk flag with a red indicator. If no flags are active, render a green 'All metrics within normal range' TextBlock and don't tag anyone.
- 7
Escalate with a tagged alert when two or more flags fire simultaneously
Add an IF node after the metric computation. Condition: `(overloaded + conversion_lag + coverage_gap) >= 2`. If true, add a second Microsoft Teams message node that posts to `#sales-alerts` and `@mentions` your sales lead and head of product by their Teams user IDs. Message: '⚠️ Sales capacity risk: {N} flags active simultaneously — demo backlog is building while trial conversion is lagging. Review pipeline allocation today.' Single-flag alerts are informational. Two flags firing at once requires a human decision, which is why this branch exists.
- 8
Append a row to Google Sheets for weekly trend review
Add a Google Sheets 'Append Row' node at the end of the workflow. Log these columns: Date, Demos Completed Last 7d, Demos Booked Next 7d, Trial Conversion Rate, Trials Expiring Next 7d, Flags Active (comma-separated). After 4 weeks of data you'll be able to see whether the conversion lag is structural — a product problem — or episodic, meaning a specific campaign pulled in bad-fit users. That context is what makes the difference between reacting correctly and overreacting when the alert fires.
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
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.
Intercom Ticket Volume + Razorpay Failed Payments: Daily Support-Cost-per-Revenue Alert to Slack via Zapier
Catch the support cost blowout from Razorpay failed payments before your agents are already buried.
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.