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.

The flow
Razorpay logo
Source
Razorpay
Intercom logo
Process
Intercom
Zapier logo
Process
Zapier
Slack logo
Destination
Slack

The stack in the order it runs — data flows from the source through to where it lands.

Why this stack

Failed payments in Razorpay aren't just a revenue leak — they're a support cost problem you're not measuring. Every failed payment generates 1.2–1.8 Intercom conversations on average: retry questions, refund status checks, payment method update requests. When you hit a gateway outage or a bank-specific failure window, your support queue spikes within 2 hours. Most teams don't connect these two events until the monthly review. By then, you've already paid for agent hours that were entirely avoidable.

Zapier fits here because both Intercom and Razorpay have solid native Zapier integrations — zero auth code, reliable webhook handling. The workflow is a scheduled digest, not event-driven. It pulls aggregated counts from both systems each morning and computes a ratio. The 'Code by Zapier' step in Python or JavaScript handles the ratio calculation without a separate service. If you're already on Zapier Professional, this costs you nothing extra.

Two real tradeoffs to know going in. First: multi-step workflows with Code steps require Zapier Professional at $49/month. If you're on Zapier Starter, replace the Code step with a Google Sheets formula and use Sheets as your calculation layer. Second: Intercom's API returns ticket counts by created date, not by root cause. You're correlating by time overlap, not causal link. That's fine for operational alerting — you'll dig into root cause manually — but don't present this correlation as causal in a board report.

Skip this entire playbook if you're on Stripe instead of Razorpay. The signal is the same, but Stripe's `payment_intent.payment_failed` webhook is more granular and suits a real-time event-driven alert far better than a daily digest. This playbook is built specifically around Razorpay's batch settlement reporting pattern.

The stack (4)

  1. Razorpay logo

    Payments + payouts built for India.

    Webhooks and the reports API make revenue an automatable signal, not a dashboard you check.

  2. Intercom logo

    Customer messaging + support inbox.

    Conversation data surfaces churn/expansion signals worth routing to chat.

  3. Zapier logo

    No-code automation across 6k+ apps.

    Fastest path from "when X happens, do Y" without standing up infrastructure.

  4. Slack logo

    Team chat where most ops alerts and reports land.

    The default place a small team already lives — pipe reports here instead of email nobody opens.

How it runs

  1. 1

    Set up a Zapier Schedule trigger for 9 AM daily

    Create a new Zap. Set the trigger to 'Schedule by Zapier' → 'Every Day' → time: 9:00 AM in your local timezone. Name it 'Daily Support-Cost-per-Revenue Alert'. The 9 AM run lands after Razorpay's overnight settlement batch has processed — Razorpay settles T+1 or T+2 depending on your account type. Confirm your settlement cycle in the Razorpay dashboard under Settings > Settlements before you finalize the schedule. You need complete data for the previous day, not partial.

  2. 2

    Pull yesterday's failed payments from Razorpay API

    Add a 'Code by Zapier' step in JavaScript. Use `fetch` to call `https://api.razorpay.com/v1/payments?from=YESTERDAY_START&to=YESTERDAY_END&count=100` with Basic Auth using your Key ID and Key Secret. Filter the response for records where `status === 'failed'`. Count total failed payments as `failedCount` and sum their `amount` fields — divide by 100 to get `failedAmountINR`. Paginate using the `skip` param whenever the response length equals 100. Also calculate `failedRate = failedCount / totalPayments * 100`.

  3. 3

    Pull yesterday's new Intercom conversations

    Add a second 'Code by Zapier' step. Call `https://api.intercom.io/conversations` with headers `Authorization: Bearer YOUR_INTERCOM_TOKEN` and `Accept: application/json`. Pass `created_after` (yesterday 00:00:00 UTC as Unix timestamp) and `created_before` (yesterday 23:59:59 UTC) as query params. Paginate through all pages using the `pages.next` cursor in the response. Count total conversations as `totalConversations`. Then filter for conversations where the first message body contains 'payment', 'failed', 'refund', or 'not processed' to get `paymentRelatedConversations`. Keyword matching is approximate but catches 70–80% of payment-related tickets reliably.

  4. 4

    Compute the support cost correlation ratio

    Add a third 'Code by Zapier' step taking outputs from the previous two steps. Calculate `ticketsPerFailedPayment = paymentRelatedConversations / failedCount` — if `failedCount` is 0, set the ratio to 0. Calculate `estimatedSupportCost = totalConversations * YOUR_COST_PER_TICKET`, where `YOUR_COST_PER_TICKET` is a hardcoded constant in your code (e.g., $4.50 for blended agent cost). Define alert thresholds as constants: `FAILED_RATE_THRESHOLD = 5` (percent) and `TICKET_SURGE_THRESHOLD = 1.5` (ratio vs 7-day average). Store the 7-day average as a Zapier Storage key using the `@zapier/storage` npm package, or pull it from a Google Sheets lookup.

  5. 5

    Determine alert severity level

    In the same Code step, classify severity: `HIGH` if `failedRate > 10%` OR `totalConversations > 2x the 7-day average`; `MEDIUM` if `failedRate > 5%` OR `totalConversations > 1.5x the 7-day average`; `LOW` otherwise. Assign the matching emoji — 🔴 HIGH, 🟡 MEDIUM, 🟢 LOW. Severity determines the Slack channel: HIGH goes to `#ops-alerts`, MEDIUM to `#ops-daily`, LOW to `#ops-log`. Routing to the right channel is what keeps this alert from becoming noise you ignore after week two.

  6. 6

    Post the correlated digest to the appropriate Slack channel

    Add a Zapier 'Send Channel Message in Slack' action. Set the channel dynamically from the severity output using Zapier's 'Paths' feature — each path (HIGH, MEDIUM, LOW) gets its own Slack step. Message template: `{{severityEmoji}} *Daily Payment + Support Health – {{YESTERDAY_DATE}}* *Razorpay Payments:* • Total processed: {{totalPayments}} • Failed: {{failedCount}} ({{failedRate}}%) • Failed value: ₹{{failedAmountINR}} *Intercom Support:* • Total new conversations: {{totalConversations}} • Payment-related: {{paymentRelatedConversations}} • Tickets per failed payment: {{ticketsPerFailedPayment}} • Est. support cost: ${{estimatedSupportCost}} *Action:* {{actionText}}` Set `actionText` based on severity: HIGH → 'Check Razorpay dashboard for gateway errors. Assign support triage lead.'; MEDIUM → 'Monitor through midday. Compare with last week.'; LOW → 'No action needed.'.

  7. 7

    Store today's metrics for 7-day rolling average

    After the Slack post, add a final step using Zapier Google Sheets 'Create Spreadsheet Row' to write today's date, `failedRate`, `totalConversations`, and `estimatedSupportCost` into a tab called 'Daily Metrics History'. Keep 7 rows always visible there. Use a Sheets formula in a separate tab to compute the 7-day averages — don't calculate that in code. On the next day's run, the Code step reads those averages back via the Zapier Google Sheets 'Lookup Spreadsheet Row' action. This is simpler than Zapier Storage for any team that wants the history to be human-readable without opening a dashboard.

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 services

More like this