5 Make.com Automations That Run My Entire Business While I Sleep

Six weeks of early mornings and half-finished builds is what this actually cost me, not the weekend every tutorial promises.

I run a one-person digital-products and consulting business out of Austin: three templates at $29, $49, and $79, a $150 consult call, roughly 40 Stripe orders a week, and 900 subscribers. I was already paying for Make.com, had two scenarios half-built, and was still typing receipts at midnight. Automation had cost me more attention than it returned.

Then I stopped rebuilding and started finishing. Five scenarios, each with its exact trigger, the apps wired in, the operations a run burns, the hours it cost, and the specific thing that broke it. The stack: the $29 Core plan billed annually for 10,000 operations, plus an $18 top-up in launch months, one JSON parse module, no custom apps.

What came back was about 11 hours a week, mostly invoices, lead replies, social scheduling, and Monday reporting. So build the Stripe sale-to-invoice scenario tonight, then lead capture, then cart recovery, publishing, and the morning digest in that order.

Quick Tips Before You Start

1. Stripe Sale to Invoice and Slack Ping

Every sale used to end with me back at the laptop: open Stripe, copy the amount, paste it into a spreadsheet, type a receipt into Gmail, and hope I did not fat-finger the date. The two minutes it cost per sale was not the point. The point was that I was still doing it at 11 p.m., after the sale had already closed.

The fix was a webhook. Stripe fires checkout.session.completed the instant a card clears, and Make takes it from there: one module writes the sale row to a Google Sheet, one sends the Gmail receipt, one drops a Slack ping into a channel I actually watch, and one catches the error branch. Four modules, no custom app, about six operations per sale.

Three hours on a Saturday is what it took, most of that spent reading Stripe's event payload and mapping the fields I wanted in my sheet.

I did not trust it with a real customer's money first. I bought a $1 test product from my own store and watched the whole chain fire. Then I let ten live orders through with me sitting there refreshing, checking every row and every receipt against Stripe's dashboard before I stopped looking.

Week two, the thing broke in the worst way. Stripe retried a webhook, the scenario ran twice, and 14 paying customers got a second receipt in their inbox on the same morning. That is the failure I still think about. I fixed it two ways: a filter on the event ID so a replay is rejected at the door, and a Make Data Store record keyed on the same ID so even a double-trigger writes one row and sends one receipt. If you build this, put both in before the first real sale, not after.

There is one quieter fault I had to design around too. Some payments land in processing instead of succeeded, and the run just stalls. Rather than guess a date, the scenario waits 30 minutes, then logs the sale and flags it in Slack so I can see it with my own eyes instead of trusting a row that might be wrong.

At about 40 orders a week, six operations per sale bought back my entire morning admin block. The maths is almost embarrassing: a few cents of operations against a cup of coffee and 20 minutes of copy-paste every morning. Of everything I have built, this is the one I would rebuild first.

2. New Lead to CRM and Welcome Email

The receipt proves a sale was handled cleanly. The person who filled out a form and asked a question before buying got nothing until I woke up, and that reply is the one people measure in minutes, not hours. A lead who waits until noon feels like a lead who was ignored.

My Tally form drops a webhook into Make with eight modules wired across Tally, Airtable, Gmail and OpenAI. A router splits the record in two: a consult request for the $150 call goes one way, and a template buyer at $29, $49 or $79 goes the other. Cost is about nine operations per lead and four hours of setup.

The OpenAI step writes exactly one thing: a single personalized opening line. The subject line and the rest of the welcome email are fixed copy I wrote once and read a hundred times, so if the model produces something strange, the damage is one sentence, not a whole send that lands in a stranger's inbox sounding off.

Timing matters more than I expected. The first email is held until 7 a.m. in the lead's own time zone. A welcome that arrives at 2 a.m. reads like a robot talking to a dark room, and it gets buried under overnight noise by the time anyone checks their phone.

It fails on the field I did not plan for. A lead types "not sure" in the budget box and the router has no branch for it, so instead of guessing and sending a pitch built for the wrong budget tier, that record lands in a human-review Airtable view and waits for me. One wrong guess sent to a real prospect costs more than the four hours the whole thing took.

Nine operations and four hours bought me replies that land before I have even seen the form fill. If that return has you thinking about launching something, AI-powered business ideas start from a free tier. Per dollar spent, that is the loudest hours-saved return of anything in this build.

3. Abandoned Cart to Three-Email Recovery

The lead who gets the welcome email and never finishes checkout is the next leak in the chain, and cart recovery is the only scenario in this build I would tell most readers to hold off on. It works, and it earned its keep for me, but it also wants more of your attention than the others.

The trigger is a Stripe checkout session that expires after 60 minutes. From there it is Stripe, a Make Data Store record, Gmail and a Google Sheets log, about 14 operations per cart and five hours of build. That is the longest of the five, and the operations are the heaviest per unit too.

Three emails go out at one hour, 22 hours and 70 hours after the session dies. The 10% code appears in the third email only. The first two are a plain reminder, not a discount, and that order matters: lead with a code and you teach every returning customer to abandon on purpose and wait for the coupon.

The part that took the most tuning is the stop. The moment an order lands, the Data Store record flips and the remaining sends cancel, so a buyer who came back and paid is never chased for a cart they already bought. I tested that specifically with my own $29 order, sitting on the expired session and finishing checkout, then watching the queued emails refuse to fire.

In its first month it recovered 11 orders against my then-volume of about 40 orders a week. Not a miracle. But real money that would otherwise have sat in a dead session forever.

do not build it until your checkout sees 20 or more session starts a week. Below that line, 14 operations per cart and the tuning attention it demands cost more than the recovered orders return. Wait until the volume pays for the babysitting.

4. Blog Post to a Week of Social Posts

A cart-recovery email cannot rescue a cart nobody started, so the habit that keeps strangers clicking through to checkout is the one worth protecting. For me that habit used to live in the worst hour of the week: one post published, five tabs open, midnight gone.

Every Tuesday I would publish a 1,200-word post and then write the social copy from scratch, retyping the same ideas five different ways while the clock crossed 12:40 and the words got worse. Doing that by hand is what actually blocks the funnel upstream of checkout.

The replacement triggers on an RSS feed for syndicated posts or a Notion status flipping to Published for the ones I write straight in the database. From there the chain runs Notion, OpenAI, Buffer and Google Sheets, and a single JSON parse module cracks the model's output into separate posts instead of one wall of text.

One finished article becomes five pieces: a LinkedIn post, two X posts, an Instagram caption and a newsletter teaser. The prompt is fed the published text itself, never a blank "write me something about marketing" instruction, which is the difference between posts that quote my actual argument and posts that invent one.

Cost on the ledger: three hours to wire up, 22 operations every time a post goes out, the highest per-unit burn of anything I run. Two things happen while I sleep. At 11 p.m. the scenario fires and fills the Buffer queue so it is loaded by 6 a.m., and the LinkedIn piece lands in drafts rather than publishing, which is why I read it at 7 with coffee, the only output I still touch by hand.

It broke on a case study with a client's name in it. My keyword filter now catches those posts and drops them into a manual folder, so the scenario never publishes a client's name to the feed. Highest operations count in the build, still the one I check least and would miss most.

5. Nightly Metrics Digest Before I Wake

Four scenarios running overnight means four places to check before my first coffee. I wanted the numbers to come to me instead, on one page, before I opened a single tab. That was the last scenario I built and the quickest of the five.

Scheduled for 5:30 a.m., it pulls from Stripe, Google Sheets, Airtable, and Gmail, and OpenAI writes a three-line summary on top. About 18 operations per run and two hours to build, the shortest build in the six weeks.

The email lands at 6 a.m. Yesterday's revenue, order count, new subscribers, unread support tickets, and tasks due, all on one page. Then a what-changed line and one recommended first task.

That recommended task is the part I did not expect to rely on. It is not smart, just the highest-priority overdue item pulled from Airtable, and it still beats the ten minutes I used to spend deciding where to start.

Stripe is the failure point. When Stripe is slow, the run retries for 20 minutes. If it still has nothing, it sends a Slack message saying metrics delayed instead of a blank or half-filled email that looks like a zero-revenue day.

That message is worth more than it sounds. A blank revenue row once made me think a payment processor was down when the real problem was my own scenario. I will not build a digest without a fallback again.

On the ledger: two hours of build and 18 operations per run, against six dashboard tabs and the entire Monday reporting block. Cheapest scenario per hour saved of the five.

It is also the last one I would switch off. Everything else runs overnight; this is how I find out whether any of it worked.

Frequently Asked Questions

How much does running five Make.com scenarios actually cost?

I pay about $29 a month for the Make Core plan billed annually, which includes 10,000 operations. In launch months I add an $18 top-up when the schedule runs hot. The five scenarios together peaked at 62 operations on my busiest night, so the plan has plenty of headroom at my volume of about 40 orders a week.

Do I need to know how to code to build these?

No. Every scenario here runs on the visual canvas with built-in modules and one JSON parse step to split model output into separate posts. The trickiest work is filtering webhooks on event ID and wiring a Data Store record for dedupe and stop rules, and both are drag-and-drop modules.

Which scenario should I build first?

The Stripe-to-invoice scenario. It touches money, which makes it the highest-stakes thing you can take off your plate, and it is the easiest to test: buy a $1 product yourself, watch ten real orders, then trust it. Three hours of build and six operations per sale is the cheapest return in the build.

What was the worst failure in the whole build?

A Stripe webhook retry in week two sent 14 duplicate receipts to paying customers in one morning. The fix was a filter on event ID plus a Data Store dedupe keyed on the same ID. I now build both locks before any scenario that sends customer email goes live.

How long until the automations actually pay back the build time?

Six weeks to build all five, 2 to 5 hours per scenario. They gave back about 11 hours a week across invoices, lead replies, social scheduling, and reporting. The Stripe scenario pays back its three-hour build in the first week or two; the cart recovery scenario took a month to justify its five hours.

Stripe Invoice First, Instagram Carousel Later

The verdict is simple: five scenarios, $29 a month Core plus an $18 top-up in launch months, never more than 62 operations on the busiest night, about 11 hours a week returned. Build Stripe sale to invoice first because it touches money, and a $1 test product proves the whole chain in one afternoon. Lead capture second, cart recovery third, social posting fourth, and the morning digest last, once the other four are stable.

Skip cart recovery until checkout gets 20 or more starts a week. Below that it burns attention faster than it recovers orders, and it is the only place in this build where the honest answer is wait.

I still think about the 14 duplicate receipts from week two more than any success. The event-ID filter and the Data Store dedupe came out of that mess, and that failure is why the scenario is trustworthy today. None of this removes the work. It moves it into one Saturday of building, so the 2 a.m. Stripe sale becomes a Slack ping and a sent invoice instead of a morning chore.