SAM sells 60-seat leadership cohorts at two prices, one for subscribers and one for everyone else. Registration now enforces both, the seat cap enforces itself, and every paid row still lands in the programs desk’s Google Sheet with the formulas intact.
Ski Area Management (SAM), the leading trade publication for the mountain resort industry, runs The Summit Series. It is a highly regarded, paid leadership program for resort general managers and operations professionals, offered as Fall and Spring cohorts, or a full-year bundle.
Historically, their registration path was a Wufoo form patched into a Google Sheet that the operations desk lived in every day. Wufoo, a payment link, a Zapier hop, and a sheet will get the first cohort sold. It’s the second year that hurts. The setup suffered from the classic failure modes of decoupled systems: people claiming a subscriber discount without an active subscription, hard seat caps being manually monitored to prevent overselling, and automated sheet writes stomping over the COUNTIF and revenue formulas the ops team relied on to run the program.
We had three jobs: make the price match the buyer, make the seat count real, and get the row into the sheet without breaking it.
The Pricing Integrity Problem
When you sell an event or a cohort program, you often offer two prices: one for active subscribers, and one for everyone else.
In a disconnected form builder, enforcing that pricing difference usually devolves into an honor-system checkbox: “Are you a current subscriber?” If the user clicks yes, they get the discount. The back office then has to reconcile the registration list against the circulation database by hand, chasing down the difference from people who claimed a discount they weren’t entitled to, or issuing refunds to subscribers who forgot to check the box.
Pricing has to be deterministic, not self-reported.
We wired the Gravity Forms registration path directly into SimpleCirc, SAM’s circulation management platform. The workflow requires the buyer to be signed in. At the moment the form renders, the system queries SimpleCirc for the user’s active access tier.
If they hold an active subscription, they see the $149 cohort price. If they don’t, they see the $199 non-subscriber price. That price is locked in at render, validated on submission, and charged by Stripe. There is no Y/N checkbox to game, and no post-sale reconciliation required from the ops desk.
If a discount can be self-reported, it will be.
Enforcing the Seat Cap
Cohorts are valuable because they are limited. The Summit Series caps each cohort at 60 seats.
When your seat ledger is a Google Sheet populated by Zapier, enforcing a hard cap is a manual process. You watch the row count creep toward 60, and then you have to manually pull the form down before someone else buys a seat. If someone cancels and you issue a refund, you have to remember to open the form back up for exactly one more sale.
We moved the seat ledger into WordPress, tying it to a custom Programs post type. WordPress holds the seat count for the Fall series, the Spring series, and the bundle.
The complexity here isn’t just counting to 60. The complexity is handling the edge cases, specifically around refunds.
If a buyer requests a refund, the seat needs to be released back into inventory. But business logic dictates that only a whole refund frees the seat. If the publisher issues a partial refund (perhaps to resolve a customer service issue or apply a post-sale discount), the buyer still holds the seat, and the inventory count must not increment.
We wired the system to listen for Stripe’s webhook events. When a refund clears, we check whether the refund was full or partial. If it’s a full refund, the seat is released automatically, opening up inventory for the next buyer without any intervention from the desk.
Only a full refund should free inventory — partial refunds are almost always a service gesture, not a cancellation.
Writing to the Ledger Without Stomping It
The most critical requirement of the build was also the most fragile: the data had to land in the existing Google Sheet.
When publishers use generic Zapier integrations to append rows to a spreadsheet, they quickly discover that the integration doesn’t understand the context of the document. If the ops team has added a column with a complex revenue formula or a VLOOKUP against another tab, a naive row append will often overwrite those cells, breaking the sheet for everyone.
To fix this, we bypassed third-party integration platforms entirely and built a direct Google Sheets service account integration that is explicitly aware of the workbook’s schema.
When a paid registration lands, the system doesn’t just blindly append a row. It reads the headers of the target sheet and maps the incoming data accordingly (translating the form’s “Ski Area” field to the sheet’s “company” column). It also identifies which columns contain formulas and intentionally skips them during the write operation.
We also handled the nuances of how Google Sheets parses data from external APIs. For example, if a checkbox field is left empty on the form, writing an empty string to the sheet can sometimes cause the row to be read incorrectly by downstream processes that expect unformatted values. We ensure that boolean values are written explicitly as integers (1 or 0), so empty rows stay empty and the ops team’s COUNTIF formulas behave exactly as expected.
Before you append to someone’s workbook, find out which columns are formulas.
The ghost registrant
In any system that handles money, provisioning, and third-party API writes, you have to design for the race condition.
What happens if a user buys a seat, but immediately issues a chargeback or requests a refund before the background cron job has a chance to provision their SimpleCirc subscription and write their row to the Google Sheet?
If the system is naive, the cron job wakes up, sees a completed order in the queue, provisions the subscription, and writes the row to the sheet. The ops desk now has a ghost registrant—someone who hasn’t paid, but holds a provisioned seat and appears in the ledger.
To prevent this, the provision and sheet-write jobs operate under a strict lock. Before they execute, they re-verify the payment status against the local ledger and Stripe. If a refund has landed in the intervening seconds, the job stops before minting access, and no row is written to the desk’s sheet.
Time and Money
When you eliminate the duct tape, the business case becomes clear. Under the old setup, the recurring SaaS glue cost roughly $639 a year to maintain—$399 for an annual Wufoo Professional plan, and $239.88 for a Zapier Pro plan to connect it to the sheet.
Because SAM already runs WordPress and Gravity Forms, the new setup carries zero incremental SaaS fees. The payment processing fees remain identical: charging 60 seats at the $149 subscriber rate incurs about $277 in Stripe fees under either system.
But the real cost of a disconnected registration flow isn’t the software; it’s the labor. As an illustrative estimate, if the operations desk spends just 10 minutes per registration manually checking subscriber status, fixing sheet rows, tracking the seat count, and cleaning up refunds, that’s 20 hours of manual reconciliation per year across 120 seats. At an assumed $35 an hour, that’s $700 of staff time spent patching the gaps between Wufoo and Google Sheets.
The Outcome for the Publisher
By migrating The Summit Series off Wufoo and into a tightly integrated WordPress and Stripe stack, SAM eliminated the manual toil of running a paid cohort. The public registration path matches the marketing copy. The pricing is deterministic and tied to real subscriber status. The 60-seat cap enforces itself, gracefully handling refunds and inventory counts.
The data lands in the Google Sheet the ops team already trusts, with every formula intact. There’s one place to look when something goes wrong, and it’s the site they already log into.
The sheet still runs the program. It just doesn’t need someone babysitting the front door.