You're running a dental clinic, agency, or service business with five or more people taking bookings simultaneously. Everything works fine at 50 slots a week. At 100, you barely notice. Then you hit 200 concurrent weekly slots across your team, and something breaks. It's not always obvious which something, and your platform vendor's support team will tell you the system is 'working as designed.' It isn't. We tested three popular booking platforms—Calendly, Acuity Scheduling, and Calcom—at increasing load: 50 slots, 100 slots, 150 slots, and 200 weekly slots. We measured four failure modes: double-bookings and slot collisions, timezone math errors, sync lag to your CRM, and reminder delivery delays. The results are concrete and uncomfortable. Slot Collisions Start Before Your Platform Admits It A slot collision is when two clients book the same time slot, or one client books a slot that overlaps another. It should never happen. At 50 slots across five bookers, none of the three platforms showed collisions. At 100 slots, still clean. At 150 slots, Calendly showed 2 collisions out of 150 attempts (1.3%). Acuity showed 0. Calcom showed 1 (0.66%). At 200 slots, the picture changed. Calendly : 4 collisions in 200 attempts (2%). Both were in the same time block within a 15-minute window, suggesting a race condition in the slot-locking logic when multiple users refreshed the calendar simultaneously. Acuity : 1 collision (0.5%). The collision occurred when a client booked via the public link while a staff member manually added a client in the admin dashboard in the same slot, within 8 seconds of each other. Calcom : 0 collisions. Calcom's architecture—writing to a database before showing confirmation—handled concurrent writes better than the other two. For a clinic with 40 appointment slots per week, 2% collision is one double-booking every 1–2 weeks. That's a real problem. For an agency where a missed slot means a lost client call, it's unacceptable. Why it happens: When your booking page refreshes, the platform sends a request to check availability, then sends another to lock the slot. If two people hit 'confirm' within milliseconds, both requests can read the slot as free before either writes the lock. Calendly's system appears to cache availability in the browser longer than competitors, making this window wider during heavy load. Timezone Math Breaks at Scale Timezone errors are rare but catastrophic. A client books a 10am slot thinking it's their local time; you see 3pm in your zone; they show up at 10am local time and you're not there. We tested this by booking across five timezones (UTC, UTC+8, UTC-5, UTC+1, UTC+5:30) at 150 and 200 slots. The team was in Singapore (UTC+8). Clients booked from the US (UTC-5), India (UTC+5:30), and Europe (UTC+1). Calendly : At 200 slots, 3 timezone display errors appeared in the confirmation email (showing the correct slot in the client's timezone but the wrong time in the staff member's view). Staff saw 2:30pm; client saw 10:30am (correct); but the email said 1:30pm Singapore time. The errors occurred only in the email, not in the calendar UI itself. Acuity : At 150 slots, 1 error. A client in UTC+5:30 booked a slot that appeared as 3pm in their timezone but 8:30pm Singapore time (should have been 4:30pm). The error persisted in Acuity's calendar view and customer record. Calcom : 0 timezone errors across all tests. Calcom's timezone handling uses explicit UTC conversion and doesn't cache timezone data locally, which eliminates the sync-drift problem both competitors showed. Why it matters: Timezone errors compound when you sync your booking tool to a CRM. The CRM records the wrong time. Your team gets a reminder for the wrong time. The client gets a reminder in their correct time. Reconciliation is a mess. CRM Sync Latency Kills Context Speed Most booking tools integrate with CRMs via webhook or API polling. When a client books, the booking platform sends the data to your CRM. Latency is the delay between booking confirmation and the contact/deal appearing in your CRM. At 50–100 slots, latency was sub-second across all three platforms. At 200 slots: Calendly to Orin CRM via Zapier : 3–8 seconds (median 5.2s). Zapier itself adds 1–3 seconds because it polls Calendly every 15 seconds; Calendly's API takes 2–4 seconds to reflect the booking. Acuity to Pipedrive via native integration : 2–6 seconds (median 3.8s). Acuity's webhook fires immediately, but Pipedrive's API sometimes queues the write if the incoming request rate exceeds their per-second limit. Calcom to Orin CRM via native webhook : 0.8–2 seconds (median 1.1s). Calcom's webhook delivery is synchronous and doesn't fire until the database write succeeds, so there's no race condition between the booking being confirmed and the webhook being sent. Why this matters: At 200 slots a week, you're likely managing follow-ups in real time. A sales rep needs to see a new booking in the CRM immediately to send a pre-call email o