In short
One Make scenario that takes a content agency customer from sign-up to a booked shoot with no manual step in between. The sign-up form captures a contract e-signature, Stripe creates the customer and the subscription checkout, a welcome email carries a booking link scoped to the customer's area, and Cal.com holds the slot. Anyone booking without an active plan is marked Rejected, their slot is released through the Cal.com API, and they get an email explaining why. Airtable holds customers, bookings, creators and an event log used for deduplication and audit.
Project description
A content agency sold a monthly plan, then ran the rest by hand: chase the signed agreement, set up the payment, confirm the plan is active, and only then let the customer book a shoot. This build turns that chain into one Make scenario. Sign-up captures a contract signature, Stripe creates the customer and the subscription checkout, the welcome email carries a booking link for the customer's own area, and the booking is only accepted if the plan is live. Everything lands in Airtable, including an event log used both for deduplication and as the audit trail.
Tools & Deliverables
- A single Make scenario acting as an events hub, routed by event type, covering sign-up, payment, booking, creator onboarding and community join events
- Sign-up form with contract e-signature, stored against the customer record and served back through a webhook
- Stripe subscription flow in test mode: customer created, checkout session created, payment confirmed by webhook before any access is granted
- Cal.com booking with genuinely limited slots, two per day per location, and a private booking link scoped to the customer's area
- Rejection path for bookings with no active plan: marked Rejected in Airtable, the slot released through the Cal.com API, and the booker emailed
- Creator onboarding flow with an invite, reminders on day two and day five, a one-click join confirmation, and a Joined status that stops the reminders
- Airtable base with Customers, Bookings, Creators and Event Log, plus Python generators that rebuild every blueprint from field-ID maps
The problem
- The chain between "yes" and "booked" was all manual. Signed agreement, payment setup, plan confirmation and then booking, each handed between tools by a person, which is where the delays and the missed steps lived.
- Shoot slots are a real constraint. Capacity is two shoots a day per location, so a slot taken by someone without an active plan is not an admin annoyance, it is lost production capacity that day.
- A booking tool alone cannot check whether someone is paying. Cal.com will happily accept anyone with the link, so the plan check has to happen outside the calendar and then reach back into it.
- Cancelling a booking through the back door is harder than it looks. The public cancel endpoint expects a browser session, so releasing a slot programmatically needs the proper API version and headers rather than the obvious route.
- Creator onboarding leaks. An invite goes out, some people join, most forget, and without reminders and a join signal the list quietly goes stale.
- Platform limits shape the architecture. The account in use allowed two active scenarios and one data store, so a tidy design of six separate scenarios was not available.
Approach
Everything runs through one scenario that acts as an events hub. Each inbound event carries a type, and a router sends it down the right branch: sign-up, Stripe payment, booking, creator onboarding or community join. That shape was chosen for a hard reason rather than elegance, because the plan allowed only two active scenarios, and consolidating let the whole flow run inside the limit with the reminder schedule as the second. The event log in Airtable does the work a data store would normally do: every event is written there first, and deduplication is a lookup against it, so a replayed webhook cannot create a second customer or a second booking.
The gates matter more than the happy path. A sign-up is not a customer until Stripe confirms the checkout, so access and the booking link are only issued after the payment webhook lands, not when the form is submitted. A booking is not accepted because someone holds the link, it is accepted because the customer record shows an active plan at that moment. When it does not, the workflow does three things rather than one: marks the booking Rejected in Airtable, releases the slot through the Cal.com API so the capacity goes back on sale, and emails the person with a clear reason. The creator flow works the same way, with an invite, reminders on day two and day five, and a join signal that sets the status and stops the chase. Every blueprint is generated by Python from field-ID maps, so the entire build regenerates into a different Make organisation without rebuilding it by hand.
Solution
The recorded runs go end to end on a live build. A sign-up is submitted with a signature, the customer is saved, the signature is stored, and Stripe creates the customer and the checkout. Payment confirms, the welcome email arrives with a booking link scoped to that customer's location, and the booking is accepted and written back. Then the case that pays for the whole thing: a booking attempt with no active plan is rejected, the slot is released through the Cal.com API so it returns to availability, and the would-be booker is emailed. Each step writes a row to the event log, so the sequence can be audited after the fact rather than reconstructed from memory.
The build was also made portable on purpose. Airtable schema, Make blueprints and Stripe wiring are generated from Python scripts driven by field-ID maps, so moving the whole thing into the client's own Make organisation is a regeneration rather than a rebuild, with webhook URLs the only values that have to be updated afterwards. Stripe runs on test keys throughout, which is the right default for a demo and avoids the common mistake of wiring a live-mode connection into something still being tested.
FAQ
What stops someone without a plan taking a shoot slot?
The booking is checked against the customer record at the moment it arrives. No active plan means the booking is marked Rejected, the slot is released back through the Cal.com API, and the person gets an email. The calendar alone cannot enforce that, which is why the check sits outside it.
How is the contract signature handled?
It is captured on the sign-up form and stored against the customer record, then served back through a webhook when it needs to be displayed. That route was chosen because of a specific platform limitation in how attachment content can be reached, and it keeps the signature with the customer rather than in a separate system.
Why one scenario instead of one per flow?
Because the account allowed two active scenarios. Consolidating into a single hub routed by event type fit the whole build inside that limit and left the second slot for the reminder schedule. On a larger plan the same branches split out cleanly, with no change to the logic.
How do you detect a community join when the platform has no API?
Through the platform's own automation trigger forwarded to a Make webhook, with a signed one-click confirmation link in the reminder emails as a backup. Either path sets the status and stops the reminders.
How does this move to the client's own account?
The Airtable schema and every Make blueprint are generated by Python from field-ID maps, so the build regenerates into another organisation. After that, the webhook URLs in the pages and flows are the only values that need updating.
