Zapier case study

In-app subscription changes mirrored to a user sheet and the right Mailchimp segment

Built white-label inside an Australian digital agency's Zapier workspace, for a subscription surf-forecasting app. One Zap receives user records from the app's Firebase backend, updates the user's row in a sheet and moves them between Mailchimp segments (free, monthly, yearly, expired) with their surfing profile, so campaigns follow the subscription. It is the workspace's busiest Zap: 240 runs from 22 Sep to 21 Oct 2026.

A subscription surf-forecasting appConsumer mobile appBuilt 20261 Zap for this client, in a 27-Zap agency workspace

runs, 22 Sep – 21 Oct 2026: 240
successful runs in that window: 195
tasks this period, about 95% of the workspace's: 842

The business

This work was delivered white-label, inside the Zapier workspace of an Australian digital agency that builds and runs WordPress and Gravity Forms sites for its clients. The agency is not named, and neither is its client. Each client has its own folder in the workspace; this page covers one of them, and the agency's other clients are written up on their own pages.

The app sells monthly and yearly subscriptions to a surf-forecasting service, with a free tier. User accounts and subscription state live in its Firebase (Firestore) backend; marketing email goes through Mailchimp, and a Google Sheet holds an export of every user.

Email has to follow the subscription: a free user who upgrades should leave the free segment, and a subscriber who lapses should stop getting paid-user emails. The backend posts user records to a Zapier webhook, and the Zap keeps the sheet and the mailing list in line with them.

Audited 21 Oct 2026. The agency's workspace holds 27 Zaps for several clients; the audit lists 1 in this client's folder, and it is on. Pro plan (annual), 750 tasks a month, resetting on the 22nd; this period's 750 plan tasks and 100 pay-per-task tasks are used up. Autoreplay off. Tasks are shown for the current period so far (22 Sep – 21 Oct) and the previous one (22 Aug – 22 Sep). Runs and errors are from Zap history for 22 Sep – 21 Oct: 254 run entries across the workspace.

What we built

Subscription state to mailing segment

One instant Zap that updates the user's row and swaps their Mailchimp tags by subscription state, with an error path for records it cannot process.

Instant13+ steps
User record to sheet row and Mailchimp segment
- Webhooks
- Google Sheets
- Formatter
- Paths
- Mailchimp
Trigger
Webhooks – Catch Hook, receiving user records from the app's Firebase backend
What it does
The user's row is found by user ID in the user-export sheet and updated (name, email, device, whether the subscription is valid, status, product, original purchase date, expiry and more), and the expiry date is formatted. Paths then route on subscription state: a valid monthly subscription removes the free-user tag in Mailchimp and adds or updates the subscriber with app-user, active-paid and monthly tags and merge fields for surf level, stance and expiry; a yearly one does the same with the yearly tag; further branches handle free and expired users.
The tricky part
A backend webhook drives a sheet update and tag swapping across subscription states, with the surfing profile carried into merge fields for personalised campaigns. Zapier's error-handling path catches records that fail.
Error handling
An error-handling path: 42 runs in 30 days ended as handled errors, caught by that path, and 3 errored unhandled. Autoreplay is off.
Usage
842 tasks (22 Sep – 21 Oct), 1,222 (22 Aug – 22 Sep), about 95% of the workspace's usage. 240 runs (195 successful, 42 handled errors, 3 errored) (22 Sep – 21 Oct).
Status
On, version 10, last edited 6 Sep 2026

What the counters show

240 runs from 22 Sep to 21 Oct 2026: 195 successful, 42 caught by the error path and 3 unhandled errors.
842 of the 886 tasks the workspace's Zaps have counted this period, and 1,222 of 1,289 in the previous one. That is this one Zap carrying about 95% of the workspace's use.
The workspace has used its 750 plan tasks and 100 pay-per-task tasks this period, so this Zap's volume is what sizes the agency's plan.

What we would change

This Zap takes the workspace past its plan: 842 of the 886 tasks counted this period, against a 750-task allowance. Every record spends tasks on the sheet lookup and update before Mailchimp is touched. We would have the backend post only when a user's subscription state changes, if it does not already, and size the plan to this Zap rather than to the allowance the workspace started on.
42 runs in 30 days end in the error path and 3 more fail outright, with autoreplay off. We would read the handled errors for a common cause and fix it upstream, and switch autoreplay on for the rest.
The paths decide monthly or yearly by whether the product name contains the word, so a product renamed in the app store would fall through to the wrong branch. We would route on a product ID or a plan field instead.
The agency's own task-usage alert Zap, meant to warn at 80% of the allowance, is off and built on deprecated apps, so nothing warned that the limit was close. We would rebuild it on current apps and switch it on.

Nothing was left out for this client: this is the only Zap the audit lists in its folder. The agency's own usage-alert Zap is not written up as a build; it is off and mentioned above.

Built with

Zapier
Firebase
Webhooks
Google Sheets
Mailchimp
Formatter
Paths

Next Zapier accountRefill reminders, self-rescheduling check-ins and a five-message drip, run from Airtable over SMSA US telehealth and prescription-medication provider

Page copy drafted with AI assistance. Skofi is accountable for it. Editorial policy

Start here

Have a Zapier account like this one?

We start by reading what is already there: every Zap, its counters and its failures. A short call is the fastest way to find out what yours needs.

Book a 15-minute call saveez@skofi.tech

What happens on the call

15 minutes, no deck
We map the process on the call
A written scope, or an honest no