How should a lean GTM team assess outsourced support capacity?
A capacity assessment model for deciding what a lean GTM team should delegate to outsourced support and how to measure the fit.
Question and scope
This protocol asks how a lean GTM team can assess whether outsourced support has enough capacity for a defined scope of work. The scope is one support role or pod covering a set of recurring GTM tasks. The assessment covers demand, available hours, cycle time, quality checks, and the escalation load on the internal team. It does not compare vendors on cost alone.
The method is intended for a team that already has a task list and a small amount of delivery history. It uses time records, queue counts, and quality samples rather than a formal time-and-motion study. The output is a capacity statement with the assumptions and the constraints that could change it. State the task list and the service window before comparing any vendor.
Capacity definitions
Define capacity as the amount of accepted work a support pod can complete in a period at the agreed quality standard. Available hours are not the same as capacity, because training, reviews, and waiting time consume part of the day. Use a utilization assumption that reflects the actual work mix, and state it explicitly. Record the assumption so the capacity number can be challenged and revised.
Separate productive time from elapsed time. A task may take two hours of work but three days to complete because it waits for an approval. Capacity planning should count the productive hours and the queue time separately. Otherwise the team will overestimate what can be delivered within a service window. Count the wait time as a constraint, not as productive capacity.
Demand measures
Measure demand by task type, volume, and arrival pattern. A queue that receives most of its work on Monday needs a different plan from one that receives a steady daily flow. Record the median and peak volume, not only the monthly total. The peak is what determines whether the service window can be met. A monthly total can hide a peak that breaks the service window.
Include the internal effort required to prepare, review, and answer questions. A task that takes the support pod one hour may also take the internal owner twenty minutes of review. If that review time is not counted, the team may approve more work than it can supervise. Measure the internal touch time as part of the total cost of the scope.
Supply and constraint measures
List the constraints that limit the pod's output: access to systems, approval wait time, missing source material, and the number of reviewers. A pod with enough hours but no system access will not deliver. Record the time lost to each constraint and the owner who can remove it. The constraint with the largest lost time is the first improvement target.
Measure quality with a sample of completed work against a written standard. Track the rework rate and the time to correct an error. A high rework rate can consume capacity that the original plan did not include. Do not use output volume alone as a capacity measure, because it can reward speed at the expense of quality.
Sampling and data sources
Use at least four weeks of delivery history, or the full history if the engagement is shorter. Pull task counts, start and end times, review notes, and rework records. If the pod uses a shared queue, export the status history rather than relying on a weekly summary. Keep the raw export for the calculation. Document the export and the date so the calculation can be repeated.
Sample completed tasks by type and reviewer. Include tasks that were returned for correction, not only the accepted ones. If the sample is small, report the count and avoid presenting a precise rate. A short engagement can still provide a useful capacity range if the assumptions are stated clearly. The sample should include returned work, not only the accepted output.
Reporting
Report the scope, the period, the demand volume, the available productive hours, the observed cycle time, and the quality result. Show the calculation in a way a reader can repeat. State the utilization and review assumptions beside the result. A capacity number without assumptions is not actionable. A range is more honest than a single number when the history is short.
Give a range rather than a single number when the data is uncertain. Identify the constraint that most limits the range and the change that would widen it. End with a recommendation to keep, adjust, or stop the scope, and name the owner who will decide. The report should help the team plan, not just describe the past.
Limits and sources of error
Time records are often incomplete, especially for short tasks and interruptions. The pod may round hours, and the internal team may not record its review time. A capacity estimate based on incomplete records should be labeled as an estimate. Do not present it as a measured guarantee. Round the estimate and label it as an estimate when the records are incomplete.
The work mix can change after the assessment, and a new campaign or launch can create a demand spike that the history does not show. The cited public sources describe employment, project management, and security practice; they do not provide a capacity benchmark for this scope. Use the result as a local planning input and revisit it when the work changes. Revisit the estimate when the work mix changes rather than defending the old number.
Review cadence
Review capacity monthly while the scope is stable and after any material change in volume, access, or quality. Compare the observed hours with the plan and record the variance. If the variance is persistent, adjust the scope or the assumptions rather than asking the pod to absorb it silently. Record the variance beside the plan so the reason for the change is visible.
Repeat the assessment when a new task type is added or a reviewer changes. Keep the prior assumptions and the prior result so the team can see what moved. The purpose is a realistic plan with visible constraints, not a one-time justification for a staffing decision. A capacity plan should make the constraint visible, not hide it in an average.
Scope boundaries and handoffs
Write down what the support pod owns and what stays with the internal team. Include the tasks the pod prepares but does not approve, and the questions it must route to a specialist. A clear boundary prevents the pod from absorbing work that requires authority it does not have. It also makes the capacity estimate more honest.
Record the handoff time between the pod and the internal owner. If every task needs a review before it can move, the reviewer is part of the capacity constraint. Measure the review queue separately. A pod that is fast but waits for approval is not delivering at the promised speed. Include the reviewer's queue in the capacity plan.
Quality-adjusted capacity
Adjust the capacity estimate for rework. If a sample of completed work shows a correction rate, add the average correction time to the productive time per task. Use the observed rate rather than a target. Report the range that results from the uncertainty in the sample. Show the correction rate beside the estimate so the reader can see the adjustment.
Do not use quality adjustment to punish the pod. Use it to plan the review and training time that the scope actually requires. If the correction rate is high because the brief is unclear, fix the brief first. Capacity is a property of the whole workflow, not only the person doing the task. The correction rate should trigger a process review, not a performance warning.
What to do with the result
Use the assessment to decide whether to keep the scope, reduce it, or add internal review capacity. If the constraint is access, fix the access. If the constraint is demand spikes, plan a buffer or a slower service window. If the constraint is quality, invest in the brief and the review step. Write the decision and the next review date beside the capacity range.
Set a date to revisit the estimate and name the person who will do it. Keep the assumptions beside the result so the next review can challenge them. A capacity plan that is never revisited becomes a stale promise. The point is a realistic operating plan, not a one-time number. Use the same assumptions so the next comparison is meaningful.