AI Content Marketing
027 Automation, Repurposing and Custom GPTs 1,516 words · 7 min

Automating the Boring Bits With Zapier and Make

Count the time your team actually lost last month. Not to writing: to the retyping. Someone pasted a brief from an email into a Google Doc. Someone else hunted for the approved product shot in a Slack thread from August. A stakeholder asked where their blog post was, for the third time, and the reply took eleven minutes to write because it needed checking first. On a three-person team that pile adds up to something like six to eight hours a month, and none of it shows up in a content calendar because none of it is a deliverable.

That overhead is what content workflow automation tools are genuinely good at. They are much worse at the thing they get sold for. Routing a brief to the right writer is a deterministic problem with a correct answer, so a Zap can own it end to end. Deciding what that brief should argue is not, and a scenario that drafts your first paragraph will produce something you rewrite anyway, at which point you have added a step rather than removed one. Repurposing and custom GPTs are a real category with real returns, covered separately in our automation, repurposing and custom GPTs pillar, but they belong to the production layer. This piece stays in the coordination layer, where the maths is boring and reliable.

Five builds follow. Each one has been run on small teams, each removes a specific recurring task, and none of them touch a sentence anybody will publish.

Which platform for which build

Pick by shape of problem, not by preference.

Build shapeUseWhy
One trigger, three or four actions, no branchingZapierFaster to build, better error replay, non-technical handover
Branching by topic, file handling, loops over arraysMakeRouters and iterators are native; visual debugging shows each bundle
Scheduled aggregation (digests, reporting pulls)MakeOperations are cheap in bulk, so a 60-record loop is not a budget event
Something a freelancer must maintain after you leaveZapierThe interface explains itself

Billing matters here because it shapes design. Zapier charges per task, meaning per action step that fires, so a five-step Zap running 80 times a month costs 400 tasks. Make charges per operation but its entry paid plan allocates tens of thousands of them, so loops that would be financially silly in Zapier become routine. Both vendors have repriced recently, so check current numbers before committing, but the ratio has held: Make is the cheaper home for anything that iterates.

Build 1: brief intake that files itself

Stop accepting briefs by email. Put a form in front of the request instead: Tally, Fillout or an Airtable form, with required fields for working title, target keyword, primary audience, the one decision the reader should make differently, and the internal SME who has to sign off.

Then a Zap does five things on submission:

  1. Creates a record in your Airtable content base with status Brief received.
  2. Looks up the topic cluster in a small Airtable table mapping cluster to owner, and sets the assignee.
  3. Copies your brief template in Google Docs, renaming it 2026-10-14 — Working title — cluster.
  4. Fills the doc’s placeholder text with the form fields using Google Docs “Create Document from Template”.
  5. Posts into #content-briefs with the record link, the doc link, and the assignee’s @-mention.

Five actions, one task each, around 30 briefs a quarter on a team this size: roughly 150 tasks a quarter. The saving is about 18 minutes per brief of copying and chasing, so call it nine hours a quarter against a task cost you will barely notice.

The underrated part is field validation. A required-keyword field stops the brief that says “something about pensions” from reaching a writer at all, which is the kind of problem no amount of downstream automation fixes.

Build 2: asset filing, with a naming convention nobody has to remember

Assets arrive as attachments, in DMs, from designers who name files final_v3_ACTUAL.png. Build this one in Make, because file handling and routing are where it beats Zapier outright.

Watch a single Google Drive inbox folder. On a new file, the scenario parses the filename for a record ID prefix (writers type C-0481_hero.png), looks that record up in Airtable, then routes on file type: images to /Assets/Images/<cluster>/, PDFs to /Assets/Source/, anything else to /Assets/Misc/ plus a Slack nudge asking what it is. Before moving, it renames to your convention and writes the resulting Drive URL back into the record’s Assets field.

The filter on the image route looks like this in Make’s expression language:

{{contains("image/png,image/jpeg,image/webp"; 1.mimeType)}}
AND {{length(2.records) > 0}}

That second clause is the one people forget. Without it, a mistyped prefix produces a file filed against nothing, which is worse than an unfiled file because it looks done.

Build 3: the publication checklist as a machine, not a document

Checklists in Notion get skipped under deadline. Checks that run themselves do not.

When an Airtable record flips to Scheduled, a Zap creates the pre-publish subtasks in whatever your team already lives in (Asana, monday.com, ClickUp), assigned and due 24 hours before the slot. Then a second scenario, scheduled hourly in Make, takes every record with a publish date in the past and no QA passed flag, fetches the live URL over HTTP, and checks four things: response code, presence of a self-referencing canonical, meta description length between 70 and 155 characters, and at least two internal links to pillar pages.

Failures post as one message, not four:

#content-qa
Post-publish QA: 3 of 4 checks failed

/pensions-auto-enrolment-guide/
  ✓ 200 OK
  ✗ canonical points to /pensions-auto-enrolment-guide/?utm_source=newsletter
  ✗ meta description 189 chars (limit 155)
  ✗ internal links to pillar: 0 (minimum 2)

Record: airtable.com/app.../C-0512
Checked 14:00, next run 15:00

On a team publishing eight to twelve pieces a month, this catches two or three real defects a month that would otherwise surface in a quarterly audit, or never. Build time is an afternoon, mostly spent on the HTML parsing regex.

Build 4: one digest instead of fourteen pings

Stakeholder notification is where automation usually makes things worse. Wire Airtable’s every-change notification into Slack and you have invented a channel people mute in a week.

Invert it. A Make scenario runs Thursdays at 09:00, pulls every record modified in the last seven days, groups by stakeholder using the SME field from Build 1, and sends each person a single email covering only their items: what moved, what needs them, and the date it becomes late. Someone with nothing pending gets nothing, which is the feature.

Measured on one five-person agency team, inbound “where is my piece” messages dropped from around a dozen a week to two or three, and the two or three left were usually about scope rather than status. Operation cost is roughly 60 records plus 8 emails, so under 100 operations weekly.

Build 5: performance data that walks back to the content record

Your content inventory decays the moment you stop updating it by hand, and you will stop.

Schedule a Make scenario monthly. For every record with a publish date between 28 and 35 days ago, call the GA4 Run Report module for sessions, engaged sessions and average engagement time on that URL path, call Search Console for clicks, impressions and average position, then write all six values into fixed fields on the record alongside a 28-day snapshot taken date.

What you get after two quarters is a table you can sort, so the question “which cluster earns its keep” has an answer:

ClusterPiecesMedian 28-day clicksMedian position
Auto-enrolment921411.4
Salary sacrifice66123.8
Workplace ISAs41941.2

Three numbers like that kill more bad commissioning decisions than any strategy deck. The automation is not clever; it just refuses to forget.

The part everyone skips

Every scenario needs somewhere to fail loudly. In Make, attach an error handler route to each critical module ending in a Slack message to #automation-errors plus a Break directive with three retries at 15-minute intervals. In Zapier, switch on autoreplay and add a weekly reminder to actually open the Zap history, because autoreplay covers transient failures and hides persistent ones.

Then write a one-page runbook listing each build, its trigger, its owner, and what breaks downstream if it stops. Store it next to the content calendar, not in the automation tool. The failure mode for a small team is not a broken Zap, it is a broken Zap that only one person understood, three months after they left.

Start with Build 1 on Monday. Give it ninety minutes, a form with six required fields, and one Slack channel, then count how many briefs arrive in October without a keyword in them.