Your service team spans Kuala Lumpur (UTC+8), Singapore (UTC+8), and Jakarta (UTC+7). Same timezone in Malaysia and Singapore, one hour behind in Indonesia. Seems simple. Then you open Calendly's timezone settings and realize the tool was built for US companies with maybe one remote engineer in London. Calendly doesn't break immediately at two timezones—it breaks visibly . The agent's calendar shows "9am Singapore" but the client booking from Jakarta sees 10am. Double-bookings don't happen right away. They happen when your agent forgets which timezone their availability block was set in, or when you add a fourth team member in Bangkok (UTC+7, same as Jakarta) and Calendly's sync logic treats them as separate slots instead of a shared pool. We've tested this across real booking workflows. Here's what actually works, what fails, and the hidden cost of getting timezone math wrong. Why Calendly breaks at two timezones (not three) Calendly's model is simple: one agent, one timezone buffer. You set your working hours in your local timezone. Clients in other timezones see the conversion applied. The system works because Calendly only converts one direction —from the agent's perspective to the client's. But here's where it fails: Calendly doesn't distinguish between a client in Malaysia and a client in Singapore when they're in the same UTC offset. More critically, it doesn't handle shared team scheduling across zones. If your agent works 9am–5pm Kuala Lumpur, and a second agent works 9am–5pm Jakarta, Calendly treats these as two separate availability windows. When a client books at 10am Singapore time, Calendly doesn't know whether to draw from the KL agent's calendar or ask if the Jakarta agent (who is technically still asleep) can take it. Real example: a Malaysian agency we spoke with runs three agents across KL, Singapore, and Jakarta. They used Calendly with a "primary timezone" set to KL. Within six weeks, they had three recorded instances where a client booked a slot that showed as free in the booking widget but was already taken on the agent's Google Calendar. Not system-breaking, but enough to require manual reconciliation after each booking. The issue isn't that Calendly can't math UTC offsets. It's that it doesn't model team scheduling across overlapping but offset zones. Acuity Scheduling: better math, same architectural flaw Acuity Scheduling (owned by Squarespace) handles timezones more explicitly than Calendly. You can set availability by timezone, not just by a single agent profile. It also supports availability rules —you can say "this agent works 9am–5pm Malaysia time, Monday–Friday" and Acuity will correctly block 8am–4pm Singapore slots on the same calendar. But Acuity still assumes one agent per timezone rule, or at least one calendar per agent. If you need to assign rotating agents to a pool—"the next available person in the SEA cluster, regardless of their local timezone"—Acuity requires manual routing logic that sits outside the tool. You either build a Zapier automation to assign slots after booking, or you accept that your booking form asks the client to choose their preferred agent. For a solo operator or a two-person team, Acuity works well. At three agents across three cities, the friction starts. Pricing also tightens: Acuity's per-calendar model means you're paying for three separate calendars (or working around the limitation with shared logins, which breaks reporting). Native calendar + CRM: why most teams actually use this Many service teams in Southeast Asia don't use a dedicated booking tool at all. They use Google Calendar with a shared view, a WhatsApp broadcast list for availability updates, and a spreadsheet to manually block time. This sounds medieval, but it works for a reason: it puts the timezone conversion problem back in human hands, where it's actually solvable. The person in KL knows they're 1 hour ahead of Jakarta. When they tell a client "I'm free Friday 2pm Singapore time," both parties are working from the same reference point. No sync bugs. No double-bookings because the calendar owner manually checks before confirming. The catch: this breaks at scale. At five agents, ten timezones, and fifty weekly bookings, the manual loop becomes a bottleneck. You need someone on the team whose job is partly "check availability and confirm bookings," which is expensive. And you lose the booking link efficiency—clients can't self-serve, so every inquiry requires a human confirmation message. Orin Bookings: cross-timezone team pools and timezone-aware team chat Orin's booking system is built for this specific problem. You create an availability pool , not per-agent calendars. You assign multiple agents to the pool and set each agent's working hours in their own local timezone. When a client books, the system checks which agents are actually available in their local time, not in the client's timezone. It also handles overlapping hours correctly: a 10am Singapore slot can pull fr