A hair salon with four stylists and two wash stations took every booking through one-to-one LINE chats. In peak season the front desk answered 80 messages a day, averaging 3 minutes 40 seconds per reply. Three months of records showed an 18% no-show rate, two to three double-booked slots a week, and 12% of calls missed. The owner's brief was one line: "Build us an online booking form, budget NT$30,000." The form really does take three days. The hard part is whether the same slot can be sold twice, and who absorbs the cost of a no-show.
Who should build one, and who should not
A custom booking system is worth it when:
- Service durations vary (a 60-minute cut, a 150-minute colour), so fixed grid slots do not fit
- One booking must lock two or more resources: stylist plus wash station, doctor plus room plus equipment
- You take 200+ bookings a month and lose over NT$200,000 a year to no-shows
- You need deposits, or need to sync with existing membership data or a POS
Stick with off-the-shelf tools when:
- One person, one service, fixed duration — the free Calendly tier is enough
- Under 50 bookings a month, so manual replies still cost less than a subscription
- No deposits and no integration with any existing system
- Your operating rules still change every two weeks — do not encode an undecided process
Four routes compared
| Approach | Upfront cost | Main limitation | Who it suits |
|---|---|---|---|
| Google Forms plus manual scheduling | NT$0 | No real-time blocking; duplicates caught by eye | Under 50 bookings a month, single service |
| SaaS platforms (Calendly, Cal.com, SimplyBook.me) | US$12–60 per user per month | Weak multi-resource dependency and Taiwan payment support | Consultants, coaches, solo studios |
| LINE Official Account plus a booking add-on | NT$1,500–5,000 per month | Your data sits with the vendor; hard to reach a POS | All customers on LINE, simple rules |
| Custom booking system | From NT$180,000 | Needs 6–9 weeks and an internal owner | Multi-resource, deposits, existing integrations |
The SaaS saving is real, and so is the trade-off. Most platforms assume one person equals one calendar, so the moment a booking occupies both a stylist and a wash station somebody patches it by hand. Taiwanese card acquiring and e-invoicing need separate wiring too.
The full pipeline: six to nine weeks
- Stage 0 — Resource modelling (3–5 days) — Deliverables: resource inventory, service-to-resource matrix, buffer time table, exception calendar. Tools: Notion, Miro. Skip it and you rebuild stage 1.
- Stage 1 — Availability engine (2–3 weeks) — Deliverables: slot algorithm, concurrency lock design, recurrence rules. Allocation locks the resource row inside the transaction: MySQL's SELECT ... FOR UPDATE takes an exclusive lock so no other transaction can read or write those rows until commit. That one line kills double bookings.
- Stage 2 — Front-end flow and calendar sync (1.5–2 weeks) — Deliverables: Figma high-fidelity screens, mobile flow, two-way sync. One Google Calendar freeBusy query covers up to 50 calendars and returns busy intervals only, so private event details stay hidden. Use the RRULE syntax from RFC 5545 instead of a custom format.
- Stage 3 — Notifications and reminders (1 week) — Deliverables: confirmation, 24-hour reminder, change and cancellation notices. LINE Messaging API push, SMS fallback, SendGrid for email.
- Stage 4 — Deposits and cancellation policy (1–1.5 weeks) — Deliverables: deposit rules, automatic slot release on expiry, refund flow. ECPay or TapPay for acquiring.
- Stage 5 — Parallel go-live (2 weeks) — Deliverables: two weeks of paper-versus-system reconciliation reports, front-desk SOP, recorded staff training.
What it really costs
- Custom build (single site, 3 resource types, deposits included): from NT$180,000; multi-branch NT$280,000–450,000
- Front-end interface design in Figma: NT$25,000–50,000
- LINE Official Account mid-tier: NT$800 per month for 3,000 broadcast messages, overage extra (official plan page)
- SMS reminders: NT$0.7–0.9 each; 300 bookings a month at two messages each is about NT$500 per month
- Payment fees: ECPay's standard credit card rate is 2.75% before tax, roughly 2.89% with VAT, plus a per-order processing fee
- Hosting, backup and monitoring: NT$1,200–3,000 per month (Cloudflare, UptimeRobot)
- Annual maintenance: NT$36,000–72,000 per year
Three costs are almost always missed: payment fees are not returned when you refund a deposit, opening extra peak-season slots takes consulting hours, and an expired calendar authorisation nobody notices costs a reconnection engagement.
What clients expect vs what happens
| Client expectation | What actually happens |
|---|---|
| It is just a form, two weeks to launch | The form takes three days; the availability engine and concurrency control take five weeks |
| No-shows drop once bookings move online | Without deposits and reminders the rate only falls from 18% to 15%; deposits get it under 6% |
| The slot rules can be explained once | "Does a colour job block two assistants?" takes four rounds — an operations decision, not a technical one |
| Customers will fill in every field | Mobile flows longer than three steps lose 30%; fewer fields means higher completion |
Six traps and how to avoid them
- Double booking: two people submit in the same second. Lock the resource row inside the booking transaction and add a unique index as the last line of defence.
- Forgotten buffer time: cleaning and handover are unscheduled, so everything runs late from the third appointment on. Model buffer as a resource attribute, not a note.
- Unmodelled resource dependency: locking the stylist but not the wash station guarantees a peak-hour collapse. One booking must lock several resources.
- Cancellation policy outside the system: "free cancellation 24 hours ahead" is never enforced by hand. Encode the threshold and auto-release the slot with a forfeited deposit past it.
- A single reminder: sending only at booking time means the customer has forgotten. Confirm on booking, remind at 18:00 the day before, with a one-tap reschedule link.
- One-way calendar sync: a stylist blocks leave in their phone calendar and the system keeps taking bookings. Subscribe to change webhooks and keep manual block-out as fallback.
Success metrics and the 90-day roadmap
- Days 1–30: online bookings at 35% or more; zero double bookings; mobile booking page LCP within the 2.5-second good threshold web.dev recommends; establish the no-show baseline.
- Days 31–60: online share above 55%; reminder delivery above 95%; no-shows below 10%; start tracking fill rate by time slot to find the genuinely empty bands.
- Days 61–90: online share above 70%; no-shows at or below 6% once deposits are live; waitlist auto-fill above 30%; use fill-rate data to reshape hours and staffing, and budget next year's maintenance.
Decision checklist: should you build one now?
- ☐ You already take more than 200 bookings a month
- ☐ The front desk spends over an hour a day on booking messages
- ☐ One booking needs to occupy two or more resource types
- ☐ You can calculate your no-show rate for the last three months
- ☐ You have decided whether to take deposits, and how much
- ☐ The cancellation and reschedule policy is written down
- ☐ Buffer and cleaning times have concrete numbers, and closure rules are listed
- ☐ One internal owner can answer rule questions within two weeks
- ☐ Staff will maintain their availability on a mobile admin view
- ☐ Any system you need to integrate with has a confirmed API
- ☐ At least NT$36,000 a year is budgeted for maintenance
FAQ
Why not just use Calendly or a similar tool?
For one person, one service and a fixed duration it is genuinely the better deal. Three things break it: a booking that must lock several resources, taking deposits and issuing invoices in Taiwan, and reconciling with membership data or a POS. Hit two and the manual patching cost exceeds the price gap within six months.
Do deposits actually reduce no-shows?
Yes, with three things in place: a deposit at 20–30% of average ticket value, a cancellation threshold the system enforces automatically, and a previous-day reminder carrying a one-tap reschedule link. A deposit without a reminder just feels like a penalty and depresses repeat visits. Run a reminder-only month first for a baseline.
Should the booking system be a mobile app?
Almost never. Booking is low-frequency; nobody installs an app for ten haircuts a year. Build a responsive web flow and drive traffic from the LINE Official Account rich menu — zero install friction, and conversion is usually an order of magnitude better. Only customers returning twice a week justify evaluating native.
How long before results show?
Online share usually reaches 35% in month one, simply by replacing canned LINE replies with a booking link. Meaningful movement on no-shows takes about 60 days, because reminder effects need a full return-visit cycle. Real revenue change arrives after day 90, from using fill-rate data to reshape staffing and hours.
Next step
ScriptWalker's online booking system build starts at NT$180,000 and covers resource modelling, the availability engine, two-way calendar sync, LINE and SMS reminders, and deposit payment integration. Multi-branch versions are scoped separately, and we also take one-off diagnostics on existing systems. For the resource-modelling worksheet you can hand straight to a store manager, get in touch:
- Email: [email protected]
- Phone: 0916-224-047
- LINE: @ufv9089p