Seven Make.com scenarios as importable JSON, plus the Airtable base every one of them writes to. What each contains, what you'll need to change, and the order to import them in — which is not the order they appear in the book.
Full contents and import instructions on this page. The files themselves need an email, and I'll explain why below.
None of them arrive connected to your accounts — connections don't transfer, and shouldn't. These are exports of the scenarios I actually run, not the teaching diagrams from the book. They differ, deliberately: the clip chain runs as three scenarios rather than one because a single chain that long is miserable to debug, the refund chain grew an approval branch the book doesn't describe, and a few of them are leaner than the chapter version because the extra modules turned out not to earn their keep. The module counts below are what is in the files. Where a chapter quotes a different number, the chapter is describing the chain you build by hand — this is what mine became after nine months of running it.
Command Center test scenario
Creates an Airtable row, then sends you a Telegram message. Useless in itself; import it first anyway. It proves your Airtable connection, your Make account and your Telegram bot all work before anything complicated depends on them.
You'll need to change: Nothing. It's the plumbing test.
Refund chain
Tally response → Stripe customer lookup → payment intents → a Router. The automatic branch refunds, tags in Kit, unsubscribes, finds and updates the Airtable row, then notifies you. The other branch just messages you — that's the threshold: refunds above your rung-two price get a human before they get processed.
You'll need to change: The threshold. Set it to your own price before activating.
Capture machine
ManyChat webhook → Kit tag → Airtable Contacts. The ManyChat flow itself is built in ManyChat; this is the half that gets the email onto your list with the source attached. Three modules because that is genuinely all it needs.
You'll need to change: Your Kit form ID and the tag naming.
Post-purchase chain
Stripe event → Airtable order row → Kit tag → Telegram. The day-7 and day-21 follow-ups the chapter describes live in Kit as an automation rather than here, which is why this is shorter than the chapter's version.
You'll need to change: Nothing in the blueprint — but write the delivery email in Kit by hand.
Scorecard chain
Quiz webhook → two variable steps that compute the score and band → Claude writes the verdict → Kit band tag → Airtable Contacts. The band-selection logic survives sanitizing; the Kit tag IDs are placeholders you replace with your own.
You'll need to change: The four Kit tag IDs.
Content ingest — the shared front end
Drive folder watch, then a Router that fans one upload into two chains: OpusClip for video, and Deepgram → Claude restructure → Airtable → Telegram for the article draft. Import this before either clip blueprint — both depend on it.
You'll need to change: Your Drive folder, and the restructure prompt if you've edited yours.
Clip chain — process
OpusClip webhook → fetch the clips → Iterator → log each one to Airtable → send it to Telegram for approval. Stops at the approval gate on purpose.
You'll need to change: The virality threshold if you want one tighter than the default.
Clip chain — approval handler
Watches Telegram for your button tap, then routes. Approve: read the record, Claude writes the caption, Buffer schedules it, Airtable updates, you get told. Reject: mark it and move on. This is the half that makes the gate mean something.
You'll need to change: The caption prompts, which point at your own Project.
Article chain — publish
Watches Airtable for a row marked Ready to Publish → posts to WordPress → marks the row → tells you. Deliberately separate from ingest, because the 25-minute editorial pass sits between them and nothing should automate across it.
You'll need to change: Your WordPress target. Swap the module if you publish to Ghost, Framer or Webflow.
Nightly dashboard aggregation
Runs at 02:00. Kit subscribers, Stripe payments and three Airtable searches, each through an Aggregator, then a Router that updates this week's Metrics row if it exists and creates it if it doesn't. Import this one last — it reads from tables the others create.
You'll need to change: Nothing, if you imported the Airtable base as-is.
Plus the Airtable base
Contacts, Content, Orders, Tasks, Automation Log and Metrics — every field typed correctly, with the views the rest of the book assumes. Duplicate it first; eight of the ten blueprints write to it.
1, 2, 6, 3, 4, 5, 7. Dependency order, cheapest and safest first — not chapter order.
Blueprints 1 and 2 teach you the import process
On something small, where a mistake costs nothing. Two modules and six modules. Get the connection-reconnecting rhythm right here.
Blueprint 6 next, while you're fresh
It touches money and it's the one where a silent failure means someone paid you and got nothing. It deserves your full attention, not the end of an evening.
Then 3, 4 and 5 — the content and capture machines
3 and 4 share a trigger, so import 3 first and let 4 fan out from it.
Blueprint 7 last
It reads data the others produce. Import it into an empty base and it'll aggregate nothing, convincingly.
Importing a chain you don't understand is faster than building one, and slower than building one you do. Read them.
Seven JSON blueprints and the Airtable base template.
And yes — this is the Chapter 7 capture machine, pointed at you. I'm telling you rather than hoping you don't notice, partly because it would be strange not to, and partly because seeing a mechanism from the buyer's side is the fastest way to understand it.
You'll get the files immediately. There's a welcome sequence. You can leave at the bottom of any email, and the unsubscribe works — because Chapter 8.2 said it should.
© 2026 Jeff Sheikowitz. All rights reserved.