How much to charge for a booking system
How much to charge for a booking system comes down to one question: what does an empty or missed appointment cost this business, and how much time goes into filling the calendar today? A salon, a clinic, a studio or a rental business does not want a calendar. It wants fewer gaps, fewer no-shows, and nobody stuck on the phone moving bookings around. Price the build on a share of that value, add lines for payments, scheduling rules and each system it connects to, and quote a monthly plan for upkeep. Do not price it on the number of pages or on hours.
Booking systems are good work to sell with Claude Code because a working first version comes together fast. You can show a client their own services, staff and time slots early. The trap is that a booking page looks done the moment someone can pick a time. The hard part is everything behind it: double bookings, time zones, cancellations, refunds, and the owner's rule that one service needs a specific room. That is where the unpaid work hides if you priced the screen.
Should they buy a booking tool instead?
Ask this before you quote anything. Plenty of businesses are well served by an off-the-shelf scheduling tool, and if one fits, telling the client so builds more trust than any proposal. I would rather lose that build and keep the client for the next one.
A custom booking system earns its price when the business has rules those tools handle badly. Bookings that need a specific person and a specific room at the same time. Prices that change by day, season or customer type. Packages and memberships that use up sessions. Deposits that depend on the service. A booking flow that has to sit inside their existing site, app or customer records. When you hear those, you are not pricing a calendar. You are pricing their rules, and that is where the value sits.
The CCC Booking Quote
Five parts of a booking system quote
| Part | What it prices | Question to ask the client |
|---|---|---|
| Base build | The admin time and lost bookings it fixes | How do people book today, who handles it, and how often do slots go empty or people not show up? |
| Payments and deposits | Taking money at booking, deposits, refunds and cancellation rules | Do you take payment or a deposit up front, and what happens when someone cancels late? |
| Scheduling rules | Staff, rooms, equipment, locations, buffers and opening hours | What has to be free at the same time for a booking to work? |
| Connections | Each calendar, reminder channel or system it syncs with | Where do bookings need to show up, and how should customers be reminded? |
| Keep plan | Monthly checks, fixes and small changes | What happens if bookings stop coming through on a Saturday? |
Base build. Work out what booking costs the client today: the hours someone spends answering calls and messages to book and move appointments, and what an empty slot or a no-show is worth to them. Price the build at a fraction of one year of that value, so they can see it pay for itself.
Payments and deposits. Taking money is its own line, because it brings refunds, partial refunds, failed payments and cancellation rules with it. Deposits are often the feature that cuts no-shows, so this line is easy to justify. Any payment key lives on the server, never in the page, and the client's payment account is in their name, not yours.
Scheduling rules. This is the line builders forget and clients never mention until launch. Ask what has to be free for a booking to work: a person, a room, a piece of equipment. Ask about buffers between appointments, different hours per location, and time zones if customers book from elsewhere. Every rule is a place for a double booking, so price them on what you find.
Connections. Each outside system is its own line: staff calendars, email or text reminders, their CRM or customer list. Each one has its own access and its own way of changing. If the bookings need to land in customer records, how to build a CRM with Claude Code shows what that side involves.
Ask these before you quote
- Walk me through one booking from first message to the appointment. Every step they describe is a step the system has to handle.
- What happens when someone cancels or moves a booking? Late-cancel rules and refunds change the payments line.
- Who can book what? Customers booking themselves, staff booking for customers, and admins overriding the rules are three different jobs.
- Where does it live? On their current website, in an app, or as a standalone page. Settle it before you quote.
- Who owns the accounts? Payment, email and hosting should be in the client's name, so the system keeps working if you part ways. How to hand off a Claude Code project covers the checklist.
More questions that save a bad quote are in client discovery questions before you quote.
Always quote the Keep plan
A booking system is live revenue. When it breaks, the business finds out from an angry customer at the front desk, or from a quiet weekend that should have been full. Reminder services change, calendar connections expire, payment settings get updated, and the owner adds a new service with a new rule.
Quote a monthly plan in the original proposal. Say what it covers: checking bookings and payments go through, fixing breaks when a connected service changes, keeping access current, and small changes like new services or new hours. Say what it does not cover: new locations, new payment types and new features, which are quoted separately. How to price a maintenance retainer covers the structure. Few clients argue with paying to keep the thing that fills their calendar working.
How to present the booking system quote
- Lead with the outcome in their words. One line on fewer phone calls and fewer empty slots, then the price.
- Itemize it. Base build, payments and deposits, scheduling rules, each connection, then the Keep plan. Itemized quotes get trimmed, not rejected.
- Gate payments on proof. A deposit to start, a payment when real test bookings and payments go through end to end, and the final payment once customers are booking live. How to structure milestone payments for an AI project covers the schedule.
- Write the rules into the proposal. A short list of the scheduling, cancellation and refund rules, signed off by the client, ends the "it should have known that" argument before it starts.
And skip hourly. Claude Code makes the build fast, so hourly pricing turns that speed into a pay cut. I covered why in why I stopped charging hourly for AI builds. If the client's team mostly needs to manage work inside the tool rather than take bookings, how much to charge for an internal tool is the better guide.
Short, practical drops on skills, MCP, agents, prompts, and more. No spam, unsubscribe anytime.
Frequently asked questions
How much should I charge for a custom booking system?
Price it on what it fixes: the admin hours spent booking by hand, the empty slots and the no-shows. Charge a fraction of one year of that value for the build, add lines for payments, scheduling rules and each connection, and quote a monthly plan for upkeep.
Should I build a custom booking system or recommend an existing tool?
If an off-the-shelf booking tool fits the business, recommend it. A custom build is worth it when the business has rules those tools handle badly, like bookings that need a person and a room at once, packages, or pricing that changes by day or customer.
Should I charge a monthly fee for a booking system?
Yes. Bookings are live revenue, and reminders, calendar connections and payment settings change over time. A monthly plan covers checking bookings and payments go through, fixing breaks and small changes like new services or hours.
Should payments and deposits be priced separately?
Yes. Taking money brings refunds, failed payments and cancellation rules with it. Put it on its own line so the client can see what it costs and choose to start without it if needed.
Should I charge hourly for a booking system?
No. Claude Code makes the build fast, so hourly pricing punishes you for that speed. Price on the value of the bookings and admin time it fixes, with each part itemized.
Last reviewed by Duncan Rogoff on October 11, 2026
