Most booking software was built assuming the business and customer share a time zone, a currency, and a language. International service businesses break those assumptions immediately.
The four challenges
- Time zones. Customer in Sydney books a 3pm slot from a New York advisor. Whose 3pm? Both calendars need to display the same moment in their respective zones, with no off-by-one errors at daylight-saving boundaries.
- Currency. Prices in USD on the booking page when the customer thinks in EUR. Some platforms convert at display time; some don’t.
- Language. The booking page text — service names, button labels, confirmation emails — should be in the customer’s language. Most platforms ship in English with limited translations.
- Phone formats. Customer enters +44 7xxx vs +1 555-xxx; the platform should accept all valid international formats and store them in E.164 for SMS.
What good handling looks like
- Time zone: customer’s browser zone detected; booking page shows times in their zone; appointment record stores the moment in UTC; advisor’s calendar renders it in advisor’s zone.
- Currency: prices shown in business currency; optionally show the customer’s local equivalent at point of booking.
- Language: at minimum, customer-facing strings (service names, button labels, confirmation emails) translatable. Ideally per-language template overrides.
- Phone: E.164 storage with international format input.
What Zedule supports
V1 handles:
- Time zones: browser-detected for the customer; business timezone configured per workspace; bookings stored UTC, rendered per-zone.
- Currency: business-currency configured per workspace (USD, EUR, GBP, INR, etc.); displayed on booking page in that currency.
- Phone: international format accepted, stored E.164.
V1 does NOT handle:
- Multi-language UI: the customer-facing booking page is English. V2 roadmap will add localisations for top 10 languages.
- Currency conversion: the booking page shows the business currency only. Customer mentally converts.
What multi-region businesses do today
Two patterns we see work:
Pattern A — Per-region workspaces. A consulting firm with US,
UK, and India offices runs three Zedule workspaces — one per region
with that region’s currency and timezone. URLs:
book.zedule.app/firm-us, firm-uk, firm-in. Customers in each
region book on the regional URL.
Pattern B — One workspace with a global timezone. A solo international advisor sets a single business timezone (often UTC or the advisor’s home zone). Customers from any zone book; their browser shows the time in their zone but the underlying schedule runs on the advisor’s clock.
When to wait for V2 multilanguage
If your customers are predominantly non-English speakers and the booking page being in their language is a deal-breaker, V1 isn’t ready. Cal.com has the deepest multi-language support today; SimplyBook.me also has wide language coverage.