A Capacity Method for Philippines Time Zone Overlap

Research findings

## Research question How much usable overlap does a Philippines-based team actually provide for a given client time zone, and how should a buyer count it? The unit is one role, one client window, and one week. The method separates clock overlap from available work time and from the decisions the role is allowed to make in that window.

## Map the clocks precisely The Philippines observes Philippine Standard Time, UTC+8, without daylight saving. The client may observe daylight saving, so the overlap can shift by an hour during the year. Build the map for both the standard and daylight-saving periods. Use a single reference such as UTC for the calculation, then display the result in both local times. Do not rely on a recurring calendar invite that was created in one season. Check the actual dates for the observation week. Record the transition dates in the table so a shift that looks covered in March is not assumed to be covered in November.

## Subtract the non-working time An eight-hour shift is not eight hours of customer-facing capacity. Subtract breaks, internal meetings, training, administration, and the time required to read and write handoffs. Subtract the part of the shift that falls outside the client's need window. For a role that handles live calls, also subtract the time between calls and the after-call work. The result is a realistic overlap figure. Present the assumptions so the buyer can challenge them.

## Separate channels and decision rights A text channel can be covered asynchronously. A live call cannot. An approval that requires the client owner cannot happen when that owner is asleep, even if the Philippines team is online. List the work by channel and by decision type. Mark each item as live, same-day asynchronous, or next-day. Then check whether the overlap supports the promised service. A team can have six hours of clock overlap and still be unable to approve a refund after 5 p.m. client time.

## Count the handoff cost If the model relies on a handoff, include the time to write, read, and acknowledge it. A handoff at the end of the Philippines shift may land in the client's morning, which is useful for asynchronous work. A handoff in the middle of a live incident is expensive. Measure the number of handoffs per request and the time lost to clarification. A capacity model that ignores handoff cost will overstate the benefit of a split shift.

Discussion

## Build a weekly capacity table For each role, list the shift start and end in both zones, the client need window, the usable overlap, the channels covered, and the decisions available. Multiply by the number of working days, then subtract planned leave and holidays. Show a range rather than a single number. A range that reflects real variability is more useful than a precise figure that assumes every seat is filled. Update the table when the client's daylight saving changes.

## Test with a sample week Choose a representative week and compare the planned capacity with the actual arrivals and responses. Look for work that arrived outside the covered window, work that waited for a decision, and handoffs that required clarification. Ask the team where the model felt wrong. Adjust the assumptions and rerun. The purpose is not to produce a perfect forecast. It is to make the tradeoffs explicit before the service promise is written.

Implications and limits

## Limitations A capacity table cannot predict a major incident, a surge, or an individual absence. It also cannot capture the value of asynchronous work that happens outside the overlap. The model depends on accurate shift data and a stable client window. Daylight-saving rules can change. Treat the output as a planning aid, not a contractual guarantee. Recheck it at least twice a year and whenever the roster or client coverage changes. If a client operates in several regions, build a separate table for each region and do not average the overlap into a single figure that hides the hardest window.

## Decision use Use the table to answer three questions: which work needs live overlap, which can be asynchronous, and which decisions need an owner in the client's time zone. If the answer requires more overlap than the team has, change the promise or the authority, not just the schedule. The goal is a service design that the team can actually deliver.

## Reporting Present the calculation with the UTC reference, both local windows, the standard and daylight-saving periods, the usable hours, the channels covered, the decisions available, and the handoff estimate. Show the assumptions in a separate column. A reader should be able to change one assumption and see how the result moves. That transparency is more useful than a polished total that hides the tradeoff. Add a short note on the work that falls outside the table, such as asynchronous tasks that the team can complete without overlap.