How We Fixed a Zapier Onboarding Bug That Was Silently Affecting Every AI Builder Purchase

If you’re running a paid program and relying on automation to onboard your buyers, one silent bug can quietly destroy trust — and you’ll never see an error to warn you. No alert. No crash. Just buyers who paid and heard nothing.

That’s exactly what happened with the AI Builder Program. Four buyers paid. Four got the wrong onboarding — or no meaningful onboarding at all. They didn’t receive a welcome to the right Basecamp project. Their Keap contact wasn’t created correctly. Some of them reached out to Dennis directly, days after paying, with zero communication from us. That’s the kind of first impression that kills programs.

The Zap never crashed. It just quietly processed the wrong person every time. Here is what caused it, how we fixed it, and what every automation builder should watch for before they go live.

What the Automation Was Built to Do

The goal was simple: when someone purchases the AI Builder Program through Stripe, the automation handles the rest without manual intervention.

Specifically, a successful payment should trigger:

• A Keap contact created or updated with the buyer’s email and name, tagged with IDs 1817 and 1821
• A Basecamp project created and named “HRI’s AI Builder: [Buyer Name]”
• The buyer and relevant team members added to that Basecamp project

No manual steps. No delays. Buyer pays, buyer gets onboarded.

This matters because onboarding is the first real experience a buyer has after handing over money. If that moment goes wrong — if they’re left waiting in silence with no welcome message, no project access, no next steps — it signals to them that they made a mistake. Getting this right is not optional.

What Actually Happened

The Zap was originally built and tested using a dummy account. During testing, the email, name, and Basecamp project ID were filled in manually as fixed values — and they were never swapped out for dynamic fields before the Zap went live.

So when real buyers started coming through, the Zap did exactly what it was told. It just wasn’t told the right thing. Every payment triggered the Zap correctly, but then:

• Keap created or updated the dummy test contact instead of the actual buyer
• Basecamp created a project named “HRI’s AI Builder: Test First Name Last Name” for every single purchase
• Steps 7, 8, and 9 tried to add people to the test project ID (6151531), which no longer existed in the right context — returning a “Not Found” error every time

The trigger worked. The logic worked. The data was just wrong from Step 2 onward, for all 24 buyers. None of them were added to the right project. None of them received the correct onboarding sequence. And because the Zap completed without failing, there was no indication anything was broken until someone noticed a buyer reaching out to Dennis days after paying — confused, unacknowledged, and frustrated.

The Fix: Replacing Hardcoded Values with Dynamic Tokens

The solution was to go into each affected step and replace the static test values with Zapier tokens that pull the real buyer’s information directly from the Stripe payment.

Step 2 — Keap (Create or Update Contact)

• Email field: now pulls from charge.billing_details.email
• First Name field: now pulls from charge.billing_details.name
• Tag IDs 1817 and 1821 were already set correctly and stayed

Step 3 — Basecamp (Create Project)

• Project name: changed from the hardcoded test name to HRI’s AI Builder: {{charge.billing_details.name}}

Steps 7, 8, and 9 — Basecamp (Add Person to Project)

• Project ID: changed from the hardcoded test project ID to {{Step 3 ID}}, so it always references the project just created for that specific buyer

The updated Zap was published as v3 and is now live.

How to Confirm It Is Working

Open the Zapier editor and check the following before considering this done:

• Step 2 shows Stripe token labels in the Email and First Name fields, not a hardcoded email or name
• Step 3 shows the project name as “HRI’s AI Builder:” followed by a Stripe token, not a static name
• Steps 7, 8, and 9 show a Step 3 token in the Project ID field, not a numeric ID
• The Zap toggle is ON and the version label reads “v3”

What Still Needs to Be Done Manually

Going forward, every new purchase will onboard the correct buyer automatically. The 24 buyers from the original batch are a different story — the Zap already ran for them with the wrong data, so they need to be onboarded by hand.

For each affected buyer:

• Create or update their Keap contact with tags 1817 and 1821
• Create their Basecamp project under the correct name: “HRI’s AI Builder: [Name]”
• Add the relevant team members to their project

What to Watch Out For in Your Own Zaps

This kind of bug is easy to miss because the automation does not fail — it succeeds, just with the wrong data. There is no error to catch, no alert to investigate. Everything looks fine until someone notices the wrong person was onboarded, or worse, until a buyer reaches out days later wondering why they never heard from you.

Before publishing any Zap that creates contacts, projects, or records tied to real users, check every field. If you see an email address, a name, or an ID typed directly into a field, it is hardcoded. Replace it with a token from the trigger before it goes live.

The broader lesson here is about the standard we hold ourselves to. Bugs happen. What separates a professional team from an amateur one is whether you document it, fix it fully, and build the habit of catching it before it ships — not only when someone reminds you. That’s what this article is: a record of what broke, how we fixed it, and a reference for next time.

The Zap will thank you. So will your buyers.