The Make.com playbook: 12 automations every SaaS should run
After building automation systems for dozens of SaaS companies, we've seen the same twelve scenarios come up again and again — the ones that quietly pay for themselves inside the first 90 days and keep paying indefinitely. This isn't a list of clever demos. These are the Make.com scenarios that operators actually run in production, that handle real volume, and that teams wish they had built sooner. We'll cover the setup logic for each, flag the edge cases that trip people up, and note where Make.com is the right choice versus where you'd be better served by something else.
1. Lead routing and enrichment
Lead routing is the automation that delivers the most immediate, measurable ROI. Inbound leads from your website form, your ad campaigns, or your product sign-up flow all arrive at different quality levels. Without automation, they sit in an inbox or a CRM in the order they arrived. With a Make.com scenario, they're enriched, scored, and routed to the right rep within seconds of submission.
The scenario listens on a webhook from your lead source. It calls Clearbit or Apollo to enrich the lead with company size, industry, and technology stack. It applies a simple scoring model — a series of filter modules that assign points based on company size, title keywords, and whether the email domain is a known free-tier domain. High-score leads route to a Slack DM to the assigned rep and create a high-priority CRM deal. Low-score leads get a nurture sequence in your email platform and a low-priority CRM record. Unclassifiable leads go to a review queue.
The edge case everyone hits: duplicate leads. The same person submits from two different forms, or submits twice. Add a deduplication step early in the scenario — check the CRM for an existing contact with the same email before doing anything else. If a match exists, update rather than create. This single step will save you hours of CRM cleanup.
2. Churn risk alerts
Product usage data is the best leading indicator of churn you have, and almost no one acts on it systematically. The scenario here runs on a schedule — daily is sufficient for most SaaS products — and queries your analytics database or event platform for customers who've crossed a usage threshold. Define your own: fewer than 3 logins in the last 14 days, no activity in the core feature in the last 7 days, or a drop in API calls of more than 50% week-over-week.
When a customer triggers the threshold, the scenario creates a task for their CSM in your task management tool, sends an internal Slack alert with their account details and recent usage summary, and optionally triggers a personalised email from your email platform. The personalisation is important — generic 'we noticed you haven't logged in' emails are ignored. Reference the specific feature they used to use and offer to show them something relevant to their use case.
The operational discipline this automation requires is more important than the automation itself. If you alert the CSM team to every at-risk account but they have no capacity to act, you've built an anxiety machine. Before you ship the scenario, agree on what action the CSM should take for each alert tier, and build a way to track whether action was taken. Close the loop.
3. Trial conversion sequences
Trial conversion is where most SaaS products leave money on the table. The typical pattern is a generic drip sequence that runs the same emails regardless of what the user has or hasn't done during the trial. The Make.com scenario replaces this with a behaviour-triggered sequence — emails that fire based on what actions the user has taken, not just how many days have elapsed.
The scenario monitors a webhook or polls your product database for key activation events: first project created, first integration connected, first export run. When an activation event fires, the sequence forks. Users who hit the activation milestone get a congratulatory email that pushes them toward the next milestone. Users who haven't hit it get a help-focused email that addresses the most common reason people get stuck at that point. The content is different. The timing adapts to the user's behaviour.
Three days before trial expiry, regardless of activation state, the scenario triggers a conversion push: a personalised email from the founder or a senior team member, a Slack DM to the assigned rep if the account is above a revenue threshold, and optionally a 20% discount code that expires at the same time the trial does. The discount is optional — test without it first. Many users will convert without it.
- Trigger: user completes trial sign-up (webhook from product)
- Branch A (activated): push toward next milestone, feature spotlight emails
- Branch B (not activated): obstacle-removal emails, offer onboarding call
- Day T-3: conversion push email + rep task if above threshold
- Day T-0: expiry notification + grace period offer
4 & 5. Invoice and billing operations
Failed payments are the silent revenue leak in any SaaS business. If your billing platform is Stripe, you get dunning emails for free, but they're generic. The Make.com scenario adds a layer of personalisation and human judgment on top of the automated dunning. When Stripe fires a payment_intent.payment_failed webhook, the scenario checks how many previous failures this customer has had, what their account value is, and whether they have an assigned CSM.
High-value accounts with a CSM get a personal outreach from that CSM via Slack DM and a CRM task, not just an automated email. The automated email still sends — you want every touchpoint firing — but the human contact differentiates the experience for customers who matter most to retention. Low-value accounts get the automated sequence only. After three failed attempts, accounts above a revenue threshold get escalated to a senior team member for manual outreach before the account is suspended.
The second billing scenario is invoice generation and delivery for customers on custom or annual plans. Rather than relying entirely on Stripe's invoice emails, use Make.com to pull the invoice data, render a branded PDF using a document generation service, and deliver it via email with specific payment instructions, a link to update payment details, and a named contact for billing questions. The branded PDF with direct payment instructions dramatically reduces payment delays on high-value invoices.
6 & 7. Onboarding task creation and welcome sequences
When a new customer signs a contract, three things need to happen within the hour: accounts need to be provisioned, an onboarding project needs to be created in your project management tool, and the customer needs to receive a welcome email with clear next steps. The Make.com scenario handles all three. The trigger is a CRM deal moving to 'Closed Won' or a Stripe subscription being created for a paid plan.
The scenario creates the onboarding project from a template, assigns the correct team members based on the customer's plan tier and territory, creates the first set of onboarding tasks with due dates calculated from the sign date, and sends the customer a welcome email that includes their onboarding manager's name, a link to the onboarding project's customer-facing view, and the direct calendar link for their kick-off call. All of this fires automatically before any human has touched the account.
The welcome sequence that follows is behaviour-triggered, not time-triggered. Within 24 hours of account creation, the scenario checks whether the user has logged in. If yes, they get a 'great start' email with their next suggested action. If no, they get a more urgent check-in. This simple branch dramatically improves day-1 engagement rates, because the email is relevant to their actual state rather than being a generic 'welcome aboard' message.
8, 9 & 10. Internal reporting and data sync
Reporting scenarios are unglamorous but consistently among the highest-value automations any team builds. The weekly revenue and retention report scenario runs every Monday morning, pulls data from Stripe, your CRM, and your product analytics, compiles a structured summary, and posts it to a Slack channel with a formatted breakdown. No one needs to pull a report manually. The numbers are there when the team starts work.
The CRM to data warehouse sync is another quiet workhorse. Keeping your CRM data current in your analytics database or BI tool usually requires either an expensive integration service or manual exports. A Make.com scenario that polls your CRM every hour for updated contacts, deals, and companies, and upserts them into Postgres or BigQuery, costs a fraction of a dedicated ETL tool and gives you the same result for the data volumes typical of a growing SaaS.
The third scenario in this category is the weekly customer health digest sent to account managers. It pulls the top at-risk accounts based on usage thresholds, new churned accounts from the previous week, accounts due for renewal in the next 30 days, and accounts that have hit expansion triggers. One email, automatically assembled, gives the team the information they need to prioritise their week without anyone manually building a spreadsheet.
11 & 12. Support operations and review collection
Support ticket routing in Make.com works similarly to the lead routing scenario: a webhook from your helpdesk fires when a new ticket is created, and a series of classify-and-route steps direct it to the correct queue, assign it to the correct agent, and set the correct priority. The classification can use keyword matching for speed, or an AI call for accuracy. For most support volumes, keyword matching is sufficient and much cheaper.
The final scenario in the playbook is review collection. Timing is everything in review requests. The optimal moment is when a customer has just experienced success — within 24 hours of a resolved support ticket with a satisfaction score above 4, after a successful milestone completion in onboarding, or after a successful renewal. The Make.com scenario listens for these events and fires a short, direct review request email. The copy should be two sentences and a link, not a paragraph asking for a favour.
Review collection automation has one firm rule: never trigger a review request within 30 days of any negative interaction. The scenario should check the customer's recent history — any open support tickets, any payment failures, any NPS score below 7 — before sending. A review request to a frustrated customer is worse than no review request at all.
Related articles
Make.com error handling patterns that actually scale
Rollbacks, dead-letter routes, and alerting that wakes the right person.
Complete Make.com Guide: Everything You Need to Automate Your Business
The definitive Make.com guide — scenarios, modules, routers, and production patterns.
Make.com Tutorial: Build Your First Scenario in 20 Minutes
A beginner-friendly walkthrough of Make.com — from signup to a working automation.