This One AI Workflow Runs My Entire Business
One customer payment triggers a single n8n workflow — built entirely with Claude — that thanks the customer, stores their data, onboards them, unlocks their course in Moodle, books calls, and feeds the ad platform. Here is the whole thing, mapped out.
The Systems Summary
I don't have a big operations team running my back office — I have one n8n workflow, built entirely with Claude. The instant a customer pays, it fires: the customer gets a thank-you on WhatsApp, their details are stored in a central database, and then the workflow branches based on what they bought — course buyers get onboarding + an automatic Moodle unlock, service clients get a detailed intake form, and consultation bookings get a calendar invite. Every sale is also pushed to the ad platform via the Conversions API. One payment in, an entire business running itself out.
It All Starts With One Trigger: A Payment
The entire system hangs off a single event: a customer payment. When the payment succeeds, the payment gateway fires a webhook into n8n, and that one signal kicks off everything else. There is no dashboard I log into, no list I work through, and no "I'll get to it tomorrow." The workflow does in seconds what used to be a scattered checklist of manual tasks — and it does the same thing, flawlessly, at 3pm or 3am.
Pro-Tip
Anchor your automation to the most reliable event you have. A confirmed payment is perfect — it only fires for real customers, so every downstream action is safe to run automatically.
The Full Workflow, Mapped Out
Here is the actual shape of it: one payment at the top, fanning out into every outcome that keeps a customer happy and my business running. Click any node to see exactly what it does, which tools it touches, and why it matters:
One Payment → Everything Runs
A single n8n workflow, built with ClaudeThank-You on WhatsApp
What Happens
The moment a payment lands, the customer gets a warm thank-you message on WhatsApp. No waiting, no wondering whether it went through — the experience feels premium from the very first second, which is exactly the UX I want.
Details
Why It Matters
Payment clears at 11pm → the customer instantly sees "Thank you for your order! Here is what happens next…" on WhatsApp, with no one awake to send it.
The Smart Part: It Branches by What They Bought
Not every customer needs the same thing, so the workflow adapts. A few actions run for everyone, and the rest depend on whether they bought a course, booked a service, or booked a consultation. Here is exactly what fires for each:
| What They Bought | Runs for Everyone | Plus, Specifically for Them |
|---|---|---|
| A Course | WhatsApp thank-you + saved to database + Conversions API | Onboarding message for the Learn platform, and the course auto-unlocks in Moodle. |
| A Service | WhatsApp thank-you + saved to database + Conversions API | A detailed intake form to collect requirements before we start. |
| A Consultation | WhatsApp thank-you + saved to database + Conversions API | A dedicated calendar invite to self-book a slot with me. |
And I Didn't Hand-Code Any of It — Claude Did
Here is the part people find hard to believe: I am not an n8n expert, and I did not hire a developer to build this. Claude built it with me. I described what I wanted in plain English — "when a payment comes in, thank the customer on WhatsApp, save them to Supabase, and if it is a course, call the Moodle API to enrol them" — and Claude told me which nodes to use, wrote the Function-node code and the API calls, and helped me debug whenever something broke.
Whenever a node threw an error or a Moodle API response looked wrong, I pasted it back to Claude and it fixed it. So this "entire business in one workflow" isn't the work of an engineering team — it is one founder plus Claude, describing requirements and shipping them. That is the real unlock: the automation runs the business, and Claude is what let me build the automation.
Pro-Tip
Build it one branch at a time. Get the WhatsApp thank-you working end to end with Claude first, then add the database, then Moodle, then the Conversions API. Small, tested steps beat one giant workflow you can't debug.
