You hired three Filipino VAs to handle customer support.<\/p>\n\n\n\n
On paper, that’s 120 hours of work per week.<\/p>\n\n\n\n
But in reality? You’re getting maybe 90 hours of productive output, tickets are piling up during PTO requests, and you’re constantly wondering if you need to hire another person or if something else is broken.<\/p>\n\n\n\n
The problem isn’t your team. It’s that you’re planning headcount when you should be planning capacity.<\/p>\n\n\n\n
This guide breaks down the difference, shows you how to plan VA pods the right way.<\/p>\n\n\n\n
A VA pod is a stable group of virtual assistants who share workflows, follow the same SOPs, and work toward common KPIs.<\/p>\n\n\n\n
Think of it like a small delivery team, not a bunch of isolated generalists.<\/p>\n\n\n\n
Example pods:<\/p>\n\n\n\n
Pods work because they create coverage, enable backup, and let people specialize instead of trying to do everything.<\/p>\n\n\n\n
When you count heads, you assume everyone works their full contracted hours at 100% productivity.<\/p>\n\n\n\n
A VA on a 40-hour-per-week contract looks like 40 hours of capacity.<\/p>\n\n\n\n
But actual productive time is closer to 25-30 hours after you subtract meetings, breaks, training, PTO, and rework.<\/p>\n\n\n\n
Not all work is equal.<\/p>\n\n\n\n
Processing routine tickets is different from handling escalations. <\/p>\n\n\n\n
Writing blog posts is different from editing them.<\/p>\n\n\n\n
If you plan headcount without understanding what kind of work your pod actually does, you’ll constantly be surprised when things take longer than expected.<\/p>\n\n\n\n
Capacity planning starts with units of work, not hours.<\/p>\n\n\n\n
You define what your team delivers and measure how much they can realistically complete over time.<\/p>\n\n\n\n
Common units for VA pods:<\/p>\n\n\n\n
You track historical throughput to see what your pod actually completes, then use that as the baseline for future planning.<\/p>\n\n\n\n
The formula is simple:<\/p>\n\n\n\n
Demonstrated capacity x utilization target = planned workload<\/strong><\/p>\n\n\n\n If your support pod averages 300 tickets per week and you plan at 75% utilization, you allocate 225 tickets per week and leave the rest as buffer.<\/p>\n\n\n\n That buffer absorbs spikes, covers training, handles incidents, and gives your team breathing room to maintain quality.<\/p>\n\n\n\n Pick the unit that matters most for your pod’s output.<\/p>\n\n\n\n For customer support, it might be tickets per day. For content operations, it might be tasks completed per week or words edited per day.<\/p>\n\n\n\n Then break work into categories:<\/p>\n\n\n\n Many teams underestimate how much time internal work consumes. Track it separately so you don’t accidentally plan like it doesn’t exist.<\/p>\n\n\n\n Start with contracted hours.<\/p>\n\n\n\n If someone is hired for 40 hours per week, write that down.<\/p>\n\n\n\n Now subtract everything that isn’t direct productive work:<\/p>\n\n\n\n What’s left is effective hours. For most VA pods, that’s 5-6 hours per day, not 8.<\/p>\n\n\n\n Multiply effective hours by the number of people in your pod. That’s your pod’s weekly capacity in hours.<\/p>\n\n\n\n Look back at the last 4-8 weeks.<\/p>\n\n\n\n How many units of work did your pod actually complete per week?<\/p>\n\n\n\n If your pod closed an average of 280 tickets per week over the last two months, that’s your baseline capacity.<\/p>\n\n\n\n This number already accounts for meetings, breaks, rework, and all the hidden friction. It’s what your team can realistically deliver under normal conditions.<\/p>\n\n\n\nHow to Build a Capacity Model for Your Pod<\/strong><\/h2>\n\n\n\n
Define Your Units and Work Types<\/strong><\/h3>\n\n\n\n
\n
Calculate Effective Hours Per Person<\/strong><\/h3>\n\n\n\n
\n
Measure Historical Throughput<\/strong><\/h3>\n\n\n\n