Brooke Wright
Brooke Wright · @wright_mode
FREE KIT

Stop renting your booking system

The 20-minute Cal.com setup done properly (buffers, Stripe, timezone traps) — plus the four prompts I'd use to have Claude build a booking page you own, with holds, payments and confirmations.

Cal.com walkthrough4 build promptsLaunch checklistBuilt by Brooke
Something went wrong. Please try again.

No spam. Unsubscribe anytime.

4 prompts that get Claude to build your booking system Jump to the prompts → Join the Membership
Wright Mode — Free Resource

The Booking System Kit

Set up Cal.com properly in 20 minutes — or use four prompts to have Claude build you a booking system you own outright.

Cal.com walkthrough included4 copy-paste build promptsNo code, no developerStripe payments covered

What's inside

1Should you even build it?2Cal.com in 20 minutes3Build your own with Claude (4 prompts)4The booking page checklist

First: should you even build it?

Honest answer: most people should start with Cal.com — it's free for the basics and takes about 20 minutes. Build your own with Claude when you want a flow no booking tool offers, or you're done paying per-seat fees for something you could own. This kit gives you both paths properly.

Take the Cal.com path if…

You need bookings working today. Standard flow (pick a time, maybe pay, get an invite) fits. You'd rather configure than maintain. The free tier covers one event type and calendar sync — genuinely enough for most service businesses.

Build with Claude if…

You want a custom flow — like holding a spot for 24 hours while payment comes through, deposits, or booking bundled into your own site. You want no monthly fee, no per-booking cut, and changes that cost a sentence, not a support ticket. I built mine this way — calendar, payment step, confirmations, the lot.

Path 1: Cal.com in about 20 minutes

1

Account + calendar sync

Sign up free at cal.com, connect your Google Calendar so booked slots block out and clashes can't happen.

2

Create your event type

One offer, one event type: name it what the client buys ("Strategy Session — 60 min"), not "Meeting with Me".

3

Availability + buffers

Set your real windows, then add a 15-minute buffer either side so back-to-backs can't happen. Check the timezone on the event is YOURS — this is the number one embarrassing mistake.

4

Paid sessions: connect Stripe

In Cal.com's app store, install the Stripe app and set the price on the event type — payment happens at booking, no invoicing dance.

5

Limits + questions

Cap bookings per day so one link can't eat your week, and add one booking question: "What do you want help with?" — you'll walk in prepared.

6

Share it

Use the direct link in your bio, DMs and email signature — or embed it on your site. Test it from your phone first, as a client, in a different timezone if you can.

Path 2: build your own with Claude

Four prompts, in order, in Claude Code or Claude Cowork. You describe, Claude builds, you test like a client, then it goes live on a free Vercel plan. You never write code — you have conversations about code someone else maintains (that someone is Claude).

1

The interview-first build prompt

Paste into Claude Code (or Claude Cowork). It interviews you about your offer and availability BEFORE it builds — so you get your booking flow, not a template.

I want to build my own booking page instead of paying for booking software. Act as my developer and interview me BEFORE you build anything. Ask me, in small groups: What I'm selling (session name, length, price, free or paid) My availability windows and timezone How much buffer I want between bookings Whether payment happens at booking (Stripe payment link) or after How long a booked spot should hold while someone pays (I suggest 24 hours) What the confirmation email should say Where this will live (my own domain or a free hosted URL) Then build the simplest working version: one mobile-first page where a client picks a time, the spot holds, payment happens through my Stripe link, and a confirmation email goes out. No accounts, no dashboard, no features I didn't ask for. Explain what you built in plain English as you go — I am not a developer and I will be maintaining this by asking you, not by reading code.
2

The change-anything prompt

This is how you maintain software you own: describe the change like you're texting a friend.

Here's what I want changed. Treat this like a text from a friend, not a ticket: [DESCRIBE THE CHANGE IN NORMAL WORDS — e.g. "the times show in the wrong timezone", "make the confirm button coral", "add a question asking what they want help with"] Make the change, show me the result, and tell me in one sentence what you did. If my request would break something (double bookings, payment issues), tell me BEFORE you change it.
3

The test-like-a-client prompt

Run this before you share the link with a single soul. Timezones and double-bookings are where booking pages embarrass you.

Walk me through testing this booking page like a real client would use it, step by step. Cover at least: Booking a slot from my phone Whether the timezone shows correctly for someone in a different city What happens if two people try to book the same slot What happens when a hold expires without payment Whether the confirmation email arrives and reads correctly What a client sees if I'm fully booked Tell me exactly what to click for each test and what I should see if it's working. List anything that failed with a plain-English explanation of the fix.
4

The go-live prompt

Vercel's free plan hosts it; your domain makes it yours. Claude walks you through both.

Deploy this booking page for me on Vercel's free plan and connect it to my domain. Walk me through every step, including what to click in Vercel, what DNS record to add and where, and how long it takes to go live. Then give me a one-paragraph maintenance guide: how I ask you for changes later, and how I check everything still works after a change.
The flow I built for my own bookings

Client picks a time → the spot holds for 24 hours while they pay through Stripe → paid bookings lock in and the confirmation goes out → unpaid holds quietly expire and the slot reopens. Book-first with a hold means the client commits to a TIME while the decision is hot, and payment follows — ask Claude for exactly this flow in prompt 1 if you want it.

The booking page checklist

Whichever path you take, don't share the link until every box is ticked:

1

The offer is named for the client — what they get, how long, what it costs.

2

Timezone verified — booked a test slot from your phone and the time was right.

3

Buffers exist — you cannot be booked back-to-back all day.

4

Payment tested with a real card — and refunded yourself after.

5

Confirmation email reads like you — not like software.

6

Cancellation line exists — one sentence on what happens if they can't make it.

One rule: one offer, one link. Don't give a new client five event types to choose from — decision fatigue kills bookings. Add more once the first one is earning.

Ready to go deeper?

Take your skills to the next level with these resources.

Community + Training

Wright Mode Membership

Join a community of women entrepreneurs implementing AI and automation in their businesses. Live calls, templates, and ongoing support.

Learn more →
Workshop Replay

Claude Masterclass

Learn how to use Claude like a pro. From prompting fundamentals to building real workflows that save hours every week.

Watch now →
Next Level

Claude Code Masterclass

Go beyond the chat interface. Build automations, process data, and create tools with Claude Code — no developer experience needed.

Explore →