Skip to content
BlackBadger

Case study. Education and training

The Business Academy

Industry
Education and training
What they were on
Keap CRM, Zapier, Google Sheets
Work
CRM, Integrations
Engagement
2025

The situation

The Business Academy runs training courses with Keap as the CRM and a large body of Zapier automations connecting it to Google Sheets and the rest of the stack, on the order of a thousand Zaps, built up over years, many on legacy and deprecated versions of their apps. The person who built most of them had left the company, and his Google account owned the connections. After his departure, things started breaking in ways nobody could trace. Course-progress fields in Keap were being overwritten, with records showing a course purchased or completed were flipping back to default. The team even created brand-new fields, and those started getting overwritten too. Worse, Zapier reported most of the runs as successful, because the Zaps were executing fine. They were just writing the wrong data. There was no clean audit trail of failures to follow.

What we built

The engagement was scoped as a CRM system design, with an honest adjustment once we looked inside. The system design could wait, because the immediate need was a diagnosis. So that is what the first paid work was.

Working live in the client's Zapier account, we traced the overwriting behavior to a search step matching records on a "contains" condition, which grabbed the first of several records sharing the same code and updated the wrong one. We also worked through the failing Google Sheets connections and found the structural cause, connections and spreadsheets owned by the departed employee's account, which testing would report as connected while edits silently failed.

The fix we recommended, and walked the client through setting up on the call, was structural rather than another patch, a dedicated integrations account, owned by the company, with admin access to Zapier and edit access to every sheet the automations touch. Every connection gets re-credentialed to that account, so no future departure can orphan the stack again.

What changed

The mystery had an explanation, which is worth more than it sounds after fields kept changing themselves. The client left with the specific Zap responsible identified, the connection failures understood, and a company-owned integrations account created during the call to hold everything going forward. The larger system design, covering the audit and redesign of the automation estate, was deferred by agreement rather than sold before it was needed.

What we would do today

A thousand Zaps maintained by memory is not an automation strategy, it is an inheritance. Given the same situation now, we would propose replacing the accumulated Zapier layer with a small owned system where course progress, contacts, and enrollment logic live in one database with one audit log, so a record changes only when something with a name and a timestamp changes it. The diagnosis and the ownership fix stand on their own. The owned build is what makes this class of failure structurally impossible.

The services behind this build

Where this work comes from

If your automations are held together by an ex-employee's login, book a strategy call before the next one breaks.

A strategy call is a conversation about your work, not a pitch. If a build is not the right answer, you will hear that first.

No newsletter, no drip sequence. One reply from a person.