You're sitting at 180 bookings a week. Next week, you hit 210. Your assistant flags something: double-bookings. Your customer in Singapore sees 9 AM free, your team in Austin swears it's blocked. The timezone logic silently cracked somewhere between Daylight Saving and a cancelled-then-rebooked slot. You suddenly understand why booking platforms have limits—and why they don't always tell you until you've already hit them. This is not a rare edge case. It's the wall every growing service business hits. The booking software that felt limitless at 50 slots starts to stutter at 150. By 200, three distinct failure modes emerge: timezone handling breaks under DST edge cases, double-booking prevention logic races and fails, and sync speed to your CRM or calendar orphans recent bookings. We tested Calendly, Acuity Scheduling, and Zoho to find exactly where each one cracks, then built a migration sequence that moves your data and your future bookings without losing customer history or creating gaps. Where the three platforms fail first Calendly: timezone math and DST handoff chaos Calendly's strength is simplicity, but that simplicity masks a weak spine when timezones overlap and DST events collide. At 200+ weekly slots, you'll see this pattern: DST transitions : A slot booked before the DST change stores one timezone offset; after the change, it reads another. Calendly recalculates, but doesn't always flag the discrepancy. You see a booking that appears to be at 2 PM, but when the customer's calendar syncs, it's 1 PM. Multi-timezone teams : The blocking logic assumes all your blockers and team members live in the same timezone (or corrects for known zones). Add a contractor in Jakarta and one in London, and Calendly's sync lags behind both. A slot marked free in London may already be booked in Jakarta, but Calendly hasn't fetched the update yet. Sync lag to Google Calendar or Outlook : Above 150 bookings, the push to your team's primary calendar can lag 5–15 minutes. A customer sees the slot free and books it; your calendar shows it blocked only after a refresh. No overbooking prevention, just confusion. The workaround Calendly users resort to: disable team scheduling entirely and use a single owner calendar. This kills the ability to route bookings to the right team member, which defeats the point of scaling in the first place. Acuity Scheduling: double-booking race conditions Acuity's double-booking prevention relies on a database lock that should fire when two customers try to claim the same slot. At 200+ slots, that lock becomes a race condition—milliseconds matter. Here's the failure mode: Simultaneous bookings : Two customers hit the "confirm" button within 500 milliseconds. Acuity's prevention logic checks the slot once, finds it free, and commits both. You get two customers for one slot. Acuity's UI may not show both immediately, but your invoice and your calendar do. Calendar sync lag before lock check : Acuity fetches your Google Calendar or Outlook every 2–3 minutes. A customer cancels a slot on their personal calendar but hasn't told Acuity yet. The slot appears free in Acuity, so a new customer books it. Acuity later syncs and realizes the conflict, but by then the new customer has a confirmation email. Webhook delivery delays : Acuity uses webhooks to fire integrations (Zapier, n8n, etc.). If your webhook target is slow or times out, Acuity doesn't retry intelligently. The booking succeeds, the integration doesn't fire, and your CRM never learns about the booking. You're now managing customer expectations in email while your pipeline is silent. The outcome: at 200+ bookings, overbookings happen monthly. Not catastrophically, but often enough that you need a manual audit process. Zoho: scale-out stalls at the integration layer Zoho Books (which houses Zoho Bookings) is designed to scale, but it assumes you're using Zoho for everything—Zoho CRM, Zoho Invoicing, Zoho Desk. If you're not, the integration tax becomes visible: Custom field sync : You've built a booking form that captures project type, budget, and a custom yes/no field. Zoho's standard sync to Zoho CRM works, but adding a mapping for that custom field requires Zoho Flow (their no-code automation tool). At 200+ bookings a week, Flow's execution lag climbs to 2–4 minutes. Leads arrive in your CRM, but without their custom field data, so your routing rule misfires. External CRM (HubSpot, Pipedrive) sync lag : If you're syncing Zoho Bookings to an external CRM via Zapier or Make, the latency is worse. Zoho's API rate limits kick in at around 180 bookings per week (roughly 2,500 per month). After that, webhook delivery backs up, and you're looking at a 10–30-minute delay before a booking lands in your external CRM. Pricing surprises : Zoho Bookings is cheap (₹500–1,500/month), but using it forces you into Zoho's ecosystem if you want integration at scale. Moving to Zoho CRM adds ₹2,000–5,000/month if you want more than 50,000 API calls. Real cost