Working With a Virtual Assistant Across Time Zones: The Honest Guide

Time zones are the objection I hear most from US and Australian prospects, and it is a fair one. It is also the objection most often answered with marketing rather than arithmetic. Here are the actual numbers and the working patterns that follow from them.

The arithmetic

I work from India, on IST (UTC+5:30). Against the markets I serve:

• Gulf / UAE, 1.5 hours behind. Effectively the same working day.
• South Africa, 3.5 hours behind. Full overlap with a 9–5.
• Central Europe, 3.5 or 4.5 hours behind depending on season. Full overlap.
• UK, 4.5 or 5.5 hours behind. Full overlap with an early start on my side.
• US Eastern, 9.5 or 10.5 hours behind. Partial overlap, requires a genuinely early start from me.
• US Pacific, 12.5 or 13.5 hours behind. Limited overlap.
• Australia Eastern, 4.5 or 5.5 hours ahead. Partial overlap, inverted.

Three of those are non-issues. Three need a deliberate working pattern. Pretending otherwise is how engagements go wrong in month two.

Three patterns that work

Full overlap

For the Gulf, Africa, Europe and the UK, I shift my day and we simply work the same hours. Real-time messaging, same-day turnaround, calls whenever. There is no coordination overhead because there is no gap to coordinate across.

This is the default for those regions and it requires nothing from the client.

Morning overlap plus overnight delivery

For US Eastern and Central, I start early enough to cover roughly 8am–2pm ET. That catches the entire US morning, which is when most coordination actually needs to happen.

The pattern: anything requiring back-and-forth happens in that window. Everything else I work through afterwards, and it lands before the client starts the next day. For US clients this often runs faster than a local hire, because work progresses while they are asleep.

Inverted async

For Australia and US Pacific, the overlap is genuinely thin. Here I set one fixed live window per day, usually the client's early afternoon, for decisions and anything ambiguous. Everything else runs fully async.

This works well for build and project work. It works less well for reactive, interrupt-driven support. If an Australian client needs someone answering the phone at 11am their time, I say so rather than take the engagement and disappoint them.

What makes async actually work

The pattern is only half of it. These practices matter more:

Loom instead of meetings

Anything needing explanation gets a short screen recording. The client watches it whenever suits them. This removes most of the reason to schedule a call across a ten-hour gap, and it has a side benefit: recordings are documentation, so the same explanation serves the next person too.

Written decisions, not verbal ones

Every decision lands in writing in a shared place. Not because anyone is untrustworthy, but because “we agreed on the call” is worthless when the call was eleven hours ago and you are both reconstructing it from memory.

Clear ownership boundaries

The biggest async killer is a task blocked pending approval on something trivial. Agree upfront what your assistant can decide alone, spend up to a limit, reply without review, reschedule without asking. Every boundary you set removes a round trip that would otherwise cost a day.

This is the single highest-leverage thing a client can do, and most under-delegate at the start. That is understandable; it should shrink over the first month as trust calibrates.

One end-of-day summary

Not a status meeting. A short written note: done, in progress, blocked, needs you. The client reads it when they start. It replaces most check-ins entirely.

The overnight advantage

The framing most providers miss is that a time gap is not purely a cost. For any work that does not need real-time collaboration, it means your business is being worked on during hours it would otherwise be idle.

Send a request at 6pm, have it done at 9am. For research, data work, content production, website changes and build tasks, the gap actively helps.

Where it genuinely hurts is interrupt-driven work, live customer support, anything needing a decision inside the hour. Be honest with yourself about which kind you have before optimising for the wrong one.

Public holidays

Indian public holidays rarely coincide with Western ones, which usually works in the client's favour. I follow the client's business calendar for anything client-facing and keep working on build tasks otherwise.

Worth agreeing explicitly at the start rather than discovering it in October.

Questions worth asking any offshore provider

1. What hours will you actually work, in my time zone? Not “flexible.” Specific hours.
2. What is your response time inside and outside those hours?
3. How do handovers work when something needs explaining?
4. What can you decide without me?
5. What happens if something urgent lands outside your window?

A provider with real answers has done this before. A provider who says “we are available 24/7” is describing an intention rather than a rota, and you should find out who is actually awake.

Region-specific working hours are set out here for the US, UK, Europe, the Gulf, South Africa, Australia and Canada.