How to Build a Booking and Scheduling System: Slot Engine, Deposits and Cutting No-Shows

A physiotherapy clinic with four therapists was taking close to 60 phone calls a day, almost all of them reschedules. We measured for two weeks before scoping the project: an average of 11 double-booked slots and 9 no-shows per week, which works out to roughly NT$54,000 of sellable capacity evaporating every month. A booking and scheduling system is not "a form on a page." Its real job is to treat time slots as inventory.

Good Fit vs. Poor Fit

Build a custom booking system when:

• Your resource splits into fixed slots: treatment rooms, classrooms, courts, technician hours
• Only one person can hold a slot, so overselling causes a real-world collision
• You need a deposit or prepayment to suppress no-shows
• You run multiple locations and staff, each with different shift and leave rules
• Booking is followed by check-in, service records and follow-up reminders

Don't spend the money when:

• You take fewer than 5 bookings a day with one provider — a Google Form plus a calendar is enough
• Every job needs a manual quote before it can be scheduled, such as a site survey
• You only collect leads and never hold a slot — that is a form system, not a booking system
• Your existing HIS or POS already has a booking module and you only lack a front end

Alternatives Matrix

The rule of thumb: once a single slot must bind two or more resources at the same time (therapist + equipment + room), packaged products almost always break down. That is the point where a custom build pays for itself.

Six-Week Build: Stages, Deliverables, Tools

Two-way calendar sync is consistently underestimated. Google Calendar API defaults to 10,000 requests per minute per project, 600 per minute per user, and 1,000,000 per day. The quota itself is generous, but you should push with webhooks rather than polling.

Real Cost Breakdown

• Build: NT$120,000–180,000 for one location and one resource type; NT$220,000–350,000 for multi-location with deposits and check-in
• Payments: ECPay standard merchants pay 2.75% on credit cards (minimum NT$5), 1% on ATM virtual accounts (minimum NT$15), and NT$31 per convenience-store code, all before 5% business tax
• SMS: Twilio charges about US$0.0842 per message to Taiwan numbers — roughly NT$2,700 for 1,000 messages a month; LINE push is materially cheaper
• Hosting and domain: NT$800–3,000 per month; SSL is free with Let's Encrypt
• Hidden costs: 8–16 hours of front-desk training, NT$15,000–40,000 of legacy data cleanup, plus rule tuning in the first three months after launch

Reality vs. Client Expectation

Six Traps and How to Avoid Them

• Concurrency oversell: lock at the database layer inside the transaction (SELECT … FOR UPDATE) plus a unique index, not by greying out a front-end button
• Time-zone drift: store UTC everywhere and convert only at render time
• Wrong reminder timing: a single 24-hour reminder underperforms; send at 24 hours and again at 2 hours
• Policy outside the system: encode "no deposit refund within 24 hours" as a rule, not as something the front desk explains verbally
• Slow on mobile: booking traffic is mostly mobile, so keep LCP at 2.5 seconds or less, measured at the 75th percentile, and serve availability from cache
• Front end only: if staff cannot reschedule and back-fill quickly, they revert to paper and the system dies

Success Metrics and the First 90 Days

• Day 30: share of bookings made online (target 30%+), funnel completion rate, P95 latency on the availability API
• Day 60: no-show rate, reschedule rate, deposit capture rate; tune slot length and buffers, A/B test reminder copy
• Day 90: repeat-visit rate, visits per customer per year, peak utilisation; add an automatic waitlist so cancelled slots resell themselves

Decision Checklist

• ☐ More than 15 bookings a day?
• ☐ Two or more resources checked together?
• ☐ Double bookings cause real loss?
• ☐ Deposit needed at booking time?
• ☐ Multiple sites or differing shifts?
• ☐ No-show rate already above 10%?
• ☐ Invoicing or member data integration?
• ☐ Need your own data for remarketing?
• ☐ Packaged tools already blocking you?
• ☐ Someone owns shift maintenance?
• ☐ Can you accept a 5–8 week build?
• ☐ Budget above NT$150,000?

Seven or more ticks and a custom build typically pays back in 9–15 months. Fewer than five, run on SaaS for six months first.

FAQ

How long until launch?

Around 4–5 weeks for a single location and resource type, 6–8 weeks with deposits and check-in across multiple sites. Most of that time goes into rule inventory and legacy data cleanup, not coding.

Do deposits really cut no-shows?

In our projects, a NT$200–500 deposit combined with two-stage reminders usually pulls no-shows into single digits. The refund and reschedule policy has to be stated in the confirmation email, not just on the page.

Can it integrate with Google Calendar or LINE?

Yes. The usual pattern writes each confirmed booking into the staff member's Google Calendar and pushes reminders through a LINE Official Account. Use webhooks rather than scheduled polling.

Is it painful to add features later?

Not if the slot engine, resources and rules are layered separately from day one. Waitlists, package deductions and cross-store referrals then extend the existing model instead of rewriting it.

Next Step

ScriptWalker's Booking & Scheduling System Build starts at NT$120,000, covering rule inventory, the slot engine, payment and notification integration, admin tooling and staff training. Book a free 30-minute consultation and we will map your shift rules and resource conflicts first.

• Email: [email protected]
• Phone: 0916-224-047
• LINE: @ufv9089p